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 de inmediato o cuando un problema no se resuelve durante un período prolongado.

Las acciones se escalan en función del paso de escalación. Cada paso tiene una duración de tiempo.

Puede definir tanto la duración predeterminada como una duración personalizada de un paso individual. La duración mínima de un paso de escalación es de 60 segundos.

Puede iniciar acciones, como enviar notificaciones o ejecutar comandos, desde cualquier paso. El paso uno es para acciones inmediatas. Si desea retrasar una acción, puede asignarla a un paso posterior. Para cada paso, se pueden definir varias acciones.

El número de pasos de escalación no está limitado.

Las escalaciones se definen al configurar una operación. Las escalaciones son compatibles solo con las operaciones de problema, no con las de recuperación.

Aspectos varios del comportamiento de la escalación

Consideremos qué sucede en distintas circunstancias si una acción contiene varios pasos de escalación.

Situación	Comportamiento
El host en cuestión entra en mantenimiento después de que se envía la notificación inicial del problema	Según la opción Pause operations for suppressed problems en la configuración de la acción, todos los pasos restantes de la escalación 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 Time period* finaliza después de que se envía la notificación inicial*	Todos los pasos restantes de la escalación se ejecutan. La condición Time period no puede detener las operaciones; tiene efecto con respecto a cuándo se inician o 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	Según la opción Pause operations for suppressed problems en la configuración de la acción, todos los pasos de la escalación se ejecutan ya sea desde el momento en que finaliza el mantenimiento o inmediatamente.
Un problema comienza durante un mantenimiento de ausencia de datos y continúa (no se resuelve) después de que finaliza el mantenimiento	Debe esperar a que el trigger se active antes de que se ejecuten todos los pasos de la escalación.
Diferentes escalaciones se suceden en rápida sucesión y se superponen	La ejecución de cada nueva escalación sustituye a la escalación anterior, pero siempre se ejecuta al menos un paso de escalación de la escalación anterior. Este comportamiento es relevante en acciones sobre eventos que se crean con CADA evaluación de problema del trigger.
Durante una escalación en curso (por ejemplo, mientras se envía un mensaje), basada en cualquier tipo de evento: - la acción se deshabilita Basada en un evento de trigger: - el trigger se deshabilita - el host o el item se deshabilita Basada en un evento interno sobre triggers: - el trigger se deshabilita Basada en un evento interno sobre items/reglas de descubrimiento de bajo nivel: - el item se deshabilita - el host se deshabilita	El mensaje en curso se envía y luego se envía un mensaje más de la escalación. El mensaje de seguimiento tendrá el texto de cancelación al comienzo del cuerpo del mensaje (NOTE: Escalation canceled) indicando el motivo (por ejemplo, NOTE: Escalation canceled: action '<Action name>' disabled). De esta forma, se informa al destinatario de que la escalación se ha cancelado y de que no se ejecutarán más pasos. Este mensaje se envía a todos los que recibieron las notificaciones anteriormente. El motivo de la cancelación también se registra en el archivo de registro del server (a partir de Debug Level 3=Warning). Tenga en cuenta que el mensaje Escalation canceled también se envía si las operaciones han finalizado, pero las operaciones de recuperación están configuradas y todavía no se han ejecutado.
Durante una escalación en curso (por ejemplo, mientras se envía 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 server (a partir de Debug Level 3=Warning), por ejemplo: `escalation canceled: action id:334 deleted`

Ejemplos de escalamiento

Ejemplo 1

Envío de una notificación repetida una vez cada 30 minutos (5 veces en total) a un grupo de "Administradores de MySQL". Para configurar:

En la pestaña Operaciones, establezca la Duración del paso de operación predeterminada en "30 m" (30 minutos).
Establezca los Pasos de escalado para que sea del "1" al "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 el problema comienza (a menos, por supuesto, que el problema se resuelva antes).

Si el problema se resuelve y se configura un mensaje de recuperación, se enviará a aquellos que recibieron al menos un mensaje de problema dentro de este escenario de escalada.

Si el iniciador que generó un escalado activo es desactivado, 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 de larga duración. A configurar:

En la pestaña Operaciones, establezca la Duración del paso de operación predeterminada en "10h" (10 horas).
Establezca los Pasos de escalado para que sea de "2" a "2".

Solo se enviará una notificación en el Paso 2 del escenario de escalado, o 10 horas después de que comience el problema.

Puede personalizar el texto del mensaje con 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 obtendrán cuatro mensajes antes de que el problema se escale al administrador de la base de datos. Tenga en cuenta que el administrador recibirá un mensaje sólo en caso de que el problema no se. haya reconocido, supuestamente nadie está trabajando en ello.

Detalles de la Operación 2:

Tenga en cuenta 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 escalamiento al administrador, Zabbix intentará reiniciar MySQL base de datos. Sucederá si el problema existe durante 2:30 horas y se no ha sido reconocido.

Si el problema persiste, 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 que tienen rangos de pasos superpuestos e intervalos personalizados. La duración por defecto de cada paso de la 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 y 1:30 después de que comience el problema.
Al administrador de la base de datos a las 2:00 y 2:10 (la duración de paso personalizada más corta de 10 minutos definida en la operación posterior anula la duración de paso más larga de 1 hora configurada aquí, como se describe en Detalles de la operación para Duración del paso cuando los pasos se superponen).
A los administradores de Zabbix a las 2:00, 2:10 y 2:20 después de que comience el problema (se aplica la duración de paso personalizada de 10 minutos).
A los usuarios invitados a las 4:00 después de que comience el problema (la duración de paso por defecto de 30 minutos entra en vigor entre los pasos 8 y 11).

What’s next?

3 Recibiendo notificaciones sobre métricas no soportadas

Docs

5 Escalado

Resumen