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 determinada.

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 operaciones de problema, no de recuperación.

Aspectos varios del comportamiento de escalamiento

Consideremos qué sucede en distintas circunstancias si una action contiene varios pasos de escalamiento.

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 configuración Pause operations for suppressed problems en la configuración de la action, todos los pasos de escalamiento restantes se ejecutan 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 action Time period* termina después de que se envía la notificación inicial*	Se ejecutan todos los pasos de escalamiento restantes. La condición Time period no puede detener las operaciones; afecta a cuándo se inician o no se inician las actions, no a las operaciones.
Un problema comienza durante un mantenimiento y continúa (no se resuelve) después de que el mantenimiento termina	Según la configuración Pause operations for suppressed problems en la configuración de la action, todos los pasos de escalamiento se ejecutan desde el momento en que termina el mantenimiento o inmediatamente.
Un problema comienza durante un mantenimiento sin datos y continúa (no se resuelve) después de que el mantenimiento termina	Debe esperar a que se dispare el trigger antes de que se ejecuten todos los pasos de escalamiento.
Diferentes escalamientos se suceden en rápida sucesión y se solapan	La ejecución de cada nuevo escalamiento sustituye al escalamiento anterior, pero al menos un paso de escalamiento siempre se ejecuta en el escalamiento anterior. Este comportamiento es relevante en actions sobre eventos que se crean con CADA evaluación del problema del trigger.
Durante un escalamiento en curso (como el envío de un mensaje), según cualquier tipo de evento: - la action se deshabilita Según un evento de trigger: - el trigger se deshabilita - el host o item se deshabilita Según un evento interno sobre triggers: - el trigger se deshabilita Según 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 en el escalamiento. El mensaje de seguimiento tendrá el texto de cancelación al principio del cuerpo del mensaje (NOTE: Escalation canceled) indicando el motivo (por ejemplo, NOTE: Escalation canceled: action '<Action name>' disabled). De este modo, el destinatario es informado de que el escalamiento 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 log 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 aún no se han ejecutado.
Durante un escalamiento en curso (como el envío de un mensaje), la action se elimina	No se envían más mensajes. La información se registra en el archivo de log del server (a partir de Debug Level 3=Warning), por ejemplo: `escalation canceled: action id:334 deleted`

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 que tienen rangos de pasos superpuestos e intervalos personalizados. La duración por defecto de los pasos 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 Recibir notificaciones sobre métricas no soportadas

Docs

5 Escalados

Resumen