Monitorización: Parte 1 — ¿Para qué sirve y qué medir?

Monitoreo — es la recopilación y el análisis continuos de datos sobre el funcionamiento de servidores, redes, bases de datos y aplicaciones. Su objetivo es conocer un problema antes que los usuarios: ver que se está terminando el espacio en disco, que aumenta el número de errores o que se ha ralentizado la respuesta del sitio, y poder intervenir antes de que el servicio deje de funcionar.

Para qué sirve el monitoreo

• Detección temprana de problemas. La mayoría de las averías se desarrollan gradualmente: un disco se llena en varios días, la memoria se fuga en varias horas. El monitoreo muestra esas tendencias con antelación.
• Búsqueda de cuellos de botella. Los datos sobre la carga de CPU, memoria, discos y el tiempo de respuesta de la base de datos muestran qué es lo que limita el rendimiento.
• Planificación de recursos. Por el historial de métricas se ve cuándo hará falta un servidor más potente o un disco adicional.
• Recuperación rápida. Cuanto antes llegue la alerta y cuanto más detallados sean los datos sobre la falla, más rápido se soluciona.
• Seguridad. Un aumento brusco del tráfico, de los intentos fallidos de acceso o de las conexiones salientes puede ser indicio de un ataque.

Tipos de monitoreo

• Sistémico — carga de CPU, memoria, discos, red, tiempo de actividad de servidores y máquinas virtuales.
• De red — estado de routers y switches, pérdida de paquetes, latencias, ocupación de canales.
• Monitoreo de aplicaciones (APM) — tiempo de respuesta, consultas a la base de datos, excepciones dentro del código.
• Monitoreo desde el punto de vista del usuario — acciones reales de los visitantes (RUM) y comprobaciones sintéticas, cuando un servicio externo abre el sitio regularmente desde distintas regiones y mide disponibilidad y velocidad.

Qué medir: tres enfoques probados

Se pueden recopilar miles de métricas, pero hay que alertar solo sobre unas pocas. Para no ahogarse en datos se usan metodologías ya establecidas.

Cuatro señales doradas. Los ingenieros de Google en el libro sobre SRE distinguen cuatro indicadores para los servicios con los que interactúan los usuarios:

• latencia — tiempo de procesamiento de la solicitud; las solicitudes exitosas y las fallidas deben contarse por separado: una respuesta rápida con error no debe mejorar el valor medio;
• tráfico — carga sobre el sistema, por ejemplo el número de solicitudes HTTP por segundo;
• errores — proporción de solicitudes fallidas: explícitas (código 500), implícitas (código 200 con contenido incorrecto) y las que violan las reglas (respuesta más larga que el umbral establecido);
• saturación — cuánto está “lleno” el sistema, principalmente respecto al recurso más limitado.

Método USE (Brendan Gregg) se aplica a recursos — CPU, memoria, discos, red. Para cada recurso se verifican tres cosas: uso (qué fracción del tiempo el recurso estuvo ocupado), saturación (cuánto trabajo espera en cola) y errores. Según el autor, dicha comprobación encuentra la mayor parte de los problemas en servidores con un coste de tiempo reducido.

Método RED (Tom Wilkie, 2015) — para servicios que procesan solicitudes: rate (frecuencia) de solicitudes, errores y duración del procesamiento. Si se construyen paneles según RED para cada servicio, todos lucen igual y la persona de guardia entiende incluso un servicio que no escribió ella.

En la práctica, USE describe los servidores, y RED y las señales doradas describen los servicios en ellos.

Alertas sin ruido innecesario

El error más frecuente al implantar monitoreo es tener demasiadas alertas. En una semana dejan de leerse, y una avería real se pierde entre falsas alarmas. Varias reglas ayudan a evitarlo.

• Cada alerta debe requerir una acción. En las recomendaciones de Google SRE se dice: si a una alerta se puede responder de forma mecánica, no debe despertar a una persona. Esos casos se automatizan o se convierten en informes.
• Alertar sobre síntomas, no sobre causas. Al usuario le importa que el sitio responda con error o sea lento, no que la CPU esté al 90 %. Una alta carga sin impacto en el servicio es motivo para mirar el gráfico, pero no para despertar al responsable de guardia por la noche.
• Añadir retardo antes de disparar. La condición debe mantenerse unos minutos antes de que llegue la alerta: los picos breves no deben causar alarma.
• Separar niveles de importancia. Alertas críticas — al mensajero o por teléfono 24/7; avisos — al chat de trabajo o a un informe.
• Agrupar. Si cae un switch, no hacen falta veinte mensajes por cada servidor detrás de él — basta uno.
• Revisar las reglas. Una alerta que en un mes no ha llevado nunca a una acción debe desactivarse o rehacerse.

La mayoría de sistemas de monitoreo envían alertas a Telegram, por correo, por SMS y a servicios de guardia.

Herramientas del ciclo

• Munin — sistema sencillo con gráficos listos para varios servidores.
• Prometheus, Node Exporter y Grafana — recolección de métricas bajo demanda, lenguaje de consultas flexible y alertas vía Alertmanager.
• Zabbix — sistema “todo en uno”: agentes, plantillas, alertas e interfaz web en un solo producto.
• VictoriaMetrics — almacenamiento económico de métricas, compatible con Prometheus, para retención a largo plazo y grandes volúmenes.

Un ejemplo de cómo se ve el monitoreo en un parque grande — en el artículo sobre cómo automatizar la gestión de 366 servidores.