3 agent SNMP
Visão geral
Talvez você queira usar o 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 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 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 a RFC 2571 (seção 3.1.1.1), ele deve ser único 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 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:
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 um template ou não ao criar o host, você terá uma lista de items 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; então 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 com algo significativo. |
| Host interface | Certifique-se de selecionar a interface SNMP, por exemplo, do seu switch/router. |
| 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 items 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; as repetições máximas para requisições bulk são configuradas 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 tempo limite da verificação do item será igual ao valor definido no arquivo de configuration do server. É recomendado usar items walk[OID] e get[OID] para melhor desempenho. Todos os items 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 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 server e o proxy do Zabbix podem consultar dispositivos SNMP para vários valores em uma única solicitação. Isso afeta vários tipos de items SNMP:
- items SNMP regulares
- items SNMP com índices dinâmicos
- regras de descoberta em 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 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 vinculaçõ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:
- items SNMP regulares se beneficiam das melhorias de "getting";
- items 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 resposta potencial 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 em uma solicitação. Se isso for bem-sucedido, consulta 2 valores em uma solicitação. Se isso também for bem-sucedido, consulta 3 valores em uma solicitação e continua da mesma forma, 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 items, 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, então 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 os lotes de items subsequentes é 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 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 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 items 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 de 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 items podem se tornar não suportados se dados parciais forem recebidos durante a descoberta ou durante walks de OID.