Zabbix Documentation 3.4

3.04.04.4 (current)| In development:5.0 (devel)| Unsupported:1.82.02.22.43.23.44.2Guidelines

User Tools

Site Tools

This translation is older than the original page and might be outdated. See what has changed.

Sidebar

pt:manual:config:notifications:action:escalations

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)