Templates no Zabbix: do template pronto ao seu próprio, sem quebrar o upgrade

Autor: Pedro Tebaldi PM do KeepGreen

Publicado ago/2026

Um servidor novo entra no inventário e alguém vincula o template de Linux. Na manhã seguinte, o painel mostra 340 itens coletando de uma máquina que só serve arquivo. Nenhum deles, porém, virou alerta útil. Enquanto isso, o banco que sustenta o faturamento continua sem a métrica que o DBA pediu na semana passada.

Essa distância entre o que o pacote pronto traz e o que a operação precisa separa um ambiente organizado de um que cresceu por acúmulo. O que se decide ali define o que a empresa inteira mede, com que frequência e o que acorda o plantonista às três da manhã.

Este guia percorre o ciclo completo. Antes de tudo, onde achar o pacote certo para a sua versão e o que a vinculação tira das suas mãos. Em seguida, como estender sem que a atualização sobrescreva o trabalho e como auditar o que já roda em produção gerando ruído.

O que é um template do Zabbix e o que vem dentro dele

Um template do Zabbix é um conjunto de entidades de monitoramento aplicado a vários hosts de uma vez. Ele carrega itens, triggers, gráficos, dashboards, regras de descoberta de baixo nível e cenários web. Ao vincular, todas passam a existir no host. Depois disso, qualquer mudança no template se propaga para os hosts vinculados.

A consequência prática está na última frase. Assim, você muda o intervalo de coleta uma vez e os 400 hosts vinculados mudam junto. Sem isso, a mesma alteração vira 400 edições manuais ou um script contra a API.

Outro ponto costuma surpreender quem chega de outra ferramenta: a vinculação acontece host a host, nunca por grupo de hosts. Os grupos existem para organizar os próprios templates entre si, não para distribuí-los pelo ambiente.

Se a arquitetura de coleta ainda não estiver clara, comece pelo guia sobre como o Zabbix funciona e coleta os dados. Ele cobre servidor, proxy e agente antes deste ponto.

Onde estão os pacotes prontos e como escolher o da sua versão

A instalação já traz um conjunto oficial, disponível em Data collection > Templates. Ele cobre sistemas operacionais, bancos de dados, aplicações, dispositivos de rede, hypervisors e serviços de nuvem.

O volume é maior do que a maioria imagina. O repositório oficial do projeto traz 295 arquivos na branch da versão 7.4 e 291 na 7.0 LTS, organizados por diretório de tecnologia.

Portanto, a escolha começa pela versão, não pelo nome. Cada branch do repositório corresponde a uma release. Um arquivo exportado de uma versão mais nova, por isso, não importa em um servidor mais antigo.

Na instalação isso fica visível na própria lista: cada linha traz o fornecedor e a versão do pacote, e o rodapé conta quantos vieram de fábrica.

Agent, agent 2 ou HTTP: o critério de decisão

Para a mesma tecnologia costumam existir três variantes. A escolha entre elas muda o que você consegue coletar.

Use agent 2 quando existir plugin nativo e você controlar o sistema operacional do alvo. Por outro lado, prefira HTTP quando não houver como instalar agente, como em appliance fechado ou serviço gerenciado. Fique no agent clássico quando o parque já padronizou nele.

Em virtualização, o pacote oficial de VMware conversa direto com a API do vCenter. Como ele dispensa agente dentro das VMs, muda o desenho de monitorar um ambiente VMware. Já em equipamento de rede, a coleta chega pelo protocolo SNMP, com as MIBs do fabricante mapeadas em itens.

Fora do oficial existe a comunidade, onde vale um filtro. Antes de importar, confira a versão declarada no arquivo e quantos itens a regra de descoberta pode gerar. Verifique também se as triggers vêm com macro para limiar. Arquivo sem macro obriga a editar item por item depois.

Vincular ao host: o que a herança tira das suas mãos

