Explica los errores de ingeniería que supone alertar sobre métricas de utilización de recursos en lugar de latencia y tasas de error orientadas al usuario.
Son las 3:15 de la mañana. Su teléfono vibra con un incidente de alta prioridad en PagerDuty: CRÍTICO: Utilización de CPU del servidor API > 95 %. Abre su portátil, consulta el dashboard de Grafana y nota que, aunque la CPU subió bruscamente durante 4 minutos, la tasa de errores HTTP 500 se mantuvo en 0 % y la latencia de la API permaneció completamente estable.
Confirma la alerta, suspira profundamente y vuelve a dormir. Acaba de experimentar la definición de libro de texto de una alerta terrible.
Durante décadas, el monitoreo de infraestructura ha dependido en gran medida de métricas de utilización como la CPU y la memoria. Pero en la era de los microservicios en contenedores y la infraestructura de nube con autoescalado, alertar sobre el consumo de recursos es un antipatrón. Este artículo explora por qué.
Para entender por qué seguimos configurando alertas de umbral de CPU, debemos remontarnos a la era de los servidores bare-metal. Cuando tenía un único servidor de base de datos en un rack, una CPU al 99 % significaba que la máquina no tenía margen de cómputo. Si el tráfico aumentaba aunque sea ligeramente, el servidor inevitablemente se bloqueaba.
La arquitectura de nube moderna funciona de manera diferente. Desplegamos explícitamente grupos de autoescalado para maximizar la utilización de recursos y reducir los costes de computación en la nube. Si un nodo funciona constantemente al 40 % de CPU, está sobreaprovisionado. En realidad quiere que los nodos operen eficientemente cerca de sus límites, permitiendo que el escalado horizontal gestione el exceso.
Cuando la capa de orquestación gestiona el flujo, una CPU alta es señal de un sistema saludable y rentable, no una emergencia.
Al diseñar una alerta, debe diferenciar entre la causa de un problema y el síntoma que experimentan los usuarios.
Un pico de memoria elevado es una causa (o un estado subyacente). Un usuario que recibe un error 502 Bad Gateway es un síntoma (el dolor real).
Si un cron job en segundo plano consume el 100 % de la CPU de un nodo durante dos minutos procesando un archivo grande, pero se ejecuta en una cola de workers dedicada, el usuario experimenta exactamente cero degradación de rendimiento. Alertar a un ingeniero por esto genera ruido puro.
Por el contrario, un deadlock en su base de datos podría consumir solo el 5 % de la CPU de la base de datos, pero detener todas las transacciones de los usuarios. Si solo alerta sobre CPU, perderá completamente la interrupción crítica.
Examinemos tres escenarios comunes en los que los picos de utilización de recursos generan falsos positivos:
En lenguajes como Java o Go, los picos de memoria intermitentes son esperados a medida que se asignan objetos antes de que una pausa del GC los limpie. Activar alertas de memoria basadas en estas formas de onda en diente de sierra es notoriamente inestable.
Una copia de seguridad nocturna de la base de datos o la rotación de registros naturalmente requiere un intenso I/O de disco y CPU. A menos que impida las funciones principales de la aplicación, no justifica una alerta.
Un flujo repentino de conexiones gravará inmediatamente la CPU a medida que se negocian los handshakes TLS y se calientan los grupos de conexiones. Mientras la aplicación escale automáticamente de manera efectiva en unos minutos, la saturación breve es un procedimiento operativo estándar.
Las alertas de pager deben reservarse exclusivamente para las "Señales Doradas": Latencia, Tráfico, Errores y Saturación.
En lugar de: CPU > 90 %
Alerte sobre: Latencia P99 > 1500 ms durante 5 m
Si la CPU alcanza el 99 % pero la latencia se mantiene de forma segura por debajo de su umbral de 1500 ms, deje que el equipo duerma.
En lugar de: Memoria > 85 %
Alerte sobre: Tasa de Errores HTTP 5xx > 2 %
Si una fuga de memoria eventualmente provoca reinicios de pods que resultan en solicitudes descartadas, la alerta de tasa de errores 5xx capturará el síntoma y alertará al equipo con precisión.
Las métricas de CPU y memoria no son inútiles — simplemente no son dignas del pager.
Estas métricas pertenecen a dos lugares:
Deje de crear calendarios de guardia basados en la salud de la infraestructura. Constrúyalos en torno a la salud de los usuarios. Al eliminar los umbrales de hardware brutos y comprometerse con alertas de latencia y error basadas en síntomas, los ingenieros sufren menos fatiga y confían en las alertas que realmente se activan.
La transición requiere telemetría externa confiable. Plataformas como Heimdall monitorizan exactamente lo que el usuario experimenta — aplicando alertas basadas en latencias HTTP reales y capacidades reales de resolución DNS — lo que permite a los equipos desactivar de forma segura las ruidosas reglas de umbral de CPU dentro de sus clusters.
Heimdall Observer fue construido para proteger su infraestructura digital. Comience hoy con alertas en tiempo real, análisis detallados y monitoreo confiable.
Comienza Gratis
Ingeniero sénior de confiabilidad de sistemas (SRE) enfocado en la disponibilidad, respuesta a incidentes y construcción de sistemas de monitoreo que revelen problemas antes de que los usuarios lo noten.
