[comment]: # ({bbb0e074-bbb0e074})
# 5 Escalações
[comment]: # ({/bbb0e074-bbb0e074})
[comment]: # ({5d89a227-3bb564c1})
#### Visão geral
Com escalonamentos, você pode criar cenários personalizados para enviar
notificações ou executar comandos remotos.
Em termos práticos, isso significa que:
- Os usuários podem ser informados sobre novos problemas imediatamente.
- As notificações podem ser repetidas até que o problema seja resolvido.
- O envio de uma notificação pode ser adiado.
- As notificações podem ser escalonadas para outro grupo de usuários "superior".
- Comandos remotos podem ser executados imediatamente ou quando um problema não for
resolvido por um longo período.
As ações são escalonadas com base na **etapa de escalonamento**. Cada etapa tem uma
duração de tempo.
Você pode definir tanto a duração padrão quanto uma duração personalizada de uma
etapa individual. A duração mínima de uma etapa de escalonamento é de 60
segundos.
Você pode iniciar ações, como enviar notificações ou executar
comandos, a partir de qualquer etapa. A etapa um é para ações imediatas. Se você quiser
adiar uma ação, poderá atribuí-la a uma etapa posterior. Para cada etapa,
várias ações podem ser definidas.
O número de etapas de escalonamento não é limitado.
Os escalonamentos são definidos ao [configurar uma
operação](operation#configuring-an-operation). Os escalonamentos são
compatíveis apenas com operações de problema, não de recuperação.
[comment]: # ({/5d89a227-3bb564c1})
[comment]: # ({8493a88c-362c7cc2})
##### Aspectos diversos do comportamento de escalonamento
Vamos considerar o que acontece em diferentes circunstâncias se uma ação
contiver várias etapas de escalonamento.
|Situação|Comportamento|
|---------|--------|
|*O host em questão entra em manutenção após o envio da notificação inicial do problema*|Dependendo da configuração *Pause operations for suppressed problems* na [configuração](/manual/config/notifications/action/operation#configuring-an-operation) da ação, todas as etapas restantes do escalonamento são executadas com um atraso causado pelo período de manutenção ou sem atraso. Um período de manutenção não cancela operações.|
|*O período definido na condição de ação **Time period** termina após o envio da notificação inicial*|Todas as etapas restantes do escalonamento são executadas. A condição *Time period* não pode interromper operações; ela tem efeito em relação a quando as ações são iniciadas/não iniciadas, não às operações.|
|*Um problema começa durante a manutenção e continua (não é resolvido) após o fim da manutenção*|Dependendo da configuração *Pause operations for suppressed problems* na [configuração](/manual/config/notifications/action/operation#configuring-an-operation) da ação, todas as etapas de escalonamento são executadas a partir do momento em que a manutenção termina ou imediatamente.|
|*Um problema começa durante uma manutenção sem dados e continua (não é resolvido) após o fim da manutenção*|É necessário aguardar que o trigger seja acionado antes que todas as etapas de escalonamento sejam executadas.|
|*Diferentes escalonamentos ocorrem em rápida sucessão e se sobrepõem*|A execução de cada novo escalonamento substitui o escalonamento anterior, mas pelo menos uma etapa de escalonamento sempre é executada no escalonamento anterior. Esse comportamento é relevante em ações sobre eventos que são criados a CADA avaliação de problema do trigger.|
|*Durante um escalonamento em andamento (como o envio de uma mensagem), com base em qualquer tipo de evento:
- a ação é desabilitada
Com base em evento de trigger:
- o trigger é desabilitado
- o host ou item é desabilitado
Com base em evento interno sobre triggers:
- o trigger é desabilitado
Com base em evento interno sobre itens/regras de descoberta de baixo nível:
- o item é desabilitado
- o host é desabilitado*|A mensagem em andamento é enviada e, em seguida, mais uma mensagem do escalonamento é enviada. A mensagem de acompanhamento terá o texto de cancelamento no início do corpo da mensagem (*NOTE: Escalation canceled*), informando o motivo (por exemplo, *NOTE: Escalation canceled: action '' disabled*). Dessa forma, o destinatário é informado de que o escalonamento foi cancelado e que nenhuma outra etapa será executada. Essa mensagem é enviada a todos que receberam as notificações anteriormente. O motivo do cancelamento também é registrado no arquivo de log do server (a partir de [Debug Level](/manual/appendix/config/zabbix_server) 3=Warning).
Observe que a mensagem *Escalation canceled* também é enviada se as operações forem concluídas, mas as operações de recuperação estiverem configuradas e ainda não tiverem sido executadas.|
|*Durante um escalonamento em andamento (como o envio de uma mensagem), a ação é excluída*|Nenhuma outra mensagem é enviada. A informação é registrada no arquivo de log do server (a partir de [Debug Level](/manual/appendix/config/zabbix_server) 3=Warning), por exemplo: `escalation canceled: action id:334 deleted`|
[comment]: # ({/8493a88c-362c7cc2})
[comment]: # ({187988b1-187988b1})
#### Exemplos de escalonamento
[comment]: # ({/187988b1-187988b1})
[comment]: # ({4d3a4940-0e2a0e62})
##### Exemplo 1
Enviando uma notificação repetida a cada 30 minutos (5 vezes no total)
para um grupo "Administradores MySQL". Para configurar:
- Na aba *Operações*, defina a *Duração padrão do passo da operação* como "30m" (30 minutos).
- Defina os *Passos* da escalonamento de "1" a "5".
- Selecione o grupo "Administradores MySQL" como destinatário da mensagem.
{width="600"}
As notificações serão enviadas às 0:00, 0:30, 1:00, 1:30, 2:00 horas após
o início do problema (a menos, é claro, que o problema seja resolvido antes).
Se o problema for resolvido e uma mensagem de recuperação estiver configurada, ela será
enviada para aqueles que receberam pelo menos uma mensagem de problema dentro deste
cenário de escalonamento.
::: noteclassic
Se o trigger que gerou um escalonamento ativo for
desabilitado, o Zabbix envia uma mensagem informativa sobre isso para todos que
já receberam notificações.
:::
[comment]: # ({/4d3a4940-0e2a0e62})
[comment]: # ({514a38fa-9f5d0fb5})
##### Exemplo 2
Enviando uma notificação atrasada sobre um problema de longa duração. Para configurar:
- Na guia *Operações*, defina a *Duração padrão da etapa de operação* como "10h" (10 horas).
- Defina as *Etapas* da escalonamento de "2" a "2".
{width="600"}
Uma notificação só será enviada na Etapa 2 do cenário de escalonamento, ou 10 horas após o início do problema.
Você pode personalizar o texto da mensagem para algo como "O problema tem mais de 10 horas".
[comment]: # ({/514a38fa-9f5d0fb5})
[comment]: # ({d6340061-2f4800fa})
##### Exemplo 3
Escalando o problema para o Chefe.
No primeiro exemplo acima, configuramos o envio periódico de mensagens
para os administradores do MySQL. Neste caso, os administradores receberão quatro
mensagens antes que o problema seja escalado para o Gerente de Banco de Dados.
Observe que o gerente receberá uma mensagem apenas se o problema ainda não tiver sido
reconhecido, presumivelmente ninguém está trabalhando nele.
{width="600"}
Detalhes da Operação 2:
{width="600"}
Observe o uso da macro {ESC.HISTORY} na mensagem personalizada. A macro
conterá informações sobre todas as etapas executadas anteriormente nesta
escalação, como notificações enviadas e comandos executados.
[comment]: # ({/d6340061-2f4800fa})
[comment]: # ({aba91a40-aba91a40})
##### Exemplo 4
Um cenário mais complexo. Após várias mensagens para administradores do MySQL
e escalação para o gerente, o Zabbix tentará reiniciar o MySQL
base de dados. Isso acontecerá se o problema persistir por 2:30 horas e
não foi reconhecido.
Se o problema persistir, após mais 30 minutos o Zabbix enviará um
mensagem para todos os usuários convidados.
Se isso não ajudar, depois de mais uma hora o Zabbix irá reiniciar o servidor com
o banco de dados MySQL (segundo comando remoto) usando comandos IPMI.
{width="600"}
[comment]: # ({/aba91a40-aba91a40})
[comment]: # ({939c3ed9-919f413f})
##### Exemplo 5
Uma escalada com várias operações que possuem intervalos de etapas sobrepostos e intervalos personalizados. A duração padrão da etapa da operação é de 30 minutos.
{width="600"}
As notificações serão enviadas da seguinte forma:
- Para os administradores do MySQL às 0:00, 0:30, 1:00 e 1:30 após o início do problema.
- Para o gerente do banco de dados às 2:00 e 2:10 (a duração da etapa personalizada mais curta de 10 minutos definida na operação subsequente substitui a duração da etapa mais longa de 1 hora configurada aqui, conforme descrito em [Detalhes da operação](/manual/config/notifications/action/operation#operation-details) para *Duração da etapa* quando as etapas se sobrepõem).
- Para os administradores do Zabbix às 2:00, 2:10 e 2:20 após o início do problema (a duração da etapa personalizada de 10 minutos é aplicada).
- Para usuários convidados às 4:00 após o início do problema (a duração padrão da etapa de 30 minutos entra em vigor entre as etapas 8 e 11).
[comment]: # ({/939c3ed9-919f413f})