SNMPD em execução, mas não escutando conexões aleatoriamente

Question

OS: CentOS release 5.7 (Final) Net-SNMP: net-snmp-5.3.2.2-14.el5_7.1 (a partir de RPM)

Periodicamente, meu NMS me notifica que o SNMP caiu nessa máquina. O serviço é restaurado entre 10 a 30 minutos. Meu NMS também pinga e verifica o SSH e esses serviços não são afetados durante a interrupção do SNMP.

O arquivo de log do SNMPD mostra que ele está funcionando e aparentemente recebendo pacotes (seja de agentes locais do 127.0.0.1 ou do meu NMS em 172.16.37.37); no entanto, tentar snmpwalk localmente ou do sistema do NMS falha com um tempo limite.

Eu tenho 7 desses servidores executando mistura do CentOS 5.7 e do RHEL 5.7 com esta versão específica do Net-SNMP instalado a partir do RPM - nenhum deles tem esse problema, exceto este. 5 das máquinas (incluindo o sistema NMS e este servidor problemático) estão no mesmo rack conectado usando um único switch.

Reiniciar o SNMPD não corrige o problema - ele acaba por se resolver sozinho. Alguma sugestão onde posso começar a diagnosticar o problema? É uma sub-rede fechada, portanto, o IPTables não é usado. Configuração do SNMPD abaixo:

# Following entries were added by HP Insight Management Agents at
#      Tue May 15 10:58:17 CLT 2012
dlmod cmaX /usr/lib64/libcmaX64.so
rwcommunity public 127.0.0.1
rocommunity public 127.0.0.1
rwcommunity 3adRabRu 172.16.37.37
rocommunity 3adRabRu 172.16.37.37
rwcommunity 3adRabRu 172.16.37.36
rocommunity 3adRabRu 172.16.37.36
trapcommunity callmetraps
trapsink 172.16.37.37 callmetraps
trapsink 172.16.37.36 callmetraps
syscontact Lukasz Piwowarek
syslocation Santiago, Chile
# ---------------------- END --------------------
agentAddress udp:161
com2sec rwlocal default public
com2sec rolocal default public
com2sec subnet  default 3adRabRu
group   rwv2c   v2c             rwlocal
group   rov2c   v2c             rolocal
group   rov2c   v2c             subnet
view    all     included        .1
access  rwv2c   ""      any             noauth          exact   all     all     none
access  rov2c   ""      any             noauth          exact   all     none    none

    

Answer 1

Existem alguns problemas a serem abordados neste.

Analisando sua configuração, vejo o OpenNMS como a solução de monitoramento, o hardware do servidor HP ProLiant, possíveis versões de pacote e problemas de driver, além de alguns ajustes que você poderia fazer em suas opções de snmpd.

Você está na versão mais recente do OpenNMS? A revisão atual é 1.10.3 A máquina está pesquisando o sistema da NMS ou não está relacionada? Isso foi um problema com uma versão mais antiga do OpenNMS ou esta é uma nova instalação?

Também vejo um módulo para os Agentes de gerenciamento HP ProLiant carregado na primeira linha do seu snmpd.conf config. Isso alimenta o pacote de suporte ProLiant e os agentes de saúde da HP. Este é o único servidor HP que você está monitorando? Para testar a configuração do snmp da HP, você pode acessar a página inicial do System Management no link ? Os sensores do sistema (temperatura, armazenamento, ILO) aparecem corretamente? Caso contrário, há um problema com a configuração do SNMP.

No lado do OpenNMS, existem opções de log incrivelmente flexíveis disponíveis para o poller. Nós podemos ajudá-lo a obter a informação que você precisa, mas eu não acho que este é um problema geral do OpenNMS se ele está afetando apenas um nó. Você poderia remover o nó do banco de dados e redescobri-lo para testar essa teoria.

Para o host em questão, convém editar /etc/sysconfig/snmpd.options para reduzir log verbosidade caso isso seja um problema.

Meu palpite é que é um problema de pesquisa / DB do OpenNMS ou que é a interação dos agentes da HP e do snmp no único sistema com problemas.

    

Answer 2

Já tentou aumentar o tempo limite do SNMP e tenta novamente no NMS? Pode ser que seu servidor não esteja respondendo rápido o suficiente algumas vezes ou que sua rede perca pacotes.

E, como @rnxrx já apontou, você precisa procurar pela porta 161 para ver se o snmpd está escutando.

    

Answer 3

Eu encontrei a causa mas não a solução. Parece que o MySQL está deixando todo o sistema sem resposta. O modo como ele consegue afetar tudo, do SNMP ao SSH e à capacidade de resposta geral do sistema (comandos que devem ser instantaneamente necessários para responder por mais de 30 segundos) está além de mim. Esta é uma máquina de CPU dupla com 96GB de RAM que é usada em rajadas de dados extremamente pesadas de 4 horas, mas depois que executamos nosso programa (que faz vários milhões de inserções no MySQL), todo o sistema rastreia mesmo que esteja ocioso. Reiniciar o MySQL limpa o problema imediatamente.