Notificações no Zabbix: do bot do Telegram ao escalonamento em 3 níveis
Autor: Pedro Tebaldi PM do KeepGreenO Zabbix detectou a queda do link às 3h12. A trigger mudou de estado, o problema entrou na tela de Problems, o gráfico guardou a interrupção inteira. Ninguém soube de nada até as 8h, quando o primeiro usuário ligou reclamando.
Coleta e notificação são dois subsistemas diferentes dentro do mesmo produto. O segundo não vem ligado de fábrica. Na versão 7.4 o tipo de mídia do Telegram já vem instalado, porém desativado, sem token e sem nenhum usuário associado. Se a dúvida ainda for o que a ferramenta coleta, a visão geral do Zabbix responde antes.
O custo disso não é hipotético. A NeuBird publicou em 2026 um levantamento com mais de mil profissionais de SRE, DevOps e operações de TI. Nele, 44% das organizações tiveram uma indisponibilidade no último ano ligada a alerta ignorado ou suprimido.
Por isso o canal de notificação vale tanto quanto a coleta.
Os três objetos que ligam a trigger ao seu celular
A notificação do Zabbix depende de três cadastros independentes. Quando um deles falta, nada chega. O produto também não reclama em lugar nenhum: a trigger continua disparando normalmente, só que sem destino.
O tipo de mídia é o canal. Ele guarda o script do webhook, o token do bot e o modo de formatação da mensagem. Ou seja, é cadastro global, feito uma vez por instalação.
A mídia do usuário é o endereço. Ela amarra um tipo de mídia a uma pessoa, com o chat id de destino. Ali também ficam as severidades que aquele usuário aceita receber e o período em que ele está disponível.
Por fim, a ação de trigger é a regra. Ela define quais eventos geram notificação, para quem, em que ordem e com que intervalo entre as tentativas.
Vale conferir os três nessa ordem quando a mensagem não chega. Na prática, a falha mais comum não é o token errado. É a ação criada com o usuário certo, mas com a mídia daquele usuário limitada a severidades que o evento não atinge.
Passo 1: criar o bot no Telegram e descobrir o chat id
O Telegram não aceita que um sistema envie mensagem em nome de uma pessoa. Todo envio sai de um bot, então o primeiro cadastro acontece fora do Zabbix.
Converse com o @BotFather no próprio Telegram, envie /newbot, escolha um nome de exibição e um nome de usuário terminado em bot. A resposta traz o token, no formato 8123456789:AAF.... Esse token é credencial de produção: quem o tem envia mensagem como o seu bot.
Em seguida vem o chat id, que é o destino. Para notificação de operação, prefira um grupo em vez de conversa individual. Assim o plantonista que entra amanhã enxerga o histórico sem precisar de cadastro novo. Crie o grupo, adicione o bot, mande qualquer mensagem lá dentro e consulte a API:
O sinal negativo faz parte do identificador. Grupos comuns começam com - e supergrupos com -100, portanto copie o número inteiro, com o sinal. Um chat id positivo é conversa individual, o que costuma indicar que o bot ainda não foi adicionado ao grupo certo.
Passo 2: configurar o tipo de mídia Telegram no Zabbix
Vá em Alertas e depois em Tipos de mídias. O Telegram já está na lista desde a instalação, com o status Inativo, porque o Zabbix distribui o webhook pronto sem as credenciais.
Abra o registro e preencha dois parâmetros. Em api_token, cole o token do BotFather no lugar do texto <PLACE YOUR TOKEN>. Em api_parse_mode, troque <PLACE PARSE MODE> por html. Dessa forma, a mensagem aceita <b> e <code> sem quebrar quando o nome do host trouxer um caractere especial.
É assim que o registro fica depois dos dois campos preenchidos: os demais parâmetros continuam com a macro que vem de fábrica.
Os demais parâmetros já vêm resolvidos por macro e não devem ser alterados. Eles carregam severidade, origem do evento e as etiquetas do problema para dentro do script do webhook.
Antes de sair, marque Ativo. O detalhe custa caro justamente por ser trivial. Ou seja, com o tipo de mídia desativado, a ação executa, o log registra a tentativa e a mensagem não sai.
Passo 3: ligar a mídia ao usuário e testar o canal antes da ação
Abra Usuários, escolha quem recebe o alerta e vá até a aba Mídia. Adicione uma entrada do tipo Telegram e cole o chat id do grupo no campo Enviar para.
Dois campos dessa mesma tela decidem o volume que vai chegar. O Usar se severidade filtra o que aquele destino aceita. Já o Ativo quando aceita expressões como 1-5,08:00-18:00 para horário comercial ou 1-7,00:00-24:00 para plantão contínuo.
Nesta mídia o líder de plantão recebe 24 por 7, mas só Alta e Desastre chegam pelo Telegram.
Agora teste o canal isolado, antes de criar qualquer ação. Na lista de tipos de mídia existe o botão Testar: ele envia uma mensagem direto pelo webhook, com o chat id que você informar.
Esse teste separa dois diagnósticos que se parecem muito na tela. Se ele falha, o problema está no token, no chat id ou na saída para a internet. Se ele funciona e mesmo assim nada chega durante um incidente, o problema está na ação ou no filtro de severidade, nunca no Telegram.
Passo 4: a ação de trigger que transforma evento em mensagem
Em Alertas, abra Ações e depois Ações de trigger. Crie uma ação nova e comece pelas condições, porque é ali que se decide o que merece interromper alguém.
Uma condição de severidade mínima resolve a maior parte dos casos. Com Severidade da trigger é maior ou igual Média, ficam de fora os avisos informativos que o Zabbix gera às dezenas. Somar uma segunda condição por etiqueta de host, do tipo ambiente = producao, evita que o laboratório acorde o plantão.
Com as duas condições combinadas por E, sobra o que é grave e está em produção.
Na aba de operações, escreva a mensagem com as macros que dão contexto. Um alerta que diz apenas “problema detectado” obriga o plantonista a abrir o navegador antes de decidir qualquer coisa:
Configure também a operação de recuperação, no bloco logo abaixo das operações. Sem ela o grupo acumula problemas abertos que já se resolveram sozinhos. Assim o canal perde a única propriedade que interessa: quando ele apita, alguma coisa está de fato quebrada.
Passo 5: a escada de escalonamento em três degraus
Aqui está o que a documentação do fabricante e os tutoriais em português deixam de fora. Todos param na primeira mensagem entregue. A pergunta que a operação faz é outra: o que acontece quando ninguém responde àquela mensagem?
O Zabbix resolve isso com passos de operação. Cada operação declara em quais passos ela roda. A ação, por sua vez, define a Duração padrão do passo da operação. Uma escada de três degraus com intervalo de 15 minutos fica assim:
| Degrau | Passos | Quando dispara |
|---|---|---|
| N1Grupo de operação, no Telegram | 1 | imediato |
| N2Líder de plantão, Telegram e e-mail | 2 | 15 min sem reconhecimento |
| N3Gerência de infraestrutura | 3 – 0 | 30 min sem reconhecimento |
Os três degraus vivem na aba de operações. A coluna Iniciar em mostra quando cada um dispara.
O passo final 3 - 0 significa repetição indefinida até o problema fechar. Use com parcimônia, porque ela transforma um incidente esquecido em mensagem a cada 15 minutos para a gerência.
A condição que faz a escada parar
Cada operação aceita uma condição própria. Nesse caso, a que importa é a de evento ainda não reconhecido. Com ela nos degraus 2 e 3, o simples ato de reconhecer o problema na interface interrompe o escalonamento.
Isso muda o contrato com quem está de plantão. O analista não precisa resolver em 15 minutos: precisa avisar que assumiu. A escada existe para cobrir ausência, não para punir demora. Essa diferença de leitura decide se a equipe aceita ou rejeita o sistema.
Os critérios de quem entra em cada degrau estão em como estruturar uma política de escalação. Já a rotina de plantão em si é assunto de gestão de on-call sem desgastar a equipe.
Numa rede de 97 escolas monitoradas, do Rio Grande do Sul à Amazônia, montamos essa lógica junto com o Marista Brasil. São cerca de 6.000 hosts e 12.000 serviços, com um dashboard por unidade.
O primeiro degrau fica com a equipe central. Dessa forma, boa parte dos incidentes se resolve antes do expediente da TI local, sem perder a autonomia de cada unidade sobre o próprio ambiente. Esse desenho é o mesmo que sustenta operações de NOC com triagem e escalação definidas.
E-mail no segundo degrau: quando cada canal serve
Manter os dois canais não é redundância desperdiçada, porque eles falham de formas diferentes. O Telegram depende de internet no aparelho e de o plantonista não ter silenciado o grupo. O e-mail depende de um servidor SMTP que, em incidente de infraestrutura, pode ser exatamente o que caiu.
A regra prática que funciona: Telegram no primeiro degrau, os dois no segundo. Quem está de plantão recebe pelo canal rápido. Quem é acionado por ausência de resposta recebe também pelo canal que deixa rastro fora do grupo.
O tipo de mídia Email também vem desativado de fábrica, com o mesmo caminho de configuração. Preencha servidor, porta e autenticação, depois use o botão de teste antes de amarrar na ação.
Quando o destino final do alerta é um chamado em vez de uma mensagem, o caminho muda de novo. A abertura automática de chamado a partir da trigger usa um webhook de outro tipo, com mapeamento de severidade para prioridade.
O que impede o canal de virar ruído
Um grupo de Telegram com 300 mensagens por dia é silenciado na segunda semana. A partir daí o investimento inteiro vira decoração. Três ajustes do próprio Zabbix seguram esse número.
O primeiro é a severidade mínima, aplicada em dois lugares diferentes: na condição da ação e no filtro da mídia do usuário. O segundo lugar costuma passar despercebido, embora seja ele que permite dar níveis diferentes para pessoas diferentes com uma ação só.
Vale calibrar isso com um critério explícito de classificação de severidade de incidentes.
O segundo ajuste é a janela de manutenção, em Dados coletados e depois Manutenção. Cadastre o período e marque, na ação, a opção Pausar operações para incidentes suprimidos. Assim a janela de atualização de madrugada deixa de acordar o plantão.
A janela cadastrada aqui é o que a ação consulta antes de acionar alguém na madrugada de domingo.
Falta o terceiro ajuste: a dependência entre triggers. Quando o switch de acesso cai, os oito equipamentos atrás dele também param de responder. Sem dependência declarada, o grupo recebe nove mensagens para um único evento. A leitura mais completa desse efeito está em o que produz fadiga de alertas e como reduzi-la.
Meça o resultado depois de duas semanas. Se a proporção de mensagens que geraram alguma ação humana ficar abaixo de um terço, o problema está no filtro, não na equipe.
É seguro colocar alerta de produção num bot do Telegram?
O bot do Telegram é seguro para notificação de operação desde que você trate o token como credencial e escolha o que vai no texto. O token permite enviar mensagem em nome do bot, então ele vale uma senha. O chat id, por outro lado, não é segredo: sem o token, ele não abre nada.
Três cuidados resolvem o resto. Restrinja o grupo por convite e revise a lista de participantes quando alguém sai da equipe, porque o bot entrega para o grupo inteiro. Nunca coloque credencial, string de conexão ou dado de cliente no texto da mensagem: o alerta diz o que quebrou e onde. O resto fica atrás do login do Zabbix.
Se o token vazar, o /revoke no BotFather invalida o antigo na hora. Mais detalhes de permissão estão na documentação oficial da API de bots.
Milhares de alertas por dia. Só os que importam chegam até você.
O KeepGreen filtra o ruído do monitoramento com IA, correlaciona eventos e entrega ao plantão apenas incidentes reais: com causa raiz, contexto e próximo passo.
O teste que fecha a configuração
Não considere a notificação pronta enquanto não tiver simulado o caminho inteiro. Coloque um host de teste em falha proposital, com severidade acima do corte. Depois cronometre: a mensagem chega em quanto tempo, o segundo degrau sobe no intervalo previsto, o reconhecimento interrompe a escada, a recuperação avisa que fechou.
Esse ensaio de dez minutos revela os erros que a configuração esconde. O tipo de mídia fica esquecido em Inativo. O filtro de severidade do usuário sai mais restrito que a condição da ação. O horário de disponibilidade exclui justamente a madrugada.
São três defeitos silenciosos. No entanto, nenhum deles aparece na tela até o incidente real acontecer.
Vale registrar o resultado do ensaio junto da política de escalação, com data e versão. A regra que ninguém testou desde a migração é a regra que vai falhar no próximo incidente maior. A discussão seguinte costuma ser outra: quem sustenta o plantão fora do horário. Para desenhar essa cobertura junto com o time, fale com um especialista da OpServices.
