3 agent SNMP
Visão geral
Você pode querer usar monitoramento SNMP em dispositivos como impressoras, switches de rede, roteadores ou UPS, que normalmente têm SNMP habilitado e nos quais seria impraticável tentar configurar sistemas operacionais completos e agents do Zabbix.
Para poder recuperar dados fornecidos por agents SNMP nesses dispositivos, o Zabbix server deve ser inicialmente configurado 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 realizadas somente pelo protocolo UDP.
Os daemons do Zabbix server e do proxy registram linhas semelhantes às seguintes se receberem uma resposta SNMP incorreta:
SNMP response from host "gateway" does not contain all of the requested variable bindingsEmbora 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 Zabbix server/proxy 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 (número OID único ou string), o Zabbix server/proxy tentará novamente pelo menos uma vez após uma tentativa de consulta sem sucesso: 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 o msgAuthoritativeEngineID (também conhecido como snmpEngineID ou "Engine ID") nunca seja compartilhado por dois dispositivos. De acordo com a RFC 2571 (seção 3.1.1.1), ele deve ser exclusivo para cada dispositivo.
A 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 serem reiniciados. 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 de EngineID → IP do SNMPv3 e reutiliza os EngineIDs em cache para verificações subsequentes, em vez de enviar uma sondagem todas as vezes, reduzindo o tráfego de rede. Se um EngineID não puder ser reutilizado, será feita uma nova tentativa com uma sondagem 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:
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 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:
IF-MIB::ifHCInOctets.3 = Counter64: 3409739121Agora você pode usar o comando snmpget para descobrir o OID numérico para 'IF-MIB::ifHCInOctets.3':
snmpget -v 2c -c public -On <host IP> IF-MIB::ifHCInOctets.3Observe 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: 3472126941Novamente, 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.
Etapa 2
Crie um host correspondente a um dispositivo.
Adicione uma interface SNMP para o host:
- Informe 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 de acordo com a versão SNMP selecionada:
- SNMPv1, v2 exigem apenas a community (normalmente 'public').
- SNMPv3 exige opções mais específicas (veja abaixo).
- Especifique o valor máximo de repetição (padrão: 10) para solicitações nativas SNMP bulk (GetBulkRequest-PDUs); somente para itens
discovery[]ewalk[]em SNMPv2 e v3. Observe que definir esse valor muito alto pode causar timeout na verificação do agent SNMP. - Marque a caixa de seleção Use combined requests para permitir o processamento combinado de solicitações SNMP (não relacionado às solicitações bulk nativas SNMP "walk" e "get").
| Parâmetro SNMPv3 | Descrição |
|---|---|
| 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 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-senha 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-senha de privacidade. Macros de usuário são resolvidas neste campo. |
No 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 mudará 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 o 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 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:
net-snmp-config --configure-optionsSe 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:
snmpget -v 3 -x AES-256Se 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.
Etapa 3
Crie um item para monitoramento.
Agora, volte ao Zabbix e clique em Items para o host SNMP que você criou anteriormente. Dependendo de você ter usado ou não um template ao criar o host, você terá uma lista de itens SNMP associados ao seu host ou apenas uma lista vazia. Vamos assumir que você vai criar o item por conta própria usando as informações que acabou de coletar com snmpwalk e snmpget; portanto, clique em Create item.
Preencha os parâmetros obrigatórios no novo formulário de item:
| Parameter | Description |
|---|---|
| Name | Digite o nome do item. |
| Type | Selecione SNMP agent aqui. |
| Key | Digite a key de forma significativa. |
| Host interface | 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) 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].Esta opção faz uso de native SNMP bulk requests (GetBulkRequest-PDUs) de forma assíncrona. As configurações de timeout para este item podem ser definidas no formulário de item configuration. 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 item mestre usando pré-processamento. É possível especificar vários OIDs em um único snmp walk, como walk[OID1,OID2,...], para processar de forma assíncrona um OID por vez.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], a saída será uma lista concatenada.As requisições GetBulk são usadas com interfaces SNMPv2 e v3, e GetNext com 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 ao determinar 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 da utilidade snmpwalk com os parâmetros -Oe -Ot -On. Você pode usar este item como item mestre em SNMP discovery. get[OID] - recupera um valor único 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 item configuration. 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 verificação do item será igual ao valor definido no configuration file do server. É recomendado usar 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 verificações sejam iniciadas. A resolução de DNS também é assíncrona.A concorrência 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 última alteração. |
Todos os campos obrigatórios de entrada são marcados com um asterisco vermelho.
Agora salve o item e vá para Monitoring > Latest data para ver 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:
snmpget -On localhost public enterprises.ucdavis.memory.memTotalSwap.0Exemplo 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 vários valores em uma única solicitação. Isso afeta vários tipos de itens SNMP:
- itens SNMP regulares
- itens SNMP com índices dinâmicos
- regras de descoberta em baixo nível 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 processados pelos pollers em lotes de no máximo 128 itens, enquanto as regras de descoberta em baixo nível são processadas individualmente, como antes.
Em um nível mais baixo, há dois tipos de operações realizadas para consultar valores: obter vários objetos especificados e percorrer uma árvore OID.
Para "getting", é usado um GetRequest-PDU com no máximo 128 associações de variáveis. Para "walking", é usado um GetNextRequest-PDU para SNMPv1 e um GetBulkRequest com o campo "max-repetitions" de no máximo 128 para SNMPv2 e SNMPv3.
Assim, os benefícios do processamento combinado para cada tipo de item SNMP estão descritos abaixo:
- itens SNMP regulares se beneficiam das melhorias de "getting";
- itens SNMP com índices dinâmicos se beneficiam tanto das melhorias de "getting" quanto de "walking": "getting" é usado para verificação de índice e "walking" para construir o cache;
- regras de descoberta em baixo nível SNMP se beneficiam das melhorias de "walking".
No entanto, há 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 simplesmente não respondem quando a possível resposta ultrapassa um certo limite.
Para encontrar um número ideal de objetos a consultar para um determinado dispositivo, o Zabbix usa a seguinte estratégia. Ele começa com cautela 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 atual de itens, 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 deve funcionar na grande maioria dos casos, porque 28 variáveis já eram conhecidas por funcionar e 21 é significativamente menor do que isso. No entanto, se isso ainda falhar, o Zabbix volta a consultar os valores um por um. Se ainda assim falhar nesse ponto, então o dispositivo definitivamente não está respondendo e o tamanho da solicitação não é o problema.
A segunda coisa que o Zabbix faz para lotes subsequentes de itens é começar com o último número de variáveis que funcionou com sucesso (28 em nosso exemplo) e continuar incrementando os tamanhos das solicitações em 1 até atingir o limite. Por exemplo, supondo que o maior tamanho de resposta seja 32 variáveis, as solicitações subsequentes terão 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 momento, 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 que um dispositivo usa para limitar o tamanho da resposta não podem ser conhecidos, mas tentamos aproximá-los usando o número de variáveis. Portanto, 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 tenha sido perdido. Por esses motivos, se o Zabbix receber uma consulta com falha, ele reduz o número máximo de variáveis para tentar entrar mais profundamente 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 se devem à perda de pacotes UDP, e não ao limite do dispositivo.
Se, porém, um dispositivo não conseguir lidar corretamente com solicitações combinadas por outros motivos e a heurística descrita acima não funcionar, há uma configuração "Use combined requests" para cada interface que permite desativar solicitações combinadas para esse dispositivo.
Se solicitações combinadas causarem respostas parciais ou malformadas que resultem em cálculos incorretos por segundo (delta) (por exemplo, picos aparentes em contadores de interface), desative Use combined requests para a interface afetada para 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 em vez das verificações OID síncronas legadas para evitar problemas relacionados a solicitações combinadas.
Procure entradas de log do server/proxy semelhantes à mostrada na seção Overview 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 OID.