Table of Contents
5 Escalados
Descripción general
Con las escaladas puedes crear escenarios personalizados para enviar notificaciones o ejecutar comandos remotos.
En términos prácticos, esto significa que:
- Los usuarios pueden ser informados sobre nuevos problemas de inmediato.
- Las notificaciones pueden repetirse hasta que el problema se resuelva.
- El envío de una notificación puede retrasarse.
- Las notificaciones pueden escalarse a otro grupo de usuarios "superior".
- Los comandos remotos pueden ejecutarse inmediatamente o cuando un problema no se resuelve durante un período prolongado.
Las acciones se escalan en función del paso de escalada. Cada paso tiene una duración en el tiempo.
Puedes definir tanto la duración predeterminada como una duración personalizada de un paso individual. La duración mínima de un paso de escalada es de 60 segundos.
Puedes iniciar acciones, como enviar notificaciones o ejecutar comandos, desde cualquier paso. El paso uno es para acciones inmediatas. Si deseas retrasar una acción, puedes asignarla a un paso posterior. Para cada paso, se pueden definir varias acciones.
El número de pasos de escalada no está limitado.
Las escaladas se definen al configurar una operación. Las escaladas solo son compatibles para operaciones de problema, no de recuperación.
Aspectos varios del comportamiento de la escalada
Consideremos lo que sucede en diferentes circunstancias si una acción contiene varios pasos de escalada.
| Situación | Comportamiento |
|---|---|
| El equipo en cuestión entra en mantenimiento después de que se envía la notificación inicial del problema | Dependiendo de la opción Pausar operaciones para problemas suprimidos en la configuración de la acción, todos los pasos de escalada restantes se ejecutan ya sea con un retraso causado por el período de mantenimiento o sin retraso. Un período de mantenimiento no cancela las operaciones. |
| El período de tiempo definido en la condición de acción Período de tiempo termina después de que se envía la notificación inicial | Se ejecutan todos los pasos de escalada restantes. La condición Período de tiempo no puede detener las operaciones; tiene efecto respecto a cuándo se inician/no se inician las acciones, no las operaciones. |
| Un problema comienza durante el mantenimiento y continúa (no se resuelve) después de que finaliza el mantenimiento | Dependiendo de la opción Pausar operaciones para problemas suprimidos en la configuración de la acción, todos los pasos de escalada se ejecutan ya sea desde el momento en que finaliza el mantenimiento o inmediatamente. |
| Un problema comienza durante un mantenimiento sin datos y continúa (no se resuelve) después de que finaliza el mantenimiento | Debe esperar a que se dispare el disparador, antes de que se ejecuten todos los pasos de escalada. |
| Diferentes escaladas se suceden en rápida sucesión y se superponen | La ejecución de cada nueva escalada reemplaza la escalada anterior, pero al menos un paso de escalada siempre se ejecuta en la escalada anterior. Este comportamiento es relevante en acciones sobre eventos que se crean con CADA evaluación de problema del disparador. |
| Durante una escalada en curso (como el envío de un mensaje), según cualquier tipo de evento: - la acción se deshabilita Según evento de disparador: - el disparador se deshabilita - el equipo o la métrica se deshabilita Según evento interno sobre disparadores: - el disparador se deshabilita Según evento interno sobre métricas/reglas de descubrimiento de bajo nivel: - la métrica se deshabilita - el equipo se deshabilita |
El mensaje en curso se envía y luego se envía un mensaje más en la escalada. El mensaje de seguimiento tendrá el texto de cancelación al principio del cuerpo del mensaje (NOTA: Escalada cancelada) indicando el motivo (por ejemplo, NOTA: Escalada cancelada: acción '<Nombre de la acción>' deshabilitada). De esta manera, el destinatario es informado de que la escalada se cancela y no se ejecutarán más pasos. Este mensaje se envía a todos los que recibieron las notificaciones antes. El motivo de la cancelación también se registra en el archivo de registro del servidor (a partir de Nivel de depuración 3=Advertencia). Tenga en cuenta que el mensaje Escalada cancelada también se envía si las operaciones han finalizado, pero las operaciones de recuperación están configuradas y aún no se han ejecutado. |
| Durante una escalada en curso (como el envío de un mensaje) la acción se elimina | No se envían más mensajes. La información se registra en el archivo de registro del servidor (a partir de Nivel de depuración 3=Advertencia), por ejemplo: escalada cancelada: acción id:334 eliminada |
Ejemplos de escalado
Ejemplo 1
Envío de una notificación repetida cada 30 minutos (5 veces en total) a un grupo "Administradores de MySQL". Para configurar:
- En la pestaña Operaciones, establezca la Duración por defecto del paso de operación en "30m" (30 minutos).
- Establezca los Pasos de escalado desde "1" hasta "5".
- Seleccione el grupo "Administradores de MySQL" como destinatarios del mensaje.
Las notificaciones se enviarán a las 0:00, 0:30, 1:00, 1:30, 2:00 horas después de que comience el problema (a menos que, por supuesto, el problema se resuelva antes).
Si el problema se resuelve y se configura un mensaje de recuperación, se enviará a quienes hayan recibido al menos un mensaje de problema dentro de este escenario de escalado.
Si el disparador que generó una escalada activa es deshabilitado, Zabbix envía un mensaje informativo al respecto a todos aquellos que ya han recibido notificaciones.
Ejemplo 2
Envío de una notificación retrasada sobre un problema prolongado. Para configurar:
- En la pestaña Operaciones, establezca la Duración por defecto del paso de operación en "10h" (10 horas).
- Establezca los Pasos de la escalada desde "2" hasta "2".
Solo se enviará una notificación en el Paso 2 del escenario de escalada, o 10 horas después de que comience el problema.
Puede personalizar el texto del mensaje a algo como "El problema tiene más de 10 horas".
Ejemplo 3
Escalando el problema al Jefe.
En el primer ejemplo anterior configuramos el envío periódico de mensajes a los administradores de MySQL. En este caso, los administradores recibirán cuatro mensajes antes de que el problema se escale al responsable de la base de datos. Tenga en cuenta que el responsable recibirá un mensaje solo en caso de que el problema aún no haya sido reconocido, suponiendo que nadie está trabajando en él.
Detalles de la Operación 2:
Observe el uso de la macro {ESC.HISTORY} en el mensaje personalizado. La macro contendrá información sobre todos los pasos ejecutados previamente en esta escalada, como notificaciones enviadas y comandos ejecutados.
Ejemplo 4
Un escenario más complejo. Después de múltiples mensajes a los administradores de MySQL y la escalada al gerente, Zabbix intentará reiniciar la base de datos MySQL. Esto ocurrirá si el problema existe durante 2:30 horas y no ha sido reconocido.
Si el problema aún existe, después de otros 30 minutos Zabbix enviará un mensaje a todos los usuarios invitados.
Si esto no ayuda, después de otra hora Zabbix reiniciará el servidor con la base de datos MySQL (segundo comando remoto) usando comandos IPMI.
Ejemplo 5
Una escalada con varias operaciones asignadas a un paso y con intervalos personalizados utilizados. La duración por defecto del paso de operación es de 30 minutos.
Las notificaciones se enviarán de la siguiente manera:
- A los administradores de MySQL a las 0:00, 0:30, 1:00, 1:30 después de que comience el problema.
- Al gestor de base de datos a las 2:00 y 2:10. (y no a las 3:00; dado que los pasos 5 y 6 se superponen con la siguiente operación, la duración personalizada más corta del paso de 10 minutos en la siguiente operación anula la duración más larga del paso de 1 hora que se intentó establecer aquí).
- A los administradores de Zabbix a las 2:00, 2:10, 2:20 después de que comience el problema (la duración personalizada del paso de 10 minutos funcionando).
- A los usuarios invitados a las 4:00 horas después de que comience el problema (la duración por defecto del paso de 30 minutos vuelve entre los pasos 8 y 11).