Migration / Monitoring

Claude Code を使って PRTG のネットワーク機器監視定義を
Zabbix へ移行してみた【続編】 #

前回の UPS 編に続き、今回はスイッチ・ルーター・無線 AP が混在する環境を移行。全台同一ベンダーという統一感を活かしつつ、「先に登録・あとで有効化」という安全な手順で進めた。

Claude Code PRTG Zabbix SNMP Python

前回（UPS 編）との違い #

前回は全台 APC UPS という均一な構成だったため、テンプレートを 1 種類当てるだけで完結した。今回は スイッチ・ルーター・無線 AP が混在する 2023 年のバックアップが対象だ。

前回（UPS 編）

全台 APC UPS #

テンプレート 1 種類・即時有効化。
30 分で完了。

今回（ネットワーク機器編）

3 カテゴリ混在 #

スイッチ・ルーター・AP に分類。
SNMP 疎通確認後に有効化する手順を採用。

全台が同一ベンダー製という点は今回の強みだった。 ベンダーが統一されているため、テンプレートの選定が迷わずに済んだ。

今回の移行対象 #

PRTG の 2023 年バックアップ（PRTG Configuration.dat）を解析した結果、ネットワーク機器として以下の 11 台を移行対象とした。

スイッチ（5 台）

国内大手ネットワークベンダー製 #

コアスイッチ 1 台、L2 スイッチ 4 台。
全台同一ベンダーで統一されていた。

ルーター（2 台）

エッジルーター × 2 #

プライマリ・セカンダリ構成。
PRTG では Syslog センサーも設定されていた。

無線 AP（4 台）

法人向け無線 AP × 4 #

各フロア・拠点に分散配置。
全台同一モデル。

PRTG でのセンサー構成

ほぼ Ping のみ #

44 センサー ÷ 28 台 ≈ 1.5 個/台。
SNMP 監視は未設定の台数が多かった。

PRTG 側のセンサーがほぼ Ping のみだったため、SNMP の疎通が取れるか不明だった。 そのため今回は「先に Zabbix へ登録・監視は無効状態で保留し、SNMP 疎通確認後に個別有効化」という手順を採った。

事前準備：Zabbix サーバーへの静的ルート追加 #

今回の対象機器は監視専用セグメント（以下 x.x.x.0/24 と表記）に存在する。 Zabbix サーバーからこのセグメントへの経路がなかったため、移行作業の前に静的ルートを追加した。

ポイント：nmcli connection up は使わない。
静的ルートの追加には nmcli connection modify と ip route add を併用する。 nmcli connection up を実行するとインターフェースが一時切断されるため、本番環境では避けるべきだ。

# 永続化（再起動後も有効）
nmcli connection modify 'System eth1' +ipv4.routes 'x.x.x.0/24 x.x.x.1'

# 即時反映（現セッションのみ）
ip route add x.x.x.0/24 via x.x.x.1 dev eth1

Claude Code に渡した指示 #

今回は UPS 編の反省を活かし、テンプレートのマッピング確認で必ず一時停止させるステップを指示に盛り込んだ。 UPS 編では電圧閾値の違いでアラートが誤発報したが、今回は事前確認でその問題を防ぐ狙いだ。

PRTG のバックアップを解析してネットワーク機器を Zabbix に移行してほしい。
今回はスイッチ・ルーター・AP が混在する環境だ。

STEP 1: XML 解析。デバイスを switch / router / ap / other に分類して CSV に出力。
STEP 2: template.get でテンプレート一覧を取得し、マッピング表を作成して確認を取る。
        私が「OK」と返答するまで STEP 3 には進まないこと。
STEP 3: ホストグループを作成し、カテゴリ別に登録する。
        ※ 全台 Disabled（監視無効）で登録すること。SNMP 疎通確認後に個別有効化する。
STEP 4: 差分確認レポートを出力する。

STEP 2 のマッピング確認 #

Claude Code が Zabbix API で取得したテンプレート一覧をもとに、以下のマッピングを提案してきた。全台が同一ベンダー製のため、スイッチ・ルーター・AP はすべて同一テンプレートで問題なかった。

