Posted inネットワーキング

盲目な運用はもう終わり：LibreNMSとSNMPでネットワークの可視化を極める

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

可視化：推測と確信の違い

昔、金曜の夜に4時間かけて「ネットワークが遅い」という苦情の原因を調査したことがあります。サーバーのCPUサイクルを確認し、データベースのロックを調べ、目に付くすべての機器を再起動しました。

結局、コアスイッチのポートで単純なデュプレックスの不一致（duplex mismatch）が発生しており、パケットが正確に12%ドロップしていたことが原因でした。もし監視ダッシュボードがあれば、30秒で赤く表示されたエラー数に気づけたはずです。集中管理された監視システムなしでネットワークを運用するのは、霧の中を時速130kmで運転するようなものです。動いてはいても、前方に何があるか全くわかりません。

ハードウェアは今でもSNMP（Simple Network Management Protocol）で通信します。Prometheusのようなツールはクラウドネイティブなアプリには最適ですが、物理環境（メタル）の王者といえばLibreNMSです。スイッチ、ルーター、ファイアウォール、UPSなど、インフラを支える機器をすべてカバーします。LibreNMSを使えば、トラブルが起きてから対処する「火消し」役から、サーバーがダウンする前に電源の故障を察知できる「プロアクティブなアーキテクト」へと進化できます。

LibreNMSを選ぶ理由

私はかつてNagiosと格闘し、Zabbixのテンプレート作成に何週間も費やしました。Zabbixは非常に強力ですが、メンテナンスの手間がかかります。ObserviumからフォークしたLibreNMSの強みは、その自動検出（auto-discovery）エンジンにあります。Cisco Catalystスイッチをスキャン対象にするだけで、すべてのVLAN、48個の個別ポート、PoEの消費電力、ファン速度が自動的にマッピングされます。「ただ動く」、それがLibreNMSです。

スタックはPHP、MariaDB、そして洗練されたUIという現代的な構成です。デザイン賞を取るほどではありませんが、1995年のスプレッドシートのような見た目でもありません。さらに重要なのは、アラートエンジンです。BGPセッションが切断されたり、リンクの使用率が90%に達した瞬間に、SlackやTelegramへ通知を飛ばすことができます。

ステップ1：Linuxホストの準備

LibreNMSはUbuntu 22.04または24.04で快適に動作します。約100台のデバイスを監視する中規模環境であれば、2 vCPU and 4GB RAMの仮想マシンが最適です。RAMをケチってはいけません。数百ものポートをポーリングすると、数分おきに大きなI/Oバーストが発生するからです。

# システムを更新
sudo apt update && sudo apt upgrade -y

# LEMPスタックと依存関係をインストール
sudo apt install software-properties-common
sudo add-apt-repository universe
sudo apt install curl acl composer fping git graphviz imagemagick mariadb-client mariadb-server mtr-tiny nginx-full nmap php-cli php-curl php-fpm php-gd php-gmp php-json php-mbstring php-mysql php-snmp php-xml php-zip python3-dotenv python3-pymysql python3-redis python3-setuptools python3-systemd rrdtool snmp snmpd whois unzip redis-server -y

データの整合性はデータベースの設定に依存します。LibreNMSは、MariaDBがテーブル名やファイルストレージをどのように扱うかについて厳格です。設定ファイルを開き、以下の調整を行ってください：

# MariaDBサーバー設定を編集
sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

# [mysqld] セクションに以下を追加:
# innodb_file_per_table=1
# lower_case_table_names=0

サービスを再起動し、データベースの権限を設定します：

sudo systemctl restart mariadb
sudo mysql -u root -p

CREATE DATABASE librenms CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'librenms'@'localhost' IDENTIFIED BY 'ここに強力なパスワードを設定';
GRANT ALL PRIVILEGES ON librenms.* TO 'librenms'@'localhost';
FLUSH PRIVILEGES;
exit

ステップ2：コアのデプロイ

LibreNMSは /opt にインストールします。これにより、監視環境を標準のシステムバイナリから分離できます。ここでのパーミッション管理は非常に重要です。WebユーザーがRRDフォルダに書き込めないと、グラフが空白のままになってしまいます。

