Table of Contents
2 Agente SNMP
Visão geral
Você pode querer usar 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 agentes Zabbix.
Para poder recuperar dados fornecidos por agentes SNMP nesses dispositivos, o servidor Zabbix deve ser initially configured with com suporte SNMP, especificando a flag --with-net-snmp .
As verificações SNMP são realizadas apenas pelo protocolo UDP.
Os daemons do servidor e proxy Zabbix consultam dispositivos SNMP para múltiplos valores em uma única solicitação. Isso afeta todos os tipos de itens SNMP (itens SNMP regulares, itens SNMP com índices dinâmicos e descoberta de baixo nível SNMP) e deve tornar o processamento SNMP muito mais eficiente. Veja a seção bulk processing para detalhes técnicos sobre como funciona internamente. Solicitações Bulk também podem ser desativadas para dispositivos que não podem lidar com elas corretamente usando a configuração "Usar solicitações em massa" para cada interface.
Os daemons do servidor e 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 em massa devem ser desativadas.
O servidor/proxy Zabbix sempre tentará novamente pelo menos uma vez após uma tentativa de consulta sem sucesso: ou através do mecanismo de repetição da biblioteca SNMP ou através do mecanismo interno de bulk processing.
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 RFC 2571 (section 3.1.1.1) ele deve ser único para cada dispositivo.
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 servidor/proxy (usando -R snmp_cache_reload) ou o servidor/proxy precisa ser reiniciado.
Configurando monitoramento SNMP
Para iniciar o monitoramento de um dispositivo através do protocolo SNMP, é necessário executar estas etapas:
Passo 1
Localize 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:
Aqui, '2c' representa a versão do SNMP. Você 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 valores atuais. Se não fornecer, é possível que a 'comunidade' SNMP seja diferente do padrão 'public', e você precisará descobrir qual é.
Você pode então percorrer a lista até encontrar a string que deseja monitorar. Por exemplo, se quiser monitorar os bytes que entram no seu switch na porta 3, você usaria a string IF-MIB::ifHCInOctets.3 da linha seguinte:
Agora você pode usar o comando snmpget para descobrir o OID numérico de 'IF-MIB::ifHCInOctets.3':
Note que o último número na string é o número da porta que você está procurando monitorar. Consulte também: Dynamic indexes.
Isso deve fornecer algo como o seguinte:
Novamente, o último número no OID é o número da porta.
Alguns dos OIDs SNMP mais utilizados são traduzidos automaticamente representation](/manual/config/items/itemtypes/snmp/special_mibs) pelo Zabbix.
No 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 and 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 mostrados como "STRING", "Hex-STRING", "OID" e outros, dependendo da presença de uma dica de exibição.
Passo 2
Crie um host Create a 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).
- Deixe a caixa de seleção Usar solicitações em massa marcada para permitir o processamento em massa de solicitações SNMP.
| Parâmetro SNMPv3 | Descrição |
|---|---|
| Nome do contexto | Insira o nome do contexto para identificar o item na sub-rede SNMP. Nome do contexto é suportado para itens SNMPv3 desde o Zabbix 2.2. Macros de usuário são resolvidos neste campo. |
| Nome de segurança | Insira o nome de segurança. Macros de usuário são resolvidos 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, SHA224, SHA256, SHA384 ou SHA512. |
| Senha de autenticação | Insira a senha de autenticação. Macros de usuário são resolvidos neste campo. |
| Protocolo de privacidade | Selecione o protocolo de privacidade - DES, AES128, AES192, AES256, AES192C (Cisco) ou AES256C (Cisco). Observe que: - em alguns sistemas mais antigos, o net-snmp pode não suportar AES256; - em alguns sistemas mais novos (por exemplo, RHEL9), o suporte ao DES pode ser removido para o pacote net-snmp. |
| Senha de privacidade | Insira a senha de privacidade. Macros de usuário são resolvidos 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;
- (desde o Zabbix 6.0.13) a disponibilidade da interface SNMP mudará para vermelho (indisponível).
Alterações no Protocolo de autenticação, Senha de autenticação, Protocolo de privacidade ou Senha de privacidade, feitas sem alterar o Nome de segurança, terão efeito somente após o cache em um servidor/proxy ser manualmente limpo (usando -R snmp_cache_reload) ou o servidor/proxy ser reiniciado. Nos casos em que o Nome de segurança também for alterado, todos os parâmetros serão atualizados imediatamente.
Você pode usar um dos templates SNMP fornecidos (Template SNMP Device e outros) que automaticamente adicionarão um conjunto de itens. No entanto, o template pode não ser compatível com o host. Clique em Adicionar para salvar o host.
Passo 3
Crie um item para monitoramento.
Agora, volte para o Zabbix e clique em Itens para o host SNMP que você criou anteriormente. Dependendo de ter usado ou não um template 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 você mesmo usando as informações que acabou de obter usando snmpwalk e snmpget, então clique em Criar item. No novo formulário de item:
- Insira o nome do item
- Altere o campo 'Tipo' para 'Agente SNMP'
- Insira a 'Chave' como algo significativo
- Certifique-se de que o campo 'Interface do host ' tenha o seu switch/roteador
- Insira o OID textual ou numérico que você recuperou anteriormente no campo 'OID SNMP', por exemplo: .1.3.6.1.2.1.31.1.1.1.6.3
- Defina o 'Tipo de informação' como Numérico (não assinado)
- Insira um 'Intervalo de atualização' e um período de 'Armazenamento de histórico' se quiser que sejam diferentes do padrão
- Na aba Pré-processamento, adicione uma etapa de Mudança por segundo (importante, caso contrário você obterá valores cumulativos do dispositivo SNMP em vez da última mudança). Escolha um multiplicador personalizado se desejar.
Todos os campos de entrada obrigatórios são marcados com um asterisco vermelho.
Agora, salve o item e vá para Monitoramento → Últimos dados para os 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) |
| Key | <Unique string to be used as reference to triggers> Por exemplo, "my_param". |
Observe que o OID pode ser fornecido em forma numérica ou textual. No entanto, em alguns casos, o OID textual deve ser convertido para representação numérica. A utilidade snmpget pode ser usada para esse propósito:
Exemplo 2
Monitoramento de 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 |
Funcionamento interno do processamento em massa
O servidor e o proxy do Zabbix consultam dispositivos SNMP para obter múltiplos 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 low-level discovery rules
Todos os itens SNMP em uma única interface com parâmetros idênticos são programados para serem consultados ao mesmo tempo. Os dois primeiros tipos de itens são processados por 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 mais baixo, há dois tipos de operações realizadas para consultar valores: obter múltiplos objetos especificados e percorrer uma árvore de OID.
Para "obter", é usado um GetRequest-PDU com no máximo 128 associações de variáveis. Para "percorrer", é usado um GetNextRequest-PDU para SNMPv1 e GetBulkRequest com o campo "max-repetitions" de no máximo 128 para SNMPv2 e SNMPv3.
Assim, os benefícios do processamento em massa para cada tipo de item SNMP são descritos abaixo:
- Itens SNMP regulares se beneficiam das melhorias de "obter";
- Itens SNMP com índices dinâmicos se beneficiam das melhorias de "obter" e "percorrer": "obter" é usado para verificação de índice e "percorrer" para construir o cache;
- Regras de descoberta de baixo nível SNMP se beneficiam das melhorias de "percorrer".
No entanto, há um problema técnico em 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 excede um certo limite.
Para encontrar o 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, consulta 2 valores em uma solicitação. Se isso for bem-sucedido novamente, 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 dar 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 maioria dos casos, porque 28 variáveis funcionaram e 21 é significativamente menor que isso. No entanto, se isso ainda falhar, o Zabbix volta a consultar 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 coisa que o Zabbix faz para lotes subsequentes de itens é começar com o último número bem-sucedido de variáveis (28 em nosso exemplo) e continuar incrementando o tamanho das solicitações em 1 até atingir o limite. Por exemplo, assumindo que o maior tamanho de resposta seja 32 variáveis, as solicitações subsequentes terão tamanhos de 29, 30, 31, 32 e 33. A última solicitação falhará e o Zabbix nunca mais fará uma solicitação de tamanho 33 novamente. A partir desse ponto, o Zabbix consultará no máximo 32 variáveis para este dispositivo.
Se consultas grandes falharem com este 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. Então, a primeira possibilidade é que esse número de variáveis esteja próximo do limite real do tamanho da resposta do dispositivo em 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 essas razões, se o Zabbix receber uma consulta falhada, ele reduz o número máximo de variáveis para tentar ficar dentro da faixa confortável do dispositivo, mas (a partir da versão 2.2.8) 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.
No entanto, se um dispositivo não puder lidar corretamente com solicitações em massa por outros motivos e a heurística descrita acima não funcionar, desde o Zabbix 2.4 existe uma configuração "Usar solicitações em massa" para cada interface que permite desativar solicitações em massa para esse dispositivo.