Vincular é um clique. É aí, no entanto, que mora a armadilha mais cara do produto. Quando a vinculação acontece, entidades idênticas que já existiam no host passam a pertencer ao template. Como resultado, a customização feita antes no host se perde.

Depois disso, o host aceita pouca coisa: habilitar ou desabilitar item, mudar intervalo de atualização e ajustar retenção. O resto se edita um nível acima, como descreve a documentação oficial de vinculação.

Existem duas saídas, que não são equivalentes. Unlink corta a relação e deixa as entidades órfãs no host, ainda coletando. Unlink and clear remove tudo o que veio junto. Quem escolhe a primeira por engano fica com itens que ninguém mantém e que continuam gravando no banco.

Há ainda um erro de colisão que trava a operação. Vincular dois pacotes que tragam item com a mesma chave falha, porque triggers e gráficos dependem daquele item. Em ambientes que acumularam material de comunidade, essa é a causa mais comum de vinculação recusada.

Abrir um item herdado no host deixa a divisão explícita: o topo aponta para o template de origem, nome e chave chegam travados e o intervalo continua editável ali mesmo.

Quando o pronto não serve: estender sem quebrar o upgrade

O material oficial resolve o caso geral. Ele não conhece o seu processo de negócio, o seu UserParameter nem o limiar que a operação negociou em contrato.

A tentação é editar o oficial direto na interface. Evite: a atualização do Zabbix sobrescreve o que veio do projeto e leva o trabalho junto.

A política de ciclo de vida das versões torna isso concreto. O 7.0 LTS chegou em junho de 2024, com suporte pleno até junho de 2027. Entre uma LTS e a seguinte, o projeto ainda publica duas releases padrão.

O caminho que sobrevive ao tempo tem três passos. Crie um template próprio, vincule o oficial dentro dele por aninhamento e acrescente apenas o que falta. Dessa forma, o projeto continua atualizando a base e o seu carrega só a diferença.

Para limiar, nem isso é necessário. Os pacotes oficiais expõem macros como {$CPU.UTIL.CRIT}. Assim, você sobrescreve o valor no host ou no grupo, sem tocar em mais nada. Definir esse número é assunto de baseline, desvio padrão e janela de sustentação, nunca de chute redondo.

No template próprio, o que muda de ambiente para ambiente fica reunido numa aba só: cada limiar vira macro com valor padrão e descrição, e o host sobrescreve apenas o valor.

Descoberta de baixo nível: o que faz um template escalar

A descoberta de baixo nível, ou LLD, é o mecanismo que adapta o mesmo pacote a hosts diferentes. Uma regra consulta o alvo e devolve JSON com macros de descoberta. Em seguida, o Zabbix instancia itens, triggers e gráficos a partir dos protótipos declarados.

[
  { "{#FSNAME}": "/",       "{#FSTYPE}": "ext4" },
  { "{#FSNAME}": "/var",    "{#FSTYPE}": "ext4" },
  { "{#FSNAME}": "/backup", "{#FSTYPE}": "xfs" }
]

Cada objeto do retorno vira um conjunto de itens. São três sistemas de arquivos hoje e sete depois do próximo deploy, sem que ninguém edite nada. O protótipo continua o mesmo, ao passo que a coleta acompanha o host.

Em contrapartida, o mecanismo cobra um preço quando roda solto. Uma regra sem filtro em um switch de 48 portas cria itens para portas administrativamente desativadas. Dessa forma, o ambiente ganha ruído que ninguém pediu. Portanto, filtre por status administrativo e por descrição da interface antes de liberar em produção.

Do lado do template não existem itens, e sim protótipos: a regra de interfaces carrega sete deles, com nome e chave escritos em cima das macros que a descoberta devolve.

Na operação da VeloNet, provedor de fibra que atende Brasil e Angola, o inventário de equipamentos era manual e nunca acompanhava a rede real.

