A Low-Level Discovery (LLD), ou Descoberta de Baixo Nível, é um dos recursos mais importantes do Zabbix para criar monitoramentos escaláveis e de fácil manutenção. Embora o Zabbix permita a criação manual de itens para equipamentos de rede, servidores Windows e Linux ou serviços específicos, essa abordagem rapidamente se torna inviável em ambientes maiores.
Criar itens manualmente funciona perfeitamente para cenários pontuais. É possível, por exemplo, definir métricas fixas para uma interface específica ou para um determinado serviço do sistema operacional. O problema surge quando pensamos em escalabilidade e replicação.
Mas imagine um equipamento de rede com 48 interfaces. Se cada interface exigir:
- 9 itens, será necessário criar 432 itens manualmente;
- 18 itens, o número sobe para 864 itens.
Esse modelo é sustentável a longo prazo? E como ficaria a manutenção de todos esses itens?
O mesmo cenário se repete em servidores. Serviços, discos, interfaces e partições precisariam ser criados e mantidos manualmente. O resultado é um alto custo operacional, mais retrabalho e uma arquitetura de monitoramento pouco eficiente.
É justamente para eliminar esse trabalho repetitivo que a LLD existe. Por meio dela, o Zabbix consegue descobrir automaticamente recursos do ambiente e criar os itens, gatilhos e gráficos necessários de forma dinâmica, tornando o monitoramento mais automatizado, padronizado e simples de administrar.
A seguir, vamos entender melhor o funcionamento do monitoramento hierárquico com LLD e como implementá-lo corretamente no Zabbix.
O que é Low-Level Discovery
Low-Level Discovery (LLD) é um tipo de configuração que permite no Zabbix a criação de itens, triggers, gráficos e até hosts de maneira automática, a partir de uma configuração de Discovery (Descoberta) via SNMP, HTTP, External Scripts, entre outras opções.
Com a utilização da LLD, o Zabbix se torna capaz de iniciar o monitoramento de interfaces de rede ou serviços automaticamente, criar as triggers, gráficos sem a necessidade de criar itens para cada sistemas de arquivos ou interfaces manualmente. A LLD também é capaz de criar hosts de hypervisores como, por exemplo, VMware ou Proxmox a partir do vcenter, criando o monitoramento das máquinas virtuais e hypervisores.
A LLD utiliza o protocolo JSON como formato de dados:
SNMP
[
{
"{#SNMPINDEX}": "1",
"{#IFNAME}": "vmnic0",
"{#IFDESCR}": "Device vmnic0 at 43:00.0 bnxtnet",
"{#IFTYPE}": "6",
"{#IFOPERSTATUS}": "1",
"{#IFADMINSTATUS}": "1",
"{#IFDEVDES}": "CPU Pkg/ID/Node: 0/0/0 Intel(R) Xeon(R) Silver 4314 CPU @ 2.40G"
},
{
"{#SNMPINDEX}": "2",
"{#IFNAME}": "vmnic1",
"{#IFDESCR}": "Device vmnic1 at 43:00.1 bnxtnet",
"{#IFTYPE}": "6",
"{#IFOPERSTATUS}": "1",
"{#IFADMINSTATUS}": "1",
"{#IFDEVDES}": "CPU Pkg/ID/Node: 0/1/0 Intel(R) Xeon(R) Silver 4314 CPU @ 2.40G"
},
{
"{#SNMPINDEX}": "3",
"{#IFNAME}": "vmnic2",
"{#IFDESCR}": "Device vmnic2 at 72:00.0 ntg3",
"{#IFTYPE}": "6",
"{#IFOPERSTATUS}": "2",
"{#IFADMINSTATUS}": "1",
"{#IFDEVDES}": "CPU Pkg/ID/Node: 0/2/0 Intel(R) Xeon(R) Silver 4314 CPU @ 2.40G"
}
]
HTTP
[
{
"database": "db1",
"created_at": "2024-02-01T12:30:00Z",
"encoding": "UTF8",
"tablespaces": [
{
"name": "ts1",
"max_size": "10GB"
},
{
"name": "ts2",
"max_size": "20GB"
},
{
"name": "ts3",
"max_size": "15GB"
}
]
},
{
"database": "db2",
"created_at": "2023-11-15T08:45:00Z",
"encoding": "UTF16",
"tablespaces": [
{
"name": "ts1",
"max_size": "5GB"
},
{
"name": "ts2",
"max_size": "25GB"
},
{
"name": "ts3",
"max_size": "30GB"
}
]
}
]
Dessa maneira, independente da forma de construção da descoberta, é necessário respeitar e estar adequado ao protocolo JSON.
Desde a versão 4.2 do Zabbix, não é mais esperado que contenha o objeto “data” no formato JSON retornado pela LLD. Assim, a LLD é capaz de aceitar um JSON normal, contendo apenas um array, além de ser capaz de executar novos recursos como pré-processamento do valor do item, caminhos personalizados, entre outras possibilidades.
Após essas alterações, a LLD é capaz de extrair de forma automática o valor da chave e atribuir a uma macro, usando {#MACRO} = $.chave, por exemplo. Quaisquer novas verificações usaram sem a necessidade de conter o elemento “data”.
Com o recurso de LLD macros, podemos mapear qualquer chave que está no JSON para ser uma macro na descoberta. Isso será útil para criar os itens, triggers, gráficos e também as tags. Podemos fazer o uso das macros também nos filtros e no overrides.
Monitoramento hierárquico
A seguir, apresentamos os elementos que fazem parte de um sistema de monitoramento hierárquico.
Hosts
Imagine uma solicitação do time de operações exigindo o monitoramento, via Zabbix, de um ambiente VMware composto por 200 máquinas virtuais e 6 hypervisors. Esse monitoramento é fundamental para a conclusão de um projeto crítico, e a equipe dispõe de apenas 3 dias para cadastrar e validar tudo.
A primeira ideia seria recorrer à API do Zabbix combinada com automação em Python ou outra linguagem. No entanto, o próprio Zabbix já oferece um recurso extremamente eficiente: o Monitoramento VMware nativo, capaz de descobrir e cadastrar automaticamente hypervisors e VMs a partir de um único host configurado.
O trabalho inicial da equipe se resume a revisar e customizar os templates VMware oficiais, ajustando-os ao cenário necessário, seja adicionando ou removendo métricas, alterando severidades de triggers, criando novos itens, entre outros ajustes.
De posse das credenciais do VMware e da URL do vCenter, basta criar o host no Zabbix, associar o template adequado e deixar que a LLD (Low-Level Discovery) faça o restante. Em poucos minutos, o Zabbix identifica todo o ambiente e cria automaticamente os hosts correspondentes, eliminando a necessidade de cadastros manuais.
Esse é apenas um exemplo da eficiência da criação de hosts via LLD. A mesma abordagem pode ser aplicada a diversos outros cenários, como controladoras Wi-Fi de fabricantes Cisco, Huawei, UniFi, Aruba e muitas outras, permitindo o descobrimento automático de APs, interfaces, rádios e demais componentes.
Itens
Com o uso de Low-Level Discovery, é possível criar itens de praticamente qualquer tipo, automatizando rotinas e tornando o monitoramento muito mais inteligente, padronizado e dinâmico. Entre os tipos de itens que podem ser descobertos automaticamente estão sistemas de arquivos, interfaces de rede, serviços, volumes, instâncias, entre muitos outros.
Podemos mapear qualquer chave que está no JSON para ser uma macro na descoberta. Isso será útil para criar os itens, triggers, gráficos e também as tags. Também podemos fazer o uso das macros também nos filtros e no overrides.
Além disso, ao criar itens via LLD, o Zabbix aplica a lógica interna para decidir quando criar, atualizar, desabilitar ou remover itens automaticamente, de acordo com:
- Filtros (aceitar ou descartar descobertas com base em regras);
- Overrides (substituições condicionais de propriedades dos itens);
- Mudanças detectadas no ambiente.
Dessa forma, o monitoramento se mantém sempre coerente com a realidade, reduzindo trabalho manual, eliminando erros e garantindo escalabilidade para ambientes grandes e dinâmicos.
Triggers
As triggers geradas via LLD são configuradas dentro da mesma regra de descoberta utilizada para os itens. A lógica de criação é idêntica à das triggers tradicionais: utilizam as mesmas funções, expressões e operadores do Zabbix. A principal diferença está na expressão, que normalmente utiliza macros de descoberta para referenciar dinamicamente os itens criados.
Por exemplo, ao monitorar o uso de sistemas de arquivos, uma trigger LLD pode utilizar a macro {#FSNAME} para identificar cada volume individualmente. Assim, uma expressão como:
{Template vFS: vfs.fs.size[{#FSNAME},pfree].last()} < 20
Que pode representar a regra: “Disparar alerta se o volume descoberto estiver com menos de 20% de espaço livre”.
As triggers LLD podem ser configuradas para:
- Serem criadas habilitadas ou apenas descobertas (ficando desativadas inicialmente);
- Receber tags específicas;
- Seguir padrões de severidade definidos no protótipo.
Além disso, as triggers descobertas também podem ser modificadas por meio de overrides, permitindo ajustes finos como:
- Alterar severidades conforme critérios específicos;
- Habilitar ou desabilitar determinadas triggers;
- Adicionar ou remover tags;
- Customizar expressões de acordo com padrões pré-definidos.
Dessa forma, o uso de triggers via LLD garante automação, consistência e escalabilidade, acompanhando dinamicamente qualquer mudança no ambiente monitorado.
Exemplos práticos de Low-Level Discovery
Descoberta de interfaces de rede
Para criar um monitoramento de interfaces de rede automaticamente, é possível usar os seguintes passos:
Criar uma descoberta em lista de descobertas contendo:
- Nome: Network interfaces Discovery;
- Tipo: SNMP Agent;
- Key: net.if.discoverySNMP OID = discovery[{#IFOPERSTATUS},1.3.6.1.2.1.2.2.1.8,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFNAME},1.3.6.1.2.1.31.1.1.1.1,{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFTYPE},1.3.6.1.2.1.2.2.1.3];
- Update interval: 1h ou 1d;
- Excluir recursos perdidos: dem quantos dias o item, triggers e gráficos após não serem encontrados mais pela LLD.
- Caso coloque 1d, será excluído em 1 dia, 30d em trinta dias e 0d será imediatamente excluído.
- Desabilitar recursos perdidos: essa nova opção permite desabilitar os itens, fazendo com que não haja itens não suportados ou alertas desnecessários no ambiente. Há 3 opções: Nunca, Imediatamente e Após;
- Descrição: insira uma breve descrição sobre o que se trata a LLD.
Exemplo da Discovery:
Quando corretamente configurada, essa descoberta retornará algo parecido como:
{
"{#SNMPINDEX}": "9",
"{#IFOPERSTATUS}": "1",
"{#IFADMINSTATUS}": "1",
"{#IFALIAS}": AP_192.168.16.200",
"{#IFNAME}": "Gi1/0/1",
"{#IFDESCR}": "GigabitEthernet1/0/1",
"{#IFTYPE}": "6",
"{#IFTRUNK}": "2"
},
{
"{#SNMPINDEX}": "10",
"{#IFOPERSTATUS}": "1",
"{#IFADMINSTATUS}": "1",
"{#IFALIAS}": "AP_192.168.16.199",
"{#IFNAME}": "Gi1/0/2",
"{#IFDESCR}": "GigabitEthernet1/0/2",
"{#IFTYPE}": "6",
"{#IFTRUNK}": "1"
},
{
"{#SNMPINDEX}": "11",
"{#IFOPERSTATUS}": "1",
"{#IFADMINSTATUS}": "1",
"{#IFALIAS}": "DVR 192.168.0.100",
"{#IFNAME}": "Gi1/0/3",
"{#IFDESCR}": "GigabitEthernet1/0/3",
"{#IFTYPE}": "6",
"{#IFTRUNK}": "2"
}
Observe que sempre será retornado um objeto JSON, como já dito anteriormente. Nele estão as macros que poderão ser utilizadas para criação de filtros, nomes de itens, triggers e gráficos.
Seguimos com o exemplo.
Em protótipos de itens, acesse e crie um novo, seguindo os parâmetros abaixo:
- Nome: insira o nome, como Interface {#IFNAME}({#IFALIAS}): Bits received (observe o uso das macros);
- Tipo: nesse caso, SNMP Agent;
- Chave: Identificador de até 2048 caracteres. Ela deve ser única, utilize as macros. Neste caso use: net.if.in[ifHCInOctets.{#SNMPINDEX}];
- Tipo de informação: qual tipo de dado será armazenado no banco de dados do Zabbix, como número (inteiro ou fload), caractere, log, texto ou binário. Neste exemplo: Número Inteiro;
- SNMP OID: correspondente a árvore OID, onde está a informação: 1.3.6.1.2.1.31.1.1.1.6.{#SNMPINDEX};
- Unidades: para interfaces de rede utilize bps, o Zabbix irá realizar a conversão em bytes por segundo (1024 -> 1 KBps);
- Intervalo de atualização: intervalo emque o Zabbix irá consultar do equipamento de rede o valor sendo trafegado referente a OID. Neste exemplo 3m;
- Histórico: Temos duas opções: “Não armazenar” ou “Armazenar até”;
- Não armazenar: o valor não será salvo no banco de dados;
- Armazenar até: especificar a duração de armazenamento de histórico detalhado, bruto no banco de dados. Neste exemplo, usaremos 7 dias, 7d;
- Tendências: temos as opções “Não armazenar” ou “Armazenar até”.
- Não armazenar: o valor não será salvo no banco de dados.
- Armazenar até: especificar a duração de armazenamento de tendências, que é o histórico agregado, sendo o cálculo de mínima, média e máxima, contagem por hora.
Por se tratar de um item com alterações por segundos, configure, na etapa de pré-processamento:
- Alterações por segundos;
- Multiplicador customizado: 8.
Com essa configuração, o Zabbix será capaz de criar quantos itens de interface do tipo bits received existirem no equipamento monitorado.
Descoberta de sistemas de arquivos
Para criarmos uma regra de descoberta automatizada de sistemas de arquivos, podemos utilizar a descoberta via Zabbix Agent, SNMP, External Scripts, HTTP e etc. Neste exemplo, vamos demonstrar com o uso do Zabbix Agent.
Em “Descoberta”, crie uma nova com os seguintes parâmetros:
- Nome: Mounted filesystem Discovery;
- Tipo: Zabbix Agent;
- Chave: vfs.fs.discovery;
- Intervalo de atualização: 1d ou 1h;
- Excluir recursos perdidos: 30d ou 7d.
Com essa configuração, o Zabbix será capaz de se comunicar com o host alvo, realizar uma descoberta de todas as partições ou sistemas de arquivos presentes:
{
"{#FSNAME}": "/boot",
"{#FSTYPE}": "xfs"
},
{
"{#FSNAME}": "/opt",
"{#FSTYPE}": "xfs"
},
{
"{#FSNAME}": "/usr/users",
"{#FSTYPE}": "xfs"
},
{
"{#FSNAME}": "/var",
"{#FSTYPE}": "xfs"
},
{
"{#FSNAME}": "/root/home",
"{#FSTYPE}": "xfs"
},
{
"{#FSNAME}": "/var/crash",
"{#FSTYPE}": "xfs"
},
{
"{#FSNAME}": "/app",
"{#FSTYPE}": "xfs"
},
{
"{#FSNAME}": "/home",
"{#FSTYPE}": "xfs"
}
Podemos observar que o JSON retorna todos os sistemas de arquivos montados no sistema. Com base no retorno, podemos criar os itens de acordo com nossa necessidade.
Aqui, criaremos o item para utilização do espaço. Para isso, clique em “Novo” e defina:
- Nome: {#FSNAME}: Space utilization, onde a macro, será o nome do sistema de arquivos retornado pelo JSON;
- Tipo: Zabbix Agent;
- Chave: vfs.fs.size[{#FSNAME},pused];
- Tipo de informação: númerico float;
- Unidade: neste caso, será porcentagem, então utilize o símbolo %;
- Intervalo de atualização: 15m.
- Para Histórico e Tendências: utilizar 7 dias e 365 dias, respectivamente.
Logo, devemos ter essa configuração:
Após a descoberta ser realizada no host destino, o Zabbix irá criar os itens. Aqui temos o item de monitoramento para Espaço utilizado em /home:
Com o gráfico devidamente criado, devemos ter um resultado similar a este:
Descoberta de aplicações
Imagine agora que um host com SO Windows subiu recentemente no monitoramento Zabbix e também possui serviços a serem monitorados. Com uso do Zabbix Agent e chaves específicas, isso é possível. Veja como:
Em “Descoberta”, crie:
- Nome: Windows services discovery;
- Tipo: Zabbix Agent;
- Chave: service.discovery;
- Intervalo de atualização: 1 dia ou 1 hora;
- Excluir recursos perdidos: 30d ou 7d
Com essa configuração de descoberta, o Zabbix é capaz de trazer as seguintes informações iniciais:
{
"{#SERVICE.NAME}": "AJRouter",
"{#SERVICE.DISPLAYNAME}": "AllJoyn Router Service",
"{#SERVICE.DESCRIPTION}": "Routes AllJoyn messages for the local AllJoyn clients. If this service is stopped the AllJoyn clients that do not have their own bundled routers will be unable to run.",
"{#SERVICE.STATE}": 6,
"{#SERVICE.STATENAME}": "stopped",
"{#SERVICE.PATH}": "C:\\Windows\\system32\\svchost.exe -k LocalServiceNetworkRestricted -p",
"{#SERVICE.USER}": "NT AUTHORITY\\LocalService",
"{#SERVICE.STARTUPTRIGGER}": 1,
"{#SERVICE.STARTUP}": 2,
"{#SERVICE.STARTUPNAME}": "manual"
},
{
"{#SERVICE.NAME}": "ALG",
"{#SERVICE.DISPLAYNAME}": "Application Layer Gateway Service",
"{#SERVICE.DESCRIPTION}": "Provides support for 3rd party protocol plug-ins for Internet Connection Sharing",
"{#SERVICE.STATE}": 6,
"{#SERVICE.STATENAME}": "stopped",
"{#SERVICE.PATH}": "C:\\Windows\\System32\\alg.exe",
"{#SERVICE.USER}": "NT AUTHORITY\\LocalService",
"{#SERVICE.STARTUPTRIGGER}": 0,
"{#SERVICE.STARTUP}": 2,
"{#SERVICE.STARTUPNAME}": "manual"
}
Com essas informações, estamos prontos para criar os itens.
Em “Protótipos de Itens”, crie:
- Nome: State of service “{#SERVICE.NAME}” ({#SERVICE.DISPLAYNAME});
- Tipo: Zabbix Agent;
- Chave: service.info[“{#SERVICE.NAME}”,state];
- Tipo de informação: numérico inteiro;
- Intervalo de Atualização: 1m ou 3m.
- Para Histórico e Tendências: utilizar 7 dias e 365 dias, respectivamente.
Logo, devemos ter essa configuração:
Com esses parâmetros, o Zabbix deve ser capaz de criar todos os itens referentes a descobertas de serviços existentes no host.
Boas práticas no uso de Low-Level Discovery
Ao projetar regras de Low-Level Discovery (LLD) no Zabbix, é essencial adotar alguns cuidados para evitar sobrecarga no ambiente e criação excessiva de itens. Dois pontos críticos de atenção são a explosão de itens e o intervalo de descoberta.
Explosão de itens
Uma LLD mal configurada pode gerar milhares de itens desnecessários em um host, aumentando o volume de dados armazenados, consumindo mais recursos do servidor Zabbix e degradando o desempenho geral.
Para minimizar esse risco, é fundamental utilizar Filtros de LLD, que permitem criar apenas os itens realmente necessários. Alguns exemplos de filtragem eficiente incluem:
- Criar itens apenas para interfaces cujo status operacional esteja “UP”.
- Descobrir portas somente quando a descrição da interface contiver uma string específica, como “[Monitor]”.
- Excluir interfaces virtuais, VLANs, loopbacks ou portas administrativas, dependendo da necessidade do ambiente.
Uma LLD bem ajustada produz um conjunto de itens limpo e relevante, garantindo eficiência no monitoramento.
Intervalo de descoberta da LLD
O intervalo de descoberta determina com que frequência o Zabbix executa novamente a LLD para identificar novos elementos ou remover elementos inexistentes.
Intervalos muito curtos podem:
- Gerar sobrecarga no servidor,
- Aumentar o número de requisições ao host monitorado,
- Provocar processamento desnecessário.
Recomenda-se definir esse intervalo com prudência, considerando a natureza dos objetos monitorados e a frequência com que mudam.
Intervalo de atualização dos itens descobertos
Cada item criado por uma LLD possui seu próprio intervalo de atualização (update interval), que define o tempo entre as coletas de dados. Esse intervalo deve refletir a variabilidade da métrica:
a) Itens com pouca ou nenhuma alteração
Exemplos:
- Velocidade da interface (ifSpeed);
- Tamanho do disco.
Nesse caso, o intervalo recomendado é entre 12h e 24h.
b) Itens com alterações pontuais, porém recorrentes
Exemplos:
- Renovação de tokens;
- Volume de disco com baixa variação.
Nesse caso, o intervalo recomendado é entre 3h e 6h.
c) Itens com alterações constantes
Exemplos:
- Tráfego de rede;
- Uso de CPU;
- Uso de memória;
- I/O de disco.
Aqui, o intevalo recomendado é entre 1 e 5 minutos, dependendo da criticidade da métrica e do ambiente monitorado.
- Importante: intervalos inferiores a 10 segundos devem ser evitados, pois tendem a gerar carga excessiva e instabilidade no monitoramento.
d) Item com alterações pontuais, mas que ocorre todos os dias
Podemos utilizar o update em 3h ou 6h, principalmente em casos como renovação de token de acesso ou espaço em disco pouco utilizado.
e) Itens com alterações constantes, frequentemente utilizados, como tráfego em portas de rede, utilização de memória, utilização de CPU
Para esses tipos de itens, podemos utilizar desde 1 minuto até 3 minutos ou 5 minutos, tudo depende do ambiente e criticidade da métrica no negócio. O ideal é que não seja menor que 10 segundos.
Além das boas práticas já mencionadas, outro recurso essencial para manter um ambiente de monitoramento eficiente é a limpeza automática dos itens que deixam de ser retornados pela LLD ou que passam a não atender mais aos filtros configurados.
Quando a LLD executa novamente o processo de descoberta, o Zabbix identifica:
- Elementos que não existem mais no host;
- Elementos que foram renomeados;
- Elementos que mudaram de estado;
- Elementos que deixaram de cumprir os filtros definidos na regra.
Nesse caso, o mecanismo de limpeza automática garante que esses itens sejam automaticamente removidos após o período configurado. Essa remoção é fundamental para:
- Manter o banco de dados do Zabbix limpo e otimizado;
- Evitar acúmulo de itens obsoletos;
- Reduzir indicadores marcados como “Not supported”;
- Impedir consumo desnecessário de CPU, memória e I/O no servidor;
- Garantir que apenas itens válidos e relevantes continuem sendo monitorados.
Uma política eficiente de limpeza automática complementa diretamente o uso de filtros e intervalos adequados, contribuindo para um ambiente mais leve, estável e com melhor desempenho.
Aprimore o uso de LLD na sua empresa
A adoção de Low‑Level Discovery (LLD) no Zabbix transforma o monitoramento em um processo escalável, padronizado e sustentável, eliminando tarefas manuais repetitivas e reduzindo a suscetibilidade a erros humanos.
Ao substituir a criação manual de itens, triggers e gráficos por protótipos e regras de descoberta, ganhamos consistência de configuração entre instâncias, aceleramos a implantação e asseguramos uma manutenção muito mais simples em ambientes dinâmicos e de grande porte.
Conte com a equipe técnica da Zabbix para indicar as melhores soluções para o seu negócio. Confira, em nossa página de Serviços Profissionais, como podemos apoiar o seu negócio a ter melhores resultados com Zabbix.
Prev Post 
