3 agent SNMP

Visão geral

Talvez você queira usar monitoramento SNMP em dispositivos como impressoras, switches de rede, roteadores ou UPS, que normalmente são compatíveis com SNMP e nos quais seria impraticável tentar configurar sistemas operacionais completos e agents do Zabbix.

Para conseguir recuperar dados fornecidos por agents SNMP nesses dispositivos, o server do Zabbix deve ser configurado inicialmente com suporte a SNMP, especificando a flag --with-net-snmp. Também é recomendável instalar arquivos MIB para garantir que os valores dos items sejam exibidos no formato correto. Sem os arquivos MIB, podem ocorrer problemas de formatação, como exibir valores em HEX em vez de UTF-8 ou vice-versa.

As verificações SNMP são executadas somente sobre o protocolo UDP.

Os daemons do server e do proxy do Zabbix registram linhas semelhantes à seguinte se receberem uma resposta SNMP incorreta:

SNMP response from host "gateway" does not contain all of the requested variable bindings

Embora não cubram todos os casos problemáticos, elas são úteis para identificar dispositivos SNMP individuais para os quais as solicitações combinadas devem ser desativadas.

O server/proxy do Zabbix tentará novamente até 5 vezes para items SNMP walk e get. O mecanismo de repetição não se aplica a falhas de resolução de DNS.

Para verificações SNMP legadas (OID único numérico ou string), o server/proxy do Zabbix tentará pelo menos mais uma vez após uma tentativa de consulta malsucedida: seja por meio do mecanismo de repetição da biblioteca SNMP ou por meio do mecanismo interno de processamento combinado.

Se estiver monitorando dispositivos SNMPv3, certifique-se de que msgAuthoritativeEngineID (também conhecido como snmpEngineID ou "Engine ID") nunca seja compartilhado por dois dispositivos. De acordo com o RFC 2571 (seção 3.1.1.1), ele deve ser único para cada dispositivo.

O RFC3414 exige que os dispositivos SNMPv3 persistam seus engineBoots. Alguns dispositivos não fazem isso, o que faz com que suas mensagens SNMP sejam descartadas como desatualizadas após uma reinicialização. Nessa situação, o cache SNMP precisa ser limpo manualmente em um server/proxy (usando -R snmp_cache_reload) ou o server/proxy precisa ser reiniciado.

Configurando o monitoramento SNMP

Para começar a monitorar um dispositivo via SNMP, as seguintes etapas devem ser executadas:

Etapa 1

Descubra a string SNMP (ou OID) do item que você deseja monitorar.

Para obter uma lista de strings SNMP, use o comando snmpwalk (parte do software net-snmp, que você deve ter instalado como parte da instalação do Zabbix) ou uma ferramenta equivalente:

snmpwalk -v 2c -c public <host IP> .

Como 2c aqui representa a versão do SNMP, você também pode substituí-lo por 1, para indicar a Versão 1 do SNMP no dispositivo.

Isso deve fornecer uma lista de strings SNMP e seu último valor. Se isso não acontecer, é possível que a "community" SNMP seja diferente do padrão public; nesse caso, você precisará descobrir qual é.

Em seguida, você pode percorrer a lista até encontrar a string que deseja monitorar, por exemplo: se você quisesse monitorar os bytes recebidos pelo seu switch na porta 3, usaria a string IF-MIB::ifHCInOctets.3 desta linha:

IF-MIB::ifHCInOctets.3 = Counter64: 3409739121

Agora você pode usar o comando snmpget para descobrir o OID numérico de IF-MIB::ifHCInOctets.3:

snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3

Observe que o último número na string é o número da porta que você deseja monitorar. Veja também: Índices dinâmicos.

Isso deve fornecer algo como o seguinte:

.1.3.6.1.2.1.31.1.1.1.6.3 = Counter64: 3472126941

Novamente, o último número no OID é o número da porta.

Alguns dos OIDs SNMP mais usados são traduzidos automaticamente para uma representação numérica pelo Zabbix.

No último exemplo acima, o tipo de valor é "Counter64", que internamente corresponde ao tipo ASN_COUNTER64. A lista completa de tipos suportados é ASN_COUNTER, ASN_COUNTER64, ASN_UINTEGER, ASN_UNSIGNED64, ASN_INTEGER, ASN_INTEGER64, ASN_FLOAT, ASN_DOUBLE, ASN_TIMETICKS, ASN_GAUGE, ASN_IPADDRESS, ASN_OCTET_STR e ASN_OBJECT_ID. Esses tipos correspondem, de forma aproximada, a "Counter32", "Counter64", "UInteger32", "INTEGER", "Float", "Double", "Timeticks", "Gauge32", "IpAddress", "OCTET STRING", "OBJECT IDENTIFIER" na saída do snmpget, mas também podem ser exibidos como "STRING", "Hex-STRING", "OID" e outros, dependendo da presença de uma dica de exibição.

