Obtendo contadores no OpenNMS

1

Estou com dificuldades para obter gráficos de carga do meu APC RackPDU no OpenNMS. Eu defini os valores apropriados em datacollection-config.xml :

<groups>
  <group name = "APC-RackPDU" ifType="ignore">
    <mibObj oid=".1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.2" instance="0" alias="rPDUCurB1" type="Gauge32" />
    <mibObj oid=".1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.3" instance="0" alias="rPDUCurB2" type="Gauge32" />
  </group>
</groups
<systems>
  <systemDef name="APC UPS">
    <sysoidMask>.1.3.6.1.4.1.318.</sysoidMask>
    <collect>
      <includeGroup>APC</includeGroup>
      <includeGroup>APC-RackPDU</includeGroup>
      <includeGroup>mib2-ups-rfc1628</includeGroup>
    </collect>
  </systemDef>
</systems>

E usando snmpget , posso recuperar os valores em questão:

# snmpget -v2c -c public 192.168.127.133 .1.3.6.1.4.1.318.1.1.12.2.3.1.1.2.3
SNMPv2-SMI::enterprises.318.1.1.12.2.3.1.1.2.3 = Gauge32: 38

Eu também defini um relatório em snmp-graph.properties para trabalhar nos dados coletados, mas nem mesmo os vejo sendo coletados. O diretório rrd do host ( rrd/snmp/170 no meu caso) contém apenas os arquivos genéricos icmp.*.jrb e tcp*.jrb data sem um sinal dos arquivos rPDUCurB1 / rPDUCurB2 esperados.

Eu tentei limpar o rrd/snmp/170 e forçar uma verificação de capacidade no nó, mas ele sai com os mesmos arquivos. Um log grep rápido para RackPDU (o nome da definição do grupo) ou rPDUCur (o nome do alias do valor) não gerou nada.

Eu suspeito que os recursos não sejam detectados corretamente, mas não tenho idéia de como depurá-lo ainda mais.

Edit: Eu aumentei o nível de log de collectd para "DEBUG" e algumas linhas suspeitas foram registradas sobre o nó em questão:

2012-04-17 12:01:50,636 DEBUG [CollectdScheduler-20 Pool-fiber0] DefaultDataCollectionConfigDao: getMibObjectList: collection: default sysoid: .1.3.6.1.4.1.318.1.3.4.5 address: 192.168.127.133 ifType: -2
[...]
DefaultDataCollectionConfigDao: getMibObjectList: includes sysoid .1.3.6.1.4.1.318.1.3.4.5 for system <name>: APC UPS
2012-04-17 12:01:50,636 DEBUG [CollectdScheduler-20 Pool-fiber0] DefaultDataCollectionConfigDao: getMibObjectList: MATCH!! adding system 'APC UPS'
2012-04-17 12:01:50,636 DEBUG [CollectdScheduler-20 Pool-fiber0] [...]
DefaultDataCollectionConfigDao: processGroupName:  processing group: APC groupIfType: ignore ifType: -2
2012-04-17 12:01:50,649 DEBUG [CollectdScheduler-20 Pool-fiber0] DefaultDataCollectionConfigDao: processGroupName: OIDs from group 'APC:ignore' are excluded for ifType: -2
2012-04-17 12:01:50,649 DEBUG [CollectdScheduler-20 Pool-fiber0] DefaultDataCollectionConfigDao: processGroupName:  processing group: APC-RackPDU groupIfType: ignore ifType: -2
2012-04-17 12:01:50,649 DEBUG [CollectdScheduler-20 Pool-fiber0] DefaultDataCollectionConfigDao: processGroupName: OIDs from group 'APC-RackPDU:ignore' are excluded for ifType: -2

Isso me fez pensar por que exatamente OIDs from group 'APC-RackPDU:ignore' are excluded for ifType: -2 , mas eu tentei mudar a definição do grupo para <group name = "APC-RackPDU" ifType="-2"> (que não funcionou e lançou um erro de validação na inicialização do OpenNMS) e <group name = "APC-RackPDU" ifType="all"> (que trabalhou e produziu um OIDs from group 'APC-RackPDU:all' are included for ifType: -2 nos registros, mas não ajudou mais nas questões).

    
por the-wabbit 17.04.2012 / 09:29

2 respostas

1

Eu fotografei meu próprio pé usando as definições do APC UPS como meu modelo ao definir meu novo grupo e não prestando atenção ao atributo "instance" ao montar os OIDs para testes com snmpget . Alterando a definição para

<groups>
  <group name = "APC-RackPDU" ifType="ignore">
    <mibObj oid=".1.3.6.1.4.1.318.1.1.12.2.3.1.1.2" instance="2" alias="rPDUCurB1" type="Gauge32" />
    <mibObj oid=".1.3.6.1.4.1.318.1.1.12.2.3.1.1.2" instance="3" alias="rPDUCurB2" type="Gauge32" />
  </group>
</groups

resolveu o problema. Tive a ideia certa ao analisar uma antiga postagem na lista de discussão do OpenNMS respondida por Jeff Gehlbach - crédito onde é devido.

    
por 17.04.2012 / 16:57
0

A melhor abordagem seria executar isso pelo canal OpenNMS IRC. Tenho certeza de que eles viram o dispositivo em questão, já que é bastante comum.

    
por 17.04.2012 / 12:17

Tags