Redactar alertas con evidencia y una vía de respuesta

Una alerta útil muestra qué falla en una aplicación y cuál es la primera vía de respuesta prevista. Su destinatario debe entenderla sin tener que adivinar el servicio a partir de un nombre de servidor desconocido.

Partir de la tarea del usuario

Empiece por una tarea importante, como cargar la lista de proyectos de un portal de clientes. Para servicios interactivos, Prometheus recomienda, entre otras señales, errores visibles para el usuario y vistas adecuadas para investigar causas. La utilización de recursos puede aportar contexto; no explica por sí sola si funciona la lista.

Defina qué solicitudes y respuestas entran en la medición. Los reintentos son solicitudes adicionales, no necesariamente más personas afectadas. La tasa de error necesita un denominador claro.

Una alerta de ejemplo cumplimentada

El equipo, las mediciones y las reglas siguientes son ficticios. No representan un incidente de ASES, umbrales universales ni un compromiso de soporte. El denominador incluye todas las solicitudes registradas para la operación indicada. La regla evalúa una ventana de 5 minutos, sin exigir un tiempo adicional de permanencia.

Aquí se superan tanto el mínimo de solicitudes como el umbral de error. El 20 % describe solicitudes de esta ventana. No demuestra una proporción equivalente de usuarios afectados ni una causa concreta.

Preparar la primera respuesta

El runbook es una guía breve para el diagnóstico previsto. Primero, la persona responsable confirma que asume el caso y comprueba si persiste el problema. Esa confirmación no significa que el fallo esté resuelto. Los filtros iniciales deben conservar el mismo servicio, operación y periodo.

Después se delimitan las instancias, versiones y dependencias afectadas. Un despliegue a las 09:08 sería aquí un evento que investigar, no una prueba de causalidad. Revertir requiere una vía adecuada y comprobada previamente; la alerta no autoriza reinicios o cambios arbitrarios.

Comprobar también la vía de notificación

Alertmanager puede agrupar alertas similares y dirigirlas a destinatarios configurados. Las instancias afectadas deben seguir visibles. Los problemas independientes no deben fusionarse solo porque sus nombres se parezcan.

Con una notificación claramente marcada como prueba, compruebe también recepción, asunción del caso y respaldo previsto. Prometheus pide explícitamente supervisar el propio sistema de supervisión. Unas mediciones normalizadas pueden terminar el estado de alerta; no sustituyen la comprobación de la tarea ni el análisis de causas. Las respuestas exitosas pero incorrectas para el negocio o las respuestas lentas no quedan cubiertas solo por esta regla de errores de servidor.

Fuentes

• Google SRE — Monitoring Distributed Systems

• Prometheus — Alerting best practices

• Prometheus — Alertmanager

• GitLab — Incident Diagnosis in a Symptom-based World