Snmpd atualiza os contadores de interface lentamente ou algo assim

Question

Eu atualizo uma caixa my freebsd para 9-stable (instalação totalmente nova) e instale o net-snmp para monitoramento.

uname -r 
9.1-PRERELEASE

pkg_info net-snmp-5.7.1_7 
Information for net-snmp-5.7.1_7:

Comment:
An extendable SNMP implementation
....


cat /var/db/ports/net-snmp/options 
# This file is auto-generated by 'make config'.
# Options for net-snmp-5.7.1_7
_OPTIONS_READ=net-snmp-5.7.1_7
_FILE_COMPLETE_OPTIONS_LIST= IPV6 MFD_REWRITES PERL PERL_EMBEDDED PYTHON DUMMY TKMIB DMALLOC MYSQL AX_SOCKONLY UNPRIVILEGED
OPTIONS_FILE_UNSET+=IPV6
OPTIONS_FILE_UNSET+=MFD_REWRITES
OPTIONS_FILE_SET+=PERL
OPTIONS_FILE_SET+=PERL_EMBEDDED
OPTIONS_FILE_UNSET+=PYTHON
OPTIONS_FILE_SET+=DUMMY
OPTIONS_FILE_UNSET+=TKMIB
OPTIONS_FILE_SET+=DMALLOC
OPTIONS_FILE_UNSET+=MYSQL
OPTIONS_FILE_UNSET+=AX_SOCKONLY
OPTIONS_FILE_UNSET+=UNPRIVILEGED

Eu tenho cerca de 500 vlan nesta máquina e coleciono informações sobre a interface através do snmpd para dois softwares diferentes, zabbix e cactos.

E ambos traçam os gráficos com campos em branco.

Eu tentei mudar o tempo de pesquisa no zabbix, de 15 segundos para 30,60,90,120,10. E de qualquer maneira eu tenho campos em branco.

O snmpd.conf está vazio - apenas os controles de acesso.

Esta configuração funcionou bem no freebsd 8.

Onde está minha culpa? Como consertar este gráfico?

UPD: Alterar o tempo de pooling, desativar um agente, não ajuda. Eu olho para o log do zabbix (dados recebidos do snmpd) e vejo que: desculpe pela localidade russa, basta olhar para os números:

eissonãoéverdade,comoomeu"iftop" mostrar velocidade foi de cerca de 90Mbits, mas snmpd retornar 2Mbits.

Eu entendo que o snmpd não retorna a velocidade, ele retorna apenas um contador. Mas como é possível? por que 2Mbit / s?

Eu tentei recompilar o snmpd com contadores de 64 bits e sem ele. Em ambas as variantes, esses campos em branco estão presentes.

Então, acho que o meu sistema operacional (freebsd) não atualiza bem os contadores de interface.

Eu ainda coleciono o tcpdump para encontrar este pedido / resposta. Mas tem problema com isso, para muito lixo.

UPD2: Descriptografar o arquivo tcpdump-ed e publicá-lo como documento do Google em gdocfile

Timediff parece estranho .. Como zabbix, por vezes, "esquecer" do pedido, e depois fazer duas vezes na linha, ehh

UPD3: Eu analiso log do comando "while true; do netstat -bin -I vlan4008 > > / var / log / netstat; dormir 300; concluído" e carregar como google docs e adicionar fórmula para velocidade: link

Parece que todos os contadores do sistema operacional são bons. Agora eu acho problema em: 1. zabbix obter solicitação duas vezes na linha (e que sobre cactos) 2. snmpd use o counter32

    

Answer 1

Geralmente, isso está relacionado à resposta SNMP não recebida em tempo hábil.
Como o SNMP usa o UDP, isso poderia significar que o congestionamento da rede ou o congestionamento do host causou a perda do pedido / resposta, mas mais comumente uma das duas máquinas envolvidas simplesmente não conseguia lidar com a solicitação em tempo hábil e a outra doente de esperar.

A chance de uma ou outra máquina ficar para trás aumenta com a carga de trabalho - Se você tiver muitos agentes SNMP consultando um determinado host, ela pode não atender as respostas da maneira mais esperada que alguns dos agentes esperam (e esses agentes mostrará pontos em branco nos gráficos ou reportará outros erros).
Por outro lado, se você tiver um agente consultando um monte de hosts - mais do que ele pode manipular em seu intervalo de pesquisa - as máquinas que não forem consultadas durante o intervalo de pesquisa terão uma lacuna em seus gráficos. (Esse problema foi particularmente comum com o PHP do Cacti, e levou ao desenvolvimento de cactid (agora spine ), que eu recomendo strongmente que você use se você ainda não estiver usando).

Meus conselhos gerais sobre como corrigir isso:

1. Pesquise a cada 5 minutos, se possível.
   A maioria dos ambientes não precisa de 1/5/15/30/60/90/120 segundos intervalos de pesquisa. Se a granularidade de cinco minutos for boa o suficiente para você, continue com ela. É menos trabalho para seus servidores, menos trabalho para seus agentes de monitoramento SNMP e menos dados para armazenar (ou um período maior de tempo em "granularidade total")

2. Aumenta o tempo limite do SNMP em seus agentes.
   Dê ao servidor mais tempo para responder ao seu pedido. Os daemons SNMP são o adolescente preguiçoso dos processos - você pede que eles limpem seu quarto (ou dêem a você uma árvore de dados) na segunda-feira, e na quarta ou quinta-feira eles podem ter pegado algumas meias.

3. Limite quanto você está exigindo do servidor com cada pesquisa.
   Se você só precisa de um contador, não peça as interfaces inteiras MIB - ele (geralmente) demora mais tempo para percorrer a árvore e gerar uma saída completa do que para dar apenas um OID.

4. Limite quantos agentes estão solicitando dados.
   Se você puder consolidar seu monitoramento em uma caixa (Zabbix ou Cacti), estará colocando menos demandas em seu servidor, e é menos provável que ele não responda em tempo hábil.

Se você ainda estiver tendo problemas depois de tentar o acima, haverá a etapa final de depuração: Percorrer seus registros e Farejar o tráfego SNMP . Certifique-se de que as solicitações e as respostas estão indo e voltando em tempo hábil e não sendo perdidas / rejeitadas como malformadas por algum motivo. Muitas vezes, olhando para os dados no fio vai lhe dar uma boa indicação do que está errado e como corrigi-lo.

    

Answer 2

Qual versão do protocolo SNMP você usa? O SNMP v1 não suporta contadores de 64 bits. É um problema antigo com o Cacti, basta mudar para "Versão 2" no "Dispositivo" relevante