前回はPython・systemd timer・Gmailを使ったSNMP監視システムを構築しました。
PythonでSNMP監視を自動化｜systemd・Gmail通知・CSV保存 | Yuu Log
今回は、実際に障害を模擬してWARNING・CRITICAL・RECOVERYの通知を確認します。
稼働中のCiscoルータの通信を止めないよう、監視先IPの一時変更やPython側の取得結果の模擬などを使用します。
実際に障害メールの動作確認を行う
監視システムを構築したら、実際に障害通知が届くかテストすることが重要です。
今回は、ルータの通信を止めずにテストできる方法を使用しました。
SNMP障害メールのテスト
まず、監視タイマーを一時停止します。
sudo systemctl stop pi-monitor.timer次に、/etc/pi-monitor.envの監視対象IPを一時的に到達不能なテスト用アドレスへ変更します。
ROUTER_IP=192.0.2.254その状態で監視サービスを繰り返し実行します。
sudo systemctl start pi-monitor.service2回目の失敗でWARNING。
3回目の失敗でCRITICALメールが届くことを確認できました。
その後、監視対象IPを元の192.168.20.1へ戻して監視を実行すると、RECOVERYメールも受信できました。
これにより、SNMP障害の検知から復旧通知まで、一連のメール通知処理が正常に動作することを確認できました。
CPU・メモリの閾値超過テスト
CPUやメモリの閾値超過テストでは、実際にC1812Jへ高負荷をかける方法は採用しませんでした。
代わりに、Raspberry Pi側の監視閾値を一時的に下げることで、異常判定を発生させました。
例えば、CPU使用率が通常24%程度であれば、テスト用の閾値を10%や15%へ変更することで、負荷をかけずに閾値超過を再現できます。
現在の監視値を確認
以前のSNMP取得結果では、C1812Jは次の状態でした。
| 監視項目 | 前回の実測値 | 通常のWarning閾値 |
|---|---|---|
| CPU（5分平均） | 24% | 80% |
| メモリ Pool 1 | 33.0% | 85% |
| メモリ Pool 2 | 14.2% | 85% |
今回のテストでは、CPUとメモリPool 1のWarning閾値を一時的に10%にします。
監視を停止してバックアップ
まず、監視タイマーを一時停止します。
sudo systemctl stop pi-monitor.timermonitor.pyを退避します。
sudo cp -a /opt/pi-monitor/monitor.py \
/opt/pi-monitor/monitor.py.bak
CPU・メモリの閾値を一時変更
CPUとメモリの閾値判定部分を探します。
grep -nE 'cpu|mem|CPU|MEM|threshold|warning|critical' \
/opt/pi-monitor/monitor.py閾値が定数として定義されている箇所を、次のテスト値に変更します。
| 項目 | Warning | Critical |
|---|---|---|
| CPU | 10% | 15% |
| メモリ Pool 1 | 10% | 20% |
sudo nano /opt/pi-monitor/monitor.py
これなら以前の実測値が維持されていれば、両方ともCritical条件を満たします。
手動実行で確認
まずPythonの構文を確認します。
sudo python3 -m py_compile /opt/pi-monitor/monitor.py問題がなければ、監視サービスを実行します。
sudo systemctl start pi-monitor.service
sudo journalctl -u pi-monitor.service -n 30 --no-pagerCPUの連続判定を確認するため、必要に応じて約1分間隔で5回実行します。
for i in 1 2 3 4 5; do
sudo systemctl start pi-monitor.service
sleep 60
done実際にCPU・メモリのメール通知が届くことを確認できました。
テスト終了後に元へ戻す
テスト後は、バックアップから元の監視スクリプトを復元します。
sudo cp -a /opt/pi-monitor/monitor.py.bak \
/opt/pi-monitor/monitor.pyその後、1回実行して正常判定・復旧メールを確認します。
sudo systemctl start pi-monitor.service
sudo journalctl -u pi-monitor.service -n 30 --no-pager
最後に自動監視を再開します。
sudo systemctl enable --now pi-monitor.timer
systemctl list-timers --all pi-monitor.timer閾値を戻し忘れると、通常状態でも障害メールが送信されるため注意が必要です。
インターフェースDOWN通知のテスト
インターフェースの障害テストでは、FastEthernet2を対象としました。
FastEthernet2はラズベリーパイと接続しています。そのためshutdownするとラズベリーパイにアクセスできなくなります。
そこで、Python側でSNMP取得結果を模擬する方法を使用しました。
実機からSNMP情報を取得したあと、Fa2のifOperStatusだけをDOWNとして監視処理に渡します。
この方法なら、ルータの設定を変更せずに障害判定をテストできます。
現在の監視を停止・バックアップ
監視タイマーを一時停止し、monitor.pyを退避します。
sudo systemctl stop pi-monitor.timer
sudo cp -a /opt/pi-monitor/monitor.py \
/opt/pi-monitor/monitor.py.bak-iftest既存の通知状態を保護するため、状態ファイルもバックアップします。
sudo cp -a /var/lib/pi-monitor/state.json \
/var/lib/pi-monitor/state.json.bak-iftestテスト用スクリプトを配置
本番のmonitor.pyを直接編集する代わりに、別ファイルでSNMP取得結果を模擬します。
test_interface.pyを/opt/pi-monitor/に配置します。
DOWN通知をテスト
環境変数を読み込んで実行します。
sudo bash -c '
set -a
source /etc/pi-monitor.env
set +a
cd /opt/pi-monitor
python3 test_interface.py
'同じコマンドを合計3回実行。
1回目にWARNING。
3回目にCRITICALメールが届きました。
復旧通知をテスト
DOWNのテスト後、本番の監視スクリプトを通常実行します。
sudo systemctl start pi-monitor.service
sudo journalctl -u pi-monitor.service -n 30 --no-pagerRECOVERYメールが届きました。
監視を再開
テストが完了したので、自動監視を再開します。
sudo systemctl enable --now pi-monitor.timer
systemctl list-timers --all pi-monitor.timer最後に通常監視が正常か確認します。
sudo journalctl -u pi-monitor.service -n 20 --no-pager監視システムの運用でよく使うコマンド
構築後によく使うコマンドをまとめます。
| 操作 | コマンド |
|---|---|
| タイマー状態確認 | systemctl status pi-monitor.timer |
| 次回実行時刻確認 | systemctl list-timers pi-monitor.timer |
| 手動監視実行 | sudo systemctl start pi-monitor.service |
| 監視ログ確認 | sudo journalctl -u pi-monitor.service -n 30 |
| リアルタイムログ確認 | sudo journalctl -u pi-monitor.service -f |
| CSV確認 | sudo tail -n 5 /var/log/pi-monitor/metrics.csv |
| タイマー停止 | sudo systemctl stop pi-monitor.timer |
| タイマー再開 | sudo systemctl start pi-monitor.timer |
監視が正常に動作しているか確認する場合は、まずsystemd timerの状態と、直近のサービス実行ログを確認するとよいでしょう。
構築した監視システムの動作確認結果
今回、実際に確認できたテスト結果は次のとおりです。
| テスト項目 | 結果 |
|---|---|
| SNMP障害 WARNINGメール | 成功 |
| SNMP障害 CRITICALメール | 成功 |
| SNMP障害 RECOVERYメール | 成功 |
| CPU閾値超過メール | 成功 |
| メモリ閾値超過メール | 成功 |
| インターフェース復旧メール | 成功 |
| 自動監視タイマー再開 | 完了 |
これにより、SNMP障害とCPU・メモリの閾値超過、インターフェース復旧に関するメール通知が動作することを確認できました。
今後追加したい監視機能
今回の構成でも基本的なネットワーク監視は可能ですが、さらに運用性を高めるなら、次のような機能も検討できます。
インターフェースのErrors・Discards監視
現在はインターフェースの状態と通信量を取得しています。
今後はifInErrorsやifOutErrors、Discardsなども取得することで、リンクがUPしていても通信品質に問題がある状態を検知できます。
トラフィックのグラフ化
CSVに保存している通信速度をグラフ化すれば、帯域使用率の推移を視覚的に確認できます。
PythonのMatplotlibなどを使う方法や、Grafanaなどの可視化ツールと連携する方法が考えられます。
Raspberry Pi自身の停止検知
今回の構成では、Raspberry Pi自身のCPU・メモリ・ディスク・温度も監視しています。
しかし、Raspberry Piが停止した場合、監視プログラムも実行されなくなります。
そのため、別の端末や外部サービスからRaspberry Piの生存を監視する仕組みを追加すると、監視システム全体の信頼性が高まります。
SNMPv3への移行
今回使用したSNMPv2cは設定が比較的簡単ですが、コミュニティ文字列が暗号化されません。
対応する機器・IOSであれば、認証や暗号化を利用できるSNMPv3への移行も検討したいところです。
SNMPv2cとSNMPv3に違いはこちらの記事でまとめています。
【実機検証】Cisco C1812JとRaspberry PiでSNMPv2c・SNMPv3の違いをWiresharkで確認してみた | Yuu Log
まとめ：Raspberry PiとPythonで実用的なSNMP監視環境を構築できた
今回は、Raspberry Piを使ってCisco C1812Jを24時間自動監視するシステムを構築しました。
構成のポイントは次のとおりです。
- Raspberry PiをSNMP監視サーバとして使用
- PythonとNet-SNMPでCiscoルータの情報を取得
- CPU・メモリ・インターフェース状態・通信量を監視
- systemd timerで1分ごとに自動実行
- CSVとJSONで監視履歴・障害状態を保存
- Gmail SMTPでWARNING・CRITICAL・RECOVERYを通知
- 実機に負荷をかけず、障害通知テストを実施
専用の監視ソフトウェアを導入しなくても、Linuxの標準機能とPythonを組み合わせることで、必要な監視項目に絞ったシンプルな監視システムを構築できます。
また、SNMPのOIDやPythonの処理を理解しながら構築することで、ネットワーク機器の状態取得や障害判定の仕組みも学べます。
小規模ネットワークや自宅ラボの監視環境を作りたい方、SNMP・Python・systemdの学習を兼ねてネットワーク監視を自作したい方には、取り組みやすい構成だと思います。
今後は、インターフェースのエラーカウンタ監視やトラフィックのグラフ化なども追加し、より実用的なネットワーク監視システムへ拡張していきたいと考えています。