Etapa 2

Crie um host correspondente a um dispositivo.

Adicione uma interface SNMP para o host:

  1. Informe o endereço IP/nome DNS e o número da porta.
  2. Selecione a versão SNMP no menu suspenso.
  3. Adicione as credenciais da interface de acordo com a versão SNMP selecionada:
    • SNMPv1, v2 exigem apenas a community (geralmente 'public').
    • SNMPv3 exige opções mais específicas; consulte SNMPv3.
  4. Especifique o valor máximo de repetição (padrão: 10) para solicitações bulk SNMP nativas (GetBulkRequest-PDUs); somente para itens discovery[] e walk[] em SNMPv2 e v3. Observe que definir esse valor muito alto pode causar timeout na verificação do agent SNMP.
  5. Marque a caixa de seleção Usar solicitações combinadas para permitir o processamento combinado de solicitações SNMP (não relacionado às solicitações bulk SNMP nativas "walk" e "get").

Você pode usar um dos templates SNMP fornecidos, que adicionará automaticamente um conjunto de items. Antes de usar um template, verifique se ele é compatível com o host.

Clique em Adicionar para salvar o host.

SNMPv3

Os seguintes parâmetros são necessários para SNMPv3:

  • Context name - Informe o nome do contexto para identificar o item na sub-rede SNMP.
    Macros de usuário são resolvidas neste campo.
  • Security name - Informe o nome de segurança.
    Macros de usuário são resolvidas neste campo.
  • Security level - Selecione o nível de segurança:
    • noAuthNoPriv - nenhum protocolo de autenticação nem de privacidade é usado;
    • AuthNoPriv - o protocolo de autenticação é usado, o protocolo de privacidade não;
    • AuthPriv - ambos os protocolos de autenticação e privacidade são usados.
  • Authentication protocol - Selecione o protocolo de autenticação: MD5, SHA1; com net-snmp 5.8 e versões mais recentes, SHA224, SHA256, SHA384 ou SHA512.
  • Authentication passphrase - Informe a frase secreta de autenticação.
    Macros de usuário são resolvidas neste campo.
  • Privacy protocol - Selecione o protocolo de privacidade: DES, AES128, AES192, AES256, AES192C (Cisco) ou AES256C (Cisco).
    Consulte as observações sobre suporte ao protocolo de privacidade.
  • Privacy passphrase - Informe a frase secreta de privacidade.
    Macros de usuário são resolvidas neste campo.

Em caso de credenciais SNMPv3 incorretas (security name, authentication protocol/passphrase, privacy protocol):

  • O Zabbix recebe um ERROR do net-snmp, exceto no caso de Privacy passphrase incorreta, em que o Zabbix recebe um erro TIMEOUT do net-snmp.
  • A disponibilidade da interface SNMP será alterada para vermelho (indisponível).

Alterações em Authentication protocol, Authentication passphrase, Privacy protocol ou Privacy passphrase, feitas sem alterar o Security name, normalmente são aplicadas automaticamente quando a interface SNMPv3 correspondente é atualizada no Zabbix. Nos casos em que Security name também é alterado, todos os parâmetros serão atualizados imediatamente.

Você pode usar um dos templates SNMP fornecidos, que adicionará automaticamente um conjunto de items. Antes de usar um template, verifique se ele é compatível com o host.

Clique em Add para salvar o host.

Suporte a protocolo de privacidade

Dependendo do seu sistema operacional e da configuração do net-snmp, alguns protocolos de privacidade podem não estar disponíveis:

  • Em alguns sistemas operacionais mais novos (por exemplo, RHEL9), o suporte a DES é removido do pacote net-snmp.

  • Os protocolos de criptografia AES192 e mais fortes não são suportados nativamente em sistemas operacionais mais antigos que RHEL 8, CentOS 8, Oracle Linux 8, Debian 12, Ubuntu LTS 22.04, openSUSE Leap 15.5.

Para verificar se a biblioteca net-snmp oferece suporte a AES192+, use uma das seguintes opções:

  1. net-snmp-config:
net-snmp-config --configure-options

Se a saída contiver --enable-blumenthal-aes, o AES192+ é suportado.

Observe que net-snmp-config faz parte do pacote de desenvolvimento para SNMP (libsnmp-dev para Debian/Ubuntu, net-snmp-devel para CentOS/RHEL/OL/SUSE) e pode não estar instalado por padrão.

  1. snmpget:
snmpget -v 3 -x AES-256

Se a saída contiver Invalid privacy protocol specified after -3x flag: AES-256, o AES192+ não é suportado. Se a saída contiver No hostname specified., o AES192+ não é suportado.

Se a sua biblioteca net-snmp não oferecer suporte aos protocolos AES192 e superiores, recompile o net-snmp com a opção --enable-blumenthal-aes e, em seguida, recompile o Zabbix server especificando a opção --with-net-snmp=/home/user/yourcustomnetsnmp/bin/net-snmp-config.

Etapa 3

Crie um item para monitoramento.

Agora, volte ao Zabbix e clique em Items para o host SNMP criado anteriormente. Dependendo de você ter usado ou não um template ao criar o host, haverá uma lista de itens SNMP associados ao host ou apenas uma lista vazia. Vamos supor que você criará o item manualmente usando as informações obtidas com snmpwalk e snmpget. Portanto, clique em Create item.

Preencha os parâmetros obrigatórios no formulário do novo item:

Parâmetro Descrição
Name Insira o nome do item.
Type Selecione SNMP agent aqui.
Key Insira uma chave significativa.
Host interface Certifique-se de selecionar a interface SNMP, por exemplo, do seu switch/roteador.
SNMP OID Use um dos formatos compatíveis para inserir o(s) valor(es) de OID:

walk[OID1,OID2,...] - recupera uma subárvore de valores.
Por exemplo: walk[1.3.6.1.2.1.2.2.1.2,1.3.6.1.2.1.2.2.1.3].
Essa opção usa solicitações bulk nativas do SNMP (GetBulkRequest-PDUs) de forma assíncrona.
As configurações de tempo limite para este item podem ser definidas no formulário de configuração do item. Considere definir um valor de tempo limite baixo para evitar longos atrasos se o dispositivo estiver inacessível, pois serão feitas até 5 tentativas caso as anteriores atinjam o tempo limite ou falhem (por exemplo, um tempo limite de 3 segundos pode resultar em uma espera de 15 segundos).
Você pode usar este item como item mestre, com itens dependentes que extraem dados do item mestre usando o pré-processamento.
É possível especificar vários OIDs em um único snmp walk, como walk[OID1,OID2,...], para processar cada OID de forma assíncrona.
Se a solicitação bulk não retornar resultados, será feita uma tentativa de recuperar um único registro sem uma solicitação bulk.
Os nomes MIB são compatíveis como parâmetros; portanto, walk[1.3.6.1.2.1.2.2.1.2] e walk[ifDescr] retornarão a mesma saída.
Se vários OIDs/MIBs forem especificados, por exemplo, walk[ifDescr,ifType,ifPhysAddress], a saída será uma lista concatenada.
As solicitações GetBulk são usadas com interfaces SNMPv2 e v3, e GetNext com interfaces SNMPv1; o número máximo de repetições para solicitações bulk é configurado no nível da interface.
O parâmetro de número máximo de repetições afeta as solicitações bulk ao determinar o número máximo de OIDs retornados em uma única resposta bulk.
Um valor maior resulta em respostas bulk maiores, reduzindo o número de transmissões necessárias. No entanto, alguns dispositivos podem não ser compatíveis com valores muito altos, o que pode causar problemas.
Este item retorna a saída do utilitário snmpwalk com os parâmetros -Oe -Ot -On.
Você pode usar este item como item mestre em descoberta SNMP.

get[OID] - recupera um único valor de forma assíncrona.
Por exemplo: get[1.3.6.1.2.1.31.1.1.1.6.3]
As configurações de tempo limite para este item podem ser definidas no formulário de configuração do item. Considere definir um valor de tempo limite baixo para evitar longos atrasos se o dispositivo estiver inacessível, pois serão feitas até 5 tentativas caso as anteriores atinjam o tempo limite ou falhem (por exemplo, um tempo limite de 3 segundos pode resultar em uma espera de 15 segundos).

OID - (legado) insira um OID textual ou numérico único para recuperar um único valor de forma síncrona, opcionalmente combinado com outros valores.
Por exemplo: 1.3.6.1.2.1.31.1.1.1.6.3.
Para esta opção, o tempo limite da verificação do item será igual ao valor definido no arquivo de configuração do server.

