Posted inネットワーキング

LinuxへのOpenNMS Horizonのインストールと設定：SNMPオートディスカバリーとしきい値アラートによるエンタープライズネットワーク監視

Networking tutorial - IT technology blog
Networking tutorial - IT technology blog

「十分な」監視が十分でなくなるとき

6ヶ月前、私たちのインフラチームはハイブリッド構成で運用していました。3拠点にわたる約180台のネットワーク機器——Ciscoスイッチ、Linuxサーバー、そして数台のレガシーWindowsマシンが混在していました。ZabbixでBasicな死活監視を行い、アラートをメール送信するシェルスクリプトをつぎはぎで運用していました。それなりに機能していましたが、ある日限界が来ました。

転換点となったのは、コアスイッチが完全に停止する前に3日間にわたってじわじわと劣化し続けたことです。誰も気づきませんでした。その間CPUは着実に上昇していましたが、私たちの監視には比較する歴史的ベースラインがなく、「CPUが6時間連続で75%超」に対して自動的にアラートを発する仕組みもありませんでした。

このインシデントが本格的な評価を迫りました。OpenNMS Horizonを本番環境で6ヶ月運用した今、共有する価値のある具体的な数値と、苦労して作り上げた設定ファイルがあります。

根本原因：スケールしない監視アーキテクチャ

ほとんどの軽量監視スタックの根本的な問題は機能不足ではなく、アーキテクチャにあります。SNMPで200台のデバイスを毎分ポーリングする場合、以下が必要です：

  • アダプティブスケジューリングを備えた効率的なSNMP収集
  • 書き込み負荷に耐えられる時系列データベース
  • 手動でデバイス登録しなくてもトポロジーをマッピングできるオートディスカバリー
  • アラートフラッピングを防ぐヒステリシス付きしきい値アラート

私たちのZabbix環境はサーバー監視には十分でした。しかし6つのVLANにわたるSNMPバルクウォークとなると話は別で、ポーリング時間は着実に増大し、ログはタイムアウトのノイズで埋まりました。根本的な問題は、ZabbixのSNMPポーラーがネットワーク機器を単なる別のホストとして扱うことです。10台であれば問題ありません。180台になると、トポロジー認識の欠如が実際の運用問題となります。

代替候補の比較

OpenNMSに決める前に、3週間かけて3つの候補を比較評価しました。

LibreNMS

LibreNMSは素直なネットワーク機器監視には優れています。インストール直後からSNMPオートディスカバリーが動作し、UIはすっきりしており、帯域グラフも信頼できます。ただし私たちの規模では、PHPベースのバックエンドがディスカバリー実行中にレイテンシーを示しました。アラートロジックの拡張には、長期的に管理したくないほどのワークアラウンドが必要でした。

Zabbix（ベースラインとして継続使用）

すでに導入済み。サーバーおよびアプリケーション監視には強力ですが、ネットワークトポロジーとSNMPオートディスカバリーでは明らかに劣ります。デバイステンプレートには大量の手動設定が必要で、ネイティブのトポロジーディスカバリーモデルはありません。

OpenNMS Horizon

Javaベース、オープンソース、ネットワークオペレーションセンター向けに特化して構築されています。3候補の中で最も急な学習曲線を持ち——Webインターフェースは古めかしく感じられ、設定がXML中心の箇所もあります。しかしSNMPコレクターは本当に目的に特化して作られています。オートディスカバリーにはプロビジョニングデーモン（Provisiond）を使用し、サービスごとに設定可能なスケジュールを持つ独立したポーリングエンジン、時系列ストレージにRRD/JRobinを採用しています。6ヶ月後、この規模でのポーリング信頼性は私がこれまで見た中で最高です。

Ubuntu 22.04へのOpenNMS Horizonのインストール

OpenNMSにはPostgreSQLとJava 17以降が必要です。本番環境対応のインストール手順を以下に示します：

ステップ1：前提条件のインストール

