3 Escalonamento
Visão geral
Com o recurso de escalonamento você pode criar cenários personalizados de quando enviar uma mensagem ou executar um comando remoto.
Situações comuns de utilização:
- Usuários precisam ser informados sobre novos incidentes imediatamente
- Notificações precisam ser reenviadas enquanto o incidente não for resolvido
- O envio de uma notificação precisa ser atrasado
- As notificações precisam ser escalonadas para um grupo mais especializado
- Comandos remotos podem ser executados imediatamente, entretanto, só é desejada a execução automática se o incidente não for resolvido em determinado tempo
- Mensagens de recuperação precisam ser enviadas
Ações são escaladas usando os passos de escalonamento. Cada passo pode ter sua própria duração.
Você pode definir tanto a duração padrão quanto a duração de um passo em específico, o tempo mínimo em ambos os casos é de 60 segundos.
A ação pode começar com uma operação simples de envio de notificação ou execução de comando remoto. O primeiro passo é para ações imediatas, se você precisa atrasar a operação, atribua a ela um número de passo superior ao 1. Para cada passo diferentes operações podem ser definidas.
Não existe limite de passos de escalonamento.
O escalonamento é definido durante a configuração das operações.
Aspectos diversos sobre escalonamento
Vamos considerar que uma mesma ação contenha diversos passos de escalonamento para diferentes situações.
| Situação | Comportamento |
|---|---|
| O host em questão entra em manutenção após a notificação do início do incidente ser enviada | Todos os escalonamentos restantes serão executados. O processo de manutenção programada não para as operações, afeta somente o início / fim das ações e se uma ação já está em execução ela não será afetada pela manutenção. |
| O Intervalo definido na condição da ação termina após a notificação inicial ser enviada | Todos os passos subsequentes de escalonamento são executados. A condição de Intervalo não termina com as operações; esta condição afeta o início das ações, não das operações. |
| Um incidente inicia durante um período de manutenção e continua como não solucionado após o final da manutenção | Todos os passos de escalonamento são executados a partir do momento final da manutenção. |
| Um problema inicia durante um período de manutenção sem coleta de dados e continua como não resolvido após a manutenção terminar | Será necessário aguardar que a trigger seja disparada, antes que os processos de escalonamento sejam executados. |
| Diferentes escalonamentos com estreita sucessão e sobreposição | A execução de cada novo escalonamento substitui o anterior, mas pelo menos um passo de escalonamento sempre será executado no escalonamento anterior. Este comportamento é relevante em ações sobre eventos que são criados em todas as mudanças para o estado de incidente em triggers. |
| Uma ação é desabilitada durante o processo de escalonamento (durante o processo de envio de mensagem por exemplo) | A mensagem atual e a próxima mensagem do escalonamento ainda serão enviadas. A mensagem seguinte terá o seguinte texto no início do corpo: NOTE: Escalation cancelled: action '<Action name>' disabled. Isso ocorre para que o destinatário saiba o motivo pelo qual o escalonamento não será executado. |
Exemplos de escalonamento
Exemplo 1
Enviando uma notificação repetida a cada 30 minutos (até um máximo de 5) para o grupo 'MySQL Administrators':
- Na aba Operações, defina a Duração padrão do passo da operação para '1800' segundos (30 minutos)
- Defina os passos do escalonamento de '1' ate '5'
- Selecione o grupo 'MySQL Administrators' como destinatário da mensagem

Nofificações serão enviadas, contando a partir do momento que o incidente inicia, às 00:00, 0:30, 1:00, 1:30, 2:00 horas (a não sere que o incidente seja resolvido antes).
Se o problema for resolvido e uma mensagem de recuperação for configurada, esta será enviada a todos que receberam pelo menos uma das mensagens do escalonamento.
Se a trigger que gerou o escalonamento for desabilitada, o Zabbix enviará uma mensagem sobre isso para todos que já receberam alguma notificação.
Exemplo 2
Enviando uma notificação com atraso, informando um longo período de problema:
- Na aba de Operações, defina a Duração padrão do passo da operação para '36000' segundos (10 horas)
- Defina os passos do escalonamento de '2' ate '2'

A notificação irá aguardar até que o cenário 2 ocorra (neste caso 10 horas após o início do incidente).
Você pode customizar esta mensagem, por exemplo, para algo como: 'O incidente já ocorre a mais de 10 horas'.
Exemplo 3
Escalando o problema para o chefe.
No primeiro exemplo acima nós configuramos o envio periódico de mensagens para o grupo 'MySQL administrators'. Agora vamos configurar para que os Administradores recebam quatro mensagens de notificação antes do problema ser escalado para o gerente de bancos de dados. Observe que o gerente só receberá a mensagem se o problema não tiver sido reconhecido também (o que indica, teoricamente, que ninguém está tratando o incidente).

Observe o uso da macro {ESC.HISTORY} na mensagem, ela conterá informações sobre todos os passos que já ocorreram. Neste caso as notificações enviadas e os comandos executados.
Exemplo 4
Um cenário mais complexo. Após múltiplas mensagens ao grupo 'MySQL administrators' e ter escalado o problema ao gerente, o Zabbix irá tentar reiniciar o banco de dados MySQL. Isso irá ocorrer se o problema já existir a mais de 2:30 horas e não tiver sido reconhecido.
Se o problema ainda existir, após outros 30 minutos, o Zabbix irá enviar uma mensagem para todos os usuários convidados.
Se isso não ajudar, após outra hora, o Zabbix irá reiniciar o servidor com o banco MySQL (um segundo comando) usando o protocolo IPMI.

Exemplo 5
Um escalonamento com diversas operações associadas a um passo e durações diferentes. A operação padrão é de 30 minutos.

As notificações serão enviadas conforme descrito a seguir:
- Para o grupo 'MySQL administrators' às 0:00, 0:30, 1:00, 1:30 após o problema começar
- Para o grupo 'Database manager' às 2:00 e 2:10 (não às 3:00; vendo que os passos 5 e 6 se sobrepõe com a próxima operação, a menor duração de passo configurada é de 600 segundos e por isso o passo corrente teve o passo sobreposto)
- Para o grupo 'Zabbix administrators' às 2:00, 2:10, 2:20 após o problema iniciar (a duração customizada de 600 segundos funcionou)
- Para o grupo 'Convidados' 4:00 horas após o problema iniciar (a duração padrão de 30 minutos retornando entre os passos 8 e 11)