É recomendável usar itens walk[OID] e get[OID] para obter melhor desempenho. Todos os itens walk[OID] e get[OID] são executados de forma assíncrona - não é necessário receber a resposta de uma solicitação antes que outras verificações sejam iniciadas. A resolução de DNS também é assíncrona.
A simultaneidade máxima de verificações assíncronas é 1000 (definida por MaxConcurrentChecksPerPoller). O número de pollers SNMP assíncronos é definido pelo parâmetro StartSNMPPollers.

Observe que, para estatísticas de tráfego de rede retornadas por qualquer um dos métodos, uma etapa Change per second deve ser adicionada na aba Preprocessing; caso contrário, você obterá o valor cumulativo do dispositivo SNMP em vez da alteração mais recente.

Todos os campos de entrada obrigatórios são marcados com um asterisco vermelho.

Agora, salve o item e acesse Monitoring > Latest data para visualizar os dados SNMP.

Exemplo 1

Exemplo geral:

Parâmetro Descrição
OID 1.2.3.45.6.7.8.0 (ou .1.2.3.45.6.7.8.0)
Chave <String única a ser usada como referência para triggers>
Por exemplo, "my_param".

Observe que o OID pode ser fornecido em formato numérico ou string. No entanto, em alguns casos, o OID em string deve ser convertido para a representação numérica. A ferramenta snmpget pode ser usada para este propósito:

snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0

Exemplo 2

Monitoramento do tempo de atividade:

Parâmetro Descrição
OID MIB::sysUpTime.0
Key router.uptime
Tipo de valor Float
Unidades uptime
Etapa de pré-processamento: Multiplicador personalizado 0.01

Requisições nativas SNMP bulk

O item walk[OID1,OID2,...] permite usar a funcionalidade nativa do SNMP para requisições bulk (GetBulkRequest-PDUs), disponível nas versões 2/3 do SNMP.

Uma requisição GetBulk no SNMP executa múltiplas requisições GetNext e retorna o resultado em uma única resposta. Isso pode ser usado para itens SNMP regulares, bem como para descoberta SNMP, para minimizar as idas e vindas na rede.

O item SNMP walk[OID1,OID2,...] pode ser usado como o item mestre que coleta dados em uma única requisição, com itens dependentes que analisam a resposta conforme necessário usando pré-processamento.

Observe que o uso de requisições nativas SNMP bulk não está relacionado à opção de combinar requisições SNMP, que é a própria maneira do Zabbix de combinar múltiplas requisições SNMP (veja a próxima seção).

Até cinco tentativas serão feitas para itens SNMP bulk para evitar falha se um dos pacotes for perdido. O timeout para itens SNMP com get e walk (definido no formulário de configuração do item) é definido para toda a sessão. O timeout é aplicado independentemente de os dados serem recuperados completamente; se os dados forem recebidos parcialmente (por exemplo, os dados são coletados com sucesso para apenas um dos múltiplos OIDs), então o item se torna não suportado com a mensagem "Only partial data received". Se o timeout for atingido, uma nova tentativa será feita, o timeout será reiniciado e a última requisição será reenviada, permitindo continuar a sessão a partir da última requisição se um único pacote for perdido ou chegar tarde demais. Considere definir um valor de timeout baixo para evitar longos atrasos se o dispositivo estiver inacessível, pois até 5 tentativas serão feitas se as anteriores expirarem ou falharem (por exemplo, um timeout de 3 segundos pode resultar em um tempo de espera de 15 segundos).

Funcionamento interno do processamento combinado

O Zabbix server e o proxy podem consultar dispositivos SNMP para obter vários valores em uma única solicitação. Isso afeta vários tipos de itens SNMP:

Todos os itens SNMP em uma única interface com parâmetros idênticos são agendados para serem consultados ao mesmo tempo. Os dois primeiros tipos de itens são obtidos pelos pollers em lotes de, no máximo, 128 itens, enquanto as regras de descoberta de baixo nível são processadas individualmente, como antes.

Em um nível inferior, há dois tipos de operações realizadas para consultar valores: obter vários objetos especificados e percorrer uma árvore de OID.

Para a operação de "obtenção", um GetRequest-PDU é usado com, no máximo, 128 associações de variáveis. Para a operação de "percurso", um GetNextRequest-PDU é usado para SNMPv1, e um GetBulkRequest com o campo "max-repetitions" de, no máximo, 128 é usado para SNMPv2 e SNMPv3.

Assim, os benefícios do processamento combinado para cada tipo de item SNMP são descritos abaixo:

  • os itens SNMP regulares se beneficiam das melhorias na "obtenção";
  • os itens SNMP com índices dinâmicos se beneficiam das melhorias tanto na "obtenção" quanto no "percurso": a "obtenção" é usada para verificar o índice, e o "percurso" é usado para criar o cache;
  • as regras de descoberta de baixo nível SNMP se beneficiam das melhorias no "percurso".