# Java 17をインストール
sudo apt update
sudo apt install -y openjdk-17-jdk

# Javaバージョンを確認
java -version

# PostgreSQLをインストール
sudo apt install -y postgresql postgresql-contrib
sudo systemctl enable postgresql
sudo systemctl start postgresql

ステップ2：OpenNMS用PostgreSQLの設定

sudo -u postgres psql -c "CREATE USER opennms WITH PASSWORD 'yourpassword';"
sudo -u postgres psql -c "CREATE DATABASE opennms OWNER opennms;"
sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE opennms TO opennms;"

ステップ3：OpenNMSリポジトリの追加とインストール

# GPGキーをインポート
curl -fsSL https://debian.opennms.org/OPENNMS-GPG-KEY | \
  sudo gpg --dearmor -o /usr/share/keyrings/opennms.gpg

# リポジトリを追加
echo "deb [signed-by=/usr/share/keyrings/opennms.gpg] https://debian.opennms.org stable main" | \
  sudo tee /etc/apt/sources.list.d/opennms.list

sudo apt update
sudo apt install -y opennms-horizon

ステップ4：データベーススキーマの初期化

# Javaランタイムを検出
sudo /usr/share/opennms/bin/runjava -s

# データベーススキーマとIPLIKE関数をインストール
sudo /usr/share/opennms/bin/install -dis

install -disフラグはデータベーススキーマのインストール、IPLIKE PostgreSQL拡張機能（IPレンジクエリに使用）のインストール、および初期設定のシードを実行します。初回実行には2〜3分かかります。

ステップ5：OpenNMSの起動

sudo systemctl enable opennms
sudo systemctl start opennms
sudo systemctl status opennms

Web UIはポート8980で待ち受けます。デフォルトの認証情報はadmin / adminです——ログイン後すぐに「管理者」→「パスワード変更」から変更してください。

SNMPオートディスカバリーの設定

この規模のほとんどの監視ツールは、各デバイスを手動で追加する必要があります。OpenNMSは違います。IPレンジを定義してProvisiondデーモンを向けるだけで、ディスカバリー、SNMP分類、サービス検出が自動的に行われます——デバイスごとの設定は不要です。

ディスカバリーレンジの定義

/etc/opennms/discovery-configuration.xmlを編集します：

<discovery-configuration xmlns="http://xmlns.opennms.org/xsd/config/discovery"
  packets-per-second="1"
  initial-sleep-time="30000"
  restart-sleep-time="86400000"
  retries="1"
  timeout="2000">

  <include-range retry="1" timeout="2000">
    <begin>192.168.10.1</begin>
    <end>192.168.10.254</end>
  </include-range>

  <include-range retry="1" timeout="2000">
    <begin>192.168.20.1</begin>
    <end>192.168.20.254</end>
  </include-range>

</discovery-configuration>

SNMPコミュニティ文字列の設定

認証情報はREST APIまたは「管理者」→「SNMP設定」画面でサブネットごとに管理されます：

# /24サブネット全体にSNMPv2cコミュニティ文字列を設定
curl -u admin:yourpassword -X PUT \
  -H "Content-Type: application/xml" \
  -d '<snmp-info><community>public</community><version>v2c</version><port>161</port><retries>2</retries><timeout>1800</timeout></snmp-info>' \
  http://localhost:8980/opennms/rest/snmpConfig/192.168.10.0/24

ディスカバリーデーモンを再起動すると、OpenNMSは定義されたレンジへのpingを開始し、応答があったものすべてにSNMPウォークを試みます。各デバイスはsysObjectID——Cisco IOS、Juniper JunOS、Linux、Windows——によって自動的に分類され、適切なデータ収集プロファイルに対応付けられます。私の180台構成のネットワークは初回実行で5分以内に完全にマッピングされました。

パフォーマンス収集としきい値アラートの設定

これが当時のスイッチを救っていたはずの機能です。しきい値は/etc/opennms/thresholds.xmlで管理され、アラートストームを防ぐヒステリシス——rearm値——をサポートしています。

