Documentation
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 UPS que geralmente possuem SNMP habilitado e nos quais seria impraticável tentar configurar sistemas operacionais completos e agents Zabbix.
Para poder recuperar os dados fornecidos pelos agents SNMP nesses dispositivos, o server Zabbix deve ser configurado inicialmente com suporte a SNMP, especificando a flag --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 às seguintes 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 desativadas.
O server/proxy 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 (número ou string OID único), o server/proxy Zabbix 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 o 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.
Configurando o monitoramento SNMP
Para começar a monitorar um dispositivo via SNMP, as seguintes etapas devem ser realizadas:
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 uma 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 sua 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.
Etapa 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 requerem apenas a comunidade (geralmente 'public').
- SNMPv3 requer opções mais específicas (veja abaixo).
- Especifique o valor máximo de repetição (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 timeout na 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 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 recente 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 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 seguintes opções:
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ê vai criar o item você mesmo 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 | Digite o nome do item. |
| Tipo | Selecione SNMP agent aqui. |
| Chave | Digite 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 SNMP bulk nativas (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 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). Você pode usar este item como item mestre, com itens dependentes que extraem dados do mestre usando pré-processamento. É possível especificar vários 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á tentado recuperar um único registro sem requisição bulk. Nomes de MIBs 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.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 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). 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 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, uma etapa Alteração por segundo deve ser adicionada na guia Pré-processamento; caso contrário, você obterá o valor cumulativo do dispositivo SNMP em vez da última alteração. |
Todos os campos obrigatórios sã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 esse propósito:
Exemplo 2
Monitoramento do tempo de atividade:
| Parâmetro | Descrição |
|---|---|
| OID | MIB::sysUpTime.0 |
| Chave | router.uptime |
| Tipo de valor | Float |
| Unidades | uptime |
| Etapa de pré-processamento: Multiplicador personalizado | 0.01 |
Requisições SNMP bulk nativas
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 tanto para itens SNMP regulares quanto para descoberta SNMP, a fim de minimizar as idas e vindas na rede.
O item SNMP walk[OID1,OID2,...] pode ser usado como 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 SNMP bulk nativas não está relacionado à opção de combinar requisições SNMP, que é uma forma própria 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 falhas caso um dos pacotes seja perdido. O tempo limite para itens SNMP com get e walk (definido no formulário de configuração do item) é definido para toda a sessão. O tempo limite é aplicado independentemente de os dados serem recuperados completamente; se os dados forem recebidos parcialmente (por exemplo, os dados são coletados com sucesso apenas para um dos múltiplos OIDs), então o item se torna não suportado com a mensagem "Only partial data received". Se o tempo limite for atingido, uma nova tentativa será feita, o tempo limite será redefinido e a última requisição será reenviada, permitindo continuar a sessão a partir da última requisição caso um único pacote seja perdido ou chegue tarde demais. Considere definir um valor baixo de tempo limite 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 tempo limite 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:
- itens SNMP regulares
- itens SNMP com índices dinâmicos
- regras de descoberta de 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 de baixo nível são processadas individualmente, como antes.
Em um nível inferior, existem dois tipos de operações realizadas para consultar valores: obter vários objetos especificados e percorrer uma árvore OID.
Para "obter", um GetRequest-PDU é usado com no máximo 128 associaçõ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:
- itens SNMP regulares se beneficiam das melhorias de "obtenção";
- itens 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 solicitaçã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 a serem consultados para um determinado dispositivo, o Zabbix usa a seguinte estratégia. Ele começa cautelosamente consultando 1 valor em uma solicitação. Se isso for bem-sucedido, ele consulta 2 valores em uma solicitação. Se isso for bem-sucedido novamente, ele consulta 3 valores em uma 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, 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 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 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, o dispositivo definitivamente não está respondendo e o tamanho da solicitação não é um problema.
A segunda coisa que o Zabbix faz para os lotes de itens subsequentes é começar com o último número bem-sucedido de variáveis (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 serão de tamanhos 29, 30, 31, 32 e 33. A última solicitação falhará e o Zabbix nunca emitirá uma solicitação de tamanho 33 novamente. A partir desse ponto, o Zabbix consultará no máximo 32 variáveis para esse dispositivo.
Se grandes consultas 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. 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 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 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, no entanto, um dispositivo não puder lidar com solicitações combinadas corretamente por outros motivos e a heurística descrita acima não funcionar, há uma configuração "Usar solicitações combinadas" para cada interface que permite desabilitar 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), desabilite Usar solicitações combinadas 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 Usar solicitações combinadas por interface — eles podem ser usados em vez de verificações OID síncronas legadas para evitar problemas relacionados a solicitações combinadas. Procure por entradas de log do server/proxy semelhantes à mostrada na seção Visão geral para ajudar a identificar dispositivos afetados.
Além disso, se a interface se tornar frequentemente 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 solicitações. Os itens podem se tornar não suportados se dados parciais forem recebidos durante a descoberta ou percorrimento de OIDs.