It’s easy to just set thresholds to every possible monitored metric and add an alarm to it. But that could lead to fatigue, distractions, and also ignoring alerts, see Las alertas deben ser muy específicas. Es fácil simplemente establecer umbrales para cada métrica monitoreada posible y agregarle una alarma. Pero eso podría provocar fatiga, distracciones y también ignorar alertas, consulte este articulo para obtener más detalles.
Las alertas nunca deben ignorarse, incluso si cree que tiene una idea de qué las causó.
Para obtener buenos consejos sobre las alertas en general, consulte “My Philosophy on Alerting”.
Pager Duty
VictorOps
Hay una práctica en cada servicio en la nube, llamada "estar de guardia". Eso significa que, en algún momento, hay una persona responsable de reaccionar ante las alertas, independientemente de cuándo sucedan.
Eso significa estar listo para actuar en medio de la noche, los fines de semana, etc. Esa es una posición tediosa y agotadora, por lo que es mejor rotar a las personas con frecuencia en eso.
Un ejemplo de la política de guardia se puede encontrar en este GitLab On-Call Handbook.
¿Qué buscar primero?
¿Está el nodo en funcionamiento? ¿El cliente del validador está funcionando? ¿CPU/RAM/espacio en disco está bien?
Lea los registros. ¿Hay suficientes peers? ¿El número de validadores encontrado por el cliente del validador es el esperado?
¿Está su nodo sincronizado/se está sincronizando? Si es así, ¿está en el fork correcto ? Tome /v1/beacon/headers/head API y verifíquelo con cualquier explorador de bloques público o en una comunidad.
¿Se está finalizando la red? eth/v1/beacon/headers/finalized API -- debe moverse cada 6,2 minutos.
La fuga de inactividad significa que su nodo fue elegido para realizar una determinada tarea (certificar el cabezal de la cadena o producir un bloque) y no hizo su trabajo a tiempo.
Las fugas de inactividad tienen penalizaciones relativamente pequeñas. Degradarán el rendimiento del Validador en términos de rendimiento anual. Eso significa que tiene alguna opción sobre cómo manejarlos:
Reaccione lo antes posible: utilícelo si tiene un equipo de DevOps adecuado y desea optimizar el rendimiento del nodo y el mejor APY posible. Asegurar rotaciones regulares en el equipo de guardia.
Reaccione solo durante el "horario comercial", pero los fines de semana, solo notifique, digamos, de 9:00 a 21:00 todos los días. Eso reduce en gran medida la tensión en el personal de guardia.
Reaccione solo durante el horario comercial, igual que (2), pero no notifique los fines de semana.
Posibles ataques de red
¿A qué canales comunicarse si cree que se trata de un ataque a la red?
Posible vulnerabilidad
¿A qué canales comunicarse si se trata de una posible vulnerabilidad?
Explicación de las alertas básicas que deben incorporar (slots retrasados, baja tasa de participación, tiempos de procesamiento de bloques, etc.)
¿Por cuánto tiempo almacenar los datos?
Recomendación genérica sobre mejores prácticas de alertas/métricas
¿Qué buscar primero? ¿Cuándo da la alarma? Primeros pasos requeridos durante la respuesta a la incidencia.