Ciscoデバイス向けCPU使用率しきい値

<group name="cisco" rrdRepository="/var/lib/opennms/rrd/snmp/" ds-type="node">

  <!-- CPUが5回連続のポーリングで80%を超えた場合に発火（5分間隔で25分） -->
  <threshold type="high"
    ds-name="CiscoLocalCPU5SecUtil"
    ds-label=""
    value="80.0"
    rearm="70.0"
    trigger="5"
    description="CiscoデバイスのCPU使用率が高い"
    triggeredUEI="uei.opennms.org/threshold/highThresholdExceeded"
    rearmedUEI="uei.opennms.org/threshold/highThresholdRearmed" />

</group>

rearm="70.0"はヒステリシスポイントです——CPUが一時的に80%を下回った瞬間ではなく、70%を下回って初めてアラートがクリアされます。trigger="5"（5分間隔で5回連続のポーリングサイクル、合計25分間持続することが必要）と組み合わせることで、アラートフラッピングが急激に減少します。最初の2週間で、誤検知の数はおよそ90%減少しました。

インターフェース帯域幅しきい値

<group name="mib2-interfaces" rrdRepository="/var/lib/opennms/rrd/snmp/" ds-type="if">

  <threshold type="high"
    ds-name="ifHCInOctets"
    ds-label="ifDescr"
    value="800000000"
    rearm="700000000"
    trigger="3"
    description="インターフェースのイングレストラフィックが800 Mbpsを超過" />

</group>

再起動なしでしきい値をリロード

# OpenNMSにしきい値設定のライブリロードを指示
/usr/share/opennms/bin/send-event.pl \
  uei.opennms.org/internal/eventsConfig/reloadDaemonConfig \
  --host localhost \
  --parm "daemonName Threshd"

通知の設定

通知ルーティングは「管理者」→「通知設定」にあります。本番環境では、重要なしきい値イベントをPagerDutyのWebhookへ、優先度の低いイベントをメールに送信しています。組み込みのメール通知機能は標準SMTPを使用し、/etc/opennms/javamail-configuration.xmlで設定します。

本番稼働前に、通知パイプライン全体をエンドツーエンドで検証してください：

# テストイベントを送信して通知ルーティングを確認
/usr/share/opennms/bin/send-event.pl \
  uei.opennms.org/nodes/nodeLostService \
  --host 192.168.10.1 \
  --interface 192.168.10.1 \
  --service ICMP

6ヶ月の本番稼働数値

この構成で200台以上のノードを6ヶ月間運用した実際の数値をご紹介します：

  • 初回ディスカバリー：180台のデバイスが5分以内に完全分類
  • ポーリングオーバーヘッド：8GBメモリの専用4コアVMでCPU約3%
  • SNMPデータソース：1,200以上のメトリクスを5分ごとにポーリングギャップなしで収集
  • アラートノイズ：しきい値チューニング後、週約40件の誤検知が5件未満に減少
  • 稼働率：180日間でOpenNMSサービスの計画外再起動ゼロ

導入前に知っておくべき正直な注意点

OpenNMSがすべてのチームに適しているわけではありません。XMLによる設定モデルには本物の学習曲線があります——アーキテクチャが理解できるまで1週間のドキュメント読み込みを見込んでください。Web UIは機能的ですが、デザイン賞を獲得するようなものではありません。Javaランタイムは、小規模な展開でも最低4GBのRAMが必要で、100台を超える場合は8GBが必要です。

小規模環境や専任のオペレーターがいないチームはLibreNMSのほうが幸せになれるでしょう。実際のスケールでSNMPネイティブな監視が必要なインフラチーム——信頼できる収集、トポロジー認識ディスカバリー、ベンダー契約なしのしきい値アラート——にとって、OpenNMSは期待に応えます。180日間で計画外の再起動ゼロという数値は、それだけで十分に語っています。

Share:
Tags: