Um alarme é uma mensagem a uma pessoa, não uma linha num log

Qualquer plataforma de monitorização consegue detetar um problema. A parte difícil é o último quilómetro: pôr o alarme certo à frente de uma pessoa que possa agir sobre ele, em segundos, sem soterrar essa pessoa em alarmes que não interessam. É assim que encaminhamos os alarmes no Zabbix, e é assim que pode verificar se a sua própria cadeia funciona de facto.

Detetar é barato, a atenção é cara

A maioria das configurações de monitorização não falha por deixar escapar um problema. Falha porque ninguém lê o que produzem. Os alertas por e-mail caem numa pasta que enche mais depressa do que alguém a consegue esvaziar. Os painéis ficam vermelhos e continuam vermelhos durante semanas, até o vermelho deixar de significar seja o que for. O engenheiro que finalmente repara está normalmente a reagir a um cliente, não ao monitor.

Acrescentar mais verificações não resolve isso. O que resolve é um desenho de encaminhamento que trata a atenção de um engenheiro como o recurso mais escasso que existe, e a gasta apenas em coisas que precisam de um humano agora.

Decida o que pode chegar a uma pessoa

Comece pela severidade, e seja estrito. Cada trigger do Zabbix tem uma severidade, de information até disaster. Nós encaminhamos apenas as duas mais altas, high e disaster, para o engenheiro de prevenção, e cada trigger a esse nível tem de passar um teste: se isto disparar de noite, alguém precisa de agir antes da manhã? Se a resposta honesta for não, é um warning. Os warnings pertencem aos painéis e à revisão diária, não ao bolso de alguém.

No Zabbix essa decisão vive em dois sítios: nas condições da action (a severidade do trigger é maior ou igual a High) e no filtro de severidade no media do utilizador. Defina ambos, e faça-os concordar. Uma action que corresponde a tudo, combinada com um filtro de media que descarta silenciosamente metade, é uma configuração sobre a qual ninguém consegue raciocinar às três da manhã.

Depois suprima os ecos. Quando um switch vai abaixo, todos os hosts atrás dele ficam também inacessíveis. As dependências de triggers dizem ao Zabbix que os alarmes dos hosts dependem do alarme do switch, para que o engenheiro receba um alarme que nomeia a causa em vez de quarenta que nomeiam os sintomas.

Entregue-o onde o engenheiro já está

Os nossos alarmes saem do Zabbix por um webhook para um canal de operações dedicado no Mattermost, o chat em que os nossos engenheiros trabalham todo o dia e levam nos telemóveis à noite. Para alarmes, o chat ganha ao e-mail por razões práticas. É onde as pessoas já olham. Mostra quem viu a mensagem. E a conversa sobre a correção acontece no thread por baixo do alarme, por isso o thread torna-se o registo do que foi feito e quando.

Uma boa mensagem de alarme traz o suficiente para agir sem abrir três outras ferramentas: o host, o nome do trigger, a severidade, o valor atual, há quanto tempo está nesse estado e uma ligação direta para o gráfico. Escreva o template da mensagem uma vez, com cuidado, e todos os alarmes que alguma vez enviar beneficiam disso.

Torne a responsabilidade visível

Um alarme que três pessoas viram e ninguém assumiu é tão mau como um que ninguém viu. O acknowledgement fecha essa lacuna. Quando o engenheiro de prevenção confirma um problema no Zabbix, com uma nota curta, todos os outros veem que tem dono, e a nota é a primeira linha do registo. Se a sua equipa tiver uma segunda linha, um passo de escalation na action (uma notificação adicional quando um problema de severidade alta continua sem confirmação ao fim de um número definido de minutos) transforma o «alguém há de ver» numa regra.

O trabalho planeado merece o tratamento oposto: uma equipa que recebe alarmes da sua própria manutenção aprende a ignorar alarmes, e esse hábito não fica dentro da janela de manutenção.

Prove que funciona