switch  → Network Generic Device by SNMP（templateid=10226）
router  → Network Generic Device by SNMP（templateid=10226）
ap      → Network Generic Device by SNMP（templateid=10226）

インターフェース: SNMP v2c / community=public / port=161
登録状態: Disabled（全台・疎通確認後に有効化）

登録結果 #

登録台数

11 台すべて成功 #

エラーゼロ。
全台 Disabled 状態で登録完了。

作成ホストグループ

3 グループ #

Migrated-NW-Switch
Migrated-NW-Router
Migrated-NW-AP

カテゴリ別登録内訳 #

スイッチ（5 台）

コアスイッチ 1 台
L2 スイッチ（PoE 対応）4 台

ルーター（2 台）・AP（4 台）

エッジルーター 2 台（プライマリ・セカンダリ）
法人向け無線 AP 4 台（各拠点）

UPS 編との比較：何が違ったか #

✅ 同じだったこと

バックアップ XML の直接解析（サーバー不要）
Claude Code がスクリプト生成から実行まで自動
ホストグループ・テンプレートの自動適用
登録後の差分レポート出力

📋 今回追加したこと

デバイスをカテゴリ別に分類して登録
テンプレートマッピング確認ステップ（一時停止）
全台 Disabled で登録（疎通確認後に有効化）
静的ルートの事前追加

注意点：Syslog センサーと SNMP 疎通 #

一部のルーターは PRTG で Syslog センサーが設定されていた。
Zabbix でも Syslog を受信したい場合は、別途 Zabbix の Syslog 受信設定が必要になる。今回は登録のみ行い、Syslog 設定は残作業として後回しにした。

Disabled 登録は正解だった。
PRTG 側のセンサーがほぼ Ping のみだったということは、機器側の SNMP 設定が未確認または未設定の可能性がある。監視有効化の前に機器側で snmp-server enable とコミュニティ文字列の設定確認を行うことを推奨する。

有効化前の確認チェックリスト #

機器側で SNMP エージェントが有効になっているか（snmp-server enable）
コミュニティ文字列が設定済みか確認（Zabbix 側と一致しているか）
Zabbix サーバーから対象機器の UDP/161 が通信できるか
Zabbix から snmpwalk で実際に応答が返るか確認

現在の状況と残作業 #

完了

Zabbix への登録 #

11 台すべて Disabled 状態で登録済み。
ホストグループ・テンプレートも適用済み。

残作業

SNMP 疎通確認 → 有効化 #

機器側の SNMP 設定確認後、
1 台ずつ個別に監視を有効化する予定。

UPS 編からの改善点 #

テンプレートは必ず事前確認してから適用する
UPS 編では電圧閾値の違いでアラートが誤発報した。今回は STEP 2 で必ず一時停止させ、マッピング表を人間が確認してから先に進む設計にした。
疎通が取れていない機器は Disabled で登録する
PRTG のセンサー構成を見ると SNMP が設定されていない台数が多かった。即時有効化せず「登録だけ先に済ませて後で確認」という手順が安全だ。
事前の環境確認をプロンプトに含める
静的ルートの追加など、移行スクリプトの実行前に必要な環境準備をプロンプトの冒頭に書いておくと Claude Code が確認ステップを提案してくれる。
カテゴリ分類ルールを明示する
デバイス名からカテゴリを推定させる場合、命名規則（接頭辞・接尾辞）を具体的に列挙しておくと分類精度が上がる。

次のステップ #

登録した 11 台の SNMP 疎通確認が完了したら、順次監視を有効化していく。また一部のルーターについては Syslog 受信の設定追加も検討中だ。

PRTG 側のセンサーがほぼ Ping のみだった機器も、Zabbix のテンプレートを活用することで CPU 使用率・インターフェーストラフィック・メモリ使用率などを追加コスト不要で監視できるようになる。 移行はゴールではなく、監視品質を上げるスタートラインだ。

Claude Code を使って PRTG のネットワーク機器監視定義を Zabbix へ移行してみた【続編】