Estruturamos a descoberta por SNMP para os dispositivos e a rotina que transforma a trigger em chamado no GLPI. Hoje o inventário se atualiza sem cadastro manual e o alerta abre chamado em segundos, como mostra o case da VeloNet.

Importar, exportar e os erros que travam a importação

O Zabbix exporta e importa em YAML, XML ou JSON. O arquivo precisa da extensão correta e de codificação UTF-8. Qualquer outra codificação devolve erro de conversão antes mesmo da validação do conteúdo.

zabbix_export:
  version: '7.0'
  template_groups:
    - uuid: 7df96b18c0a24d3ea7e7cf9b1e8fb3a2
      name: Templates/Applications
  templates:
    - uuid: 4e1e2c0f9a1d4a5f9d6e0b3c8a7f2e11
      template: 'Servico Interno by Agent'
      name: 'Servico Interno by Agent'

Duas causas explicam quase toda falha de importação. A primeira aparece na segunda linha do arquivo: o campo version precisa ser compatível com o servidor de destino. Além disso, o caminho só funciona para frente.

A segunda é o uuid. Cada entidade exportada carrega esse identificador, que o Zabbix usa para decidir entre criar e atualizar. Quando já existe um registro de mesmo nome com UUID diferente, a importação para com erro de duplicidade. Renomear resolve o sintoma; decidir qual dos dois é o canônico resolve o problema.

Nas opções de importação, trate Update existing com cuidado. Ela sobrescreve o que está no servidor pelo conteúdo do arquivo, incluindo as triggers que a sua equipe calibrou ao longo de meses.

O diálogo mostra por que o cuidado importa: a coluna que sobrescreve o que já existe chega marcada, item por item, com triggers e gráficos no meio.

O que já roda em produção e virou ruído

Implantar é a parte fácil e a que todo tutorial cobre. O trabalho que quase ninguém escreve começa depois, quando o ambiente acumulou dezenas de vinculações e ninguém sabe mais o que cada uma dispara.

Antes de tudo, comece pelo inverso do óbvio. Liste as triggers que mais dispararam nos últimos 90 dias e cruze com quantas viraram chamado. Aquela que dispara toda semana e nunca gera chamado é candidata a desativação ou recalibragem. Mais uma regra de filtro na caixa de entrada só adia o problema.

Em seguida, olhe a severidade. O material oficial chega com severidade genérica. Severidade errada, por sua vez, alimenta direto a fadiga de alerta. Decidir o que é Warning e o que é Disaster no seu ambiente pertence à operação, alinhado à matriz de severidade de incidentes.

Por fim, procure o item que ninguém consulta. Coleta a cada 30 segundos de métrica que nenhum gráfico exibe e nenhuma trigger avalia gasta banco e history sem devolver nada. Intervalo maior, ou item desabilitado, vira ganho direto de capacidade no servidor.

Decisão de arquitetura, não tela de cadastro

O template concentra as escolhas que definem a operação: o que entra na coleta, com que frequência, qual desvio vira alerta e qual severidade chega ao plantão. Por isso, tratá-lo como formulário a preencher explica boa parte dos ambientes que coletam muito e enxergam pouco.

Três decisões carregam quase todo o resultado. Antes de tudo, escolher o pacote pela versão e pela forma de coleta, nunca pelo nome parecido. Depois disso, herdar do oficial em vez de editá-lo, para que a atualização deixe de ser um evento de risco. Por fim, ajustar limiar por macro no host, mantendo um único modelo para centenas de máquinas.

O restante é cadência. Uma revisão trimestral de triggers ruidosas e itens órfãos custa poucas horas. Em troca, evita a erosão silenciosa que transforma um ambiente bem desenhado em gerador de alarme falso.

Se a sua operação já passou do ponto em que dá para revisar isso à mão, fale com um especialista da OpServices. Podemos avaliar juntos como estruturar a padronização da coleta no seu ambiente.