web-dev-qa-db-ja.com

OpenNMSへのカウンターの取得

APCRackPDUの負荷グラフをOpenNMSに取り込むのに苦労しています。 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>

そして、snmpgetを使用して、問題の値を取得できます。

# 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

また、収集したデータを処理するためにsnmp-graph.propertiesでレポートを定義しましたが、収集されていることすらわかりません。ホストのrrdディレクトリ（私の場合はrrd/snmp/170）には、一般的なicmp.*.jrbおよびtcp*.jrbデータファイルのみが含まれ、予想されるrPDUCurB1/rPDUCurB2ファイルの兆候はありません。

rrd/snmp/170をクリーンアップし、ノードで機能スキャンを強制しようとしましたが、同じファイルで出力されます。 RackPDU（グループ定義名）またはrPDUCur（値エイリアス名）のクイックログgrepは何も生成しませんでした。

機能が正しく検出されていないのではないかと思いますが、それ以上デバッグする方法がわかりません。

編集：collectdのログレベルを「DEBUG」に増やしました。問題のノードについていくつかの疑わしい行がログに記録されています。

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

なぜ正確にOIDs from group 'APC-RackPDU:ignore' are excluded for ifType: -2なのか疑問に思いましたが、グループの定義を<group name = "APC-RackPDU" ifType="-2">に変更しようとしました（これはまったく機能せず、OpenNMSの起動時に検証エラーをスローしました）および<group name = "APC-RackPDU" ifType="all">（これは機能し、ログにOIDs from group 'APC-RackPDU:all' are included for ifType: -2を生成しましたが、それ以上問題を解決しませんでした）。

opennms
1
the-wabbit

新しいグループを定義するときにテンプレートとしてAPCUPS定義を使用し、snmpgetでテストするためにOIDを組み立てるときに「インスタンス」属性に注意を払わずに、自分の足で撮影しました。定義をに変更する

<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

問題を修正しました。古い Jeff Gehlbachが回答したOpenNMSメーリングリストへの投稿 -クレジットを見ると正しい考えが浮かびました。

1
the-wabbit

最善のアプローチは、OpenNMS IRCチャネルでこれを実行することです。かなり一般的であるため、問題のデバイスを見たことがあると確信しています。

0
ewwhite