Hosts, templates, macros e tags

Não use uma ferramenta para resolver cinco problemas

Uma configuração sustentável começa separando responsabilidades. O host representa o alvo; o grupo organiza e participa do controle administrativo; o template define comportamento reutilizável; a macro parametriza esse comportamento; e a tag acrescenta contexto que pode acompanhar métricas e eventos.

ALVO REAL
   │
   ▼
HOST ─────────────── identidade, interfaces, inventário
 │
 ├── HOST GROUP ─── organização / permissões / seleção
 │
 ├── TEMPLATE ───── itens, triggers, LLD, gráficos, dashboards...
 │       │
 │       └── MACROS ─ parâmetros e thresholds
 │
 └── TAGS ───────── contexto operacional e semântico

O host é identidade, não documentação inteira

Um host pode possuir interfaces de Agent, SNMP, JMX e IPMI, ser associado a templates, macros, tags, inventário e proxy. O nome técnico deve ser estável e previsível.

rtr-rj-centro-01
sw-rj-pop01-02
olt-rj-marica-01

ROTEADOR-CLARO-1GB-CENTRO-CRITICO
SWITCH_CLIENTE_X_OPERADORA_Y...

Grupo não deve virar banco de metadados

Use grupos para organização, seleção em massa e escopo administrativo. Não crie uma explosão combinatória de grupos para representar toda característica possível do ativo.

Network
├── Core
├── Distribution
├── Access
└── OLT

Servers
├── Linux
└── Windows

Sites
├── RJ
└── SP

Operadora, serviço, circuito, criticidade e função podem ser melhores como tags quando precisam participar de filtros, ações, correlação ou Services.

Template é uma unidade de comportamento reutilizável

Templates podem entregar itens, triggers, gráficos, regras LLD, web scenarios e dashboards aos hosts. Templates também podem vincular outros templates, criando herança. Isso permite construir blocos menores e reutilizáveis em vez de duplicar configurações.

Perfil: Switch de acesso
│
├── ICMP ping
├── Interfaces by SNMP
└── Fabricante/modelo by SNMP
       ├── CPU
       ├── memória
       ├── temperatura
       ├── fontes
       └── sensores específicos

A própria guideline oficial recomenda modularidade: um template deve representar um recurso ou conjunto inseparável de recursos; quando vários módulos precisam andar juntos, um template de perfil/meta pode agregá-los.

O nome deve dizer o alvo e o método de coleta

Nas guidelines atuais, o Zabbix não exige o prefixo “Template” nos nomes modernos. Quando útil, o método principal de coleta aparece como sufixo.

Transforme diferenças em parâmetros, não em cópias

User macros usam a sintaxe {$MACRO} e podem existir globalmente, em templates ou hosts. Elas são ideais para thresholds, portas, URLs, communities, tokens e outros parâmetros que variam sem mudar a lógica do template.

{$NET.IF.UTIL.MAX.WARN}=80
{$NET.IF.ERRORS.MAX.WARN}=10
{$SNMP.COMMUNITY}=valor-definido-no-host
{$API.URL}=https://exemplo.local/api

Precedência real

1. Host
2. Templates diretamente vinculados ao host
3. Templates do próximo nível de herança
4. Próximos níveis...
5. Macro global

Um threshold diferente sem duplicar a trigger

Context macros permitem que a mesma macro tenha valores diferentes conforme uma entidade descoberta. Isso é especialmente poderoso com LLD.

{$IF.UTIL.MAX.WARN}=80
{$IF.UTIL.MAX.WARN:"ether1"}=95
{$IF.UTIL.MAX.WARN:"uplink-core"}=70

# Também pode existir contexto por expressão regular:
{$IF.UTIL.MAX.WARN:regex:"^uplink-.*"}=70

Evite criar contextos simples e regex que possam corresponder simultaneamente ao mesmo valor: a documentação alerta para comportamento indefinido quando múltiplos contextos regex casam com a mesma string.

Secret text não é sinônimo de segredo inalcançável

Macros aceitam Text, Secret text e Vault secret. Secret text mascara o valor na interface; Vault secret referencia um gerenciador externo suportado. Porém, o Server precisa resolver o valor para usá-lo: um segredo mal empregado pode ser exposto por um item/script que o devolva como dado.

Tags são parte do modelo de dados operacional

Tags podem existir em templates, hosts, itens, web scenarios, triggers, Services e protótipos. Eventos podem receber tags ao longo dessa cadeia. Por isso, uma taxonomia bem desenhada afeta filtragem, Actions, correlação, Services e análise de incidentes.

Um modelo de tags para infraestrutura heterogênea

Abaixo está uma proposta operacional — não uma exigência do Zabbix. Ela separa características do ativo, localização, serviço e incidente para evitar tags sem semântica consistente.

# Identidade técnica
class=network
vendor=cisco
role=edge-router

# Localização
region=rj
site=centro
pop=pop-01

# Negócio/serviço
service=internet
carrier=operadora-a
criticality=high

# Contexto de evento/trigger
scope=availability
component=network

Escolha uma grafia e mantenha-a. carrier, operadora e isp usados simultaneamente para a mesma dimensão criam três taxonomias diferentes.

Não confunda guideline de template público com CMDB interna

As guidelines oficiais sugerem tags como class e target para templates, component para itens e scope para triggers. Uma empresa pode adicionar tags operacionais próprias — site, carrier, tenant, owner, service — desde que a taxonomia seja documentada e consistente. O objetivo não é copiar cegamente um padrão; é manter interoperabilidade sem perder o contexto necessário à operação.

Base → recurso → fabricante → perfil

ICMP ping
      │
Interfaces by SNMP
      │
      ├──────────── Cisco IOS by SNMP
      │
      ├──────────── Huawei switch by SNMP
      │
      └──────────── Datacom switch by SNMP

Perfil / Meta template (quando fizer sentido)
      │
      ├── ICMP ping
      ├── Interfaces by SNMP
      └── recurso específico

O perfil/meta template é útil quando um conjunto de módulos deve ser aplicado repetidamente como uma unidade. Evite criar dependências artificiais entre tecnologias que podem evoluir separadamente.

Configurações que funcionam hoje e cobram a conta depois

O que muda de 10 para 1.000 hosts?

Template próprio deve ser tratado como código

O frontend permite exportar templates em YAML, XML ou JSON; YAML é uma escolha prática para versionamento. Guarde o template junto de um README que documente dependências, macros, versão do Zabbix testada, alterações e procedimento de implantação.

templates/
└── network/
    └── meu-switch-by-snmp/
        ├── README.md
        ├── CHANGELOG.md
        └── template_meu_switch_by_snmp.yaml

Criando um modelo reutilizável de rede

O objetivo é monitorar vários switches sem copiar configuração por equipamento.

Resultado esperado

Host: sw-rj-pop01-01

Templates:
  ICMP ping
  Interfaces by SNMP
  Vendor/modelo by SNMP

Host tags:
  region=rj
  site=pop-01
  role=access-switch
  service=network-access

Host macros:
  somente valores que diferem do default do template

Onde colocar cada informação?

Antes de liberar um novo padrão

Base factual desta página

Conteúdo desenvolvido a partir da documentação e das guidelines oficiais do Zabbix 7.4 sobre hosts, templates, linking/unlinking, user macros, macro context, secret macros, tagging e template guidelines. A arquitetura, taxonomia operacional, exemplos e recomendações de organização desta página são uma síntese editorial própria para aplicação prática.

Linha Zabbix 7.4

O Host Wizard do 7.4 simplifica onboarding e depende de templates atualizados. Preserve templates como código/versionados quando a operação exigir rastreabilidade.