Hola, ¿qué tal? ¿Cómo estás? Espero que todo vaya muy bien.
Download transcript (.srt)
0:00
0:02
0:06
0:10
0:17
0:26
0:28
0:32
0:36
0:39
0:45
0:49
0:53
0:59
1:09
1:21
1:30
1:46
1:53
2:07
2:14
2:28
2:36
2:40
2:49
2:56
3:04
3:10
3:14
3:22
3:39
4:00
4:18
4:25
4:30
4:35
4:41
4:44
5:03
5:18
5:37
5:53
6:01
6:08
6:16
6:22
6:27
6:29
6:35
6:38
6:42
6:45
6:49
6:52
6:56
6:59
7:01
7:05
7:12
7:16
7:23
7:29
7:38
7:42
7:44
7:50
7:55
7:59
8:02
8:05
8:11
8:13
8:22
8:25
8:34
8:39
8:41
8:44
8:46
8:48
8:50
8:55
8:58
9:01
9:03
9:06
9:13
9:16
9:21
9:27
9:32
9:37
9:39
9:41
9:44
9:46
9:48
9:50
9:51
9:54
9:56
9:58
10:00
10:01
10:05
10:05
10:13
10:20
10:29
10:33
10:37
10:41
10:46
10:49
10:54
10:57
11:01
11:05
11:08
11:13
11:17
11:20
11:22
11:26
11:27
11:33
11:36
11:41
11:46
11:50
11:53
11:57
12:04
12:11
12:18
12:24
12:31
12:39
12:46
12:55
13:01
13:05
13:07
13:11
13:17
13:20
13:24
13:36
13:39
13:40
13:49
13:53
13:57
14:02
14:04
14:08
14:13
14:17
14:21
14:25
14:27
14:28
14:30
14:31
14:36
14:38
14:43
14:45
14:46
14:47
14:52
14:54
14:57
15:01
15:05
15:10
15:12
15:16
15:20
15:23
15:28
15:31
15:33
15:38
15:40
15:41
15:44
15:47
15:49
15:54
16:04
16:09
16:17
16:34
16:44
16:51
16:58
17:05
17:12
17:22
17:36
17:53
18:08
18:16
18:41
19:00
19:06
19:14
19:18
19:25
19:28
19:36
19:47
19:53
20:06
20:13
20:16
20:26
20:32
20:46
20:49
20:51
20:53
20:55
20:57
20:59
21:00
21:03
21:05
21:06
21:09
21:11
21:13
21:15
21:27
21:36
21:43
21:51
21:54
21:58
21:59
Te saluda Alex Ávalos y te doy la bienvenida a Panel de Control,
el podcast para quienes quieren tener el control de su propio servidor
y disfrutar de las ventajas del Hosting VPS.
En el caso de que tu servidor VPS deje de funcionar, se caiga, quede offline,
¿cómo te enteras?
Si no tienes monitoreo, te puedes enterar de dos formas.
La primera forma es que un cliente te escriba,
¡Ey! ¡Mis webs no me cargan!
Y la segunda sería que vos mismo intentas entrar horas después
y ves que todo ha dejado de funcionar.
Ambas opciones son malas, muy malas,
Porque significa que el servidor estuvo caído y vos ni te enteraste.
Estuviste durante ese momento que estuvo caído perdiendo visitas, perdiendo ventas y por supuesto perdiendo credibilidad.
Si tenés un sistema de monitoreo, si algo llegara a pasar, en lugar de enterarte por casualidad, te enterás inmediatamente.
Un servicio de monitoreo revisa tu servidor cada minuto o como vos lo configurez, puede ser cada cinco minutos también.
Y si no responde, te envía una alerta que puede ser un correo, un mensaje SMS o por medio de la app de Telegram o de Slack o una notificación push, como sea, la que hayas vos configurado.
Y en el momento que te llega esa alerta, vos podés tomar cartas en el asunto.
Antes de los sustos, antes de los disgustos, antes de que alguien lo note, antes de que afecte a tus clientes y antes de que se vuelva un problema.
Por eso es muy importante hablar del monitoreo básico.
Al hablar de monitoreo, lo primero que se nos viene a la cabeza es la siguiente pregunta. ¿Qué tengo que monitorear? Porque claro, uno piensa en tanto y al final no hace nada.
Lo primero que es muy bueno que sepas es que no necesitas monitorizarlo, monitorearlo todo.
O por lo menos en un inicio no es necesario.
Siempre es recomendable comenzar con lo más básico, con lo que es humanamente posible para vos en un inicio.
Y luego ir subiendo de nivel, ir rizando un poquito más el rizo, irlo complicando un poco más.
Pero para que tengas una idea en lo que tienes que monitorizar, lo primero es el uptime.
Es decir, ¿está vivo el servidor? ¿Están vivas las webs?
Esto es lo más básico. El servidor responde sí o no.
Y esto se hace con un ping, P-I-N-G, simple, que puede ser cada minuto o cada cinco minutos.
Si no responde a este ping tres veces seguidas, entonces tu sistema de monitoreo te va a enviar una alerta. Y esto quiere decir que el servidor está caído porque ha intentado hacer el ping y no hay respuesta.
O también puede ser que la red tenga problemas. O puede ser que tu proveedor tiene un incidente. O si utilizas herramientas de tercera como Cloudflare, puede ser que también haya un problema de ese lado. El tema es que ya sea por uno o por otro, en ese momento no responde.
¿Qué más monitorizar? El HTTP, HTTPS, es decir, la web carga. El servidor puede estar funcionando correctamente, pero el web server, el servidor web en Jinx, Apache, Lightspeed, Cadi, puede estar caído.
Monitorizar que tu sitio web responda correctamente es una muy buena idea.
Pero con esto también es importante tener claro que no solo es que responda,
sino que responda bien con el código correcto, con el contenido esperado.
Porque hay errores que la página carga, pero carga un error.
Puede ser, para que te hagas una idea, con WordPress.
Carga, porque sí carga, pero carga un mensaje que dice error de conexión con la base de datos. O sea, que la web está cargando, pero no está cargando bien. Y si devuelve errores 500 o páginas en blanco, ¡guau! Mal plan, porque significa que hay un error del lado del servidor.
¿Qué más? El tiempo de respuesta. Y en esto vamos a comenzar a hilar fino, porque monitorear o monitorizar no solo es comprobar si responde, sino que revisar qué tan rápido responde.
Si tu web normalmente carga en 500 milisegundos y de repente una y otra vez que haces el chequeo, el monitoreo automatizado, tarda 5 minutos, 5 segundos, 7 segundos, 4 segundos.
Ahí algo está mal. Y esto puede ser ya sea por alto tráfico, por problemas, por ejemplo, con la base de datos o con un archivo, plugin, extensión.
puede ser que tus recursos estén a tope, puede ser que el CPU está a 100 porque ha quedado en bucle algo que no logró resolver.
El caso es que este monitoreo de tiempo de respuesta te avisa antes de que las cosas fallen,
antes de que la web se caiga, antes que la saturación de recursos, vote la base de datos, vote tu servidor web.
Es decir, te avisa cuando aún hay algo que se pueda hacer.
Cuarto detalle, cosa que tenés que monitorizar.
El SSL.
La pregunta es, ¿el certificado SSL está vigente?
Para que te hagas una idea, los certificados SSL gratuitos,
Lesson Crip, expiran cada 90 días.
Si se vence, si expira tu certificado,
tu sitio va a dejar de cargar en HTTPS.
Los navegadores van a mostrar una advertencia de seguridad.
Van a decir, uy, este sitio no es seguro.
En ese momento, tus visitas van a volar.
Se van a ir.
Si has hecho bien tus tareas, no va a cargar ni eso.
Va a mostrar un error de SSL porque lo ideal es no cargar nada en HTTP.
Todo en HTTPS y si no, bloquear.
Por lo que entonces tendrías un hermoso error relacionado con el SSL.
Yo te recomiendo monitorizar que tu certificado SSL no esté por vencer.
Y estés pendiente con 15 días de anticipación para renovarlo.
Quinto y último punto que debes de monitorizar.
Los puertos específicos.
Si corres servicios específicos, monitoriza esos puertos específicos,
como cuáles, el puerto 22 o el que usés para el SSH,
el puerto 3306 para la base de datos.
Yo no te recomiendo crearte tu propia solución de correo,
pero bueno, cada proyecto es como es y puede ser que necesites.
El caso es que el puerto 25, 587 y 993 son el estándar
para lo que tiene que ver con el correo.
Pero además también te recomiendo verificar si necesitas un puerto específico para tu panel de control, también monitorizarlo.
Aquí va a depender mucho de lo que necesites.
El tema cuál es? Que si el puerto no responde, el servicio está caído y entonces tenés que ponerte manos a la obra.
Y esto, claro, al verlo así, cualquiera pensaría, vaya faena, no?
¿Tener que estar pendiente de esto?
¿Estarlo viendo? ¿Tener abierta la terminal?
Pues sí y no.
Hay herramientas de monitoreo y hay varias.
Hay muchas opciones.
Desde gratuitas hasta nivel empresarial enterprise.
La gratis, aunque también tiene una capa de paga,
pero la que puede ser gratis y un muy buen punto de partida
es Uptime Robot.
Es gratuita hasta 50 monitores.
Es decir que tu servidor, tus webs, los puertos, la base, o sea, tenés un montón.
Muy, muy, muy recomendable para comenzar.
Vos podés configurar las URLs o lo que necesitas monitorizar.
Eso sí, en la cuenta gratuita este chequeo lo hace cada cinco minutos, suficiente para comenzar.
Y si algo falla o algo no responde, te manda un correo.
Simple, efectivo y funciona sin complicaciones.
otra alternativa que a mí me gusta mucho
es lo auto alojado
el self hosting
¿por qué? porque así en un servidor
vos tenés montado tu propio sistema
tenés tus datos
tenés tu propia información
y no estás compartiendo esto con terceros
y algunas veces estas herramientas
te piden instalar
un script o un demon
para poder conectarte
y ahí estás abriendo una potencial
puerta
a un problema. Si algo le pasa a la empresa, como tiene conexión directa con tu servidor,
algo puede pasar. Por eso yo soy muy, muy de auto alojarme en mis servicios y el más sencillo,
herramienta fácil y rápido que casi solo es de instalar y usar, es UptimeKuma. Si quieres,
digamos que tener un poco más de control que Uptime Robot,
puedes instalarte UptimeKuma en un VPS o también lo puedes
contratar en Pikapods. Así te ahorras toda la parte técnica, pero tenés
tu propia UptimeKuma. UptimeKuma es open source,
gratis y vas a tener vos el control total de la herramienta.
El dashboard es simple, bastante simple, pero
completo. Vas a poder personalizar alertas, notificaciones
a Discord, Slack, Telegram, correo, etc.
Y como UptimeKuma también te puedo recomendar Checkmate
y te recomiendo también Tianji.
De hecho, en mi podcast SalsaTec en el episodio 89
titulado "Un nuevo comienzo con Tiangi"
hablé largo y tendido de esta herramienta
que es un todo en uno.
Monitoreo, Uptime, analítica, páginas de estatus,
te lo recomiendo.
Si por el contrario no te va el self-hosting, te queda corto,
opt-time robot, una de las alternativas muy potentes
con una calidad-precio muy buena es Better Stack.
Esto, claro, es si buscas algo más robusto.
Esta herramienta es muy buena, tiene un plan gratuito
y su plan de pago comienza desde 29 dólares al mes.
Vas a tener monitoreo desde múltiples ubicaciones,
eso es genial por si tu proyecto tiene clientes en diferentes puntos del mundo. También vas a tener,
por supuesto, las páginas de estatus, la gestión de incidentes, alertas inteligentes y claro, esto
si te viene bien y si tienes el presupuesto, vale la pena invertir en herramientas como esta.
Y bueno, ya sea la herramienta que sea, ya la escogiste, la pusiste a punto, ya tenés todo
funcionando y de repente te llega un correo, te llega una notificación, te llega un mensaje.
¿Qué hacer con estas alertas? Porque ya te montaste todo y si ya tienes todo montado y
te van a llegar las alertas y las vas a ignorar, hombre, mal plan. Recibir alertas está bien,
pero si no haces nada, si no haces algo cuando te llegan, no sirve de nada, my friend.
Por ejemplo, una alerta de Uptime del servidor caído.
Yo te recomiendo primero que verifiques si es real,
porque a veces se dan falsos positivos,
ya sea porque tu implementación de seguridad lo bloquea,
porque la herramienta de Uptime tuvo un hipo.
Yo te recomiendo que revises, ¿es real o no?
Entra, haz el chequeo desde otro punto,
Usa una VPN o pregunta directamente a alguien de tu equipo o del proveedor, en el panel del proveedor, en la página de estatus del proveedor.
Intenta entrar por SSH.
Verificar.
O sea, aquí con la alerta, lo primero en el caso de Uptime del servidor es revisar, verificar si es real.
Y si es real, hay que revisar qué pasó.
¿El servidor se reinició? ¿Por qué?
¿El problema, el proveedor tiene un incidente? ¿Cuál?
Ya lo solucionaron.
¿Está sufriendo un ataque? ¿Qué hago?
Se debe responder siempre dependiendo del tipo de incidente.
Por eso yo te recomiendo hacer una lista de los posibles casos
y prepararte para saber qué tienes que hacer si sucede.
Por ejemplo, si el proveedor tiene un incidente, ¿qué tengo que hacer?
Ah, tengo que escribir al correo.
¿A cuál correo?
¿Puedo llamar por teléfono?
¿A cuál número?
Porque cuando suceda, tengas todo caído y comiencen a llamarte y a escribirte a tus clientes.
Eh, ¿qué pasó? ¿Qué pasó? ¿Qué pasó?
En ese momento no es el momento para ir a ver a dónde tengo que escribir.
No.
Otro.
Siguiente.
Alerta de tiempo de respuesta lento.
conéctate al servidor, revisar los recursos.
¿El CPU está bien o está a tope?
¿La RAM tenés libre o está full?
¿El disco tiene espacio disponible o está lleno?
Lo primero es intentar identificar qué proceso está consumiendo los recursos
y luego decidir.
¿Lo detenés? ¿Necesita más recursos?
¿Y esto que está sucediendo es tráfico legítimo
o estás siendo víctima de un ataque.
En el caso de la alerta del SSL,
porque está por vencer o porque ya venció,
por supuesto, inmediatamente,
renova el certificado y hacelo inmediatamente.
No lo dejes para después.
En el caso del Let's Encrypt,
en la gran mayoría de paneles,
el proceso de renovación de los certificados SSL
es automático.
Pero si por alguna razón la renovación falló, hacelo manual.
Pero en ese momento no te va a quitar más de 5 minutos y es mejor dejarlo hecho, resuelto que tener que volver después.
Claro, hasta el momento hemos hablado del monitoreo externo.
Te dice si el servidor desde afuera responde, pero no te dice qué está pasando dentro.
Para eso vas a necesitar un monitoreo interno y ahí a la cosa cambia. De entrada lo que vas a tener que revisar son los recursos del sistema. Monitorizar el consumo del CPU, el consumo de RAM, el consumo de disco, el consumo de la red.
Si la CPU está constantemente al 90%, vas a tener que tomar cartas en el asunto porque vas a tener problemas pronto.
Si la RAM está a tope, vas a necesitar ampliar si es que es lo necesario,
porque algunas veces está siendo atacada una web o tenés problemas con alguna web.
Si el disco está al 90% de su capacidad, urge ya sea limpiar o aumentar.
Con esto es importante tener claro que la opción, la mejor opción, no siempre es aumentar recursos a la primera.
Se tiene que evaluar en cada caso si de verdad estás utilizando los recursos o te están intentando hackear.
Además, también en el monitoreo interno, lo que te va a dar la vida y tienes que estar muy atento son los logs del sistema. Los logs te dicen todo. Errores, accesos, problemas, potenciales ataques.
No hace falta ponerte a leer todo porque es demasiado, pero hay herramientas que te ayudan a investigar y te muestran de forma muy visual patrones que te alertan que están sucediendo cosas raras.
Por ejemplo, errores 500, intentos fallidos de SSH o servicios que sin por qué ni para qué repentinamente caen, se desconectan, se apagan.
Con este monitoreo interno también es muy buena idea estar siempre atento a los servicios críticos.
Si por ejemplo vos corres, ejecutas, trabajas con servicios específicos, yo te recomiendo monitorizar, siempre estar pendiente de tu web server, de tu servidor de base de datos, es decir, de Nginx, Apache, Lightspeed, Cadi, de MySQL, MariaDB, PostgreSQL, Mongo, lo que uses.
Con este punto lo que tenés que tener presente es eso crítico. Para esto existen herramientas que pueden revisar y reiniciar automáticamente si algo se cae, mientras te notifican. Yo te recomiendo darle una mirada en este punto a Monit.
Ya estamos llegando al final del episodio y para cerrar veamos los errores comunes.
Porque siempre es mejor aprender de los errores de los demás y no sufrirlo todo en nuestras carnes.
Error número uno. Monitorizar solo desde una ubicación.
Tus servidores pueden estar caídos solo para cierta región por temas que se escapan a tu control.
Por ejemplo, LaLiga Cloudflare en España.
por ejemplo. Por eso es muy recomendable monitorizar desde por lo menos dos ubicaciones.
Error número dos. Demasiadas alertas. Si recibís 50 alertas por día, va a llegar un momento en el que las vas a comenzar a ignorar.
Y luego, cuando algo grave suceda, pues te va a dar lo mismo. Vas a pensar, nada, otra vez.
Por eso es muy buena idea configurar los umbrales con criterio y activar solo alertas que realmente sean importantes.
No todo, no todo debe revisarse y alertarse cada 60 segundos.
Error número 3. No probar las alertas.
Vos podés configurar el monitoreo, pero si nunca verificas que las alertas lleguen, algo va a pasar y no te vas a enterar.
Las herramientas de monitoreo, de uptime, tienen la opción para hacer una prueba.
Y si no, es muy fácil. Desconecta, apaga, reinicia tu servidor, desactiva tu web y ahí vas a ver si las alertas llegan.
Error número 4
monitorizar sin actuar
sin tomar cartas en el asunto
de nada sirve monitorizar
si no vas a hacer nada
ni con las alertas
ni con la información
de nada sirve
y bueno vamos cerrando esta terminal
y te recuerdo
el monitoreo no es opcional
up time tiempo de respuesta
SSL
es muy necesario
Yo te recomiendo utilizar servicios externos, montarte tu propia herramienta y tomar cartas en el asunto cuando recibas alguna alerta porque algo está pasando.
En el próximo episodio ya vamos a hablar de implementar, de crearte tu primer sitio web en tu VPS.
Y vamos a ver desde el servidor en blanco hasta tener algo ya corriendo en producción.
Si tienes alguna duda, alguna pregunta, me quieres hacer algún comentario, no te voy a dar mi IP, pero sí la URL:
paneldecontrol.org/contacto
¿Qué te parece si nos conectamos en el próximo episodio?
Espero que sí.
¡Salú!