Raio-X de um Zabbix com mais de mil hosts: auditando configuração ativa só via API

O problema #

Zabbix que cresce por anos acumula config morta: template vinculado que ninguém usa mais, action habilitada de teste que nunca foi desativada, trigger apontando pra dependência cujo mestre foi desabilitado há meses. “O que está configurado” e “o que está realmente em uso” divergem — e sem saber a diferença, qualquer decisão de limpeza é um chute.

Objetivo: gerar um raio-X 100% read-only da configuração efetivamente ativa, direto via API, sem exportar backup nem logar em nada além de leitura.

Critério: configurado não é usado #

Incluído — hosts ativos, templates ligados a esses hosts, triggers/itens próprios habilitados, actions ativas, macros em uso e manutenção vigente.

Excluído — objetos desabilitados, cópias herdadas repetidas, objetos gerados automaticamente por LLD, manutenção expirada/futura, histórico e qualquer segredo.

Um exemplo: havia scripts configurados, mas a API não prova histórico de execução. Pelo critério de uso comprovado, apenas scripts vinculados a actions ativas deveriam ser tratados como parte do fluxo operacional.

O que o raio-X mostrou #

1
2
3
4
5

mais de 1.000 hosts ativos
dezenas de templates efetivamente utilizados
milhares de vínculos host → template
milhares de dependências entre triggers
centenas de referências com trigger mestre desabilitado

As referências órfãs não contam como dependência operacional, mas são candidatas claras de limpeza ou correção.

Um achado que só apareceu na auditoria #

Entre as actions ativas apareceu uma chamada com “TESTE” literal no nome, embora estivesse habilitada. O relatório não conclui que está errada; apenas sinaliza para validação explícita. É o tipo de coisa que fica invisível quando ninguém audita configuração ativa de forma sistemática.

Tecnologias #

Zabbix API (JSON-RPC) · CSV · read-only