NexTool Solutions

Zabbix vira monitoramento proativo quando o alerta deixa de ser um e-mail que ninguém lê e vira um chamado no GLPI com dono, prioridade e contexto. Na NexTool, o Zabbix não roda isolado: ele fica ao lado do GLPI que já sustentamos para o cliente, e cada trigger relevante nasce ligado a um fluxo de resposta. Este post mostra como implantamos e sustentamos essa dupla - da arquitetura ao trigger real e à integração com o módulo Automações do NexTool.

Arquitetura: Zabbix ao lado do GLPI, não concorrendo com ele

O erro clássico é tratar Zabbix e GLPI como mundos separados: o Zabbix grita, alguém vê, e abre o chamado na mão. Isso adiciona minutos (ou horas) entre a detecção e a ação, e depende de um humano estar olhando o painel. Na nossa implantação, o Zabbix Server roda em contentor ao lado da stack do cliente, com o Zabbix Agent 2 nos hosts monitorados. 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 do NexTool - e é o Automações que cria o chamado no GLPI, com autenticação HMAC SHA-256 por fluxo.

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

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

Na sustentação, a causa número um de "todo mundo silencia o Zabbix" é o flapping: um pico de 2 segundos de CPU dispara e limpa o alerta dezenas de vezes por hora. A defesa é dupla - avaliar sobre uma janela temporal e usar expressão de recovery separada (histerese), para o problema só fechar quando realmente estabilizou. Um trigger de disco enchendo, escrito para prever a falha antes dela acontecer, é assim:

# Trigger: filesystem 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 flapping de CPU
# Problem  expression:
avg(/Linux by Zabbix agent/system.cpu.util,5m)>90
# Recovery expression (so limpa quando cair de verdade):
avg(/Linux by Zabbix agent/system.cpu.util,5m)<70

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

Templates e macros: consistência entre hosts

Padronizamos servidores, rede e aplicações por template vinculado, com os limiares expostos como macros ({$CPU.UTIL.CRIT}, {$VFS.FS.PUSED.MAX.CRIT}). Assim um host que legitimamente vive com uso alto (um banco, por exemplo) recebe um override da macro no próprio host, sem duplicar o trigger nem quebrar o padrão dos outros 200 hosts. Isso acelera o onboarding de novos hosts e evita a divergência silenciosa que corrompe qualquer monitoramento maduro.

Integração com o GLPI: o webhook que vira chamado

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 carrega o suficiente para o chamado nascer com contexto - severidade, host, item, valor e o {EVENT.ID}, que usamos como chave de idempotência para não abrir dois chamados 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
  host:       '{HOST.NAME}',
  gatilho:    '{TRIGGER.NAME}',
  valor:      '{ITEM.VALUE}',
  status:     '{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 chamado, escolhe a categoria e a entidade certas e atribui ao grupo técnico responsável. Quando o evento recupera (status: 0), o mesmo fluxo pode adicionar um acompanhamento de "resolvido automaticamente" ou fechar o chamado - fechando o ciclo detecção -> ação -> resolução sem intervenção manual.

Reativo x proativo, na prática

Erros comuns que corrigimos na sustentação

• Sem recovery expression: problema e recuperação usam a mesma condição, o alerta pisca. Sempre defina histerese em métricas voláteis (CPU, latência).
• Severidade sem mapeamento: tudo chega no GLPI como "média". Mapeie Disaster/High para urgência alta e deixe Information só no painel, sem gerar chamado.
• Sem idempotência: retries do webhook criam chamados 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 você já tem GLPI e quer que o Zabbix pare de gerar e-mail ignorado e passe a gerar chamado com dono e contexto, é esse trabalho de implantação e sustentação que a NexTool entrega - do template ao fluxo de integração. Fale com a gente sobre suporte e sustentação do seu ambiente GLPI + monitoramento.

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