NexTool Solutions

Um alerta que chega só por e-mail é um incidente sem dono. A integração entre Zabbix e GLPI existe para transformar cada problema detectado em um chamado rastreável - com número, responsável, categoria, prioridade e SLA - e para fechá-lo sozinho quando o Zabbix confirma a recuperação. O segredo não está em "criar o ticket": está em não criar quarenta.

O que a integração precisa entregar

Uma ponte Zabbix para GLPI que sustenta produção precisa de quatro garantias, não apenas "postar um ticket":

• Idempotência: um problema gera um chamado, não um por passo de escalonamento.
• Correlação problema/recuperação: o evento de recovery precisa encontrar e fechar exatamente o chamado que abriu.
• Mapeamento de severidade: a severidade do Zabbix vira prioridade do GLPI de forma consistente, sem ficar a critério de cada analista.
• Contexto suficiente: host, IP, trigger, horário e mensagem no corpo, para o analista agir sem precisar abrir o Zabbix.

Arquitetura: onde o webhook vira chamado

O Zabbix dispara por uma Action; a Action executa uma operação de mídia do tipo Webhook; o Webhook é um script JavaScript nativo do Zabbix que faz um POST para um endpoint do lado do GLPI. Do lado do GLPI usamos o receiver do módulo Automações, que valida a assinatura HMAC, aplica o mapa de campos e cria (ou fecha) o chamado. Evitamos chamar a API REST do GLPI direto do Zabbix porque cada chamada exigiria o par app-token/user-token e um par initSession/killSession - sob uma tempestade de alertas isso martela a API e ainda esgota sessão.

Artefato: o Media Type webhook do Zabbix

Os parâmetros mapeiam macros do evento; o script monta o payload e trata o código HTTP. Problema e recuperação usam o mesmo Media Type - o campo event_value distingue (1 = problema, 0 = recuperação):

// Zabbix -> Media type -> Webhook -> Parametros
// endpoint     = https://glpi.cliente.com/plugins/nextool/automations/webhook/zabbix
// event_id     = {EVENT.ID}        // estavel no par problema/recovery
// event_value  = {EVENT.VALUE}     // 1 = problema, 0 = recuperacao
// host_name    = {HOST.NAME}
// host_ip      = {HOST.IP}
// trigger_name = {TRIGGER.NAME}
// severity     = {TRIGGER.SEVERITY}
// occurred     = {EVENT.DATE} {EVENT.TIME}
// message      = {ALERT.MESSAGE}
// hmac         = {$NEXTOOL_HMAC}    // macro secreta, nunca no corpo do alerta

var p = JSON.parse(value);
var req = new HttpRequest();
req.addHeader('Content-Type: application/json');
req.addHeader('X-Nextool-Signature: ' + p.hmac);

var payload = JSON.stringify({
    event_id: p.event_id,
    recovery: p.event_value === '0',
    host:     p.host_name,
    host_ip:  p.host_ip,
    trigger:  p.trigger_name,
    severity: p.severity,
    occurred: p.occurred,
    message:  p.message
});

var resp = req.post(p.endpoint, payload);
var code = req.getStatus();
if (code < 200 || code >= 300) {
    Zabbix.log(3, '[nextool] falha HTTP ' + code + ': ' + resp);
    throw 'Envio ao GLPI falhou: HTTP ' + code;
}
return resp;

Mapa de severidade Zabbix para prioridade GLPI

O Zabbix tem seis severidades; o GLPI, cinco prioridades. Fixamos o mapa no receiver para não deixar a critério de cada analista:

Deduplicação e fechamento automático

Este é o ponto que separa uma integração de brinquedo de uma que aguenta produção. Ao abrir o chamado, o receiver grava o tickets_id do GLPI como tag do evento no Zabbix (ou numa tabela de correlação indexada por event_id). Quando o Zabbix envia o recovery com o mesmo event_id, o receiver localiza aquele chamado e adiciona um acompanhamento de recuperação - ou o fecha, conforme a política do cliente. Sem essa chave, o recovery não sabe qual dos chamados fechar e você acumula tickets abertos de problemas já resolvidos.

Erros comuns que corrigimos na sustentação

Na sustentação, o incidente mais comum não é o alerta que não vira chamado - é o alerta que vira quarenta. Uma interface em flapping às 3h da manhã abriu dezenas de tickets idênticos porque a Action disparava a cada passo de escalonamento e o receiver não deduplicava. A correção tem dois lados: no Zabbix, dependência de trigger, histerese na expressão de recovery e operação de mídia só no primeiro passo; no GLPI, idempotência por event_id. Outros dois erros recorrentes: mandar a categoria do chamado como texto livre (o GLPI espera itilcategories_id numérico - um texto novo não casa e o chamado cai sem categoria) e colocar o segredo HMAC no corpo do alerta em vez de numa macro protegida como {$NEXTOOL_HMAC}.

Métodos de integração comparados

Se a sua operação já roda Zabbix mas os alertas morrem numa caixa de e-mail que ninguém lê, a NexTool implanta essa ponte com o módulo Automações e mantém as regras afinadas na sustentação - triggers, mapa de severidade e política de fechamento. Conheça o módulo Automações.

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