cd /opt
sudo git clone https://github.com/librenms/librenms.git

# 専用ユーザーの設定
sudo useradd librenms -d /opt/librenms -M -r -s /usr/sbin/nologin
sudo chown -R librenms:librenms /opt/librenms
sudo chmod 771 /opt/librenms
sudo setfacl -d -m g::rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/bootstrap/cache /opt/librenms/storage
sudo setfacl -R -m g::rwx /opt/librenms/rrd /opt/librenms/logs /opt/librenms/bootstrap/cache /opt/librenms/storage

librenmsユーザーに切り替えて、PHPの依存関係をインストールします。ラッパーを使用することで、適切な所有権ですべてがインストールされます：

sudo -u librenms ./scripts/composer_wrapper.php install --no-dev

ステップ3：ハードウェアとの通信

デバイスが沈黙したままでは、監視サーバーはただの空のダッシュボードです。内部ネットワークではSNMP v2cが主流ですが、パブリックなインターネットを経由する場合や機密性の高いデータを扱う場合はv3を使用してください。v3にはv2cに欠けている暗号化と認証機能が備わっています。

Linuxサーバーの設定

/etc/snmp/snmpd.conf を編集します。世界中に公開してはいけません。情報漏えいを防ぐため、クエリをLibreNMSサーバーのIPアドレスに制限します。

# LibreNMSのIPアドレスに制限 (例: 192.168.1.50)
rocommunity MyPrivateCommunity 192.168.1.50
syslocation "ラック 4, B列"
syscontact [email protected]

sudo systemctl restart snmpd で再起動します。

Cisco IOSの設定

ログインして、以下の行をグローバル設定に貼り付けます。30秒もかかりません：

conf t
snmp-server community MyPrivateCommunity RO
snmp-server location IDF_Closet_2
snmp-server contact Network_Ops
exit
wr mem

ステップ4：自動検出（Auto-Discovery）の威力

サーバーのIPアドレスにアクセスしてWebインストーラーを完了させ、**Devices -> Add Device** へ進みます。コアルーターを追加すると、LibreNMSの真の力が発揮されます。機器がCDPやLLDPを使用していれば、LibreNMSはネットワークを「クロール」します。ポート1の隣接機器を見つけて追加し、さらに *その* 隣接機器を見つけ出し、トポロジーを自動的に構築します。

この機能を有効にするには、config.php に以下を追加します：

$config['discovery_modules']['discover-protocols'] = true;

苦労して得たベストプラクティス

ダッシュボードを作るのは戦いの半分に過ぎません。有用な状態を保つために、以下のルールを守りましょう：

  • ポーリング間隔： デフォルトは5分です。主要な10Gbpsアップリンクについては1分に短縮しましょう。ただし、古いルーターのCPU負荷には注意してください。頻繁なポーリングは、時としてコントロールプレーンに負荷をかけることがあります。
  • ログの集約： Syslog連携を有効にしましょう。光SFPモジュールが故障し始めると、通常、インターフェースが実際にダウンする前にログエラーが発生します。ログとグラフを一つの画面で確認できるのは、トラブルシューティングにおける大きな武器になります。
  • アラート疲れの解消： すべてを通知しないでください。CPU使用率が一時的に80%に跳ね上がるたびにメールを受け取る必要はありません。アクションが必要なもの、つまりリンクダウン、BGPフラップ、あるいはディスク使用率95%が15分間継続した場合などに絞ってアラートを設定しましょう。
  • アップデートの自動化： LibreNMSの進化は速いです。daily.sh をcrontabに追加して、常に最新のデバイスMIBやセキュリティパッチが適用されている状態にしましょう。

結論

包括的な監視とは、きれいなチャートを眺めることではありません。ハードウェアのアップグレードが必要であることを証明するための確かなデータを持ち、CEOのZoom会議が切れる前にボトルネックを解消できるスピードを持つことです。まずは今日、コアルーターを追加することから始めましょう。リアルタイムのトラフィックフローを目にすれば、今までこれなしでどうやって管理していたのか不思議に思うはずです。今日コミュニティ名を設定するのに費やす20分が、来月のパニック状態でのトラブルシューティング20時間を救ってくれます。

Share:
Tags: