En un entorno de nube, ¿sobre qué alertas y qué te limitas a registrar?

Alerta sobre síntomas que un cliente notaría y sobre los que una persona pueda actuar ahora mismo, normalmente ligados a tus objetivos de servicio: tasas de error elevadas, latencia que rompe el objetivo, una cola creciendo sin límite, una copia de seguridad fallida. Registra y pon en paneles todo lo demás, incluidas las métricas de recurso individuales como la CPU, que son útiles para diagnosticar pero malas como disparador. Si la respuesta a una alerta es reconocerla y volver a dormir, debería ser un ticket.

Mi listón son tres cosas: hay un cliente afectado o a punto de estarlo, es urgente, y hay algo que una persona puede hacer ahora mismo. Si alguna de esas es falsa, es un ticket o un panel. Así que tasa de error por encima del objetivo, latencia rompiendo el objetivo, una cola creciendo sin límite, el checkout fallando, eso avisa. La CPU al ochenta por ciento no, porque podría estar perfectamente sana y no me dice nada sobre si alguien está sufriendo; su sitio es un panel para cuando estoy diagnosticando. Alertar sobre causas en vez de síntomas es como acabas con cuarenta alertas para un solo incidente y un equipo que ha silenciado el canal. Hay excepciones que siempre mantengo: la caducidad de certificados, porque está oculta hasta que es catastrófica, los fallos de copia de seguridad, y los límites duros de cuota acercándose, ya que las tres son silenciosas justo hasta que te arruinan la semana. Y reviso las alertas de forma periódica, mirando qué saltó y qué hizo alguien al respecto. Todo lo que salta a menudo y nunca lleva a una acción se borra o se degrada, porque un busca ruidoso es peor que no tener busca.