Prove a cadeia depois de cada alteração

Nada disto conta até ter visto um alarme real percorrer todo o caminho. Depois de cada alteração na plataforma de monitorização disparamos um alarme genuíno e cronometramo-lo do trigger até à mensagem. A nossa equipa de rede escreveu exatamente como correr esse teste, e como confirmar que todos os dispositivos continuam a ser ouvidos, em A sua monitorização também é um sistema: teste o caminho, não o dashboard. Guarde os tempos que registar. Se o número for subindo entre testes, algo na cadeia está a ficar mais lento, e ficou a sabê-lo por um teste em vez de por uma interrupção.

Ajuste por host, nunca silencie às cegas

Os templates partilhados são onde nasce a fadiga de alarmes. Um servidor de base de dados corre legitimamente quente, alguém sobe o limiar de CPU no template para o calar, e todos os outros hosts da frota acabaram de perder um alarme útil. Nunca editamos um template partilhado para ajustar uma máquina. Os limiares que precisam de ser diferentes são definidos como macro overrides ao nível do host, por exemplo o valor próprio desse host para {$CPU.UTIL.CRIT}, para que ajustar uma máquina nunca altere os alarmes de outra.

A mesma regra aplica-se a desligar triggers. Um trigger que dispara constantemente está a dizer-lhe algo: ou o limiar está errado para esse host, ou o host tem um problema real. Desativá-lo para pôr o painel verde elimina a única testemunha. Corrija o limiar nesse host, ou corrija o host.

Vigie o vigilante

Um monitor que parou é pior do que nenhum, porque confiamos no seu silêncio. Duas verificações cobrem a maior parte do risco. Dentro do Zabbix, um trigger nodata em cada agent, como nodata(/<host>/agent.ping,5m)=1, apanha um host que deixou de reportar, que é uma falha diferente e mais silenciosa do que um host a reportar problemas. Fora do Zabbix, algo independente tem de reparar quando a própria plataforma se cala: um heartbeat que o servidor envia com regularidade para um sistema separado, que levanta o seu próprio alarme quando o heartbeat deixa de chegar.

Tratamos também a plataforma de monitorização como produção: retenção da base de dados imposta, e uma auditoria desde o hardware até ao sistema operativo, à base de dados, ao daemon e ao caminho dos alertas.

Uma segunda opinião antes de o engenheiro o ler

As regras filtram primeiro o ruído conhecido, e depois cada alarme que resta é analisado em tempo real por modelos de IA a correr nas nossas próprias GPU NVIDIA A100, dentro do nosso próprio datacenter. A análise olha para o alarme juntamente com eventos recentes, hosts relacionados e padrões conhecidos, e coloca ao lado dele uma segunda opinião curta: o que mais mudou nas proximidades, e o que este padrão significou no passado. Não decide nada e não alerta ninguém. Poupa ao engenheiro os primeiros minutos de procura. Como os modelos correm no nosso próprio hardware, os dados de monitorização nunca saem da nossa rede e nunca são enviados para um serviço de IA público.

Se construir algo semelhante, mantenha a mesma fronteira. A IA anota o alarme. Uma pessoa é dona da decisão.

Verifique a sua própria cadeia

Que severidades chegam a uma pessoa, e essa decisão está escrita em algum lado?
Toda a gente consegue ver quem é o dono de um alarme aberto?
Quando foi a última vez que alguém disparou um alarme de teste real e o cronometrou de ponta a ponta?
Uma falha de switch chega como um alarme ou como quarenta?
Alguém já ajustou um limiar editando um template partilhado?
Quantos triggers estão desativados neste momento, e alguém sabe porquê?
O que lhe diz que a própria plataforma de monitorização parou?

Se quiser um segundo par de olhos sobre a forma como os seus alarmes chegam às suas pessoas, teremos todo o gosto em ver. Fale com um engenheiro

footer line: Publicado em 22 de outubro de 2026. Todas as notas de campo