No entanto, existe um problema técnico: nem todos os dispositivos são capazes de retornar 128 valores por solicitação. Alguns sempre retornam uma resposta adequada, mas outros respondem com um erro "tooBig(1)" ou não respondem quando a resposta potencial ultrapassa determinado limite.

Para encontrar um número ideal de objetos a serem consultados para um determinado dispositivo, o Zabbix usa a estratégia a seguir. Ele começa de forma cautelosa, consultando 1 valor por solicitação. Se isso for bem-sucedido, consulta 2 valores por solicitação. Se isso também for bem-sucedido, consulta 3 valores por solicitação e continua de forma semelhante, multiplicando o número de objetos consultados por 1,5, resultando na seguinte sequência de tamanhos de solicitação: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.

No entanto, quando um dispositivo se recusa a fornecer uma resposta adequada (por exemplo, para 42 variáveis), o Zabbix faz duas coisas.

Primeiro, para o lote de itens atual, ele reduz pela metade o número de objetos em uma única solicitação e consulta 21 variáveis. Se o dispositivo estiver ativo, a consulta deverá funcionar na grande maioria dos casos, pois já se sabe que 28 variáveis funcionam, e 21 é significativamente menos que isso. No entanto, se isso ainda falhar, o Zabbix volta a consultar os valores um por um. Se ainda falhar nesse ponto, o dispositivo definitivamente não está respondendo, e o tamanho da solicitação não é o problema.

A segunda ação que o Zabbix realiza para os lotes de itens subsequentes é começar com o último número de variáveis bem-sucedido (28 no nosso exemplo) e continuar incrementando o tamanho das solicitações em 1 até que o limite seja atingido. Por exemplo, supondo que o maior tamanho de resposta seja de 32 variáveis, as solicitações subsequentes terão os tamanhos 29, 30, 31, 32 e 33. A última solicitação falhará, e o Zabbix nunca mais emitirá uma solicitação de tamanho 33. A partir desse ponto, o Zabbix consultará no máximo 32 variáveis para esse dispositivo.

Se consultas grandes falharem com esse número de variáveis, isso pode significar uma de duas coisas. Os critérios exatos usados por um dispositivo para limitar o tamanho da resposta não podem ser conhecidos, mas tentamos fazer uma aproximação usando o número de variáveis. A primeira possibilidade é que esse número de variáveis esteja próximo do limite real de tamanho de resposta do dispositivo no caso geral: às vezes, a resposta é menor que o limite e, às vezes, é maior. A segunda possibilidade é que um pacote UDP em qualquer uma das direções simplesmente tenha sido perdido. Por esses motivos, quando o Zabbix recebe uma consulta com falha, ele reduz o número máximo de variáveis a serem tentadas para avançar mais na faixa confortável do dispositivo, mas somente até duas vezes.

No exemplo acima, se uma consulta com 32 variáveis falhar, o Zabbix reduzirá a quantidade para 31. Se isso também falhar, o Zabbix reduzirá a quantidade para 30. No entanto, o Zabbix não reduzirá a quantidade para menos de 30, pois presumirá que falhas adicionais são causadas pela perda de pacotes UDP, e não pelo limite do dispositivo.

Se, no entanto, um dispositivo não conseguir processar corretamente solicitações combinadas por outros motivos e a heurística descrita acima não funcionar, haverá uma configuração Use combined requests para cada interface, que permite desativar as solicitações combinadas para esse dispositivo.

Se as solicitações combinadas causarem respostas parciais ou malformadas que resultem em cálculos incorretos por segundo (delta) (por exemplo, picos aparentes nos contadores de interface), desative Use combined requests para a interface afetada a fim de forçar consultas separadas por item; isso geralmente evita picos falsos. Como alternativa, considere usar itens assíncronos get[] ou walk[], que são executados de forma assíncrona e não estão sujeitos ao agrupamento por interface de Use combined requests — eles podem ser usados no lugar das verificações de OID síncronas legadas para evitar problemas relacionados a solicitações combinadas. Procure nos logs do server/proxy entradas semelhantes à mostrada na seção Visão geral para ajudar a identificar os dispositivos afetados.

Além disso, se a interface ficar indisponível com frequência, pode ser necessário aumentar o parâmetro UnavailableDelay nos arquivos de configuração do Zabbix server ou do Zabbix proxy para reduzir a frequência das solicitações. Os itens podem se tornar não suportados se dados parciais forem recebidos durante a descoberta ou durante percursos de OID.