Um alerta que dispara no Zabbix e não vira chamado automaticamente no service desk cria um gap conhecido. Alguém precisa perceber a notificação, abrir o sistema de tickets, e registrar manualmente o problema.
Em ambientes com volume alto de alertas, essa etapa manual é onde incidentes se perdem ou demoram para ser tratados.
O Zabbix resolve esse gap com um mecanismo único para as três ferramentas de service desk mais comuns em ambientes open source, como a OTRS Community Edition, GLPi e Zammad. E vale destacar isso logo de início, porque é um ponto que costuma ser mal entendido: as três integrações não usam abordagens diferentes.
Todas passam pelo mesmo recurso de webhook do Zabbix, configurado através de media type, usuário e action.
Vamos entender, de maneira simplificada, como funciona a integração do Zabbix e essas ferramentas de service desk.
Como funciona o mecanismo por trás das três integrações
O Zabbix dispara notificações através de actions, que são regras configuradas para reagir a condições específicas, como a criação de um problema com determinada severidade. Cada action pode disparar uma ou mais operações, entre elas o envio de mensagem via um media type.
Os media types do tipo webhook permitem que o Zabbix envie requisições HTTP para sistemas externos, com o corpo da requisição, os parâmetros e o comportamento definidos em um script JavaScript embutido no próprio media type.
É esse mecanismo que sustenta as integrações oficiais com OTRS CE, GLPi e Zammad, todas distribuídas como templates de media type prontos, disponíveis no repositório oficial de integrações do Zabbix.
Nas três, o fluxo de configuração segue o mesmo roteiro: importar o media type correspondente, criar um usuário dedicado à integração e configurar a action que vai disparar as notificações para esse usuário quando os critérios definidos forem atendidos.
Integração com OTRS Community Edition
A integração oficial com o OTRS CE funciona a partir da versão 7.2 do Zabbix. Depois de importar o webhook, é preciso criar um web service no OTRS, usando o arquivo ZabbixTicketConnector.yml, que expõe o endpoint que o Zabbix vai chamar.
Os parâmetros do webhook incluem a URL do frontend do OTRS CE e, opcionalmente, um mapeamento de severidade: para cada nível de severidade do Zabbix (não classificado, informação, atenção, média, alta, desastre) é possível definir o ID de prioridade correspondente no OTRS. Também é possível preencher campos dinâmicos do OTRS com valores vindos do Zabbix, desde que sejam do tipo texto, área de texto, checkbox ou data.
Um recurso importante para quem quer fechar o ciclo completo é configurar o webhook para fechar automaticamente o ticket no OTRS quando o problema correspondente for resolvido no Zabbix, definindo o State ID de “fechado” nos parâmetros do webhook.
Integração com GLPi
A integração com o GLPi segue exatamente o mesmo modelo de webhook, com suporte tanto à API REST legada (V1) quanto à API RESTful mais recente (V2) do GLPi. O webhook cria os tickets diretamente na seção de atendimento (Assistance) do GLPi.
Quando um problema já reportado é atualizado no Zabbix, o webhook atualiza o título e a urgência do ticket correspondente no GLPi, e adiciona um followup com o comentário da atualização. Isso significa que o ciclo de vida do ticket acompanha o ciclo de vida do problema no Zabbix sem intervenção manual, incluindo a evolução de severidade e o fechamento.
Integração com Zammad
No Zammad, o pré-requisito inicial é habilitar o acesso via API token, em Settings > System > API.
A partir da versão 7.2 do Zabbix (a integração também existe para 7.4 e versões anteriores, com pequenas variações), o webhook segue o mesmo padrão das outras duas, com media type, usuário e action.
Assim como no OTRS, o Zammad também permite mapear a severidade do Zabbix para os campos de prioridade do sistema, e oferece suporte a tags do Zammad através do parâmetro zammad_enable_tags. Um detalhe técnico relevante é que, quando o suporte a tags está habilitado, cada tag é enviada como uma requisição separada, o que vale considerar em cenários de alto volume de eventos.
Boas práticas de integração
Independente de qual das três ferramentas está em uso, alguns cuidados valem para todas.
Todos os webhooks do Zabbix suportam proxy HTTP, o que é relevante em ambientes onde o servidor não tem saída direta para a internet ou para a rede do service desk. Nesse caso, basta adicionar um parâmetro de media type chamado http_proxy com a URL do proxy.
Vale também revisar com atenção o mapeamento de severidade antes de colocar a integração em produção. Um mapeamento mal ajustado pode fazer com que problemas de baixa relevância cheguem como prioridade alta no service desk, ou o contrário, gerando o mesmo tipo de ruído que a integração deveria eliminar.
E antes de liberar para o time de suporte, vale testar o ciclo completo: abertura do ticket a partir de um problema simulado, atualização de severidade, e fechamento automático quando o problema for resolvido. Esse teste de ponta a ponta costuma revelar rapidamente se o mapeamento de campos e de severidade está correto.
Escolhendo entre as três
Como as três seguem exatamente o mesmo mecanismo de webhook, a decisão de qual usar normalmenteé muito mais organizacional do que técnica, considerando a ferramenta de service desk que a equipe já opera.
- Times que já usam GLPi para gestão de ativos de TI tendem a se beneficiar da associação entre os tickets e os ativos cadastrados na própria ferramenta;
- Times com processos mais alinhados a ITIL costumam gravitar para OTRS ou Zammad, dependendo da preferência de interface e do ecossistema de plugins de cada um.
Cada operação tem um fluxo de incidentes diferente, e o mapeamento de severidade, campos e ciclo de fechamento precisa ser desenhado para a realidade do seu service desk. Fale com o time técnico da Zabbix e planeje a integração ideal para a sua empresa!
Prev Post 
