Discovery e Low-Level Discovery

Três problemas de descoberta, três ferramentas diferentes

O Zabbix separa descoberta de rede, autoregistration de agentes ativos e Low-Level Discovery. Network discovery encontra hosts/serviços disponíveis. Autoregistration permite que agentes ativos se apresentem ao Server. LLD trabalha dentro de um host para descobrir entidades como interfaces, filesystems, CPUs e sensores. Misturar esses conceitos leva a automações difíceis de controlar.

Encontrar dispositivos não significa monitorá-los cegamente

Network discovery varre intervalos de IP e executa checks como ICMP, SNMP ou serviços. Discovery actions podem transformar o resultado em ação operacional, como criar host, adicionar a grupos ou vincular templates. Em redes grandes, as condições precisam ser rigorosas para impedir duplicidade, classificação errada e inclusão automática de equipamentos temporários.

Quando o host se apresenta ao Zabbix

Active agent autoregistration é adequada quando o agente ativo conhece o Server/Proxy e pode registrar-se automaticamente. Metadados enviados pelo agente podem ser usados por ações para determinar grupo, template e outras decisões. É um modelo diferente de varrer rede: o host inicia o processo.

LLD cria objetos a partir de entidades descobertas

Uma regra LLD coleta JSON descrevendo entidades. Para cada objeto retornado, prototypes podem criar itens, triggers, gráficos, hosts e outras estruturas. Se a regra retorna interfaces eth0 e eth1, prototypes com macros como {#IFNAME} geram objetos individualizados sem configuração manual para cada interface.

A saída da descoberta é um contrato de dados

No formato atual, a regra retorna um array de objetos. Cada objeto representa uma entidade. Chaves no formato {#MACRO} tornam-se LLD macros disponíveis nos prototypes; campos comuns também podem ser mapeados manualmente com JSONPath para macros personalizadas. Quanto mais estável esse contrato, mais reutilizável é a regra.

Nome e key devem deixar claro que aquilo é discovery

As guidelines oficiais recomendam nomes terminando em “discovery” e keys terminando em “.discovery”. Isso não é apenas estética: torna busca, exportação e leitura de templates muito mais previsíveis. Nomes gerados pelos prototypes devem começar pelo nome da entidade descoberta quando aplicável.

Discovery é operação relativamente pesada

LLD não deve rodar na mesma frequência de métricas comuns sem necessidade. As guidelines recomendam começar em torno de 1 hora e ajustar conforme a dinâmica do ambiente. Interfaces e filesystems normalmente mudam muito menos que tráfego ou CPU. Uma descoberta a cada 30 segundos raramente agrega valor proporcional ao custo.

Descobrir tudo é fácil; descobrir apenas o que importa é engenharia

Filtros usam LLD macros e expressões para aceitar ou rejeitar entidades. Em redes, é comum eliminar loopback, interfaces administrativas, túneis, subinterfaces sem importância e portas sem alias operacional. Em storage, mounts temporários podem ser descartados. O filtro deve reduzir ruído sem eliminar entidades que futuramente podem ganhar relevância.

Override permite uma política diferente sem duplicar a regra

Overrides avaliam condições sobre entidades descobertas e alteram propriedades dos prototypes: descoberta, estado, intervalo, history, trends, severidade, tags, templates e outros atributos suportados. Isso permite tratar uplinks, portas de cliente e interfaces internas com políticas diferentes dentro da mesma LLD.

Entidades desaparecem; a configuração precisa envelhecer corretamente

LLD possui políticas para recursos perdidos. O default recomendado pelas guidelines para delete lost resources é 7 dias. Em ambientes altamente dinâmicos pode ser menor; em infraestruturas onde interfaces oscilam ou inventário muda durante manutenção, remoção imediata pode destruir histórico e contexto cedo demais.

Prototype é uma fábrica de objetos

Item prototype, trigger prototype, graph prototype, host prototype e discovery prototype representam padrões que serão instanciados para cada entidade. O prototype deve ser pensado como código parametrizado: qualquer erro será multiplicado por todas as entidades descobertas.

Tags descobertas tornam eventos autoexplicativos

Item e trigger prototypes podem receber tags contendo LLD macros. Isso permite que cada evento carregue contexto como interface, filesystem, sensor, database ou serviço descoberto. As guidelines recomendam valores de tags padronizados e permitem macros LLD nos valores.

Um walk pode substituir centenas de consultas repetidas

Desde a abordagem moderna de SNMP walk, um item master com walk[] pode coletar uma tabela de uma vez. O resultado pode alimentar dependent items e LLD, reduzindo round trips. Essa arquitetura é especialmente eficiente para tabelas de interfaces, sensores e entidades indexadas por SNMP.

Índice SNMP não deve ser tratado como identidade humana

O índice SNMP é um mecanismo de endereçamento da tabela e pode mudar após reboot, alteração de configuração ou firmware. Sempre que possível, descubra atributos estáveis — nome, alias, serial, descrição — e use o índice apenas para localizar o valor. A lógica operacional não deve depender de “ifIndex 27” como se fosse identidade permanente.

Zabbix 7.4 permite descoberta em camadas

O Zabbix 7.4 introduziu discovery prototypes: regras LLD dentro de outra regra LLD. Isso permite descobrir uma entidade pai e, para cada pai, descobrir seus filhos. O modelo é útil quando uma API ou sistema possui hierarquia natural, como instância → banco → tablespace → tabela ou cluster → nó → interface.

A origem do dado influencia limites práticos

Quando o JSON LLD chega diretamente ao Server, ele pode ser processado sem persistência intermediária no banco. Quando passa por Proxy, o Proxy precisa armazenar os dados, então limites e características do banco entram no caminho. Retornos gigantes também aumentam parsing, memória e complexidade de troubleshooting.

Discovery e dependent items combinam muito bem

Uma coleta master pode trazer uma lista completa de entidades e seus atributos. Um dependent LLD extrai a estrutura de descoberta; dependent item prototypes extraem métricas individuais. Isso reduz requests e mantém descoberta e métricas baseadas na mesma fotografia do alvo.

Automação sem governança apenas cria configuração mais rápido

Toda regra de discovery deve possuir owner, escopo, critérios, naming e política de lifecycle. Em ambientes grandes, automação precisa ser previsível o suficiente para permitir auditoria: por que este host apareceu? qual regra o criou? por que recebeu este template? qual condição o classificou?

Duas interfaces, um JSON, vários prototypes

[
  {
    "{#IFNAME}": "ge-0/0/0",
    "{#IFALIAS}": "UPLINK-CORE",
    "{#IFTYPE}": "ethernetCsmacd",
    "{#SNMPINDEX}": "27"
  },
  {
    "{#IFNAME}": "ge-0/0/1",
    "{#IFALIAS}": "CLIENTE-001",
    "{#IFTYPE}": "ethernetCsmacd",
    "{#SNMPINDEX}": "28"
  }
]

A mesma regra pode criar item prototypes de tráfego, status, erros e velocidade; trigger prototypes podem usar alias/nome nas tags e no event name.

O prototype precisa produzir objetos legíveis depois de expandido

Item prototype:
Name: Interface {#IFNAME}: Bits received
Key:  net.if.in["{#IFNAME}"]

Trigger prototype:
Name: Interface {#IFNAME}: Link down

Tags:
component=network
interface={#IFNAME}
interface-alias={#IFALIAS}
scope=availability

Whitelist operacional costuma ser mais segura que “monitorar tudo”

Uma regra, políticas diferentes por função

LLD: Network interface discovery

Override #1
IF {#IFALIAS} matches ^UPLINK-
THEN:
  trigger severity = High
  tag role = uplink

Override #2
IF {#IFALIAS} matches ^BACKUP-
THEN:
  trigger severity = Warning
  tag role = backup

Override #3
IF {#IFNAME} matches ^lo$
THEN:
  discover = No

Colete a tabela uma vez

# Master item conceitual
walk[ifDescr,ifName,ifAlias,ifOperStatus,ifHCInOctets,ifHCOutOctets]

# O resultado pode alimentar:
- regra LLD de interfaces
- item prototype de status
- item prototype de tráfego RX
- item prototype de tráfego TX
- trigger prototype
- tags por interface

Descoberta hierárquica

Database server discovery
│
├── Instance A
│   └── Database discovery
│       ├── DB01
│       │   └── Tablespace discovery
│       └── DB02
│           └── Tablespace discovery
│
└── Instance B
    └── Database discovery

Discovery prototypes possuem seus próprios item, trigger, graph, host e discovery prototypes, permitindo compor múltiplos níveis sem achatar uma hierarquia natural em uma regra gigante.

Perder uma entidade não é o mesmo que apagá-la imediatamente

Descobrir rede com classificação progressiva

Range: 10.20.0.0/24

Checks:
1. ICMP
2. SNMP sysObjectID
3. SNMP sysName

Action:
IF ICMP + SNMP respondem
AND sysObjectID corresponde ao vendor esperado
THEN
  criar host
  adicionar grupo correto
  adicionar tags
  vincular template correspondente

Metadata pode dirigir o onboarding

HostMetadata=linux,web,production

Action conditions:
metadata contains linux
metadata contains production

Operations:
- add host
- group: Servers/Linux
- link: Linux by Zabbix agent
- apply tags: environment=production

Automação que cria dívida técnica

LLD de interfaces com política por alias

Valide criação, alteração e remoção

Antes de liberar discovery em escala

Base factual

Conteúdo construído a partir da documentação oficial Zabbix 7.4 sobre Network Discovery, Active Agent Autoregistration, Low-Level Discovery, LLD macros, filters, overrides, lost resources, SNMP walk, nested low-level discovery e das Template Guidelines oficiais. Os modelos de governança, laboratórios, estratégias de filtro, lifecycle e recomendações operacionais são síntese editorial própria.

Linha Zabbix 7.4

Zabbix 7.4 adicionou nested LLD e host prototypes em hosts descobertos, permitindo hierarquias de descoberta mais profundas; use filtros e overrides para evitar explosão de entidades.