NexTool Solutions

O Zabbix torna-se monitorização proativa quando o alerta deixa de ser um e-mail que ninguém lê e passa a ser um pedido no GLPI com dono, prioridade e contexto. Na NexTool, o Zabbix não corre isolado: fica ao lado do GLPI que já sustentamos para o cliente, e cada trigger relevante nasce ligado a um fluxo de resposta. Este artigo mostra como implementamos e sustentamos esta dupla - da arquitetura ao trigger real e à integração com o módulo Automações da NexTool.

Arquitetura: Zabbix ao lado do GLPI, sem concorrer com ele

O erro clássico é tratar o Zabbix e o GLPI como mundos separados: o Zabbix grita, alguém vê e abre o pedido à mão. Isto acrescenta minutos (ou horas) entre a deteção e a ação, e depende de um humano estar a olhar para o painel. Na nossa implementação, o Zabbix Server corre num contentor ao lado da stack do cliente, com o Zabbix Agent 2 nos anfitriões monitorizados. O ponto de integração é o media type de webhook do Zabbix, que dispara um POST para o endpoint stateless do módulo Automações da NexTool - e é o Automações que cria o pedido no GLPI, com autenticação HMAC SHA-256 por fluxo.

Esta separação de papéis importa: o Zabbix decide o que é um sinal digno de ação (o trigger); o Automações decide como isso se torna trabalho no service desk (categoria, entidade, urgência, técnico). Alterar um sem mexer no outro torna-se trivial.

Triggers que importam: janela temporal e recovery, não um pico isolado

Na sustentação, a causa número um de "toda a gente silencia o Zabbix" é o flapping: um pico de CPU de 2 segundos levanta e limpa o alerta dezenas de vezes por hora. A defesa é dupla - avaliar sobre uma janela temporal e usar uma expressão de recovery separada (histerese), para que o problema só feche quando estabilizar de verdade. Um trigger de disco a encher, escrito para prever a falha antes de ela acontecer, é assim:

# Trigger: o sistema de ficheiros raiz vai encher nas proximas 24h (previsao, nao reacao)
# name: "Disco {HOST.NAME}: previsao de saturacao de / em 24h"
timeleft(/Linux by Zabbix agent/vfs.fs.size[/,pfree],1h,0)<24h
  and
last(/Linux by Zabbix agent/vfs.fs.size[/,pused])>80

# Trigger com histerese (recovery diferente do problema) para evitar o flapping de CPU
# Expressao de problema:
avg(/Linux by Zabbix agent/system.cpu.util,5m)>90
# Expressao de recovery (so limpa quando desce a serio):
avg(/Linux by Zabbix agent/system.cpu.util,5m)<70

A função timeleft() é o coração do "proativo": a partir da tendência, projeta quanto tempo falta para o disco encher - e alerta enquanto ainda há tempo de agir, não quando o serviço já caiu. O erro comum aqui é usar last() num valor de 95% de utilização e chamar a isso proativo; não é, é reativo com um limiar mais folgado.

Modelos e macros: consistência entre anfitriões

Padronizamos servidores, rede e aplicações através de um modelo (template) ligado, com os limiares expostos como macros ({$CPU.UTIL.CRIT}, {$VFS.FS.PUSED.MAX.CRIT}). Assim um anfitrião que vive legitimamente com utilização elevada (uma base de dados, por exemplo) recebe um override da macro no próprio anfitrião, sem duplicar o trigger nem quebrar o padrão dos outros 200 anfitriões. Isto acelera o onboarding de novos anfitriões e evita a divergência silenciosa que corrompe qualquer monitorização madura.

Integração com o GLPI: o webhook que se torna pedido

O media type de webhook do Zabbix é um script JavaScript que monta o payload e faz o POST. O que enviamos para o Automações leva o suficiente para o pedido nascer com contexto - severidade, anfitrião, item, valor e o {EVENT.ID}, que usamos como chave de idempotência para não abrir dois pedidos do mesmo evento:

// Zabbix media type (webhook) -> Automacoes NexTool -> GLPI
var req = new HttpRequest();
req.addHeader('Content-Type: application/json');
req.addHeader('X-Signature: ' + hmacSha256(params.payload, params.secret));

var payload = JSON.stringify({
  evento_id:  '{EVENT.ID}',        // chave de idempotencia
  severidade: '{EVENT.SEVERITY}',  // mapeada para urgencia GLPI
  anfitriao:  '{HOST.NAME}',
  gatilho:    '{TRIGGER.NAME}',
  valor:      '{ITEM.VALUE}',
  estado:     '{EVENT.VALUE}'      // 1=problema, 0=recuperado
});

var resp = req.post('https://glpi.cliente.com/automacoes/hook/zabbix', payload);
return JSON.stringify({ tags: [{ tag: '__glpi_ticket', value: resp }] });

Do lado do GLPI, o fluxo do Automações mapeia a severidade do Zabbix para a urgência do pedido, escolhe a categoria e a entidade certas e atribui-o ao grupo técnico responsável. Quando o evento recupera (estado: 0), o mesmo fluxo pode adicionar um seguimento de "resolvido automaticamente" ou fechar o pedido - fechando o ciclo deteção -> ação -> resolução sem intervenção manual.

Reativo vs proativo, na prática

Erros comuns que corrigimos na sustentação

• Sem expressão de recovery: problema e recuperação usam a mesma condição, o alerta pisca. Defina sempre histerese em métricas voláteis (CPU, latência).
• Severidade sem mapeamento: tudo chega ao GLPI como "média". Mapeie Disaster/High para urgência alta e deixe Information só no painel, sem gerar pedido.
• Sem idempotência: as repetições do webhook criam pedidos duplicados. Usar {EVENT.ID} como chave resolve.
• Alertar sem dono: um trigger que não aponta grupo/técnico é ruído. Todo alerta acionável precisa de rota de atribuição no fluxo do Automações.

Se já tem GLPI e quer que o Zabbix deixe de gerar e-mail ignorado e passe a gerar pedidos com dono e contexto, é este trabalho de implementação e sustentação que a NexTool entrega - do modelo ao fluxo de integração. Fale connosco sobre suporte e sustentação do seu ambiente GLPI + monitorização.

Este conteúdo foi produzido com o auxílio de inteligência artificial e revisto pela equipa Nextool Solutions.