NET-SNMP pode estar atingindo um problema relatando partições maiores que 2TB

1

Recentemente, atualizamos uma de nossas máquinas MYSQL com uma matriz de 2,5 TB.

Depois disso, o OpenNMS parou de relatar informações sobre nossa partição de dados do mysql ...

quando faço:

snmpwalk -v 1 localhost -c public .1.3.6.1.4.1.2021.9

Eu recebo isso em / var / log / messages

Aug  3 16:44:11 mysql6 snmpd[8789]: Connection from UDP: [127.0.0.1]:47333 
Aug  3 16:44:11 mysql6 snmpd[8789]: truncating signed value to 32 bits (10) 
Aug  3 16:44:11 mysql6 snmpd[8789]: truncating signed value to 32 bits (10) 

Quando eu removo a partição do snmpd.conf, não recebo avisos ... e o resto dos dados do recurso é preenchido no OpenNMS.

Do meu googling, parece um problema comum, mas não consegui encontrar nenhuma solução.

Alguém sabe de uma solução?

    
por Nathan Milford 03.08.2009 / 23:02

2 respostas

1

Esta não é realmente uma resposta, mas é muito grande para um comentário.

  • Linux 2.6.26-gentoo-r4 # 10 SMP Sáb 17 de janeiro 22:38:48 EST 2009 i686 CPU Intel (R) Celeron (R) E1200 @ 1,60 GHz GenuineIntel GNU / Linux
  • Versão NET-SNMP: 5.4.2.1
  • Tamanho do volume lógico: 3,4 TB

E eu não tenho problemas. Eu não tenho certeza se snmpd é compilado como 64 bits embora. Eu ficaria feliz em fazer qualquer teste (não intrusivo) que você goste.

    
por 03.08.2009 / 23:14
3

Eu encontrei isso em uma plataforma diferente. O que eu descobri é o que seu log lhe disse, ele estava retornando um valor que excedeu o inteiro inteiro de 32 bits assinado. O daemon SNMP específico estava retornando números negativos, que foi como eu descobri que era um problema Int / assinado / não assinado. No meu script eu fiz as contas para converter um inteiro assinado em um inteiro não assinado, o que me permitirá monitorar esse volume em particular até 4 TB. Nesse ponto, estou praticamente sem sorte.

Quanto a soluções alternativas ... não parece que você obterá o valor bruto, portanto, talvez seja necessário escrever um script que será executado quando um OID específico for consultado. Esse script retornará o valor KB do volume, em vez do valor B. O que deve levá-lo até 16 TB antes que ele também atinja o máximo.

No seu arquivo snmpd.conf, digite algo parecido com isto (eu estou cribbing de algumas notas vmware, então o OID que você usa deve ser outra coisa):

exec .1.3.6.1.4.1.6876.99999.2.0 sqlvolspace /usr/local/script/sqlvolspace /dev/mapper/volname

Então, quando você consultar esse OID, você obterá um valor que cabe dentro de um inteiro de 32 bits. Claro, você terá que escrever esse script. Deve retornar apenas um único inteiro.

    
por 03.08.2009 / 23:16

Tags