Table of Contents
2 Agente SNMP
Visão geral
Você pode querer usar o monitoramento SNMP em dispositivos como impressoras, switches de rede, roteadores ou nobreaks que geralmente possuem SNMP habilitado e nos quais seria impraticável tentar configurar sistemas operacionais completos e agents Zabbix.
Para poder recuperar dados fornecidos por agents SNMP nesses dispositivos, o server Zabbix deve ser inicialmente configurado com suporte a SNMP, especificando o parâmetro --with-net-snmp. Recomenda-se também 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 realizadas apenas pelo protocolo UDP.
Os daemons do server e do proxy Zabbix registram linhas semelhantes à seguinte se receberem uma resposta SNMP incorreta:
Embora não cubram todos os casos problemáticos, são úteis para identificar dispositivos SNMP individuais para os quais as solicitações combinadas devem ser desabilitadas.
O server/proxy Zabbix sempre tentará novamente pelo menos 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 exclusivo para cada dispositivo.
O RFC3414 exige que os dispositivos SNMPv3 persistam seus engineBoots. Alguns dispositivos não fazem isso, o que resulta em suas mensagens SNMP sendo descartadas como desatualizadas após serem reiniciadas. 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.
O Zabbix armazena em cache os mapeamentos SNMPv3 EngineID → IP e reutiliza os EngineIDs em cache para verificações subsequentes, em vez de enviar uma sonda a cada vez, reduzindo o tráfego de rede. Se um EngineID não puder ser reutilizado, uma nova tentativa com uma sonda será realizada para descobrir o novo EngineID.
Configurando o monitoramento SNMP
Para começar a monitorar um dispositivo via SNMP, as seguintes etapas devem ser executadas:
Passo 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 deve ter sido instalado como parte da instalação do Zabbix) ou ferramenta equivalente:
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 seus últimos valores. Se não fornecer, é possível que a 'comunidade' SNMP seja diferente da padrão 'public', caso em que você precisará descobrir qual é.
Você pode então percorrer a lista até encontrar a string que deseja monitorar, por exemplo, se você quiser monitorar os bytes que entram em seu switch na porta 3, você usaria a string IF-MIB::ifHCInOctets.3 desta linha:
Agora você pode usar o comando snmpget para descobrir o OID numérico para '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:
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 aproximadamente 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.
Passo 2
Crie um host correspondente a um dispositivo.
Adicione uma interface SNMP para o host:
- Insira o endereço IP/nome DNS e o número da porta.
- Selecione a versão SNMP no menu suspenso.
- Adicione as credenciais da interface dependendo da versão SNMP selecionada:
- SNMPv1, v2 exigem apenas a comunidade (geralmente 'public').
- SNMPv3 requer opções mais específicas (veja abaixo).
- Especifique o valor de repetição máxima (padrão: 10) para requisições nativas SNMP bulk (GetBulkRequest-PDUs); apenas para itens
discovery[]ewalk[]em SNMPv2 e v3. Observe que definir esse valor muito alto pode causar o tempo limite da verificação do agent SNMP. - Marque a caixa Usar requisições combinadas para permitir o processamento combinado de requisições SNMP (não relacionado às requisições nativas SNMP bulk "walk" e "get").
| Parâmetro SNMPv3 | Descrição |
|---|---|
| Nome do contexto | Insira o nome do contexto para identificar o item na sub-rede SNMP. Macros de usuário são resolvidas neste campo. |
| Nome de segurança | Insira o nome de segurança. Macros de usuário são resolvidas neste campo. |
| Nível de segurança | Selecione o nível de segurança: noAuthNoPriv - nem protocolos de autenticação nem de privacidade são usados AuthNoPriv - protocolo de autenticação é usado, protocolo de privacidade não AuthPriv - ambos os protocolos de autenticação e privacidade são usados |
| Protocolo de autenticação | Selecione o protocolo de autenticação - MD5, SHA1; com net-snmp 5.8 e mais recentes SHA224, SHA256, SHA384 ou SHA512. |
| Senha de autenticação | Insira a senha de autenticação. Macros de usuário são resolvidas neste campo. |
| Protocolo de privacidade | Selecione o protocolo de privacidade - DES, AES128, AES192, AES256, AES192C (Cisco) ou AES256C (Cisco). Veja as notas sobre suporte ao protocolo de privacidade |
| Senha de privacidade | Insira a senha de privacidade. Macros de usuário são resolvidas neste campo. |
No caso de credenciais SNMPv3 incorretas (nome de segurança, protocolo/senha de autenticação, protocolo de privacidade):
- O Zabbix recebe um ERRO do net-snmp, exceto para Senha de privacidade incorreta, caso em que o Zabbix recebe um erro de TIMEOUT do net-snmp.
- A disponibilidade da interface SNMP mudará para vermelho (indisponível).
Alterações em Protocolo de autenticação, Senha de autenticação, Protocolo de privacidade ou Senha de privacidade, feitas sem alterar o Nome de segurança, normalmente são aplicadas automaticamente quando a interface SNMPv3 correspondente é atualizada no Zabbix. Nos casos em que o Nome de segurança 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 Adicionar para salvar o host.
Suporte ao 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 recentes (por exemplo, RHEL9), o suporte ao DES foi removido do pacote net-snmp.
Protocolos de criptografia AES192 e superiores não são suportados por padrão 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 suporta AES192+, use uma das opções a seguir:
net-snmp-config:
Se a saída contiver --enable-blumenthal-aes, AES192+ é suportado.
Observe que o 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.
snmpget:
Se a saída contiver Invalid privacy protocol specified after -3x flag: AES-256, AES192+ não é suportado. Se a saída contiver No hostname specified., AES192+ não é suportado.
Se sua biblioteca net-snmp não suportar os 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.
Passo 3
Crie um item para monitoramento.
Agora, volte ao Zabbix e clique em Itens para o host SNMP que você criou anteriormente. Dependendo se você usou um template ou não ao criar seu host, você terá uma lista de itens SNMP associados ao seu host ou apenas uma lista vazia. Vamos trabalhar com a suposição de que você irá criar o item manualmente usando as informações que acabou de coletar usando snmpwalk e snmpget, então clique em Criar item.
Preencha os parâmetros necessários no novo formulário de item:
| Parâmetro | Descrição |
|---|---|
| Nome | Insira o nome do item. |
| Tipo | Selecione SNMP agent aqui. |
| Chave | Insira a chave como algo significativo. |
| Interface do host | Certifique-se de selecionar a interface SNMP, por exemplo, do seu switch/roteador. |
| SNMP OID | Use um dos formatos suportados para inserir o(s) valor(es) do 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].Esta opção faz uso de requisições nativas SNMP bulk (GetBulkRequest-PDUs) de forma assíncrona. As configurações de timeout para este item podem ser definidas no formulário de configuração do item. Considere definir um valor de timeout baixo para evitar longos atrasos caso o dispositivo esteja 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). Você pode usar este item como item mestre, com itens dependentes que extraem dados do mestre usando pré-processamento. É possível especificar múltiplos OIDs em um único snmp walk, como walk[OID1,OID2,...] para processar um OID por vez de forma assíncrona.Se a requisição bulk não retornar resultados, será feita uma tentativa de recuperar um único registro sem requisição bulk. Nomes de MIB são suportados como parâmetros; assim, 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, ou seja, walk[ifDescr,ifType,ifPhysAddress], então a saída será uma lista concatenada.Requisições GetBulk são usadas com interfaces SNMPv2 e v3 e GetNext para interfaces SNMPv1; o número máximo de repetições para requisições bulk é configurado no nível da interface. O parâmetro de repetições máximas afeta as requisições bulk determinando o número máximo de OIDs retornados em uma única resposta bulk. Um valor mais alto resulta em respostas bulk maiores, reduzindo o número de transmissões necessárias. No entanto, nem todos os dispositivos podem suportar 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 timeout para este item podem ser definidas no formulário de configuração do item. Considere definir um valor de timeout baixo para evitar longos atrasos caso o dispositivo esteja 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). OID - (legado) insira um único OID textual ou numérico 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 timeout da checagem do item será igual ao valor definido no arquivo de configuração do server. É recomendado usar os itens walk[OID] e get[OID] para 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 requisição antes que outras checagens sejam iniciadas. A resolução de DNS também é assíncrona.A concorrência máxima de checagens 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, um passo Alteração por segundo deve ser adicionado na aba Pré-processamento; caso contrário, você obterá o valor acumulado do dispositivo SNMP em vez da última alteração. |
Todos os campos obrigatórios estão marcados com um asterisco vermelho.
Agora salve o item e vá para Monitoramento > Últimos dados para seus 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:
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 walk[OID1,OID2,...] item permite usar a funcionalidade nativa SNMP para requisições bulk (GetBulkRequest-PDUs), disponível nas versões SNMP 2/3.
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).
Uma nova tentativa ocorrerá 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. Se o timeout for atingido, uma nova tentativa ocorrerá, o timeout será redefinido 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 novas 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 múltiplos valores em uma única requisição. Isso afeta vários tipos de items SNMP:
- items SNMP regulares
- items SNMP com índices dinâmicos
- regras de descoberta de baixo nível SNMP
Todos os items SNMP em uma única interface com parâmetros idênticos são agendados para serem consultados ao mesmo tempo. Os dois primeiros tipos de items são processados pelos pollers em lotes de no máximo 128 items, enquanto as regras de descoberta de baixo nível são processadas individualmente, como antes.
Em um nível mais baixo, existem dois tipos de operações realizadas para consultar valores: obter múltiplos objetos especificados e percorrer uma árvore OID.
Para "obter", um GetRequest-PDU é usado com no máximo 128 ligações de variáveis. Para "percorrer", um GetNextRequest-PDU é usado para SNMPv1 e 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:
- items SNMP regulares se beneficiam das melhorias de "obtenção";
- items SNMP com índices dinâmicos se beneficiam tanto das melhorias de "obtenção" quanto de "percorrimento": "obtenção" é usada para verificação de índice e "percorrimento" para construir o cache;
- regras de descoberta de baixo nível SNMP se beneficiam das melhorias de "percorrimento".
No entanto, há uma questão técnica de que nem todos os dispositivos são capazes de retornar 128 valores por requisição. Alguns sempre retornam uma resposta adequada, mas outros respondem com um erro "tooBig(1)" ou não respondem de forma alguma quando a resposta potencial ultrapassa um determinado limite.
Para encontrar um número ideal de objetos para consultar em um determinado dispositivo, o Zabbix usa a seguinte estratégia. Ele começa cautelosamente consultando 1 valor em uma requisição. Se isso for bem-sucedido, ele consulta 2 valores em uma requisição. Se isso for bem-sucedido novamente, ele consulta 3 valores em uma requisição e continua de forma semelhante, multiplicando o número de objetos consultados por 1,5, resultando na seguinte sequência de tamanhos de requisição: 1, 2, 3, 4, 6, 9, 13, 19, 28, 42, 63, 94, 128.
No entanto, uma vez que um dispositivo se recusa a fornecer uma resposta adequada (por exemplo, para 42 variáveis), o Zabbix faz duas coisas.
Primeiro, para o lote atual de items, ele reduz pela metade o número de objetos em uma única requisição e consulta 21 variáveis. Se o dispositivo estiver ativo, a consulta deve funcionar na grande maioria dos casos, porque 28 variáveis eram conhecidas por funcionar e 21 é significativamente menos do que isso. No entanto, se ainda falhar, o Zabbix volta a consultar os valores um por um. Se ainda falhar neste ponto, então o dispositivo definitivamente não está respondendo e o tamanho da requisição não é o problema.
A segunda coisa que o Zabbix faz para os próximos lotes de items é começar com o último número bem-sucedido de variáveis (28 em nosso exemplo) e continuar incrementando os tamanhos das requisições em 1 até atingir o limite. Por exemplo, assumindo que o maior tamanho de resposta seja 32 variáveis, as requisições subsequentes terão os tamanhos 29, 30, 31, 32 e 33. A última requisição falhará e o Zabbix nunca mais fará uma requisição de tamanho 33. A partir desse ponto, o Zabbix consultará no máximo 32 variáveis para esse dispositivo.
Se grandes requisições falharem com esse número de variáveis, isso pode significar uma de duas coisas. Os critérios exatos que um dispositivo usa para limitar o tamanho da resposta não podem ser conhecidos, mas tentamos aproximar isso usando o número de variáveis. Assim, 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, às vezes é maior. A segunda possibilidade é que um pacote UDP em qualquer direção simplesmente se perdeu. Por esses motivos, se o Zabbix receber uma consulta com falha, ele reduz o número máximo de variáveis para tentar chegar mais fundo na faixa confortável do dispositivo, mas apenas até duas vezes.
No exemplo acima, se uma consulta com 32 variáveis falhar, o Zabbix reduzirá a contagem para 31. Se isso também falhar, o Zabbix reduzirá a contagem para 30. No entanto, o Zabbix não reduzirá a contagem abaixo de 30, porque assumirá que falhas adicionais são devido à perda de pacotes UDP, em vez do limite do dispositivo.
Se, no entanto, um dispositivo não puder lidar com requisições combinadas corretamente por outros motivos e a heurística descrita acima não funcionar, existe uma configuração "Usar requisições combinadas" para cada interface que permite desabilitar requisições combinadas para esse dispositivo.
Além disso, se a interface frequentemente se tornar indisponível, 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 requisições. Os items podem se tornar não suportados se dados parciais forem recebidos durante a descoberta ou percorrimento de OIDs.