Descoberta de OIDs SNMP
Visão geral
Nesta seção, realizaremos uma descoberta de baixo nível em um dispositivo SNMP.
Este método de descoberta de OIDs SNMP é suportado desde o Zabbix server/proxy 6.4.
Configuração de exemplo
1. Crie um item de agente SNMP com uma chave como:
walk[.1.3.6.1.4.1.9999.1.1.1.1]

Este item executa uma única consulta de tabela SNMP e retorna todas as entradas da tabela em uma solicitação, em um formato correspondente à saída do utilitário snmpwalk com as opções de formatação -Oe -Ot -On.
Ele retornará o seguinte valor de texto multilinha:
.1.3.6.1.4.1.9999.1.1.1.1.1.1 = STRING: "Temperature Sensor"
.1.3.6.1.4.1.9999.1.1.1.1.2.1 = STRING: "temp"
.1.3.6.1.4.1.9999.1.1.1.1.3.1 = 100
.1.3.6.1.4.1.9999.1.1.1.1.1.2 = STRING: "Humidity Sensor"
.1.3.6.1.4.1.9999.1.1.1.1.2.2 = STRING: "humidity"
.1.3.6.1.4.1.9999.1.1.1.1.3.2 = 200
2. Crie uma regra de descoberta:
- No campo Name, insira um nome descritivo para a regra de descoberta (por exemplo, "Descobrir sensores").
- No campo Type, selecione "Dependent item".
- No campo Key, insira uma chave descritiva (por exemplo, "net.if.discovery").
- No campo Master item, selecione "SNMP walk item".

3. Na aba Preprocessing, adicione uma etapa de pré-processamento com "SNMP walk to JSON" no menu suspenso Name, com 3 parâmetros:
- Field name: "{#SENSORNAME}"; OID prefix: ".1.3.6.1.4.1.9999.1.1.1.1.1": Format: "Unchanged".
- Field name: "{#SENSORTYPE}"; OID prefix: ".1.3.6.1.4.1.9999.1.1.1.1.2": Format: "Unchanged".
- Field name: "{#SENSORVALUE}"; OID prefix: ".1.3.6.1.4.1.9999.1.1.1.1.3": Format: "Unchanged".
Após o pré-processamento, a regra de descoberta retorna um array JSON de conjuntos de macros.
Por exemplo:
[
{
"{#SNMPINDEX}": "1",
"{#SENSORNAME}": "Temperature Sensor",
"{#SENSORTYPE}": "temp",
"{#SENSORVALUE}": "100"
},
{
"{#SNMPINDEX}": "2",
"{#SENSORNAME}": "Humidity Sensor",
"{#SENSORTYPE}": "humidity",
"{#SENSORVALUE}": "200"
}
]
Cada objeto representa um sensor descoberto e fornece macros como {#SNMPINDEX}, {#SENSORNAME}, {#SENSORTYPE} e {#SENSORVALUE}.
Eles são agrupados pelo índice SNMP, que é o sufixo numérico no final de cada OID (por exemplo, .1, .2). Esse índice identifica exclusivamente cada linha na tabela SNMP e é extraído automaticamente como {#SNMPINDEX}.
4. Na regra de descoberta, crie um ou mais protótipos de item (com a regra de descoberta como item mestre).
Por exemplo, um item dependente do valor do sensor:
- No campo Name, insira "Sensor {#SNMPINDEX}: {#SENSORNAME}".
- No campo Type, selecione "Dependent item".
- No campo Key, insira "sensor.value[{#SNMPINDEX}]".
- No campo Master item, selecione "SNMP walk item".

Na aba Preprocessing, adicione uma etapa de pré-processamento com o nome "SNMP walk value", inserindo o OID ".1.3.6.1.4.1.9999.1.1.1.1.3.{#SNMPINDEX}" no campo Parameter. Format: "Unchanged".
Os itens a seguir serão descobertos:
| Name | Key | OID from which value is extracted | Item value |
|---|---|---|---|
| Sensor 1: Temperature Sensor | sensor.value[1] | .1.3.6.1.4.1.9999.1.1.1.1.3.1 | 100 |
| Sensor 2: Humidity Sensor | sensor.value[2] | .1.3.6.1.4.1.9999.1.1.1.1.3.2 | 200 |
Quando a regra de descoberta for executada, itens como sensor.value[1] e sensor.value[2] serão criados.
Cada item dependente extrai seu valor do resultado da consulta SNMP do item mestre usando o pré-processamento, sem executar solicitações SNMP separadas.
5. Faça referência aos protótipos de item dependentes nos protótipos de trigger usando as mesmas macros da regra de descoberta. Exemplo:
{Template_Sensor:sensor.value[{#SNMPINDEX}].last()} > 75
Isso cria um trigger para cada sensor descoberto (por exemplo, sensor.value[1] e sensor.value[2]) e o ativa se o valor mais recente (temperatura ou umidade) exceder 75.
6. Inclua itens dependentes para cada entidade descoberta. Exemplo de chave de item de gráfico:
sensor.value[{#SNMPINDEX}]
Um gráfico é criado para cada {#SNMPINDEX}, exibindo a temperatura e a umidade ao longo do tempo.
Essa configuração executa apenas uma solicitação de consulta SNMP por ciclo de coleta, independentemente do número de itens descobertos. Todos os itens dependentes extraem seus valores do resultado da consulta SNMP do item mestre usando o pré-processamento, reduzindo significativamente o tráfego e a carga do SNMP.
Índices dinâmicos com walk[]
Os índices dinâmicos (por exemplo, índices de interface) podem mudar quando o hardware é reconfigurado. Para acomodar esse comportamento, uma regra de descoberta mestre SNMP walk é criada com uma chave como:
walk[1.3.6.1.2.1.2.2.1.10]
Após o pré-processamento SNMP walk para JSON, o resultado pode ser semelhante a:
[
{
"{#SNMPINDEX}": "2",
"{#VALUE}": "123456"
},
{
"{#SNMPINDEX}": "3",
"{#VALUE}": "654321"
}
]
Um protótipo de item dependente usa a macro {#SNMPINDEX} para construir a chave:
net.if.in[{#SNMPINDEX}]
O pré-processamento para este protótipo inclui o nome "SNMP walk value" com o OID "1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}" no campo Parâmetro. Formato: "Inalterado".
Em tempo de execução, itens reais como net.if.in[2] e net.if.in[3] são criados.
Se um determinado índice de interface mudar (por exemplo, se o índice 2 for substituído por 5 na tabela SNMP), então na próxima execução da regra de descoberta:
- O item dependente antigo net.if.in[2] é marcado como "perdido" ou removido, e nenhum novo dado é coletado para esse item.
- Um novo item dependente net.if.in[5] é criado, começando com um histórico vazio.
- Os dados históricos de net.if.in[2] não são movidos automaticamente para net.if.in[5].
Exemplo de protótipo de trigger:
{Template_Interface:net.if.in[{#SNMPINDEX}].last()} > 1000000000
Exemplo de protótipo de gráfico inclui itens:
net.if.in[{#SNMPINDEX}]
net.if.out[{#SNMPINDEX}]
Esta configuração garante o monitoramento confiável de tabelas com índices dinâmicos, minimizando o tráfego SNMP—apenas um único SNMP walk por ciclo de coleta é necessário, com protótipos de itens dependentes extraindo os valores necessários.
Entidades descobertas
Quando o server é executado, ele criará itens dependentes reais, triggers e gráficos com base nos valores que a regra de descoberta SNMP retorna.