avargas

Algunas veces en el trabajo discutimos sobre la exactitud de las alertas de los sistemas de monitoreo (sensu, datadog, nagios, opsview, etc), de lo ruidosos que pueden ser, como mejorarlos, bromeamos, etc.

La última conversación de esas que recuerdo fue sobre el uso de CPU de unas instancias en un cluster ECS, yo traté de ilustrar mis ideas usando una analogía y creo que le sería útil a otras personas, especialmente si son managers, directores, etc (que usualmente son los que demandan aumentar el número de alertas), aquí vamos:

Supongamos que ud compra un bus con 10 asientos para trabajar en el, ud quiere obviamente obtener ganancias, ser eficiente y además quiere monitorear la ocupación del bus para saber cuando es la hora de añadir capacidad y ofrecer un buen servicio (suponiendo que ampliar el bus para añadir asientos no fuera un problema).

En este caso, ud es el dueño del bus y además es el conductor, es el on-call.

Qué hace para resolver el problema de saber cuando es hora de añadir capacidad?

1. Pone una señal de alerta ruidosa en el bus que se encienda cada vez que hayan 9 asientos ocupados?
2. Revisa regularmente (semanalmente, mensualmente, etc) el uso y añade capacidad a medida que haya mas demanda?

Yo creo que a esta altura ya se nota cuál es mi punto, y ojalá sea claro como aplica la analogía, en todo caso la respuesta que espero es que prefiere la segunda opción.

Por qué no elegir la primera opción?

• Desperdicia recursos, ud lo que quiere es llenar ese bus, vender todos los asientos, qué sentido tiene alertar cuando esta siendo eficiente?
• Fatiga, las personas aprendemos rápidamente a ignorar las señales de alerta si vemos que no hay consecuencias, sí la primera noche de la rotación de on-call alguien recibe una alerta, y cuando la atiende ve que no hay nada que pueda hacer o que se resuelve sola y no pasó nada, esa persona lo más probable es que nunca más le vuelva a dar importancia, incluso en los casos en los que sí hay problemas (y además le va a contar a las otras personas de la rotación).
• No es accionable, que puede hacer ud para solucionar el problema si suena la alerta? se va a aguantar la alerta toda una semana sonando cada que tenga 9 pasajeros hasta que finalmente pueda añadir capacidad? va a bajar los pasajeros para que dejen de sonar? va a desactivar la alerta y adiós monitoreo?

Hay usos legítimos para una alerta mientras opera su bus si se cumple con las condiciones de que sea accionable y que realmente indique que hay un problema que le impide prestar el servicio:

• Excedió el límite de velocidad.
• Arrancó y hay gente de pie.
• etc

Ahora bien no se trata de no monitorear, ud aun necesita saber cuantos pasajeros llevaba determinado día a determinada hora, a que velocidad iba, etc, pero no tiene que ponerle a todo un alerta y puede por ejemplo enviar un email.

Yo sospecho que si ud ha estado en una rotación de on-call por un tiempo ya sabrá estas cosas de manera intuitiva, porque ya las experimentó, en todo caso si hice un mal trabajo con la analogía, el punto que quería exponer es:

• Es válido recoger métricas sobre un fenómeno y no alertar.
• Si va a alertar que sea por algo que afecta el negocio, si puede esperar hasta la mañana mas bien envíe un email.
• Si va a alertar que sea por algo que tenga arreglo y/o runbook, si el on-call no puede hacer nada para qué una alerta? (admito que este punto en particular es difícil de vender, management siempre querrá a alguien revisando la mas mínima señal de problemas)
• Si todo es urgente al final nada es urgente.

Punto Extra

Cuando diseñe una alerta y su correspondiente runbook, imagínese que el que la va a recibir es nuevo en su equipo y le va a sonar a las 2:00 AM cuando no hay nadie con más experiencia para ayudarle.

Ahora si vaya y cree esa alerta.