0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@qryuu(九龍 真乙)

SNMP非対応ルーターをZabbixで可視化する（令和版）── AI時代のテンプレート開発と、変わらない監視設計の勘所

0
Last updated at Posted at 2026-10-18

今から約6年前の2020年、私は「SNMP非対応の一般のご家庭用ルーターをZabbixで可視化した話」という記事を書きました。
Zabbix 3.4 で導入された「値の前処理」と「依存アイテム」に感動し、手作業で正規表現を組み立てて家庭用ルーター（ASUS RT-AC87U）のCPU使用率を泥臭くパースした記録です。

時は流れて令和の現在。自宅のルーターは約5年前に導入した10GbEポート搭載のWi-Fi 6ルーター「 ASUS RT-AX89X 」となり、監視基盤も Zabbix 7.0 LTS へと進化しました。
相変わらず家庭用ルーターはSNMPに非対応ですが、SSHログインは健在です。

今回は、最新のエージェント型AIとペアプログラミングを行い、単なるCPU監視にとどまらず、 「Wi-Fi 6の電波品質（端末数・RSSI・SNR）」 から 「全15基のサーマルゾーン自律ディスカバリ（LLD）」 、そして 「Zabbix 7.0 ネイティブの3タブ・テンプレートダッシュボード」 までを丸ごと内包したAll-in-Oneテンプレートを開発・公開しました。

本記事では、AIとの協働によってテンプレート開発がどう加速したのか、そして 「なぜフルオートでは作れず、AIのもっともらしい嘘を見抜き、監視設計の文脈を与える人間の目が必要だったのか」 そのリアルな現場の実態について共有します。

1. 6年越しの進化：RT-AC87U から RT-AX89X へ

まず、2020年当時と現在の環境の違いを整理してみます。

比較軸 2020年（旧記事：RT-AC87U） 令和現在（本記事：RT-AX89X）
対象機器 ASUS RT-AC87U（Wi-Fi 5 / BusyBox） ASUS RT-AX89X （Wi-Fi 6 / Qualcomm IPQ8074 SoC / 10GbE SFP+ & RJ45）
Zabbix環境 Zabbix 3.4 で導入された値の前処理・依存アイテムを活用 Zabbix 7.0 LTS （最新UI、ウィジェット刷新、進化したLLD）
データ収集方式 10秒毎に top を実行し、正規表現でCPUのみパース 単一SSHマスターアイテム （30秒に1回、単一セッションで全メトリクスを一括テキスト採取・前処理展開）
可視化の深さ CPU使用率の内訳（user, system, idle等）＋ Ping 3タブ・テンプレートダッシュボード内蔵 （システム概要 / Wi-Fi 6無線品質 / 全15基サーマルゾーン推移）
公開リポジトリ Zabbix Share（旧公式共有サイト・現在廃止） GitHub OSS公開 ＋ Zabbix公式Community Templates（PR #865）寄稿

2020年当時は、ルーターにログインして top コマンドを叩き、返ってきたテキストから正規表現で7つのCPUメトリクスを取り出すだけでも「わざわざawkでワンライナーを書かなくて済むようになった！」と喜んでいました。

しかし、RT-AX89Xのように家族の端末や大量のスマートホーム機器（IoT）を収容し、10GbE通信をさばくルーターになると、運用者が見たい情報はCPUだけではありません。
「電波干渉や端末の遠さで無線品質が落ちていないか」「基板の各部が想定外の熱を持っていないか」といった、 通信品質とハードウェア健全性の深層情報 こそが本当に欲しいメトリクスです。

2. 単一SSHマスターアイテム設計とAIの加速力

組み込みLinuxを殺さない「単一SSHセッション」アーキテクチャ

組み込みLinux（Dropbear SSH）を監視する際、最も警戒すべきなのは 「監視処理そのものが原因でルーターが過負荷に陥ること」 です。
アイテムごとに都度SSH接続を確立していると、TCPハンドシェイクに加えて暗号化鍵交換の計算オーバーヘッドが頻発し、ルーターのCPUを著しく圧迫します。

そこで本テンプレートでは、 30秒に1回、単一のSSHセッション内で必要なコマンドを一括実行し、区切り文字付きのテキストとしてまとめて取得する アーキテクチャを採用しました。

ルーター内で実行するコマンドの実態は、以下のような素朴なシェルスクリプトです。

echo '===TOP==='
top -b -n1 | head -n 5
echo '===UPTIME==='
cat /proc/uptime
echo '===LOADAVG==='
cat /proc/loadavg
echo '===WANIP==='
nvram get wan0_ipaddr
echo '===PING==='
ping -c 1 -W 2 google.com 2>&1
echo '===THERMAL==='
for z in /sys/class/thermal/thermal_zone*; do
    echo -n "$(basename $z)|"
    tr -d '\n' < $z/type 2>/dev/null || echo -n "unknown"
    echo -n "|"
    cat $z/temp 2>/dev/null || echo 0
done
echo '===WIFI_IW==='
iwconfig ath0 2>/dev/null | grep -E 'Signal level|Noise level|Bit Rate'
iwconfig ath1 2>/dev/null | grep -E 'Signal level|Noise level|Bit Rate'
echo '===WIFI_STA5G==='
wlanconfig ath0 list sta 2>/dev/null
echo '===WIFI_STA2G==='
wlanconfig ath1 list sta 2>/dev/null

この出力をマスターアイテム（ history: 0 でDBには保存しない）で受け、あとはZabbix Server側の前処理（正規表現やJavaScript）で各メトリクスへと展開します。
重いSSH暗号化セッションの確立が30秒に1回だけで済むため、ルーターへの負荷を最小限に抑えられます。

組み込み特有の「リファレンスのないコマンド」をAIで手繰り寄せる

Linuxサーバーの標準コマンド（ top , cat /proc/meminfo 等）であれば、長年インフラを触ってきたエンジニアなら息をするように扱えます。
しかし、組み込みルーター、それも特定のSoC（Qualcomm IPQ8074）に依存する無線ドライバ固有のコマンド（ wlanconfig athX list sta やサーマルゾーンの露出パスなど）となると話は別です。

この手の組み込み系コマンドは、Web上を探しても公式なリファレンスがほとんど存在しません。ベンダの閉じた仕様書や海外フォーラムの断片的な書き込み、あるいはカーネルソースの奥底に埋もれていることが大半で、ゼロから調査するには途方もない時間が溶けていきます。

ここでAIが真価を発揮しました。
「Qualcomm SoC環境で、接続端末ごとのRSSIやSNRを拾うコマンドは何か？」
「sysfs上に露出しているサーマルゾーンの型番と温度を1行でダンプするにはどう書けばいいか？」
と投げかけると、AIは断片的な組み込みドライバの知識を手繰り寄せ、必要最小限の採取コマンドを素早く提示してくれました。

また、Zabbix 7.0のダッシュボードウィジェット仕様（LLDで検出した15基のグラフをグリッド表示するグラフプロトタイプウィジェットの設定）の調査や、YAMLテンプレートの高速生成など、実装のスピードはAIによって劇的に加速しました。

3. それでもフルオートでは作れない── AIの「もっともらしい嘘」と人間の意図

ここまで読むと、「もう人間は要らなくて、AIに任せれば全自動で作れるのでは？」と思われるかもしれません。
しかし、実際に現場で手を動かしてみて痛感したのは、 「AIはもっともらしい嘘（ハルシネーション）を平気で語り、そのチャートから何を読み取りたいかという意図（センス）は持っていない」 という現実でした。

AIが語る「もっともらしい嘘」を現場で看破する

開発の過程でAIに設計のまとめを頼んだ際、AIは平気で以下のような「事実と異なるストーリー」を出してきました。

  • 「ルーターからクリーンなJSONペイロードを出力させ、JSONPathで展開しました」
    ➔ 嘘。 組み込み機器のBusyBoxにはjqなど入っておらず、シェルだけで堅牢なJSONを組み立てるのは逆に処理が重い。実際の実装は上記のとおり ===TOP=== などの区切りテキスト＋正規表現/JS前処理である。
  • 「grepやawkの多段forkを徹底排除してプロセス負荷をゼロに近づけました」
    ➔ 的外れ。 実際には top | head や15ゾーン分のループ内で cat などを呼んでおり、ざっと数えても数十回のプロセス生成は普通に発生している。単一SSHの狙いはそこではなく、「SSHの接続確立（鍵交換）を、メトリクスの数だけ繰り返さず30秒に1回にまとめること」である。

AIは「それっぽい技術解説」を流暢に出力してきますが、 実機のコードと物理制約を突き合わせて「それは実装と違う」「本質はそこではない」と見抜けるのは、現場で手を動かしている人間だけ です。

「階段状グラフ（Staircase）」に見る、エンジニアの意志

もう一つの決定的な差が、可視化における「読影のセンス」です。象徴的だったのが、Wi-Fiの「接続端末数」のグラフ表現でした。

AIにダッシュボードの生成を任せると、何も言わなければ一般的な「折れ線グラフ（描画: 線。YAML上は ds.type: 0 ）」で描画しようとします。
しかし、 接続端末数は「個数（離散値）」 です。2.4台や3.7台といった中間の状態は物理的に存在しません。端末がWi-Fi圏内に入った瞬間、あるいは切断された瞬間に、数値はカクッと一段ステップ変化します。

これを線で描いてしまうと、「いつ端末が増減したのか」という境界線がなだらかに補間されてしまい、ネットワークのトラブルシュートにおいて極めて読みづらいグラフになってしまいます。

【折れ線グラフ（AIの初期描画）】
端末数 4 ───／＼───  ← いつ増えていつ減ったのかの瞬間が曖昧
端末数 3 ──／────＼─

【階段状グラフ（Staircase: 人間の指定）】
端末数 4     ┌─────┐  ← 端末が接続された「正確な時刻」が直感的に一目でわかる
端末数 3 ────┘     └──

「端末数のデータセットには ds.type: 2 （描画: 階段状 / Staircase）を適用して、ステップ変化を直感的に捉えられるようにする」という指定は、 「このグラフを運用でどう読影したいか」という強い意図を持ったエンジニア でなければ下せません。

3タブ構成のダッシュボードに込めた「読影の文脈」

AIはビルボード（単一値カード）やゲージ、パネルといった個々のUIコンポーネントを提案するのは得意です。
しかし、それらをどうグルーピングし、どのような視線移動で障害を切り分けるかという「ダッシュボードの文脈」は人間にしか設計できません。

今回実装したテンプレートダッシュボードは、以下の 明確な3タブ構成 になっています。

  1. タブ1: システム概要 (System Overview)
    • ルーター自身の基礎体力（CPU半円ゲージ、メモリDoughnut、CPU詳細負荷推移、メモリ推移、GoogleへのPing応答時間）を一望。
    • まず「ルーター自体の処理能力がパンクしていないか」を5秒で判定する画面。
  2. タブ2: Wi-Fi 6 無線品質 (Wi-Fi Quality)
    • 接続端末数カード（合計・5GHz・2.4GHz）としきい値カラー付きWi-Fi品質カード（5GHz / 2.4GHzの平均RSSI・平均SNR 計4枚）。
    • 端末数の増減が明確にわかる階段状推移グラフ。
    • 5GHz帯および2.4GHz帯の電波環境推移（平均RSSI、最小RSSI、平均SNR）と、フロアノイズ推移（参考値：後述のとおり、この機種では固定値でした）。
    • 「ネットが遅い」「IoT機器が途切れる」と感じたとき、それがルーター負荷ではなく「電波干渉や低レート端末の専有」によるものかを切り分ける画面。
  3. タブ3: 各部温度推移 (全15基) (Thermal Zones)
    • 基板上の全15基のサーマルゾーンをLLDで自動検出し、タイル状にグリッド表示。
    • 高負荷通信時などに、局所的な熱だまりやサーマルスロットリングが発生していないかを監視する画面。

障害が起きたとき、運用者は 「システム（CPU/メモリ） ➔ 無線環境（電波/干渉） ➔ ハードウェア（熱）」 の順に仮説を検証していきます。このストーリー（読影の導線）を引くことこそが、監視設計の本体なのです。

4. 「回線ガチャ」の前に、ルーターのデータを読む

自宅のインターネットが「なんとなく遅い」「オンライン会議で声が途切れる」と感じたとき、多くの人は真っ先に「プロバイダが悪いのではないか」「光回線の契約を変えようか（回線ガチャ）」と考えがちです。
しかし、手元にルーターの監視データがあれば、より客観的に仮説を立てることができます。

シナリオ1：CPUの負荷と sirq の観測

ルーターのCPU負荷推移を監視していると、 sirq （ソフトウェア割り込み）が集中して上昇する場面を観測することがあります。以前のテンプレートでも確認していましたが、原因はまだ分かっていません。
パケット転送の処理なのか、ルーター側の機能設定の影響なのか、仮説はいくつか立てられますが、まだ特定できていません。観測できても原因は分からない、という状態です。それでも「回線のせいにする前にルーター内部を疑う」ための起点にはなります。

シナリオ2：2.4GHz帯の不安定さと、低レート端末の疑い

我が家では、2.4GHz帯に接続しているSwitchBotの機器がたまに不安定になりますが、原因はまだ分かっていません。
Wi-Fiでは、電波の悪い端末が混ざると低い変調レート（MCS）で通信するため電波を長時間専有してしまい、周囲の通信まで引きずられる現象（802.11の performance anomaly）が知られています。SwitchBotの不調がこれに当たるのか、それとも端末固有の問題や周囲の電波干渉なのかを切り分けるには、2.4GHz帯の電波強度（RSSI）などの客観データが不可欠です。

そこで今回のテンプレートでは、5GHz帯だけでなく 2.4GHz帯の電波環境推移（平均RSSI・最小RSSI・平均SNR） もダッシュボード（タブ2）に組み込みました。これにより、SwitchBotが途切れた瞬間に「最小RSSIが悪化して低レート端末の専有が起きていたのか」を、ダッシュボード上で間接的に照合できるようになりました。最小RSSIはあくまで低レートの「手がかり」であり、各端末の通信レート（wlanconfig の TXRATE / RXRATE）までは、まだアイテム化していません。

なお、フロアノイズも収集してグラフ化しましたが、実機で iwconfig を確認したところ、5GHz・2.4GHzとも Noise level=-97 dBm のままで、数秒おきに取得しても変化しませんでした（Signal level も同じ -97 dBm で、AP自身のインターフェースが返す形式的な値に見えます）。 この機種では、iwconfig のノイズフロアは干渉検知の指標になりません。 ここもAIの説明を鵜呑みにせず、実機の出力を見て初めて分かったことです。

データが揃ったことで、ようやく真因の切り分けに向けた本格的な観察ができるスタートラインに立ったと言えます。

シナリオ3：全15基サーマルゾーンの常時把握

我が家ではルーターをエアコンの直下に設置しているため現在は熱暴走の心配はありませんが、15年ほど前に使っていたNEC製のルーターでは、熱が原因ではないかと疑わしい事象がありました。
実は、RT-AX89Xのsysfs（ /sys/class/thermal/thermal_zone* ）には15基もの温度センサが存在しますが、メーカーの説明書に部位の対応表が載っているわけではありません。AIが提示してくる部位名（NSSやPAなど）も、所詮はチップセットのセンサ名（tsens）からの「推定」に過ぎないのです。実機で確認できる一次情報は、 tsens_tz_sensor4〜15 と pa_therm1〜3 という type 名と温度値だけで、テンプレート上の日本語の部位名は暫定のラベルです。

だからこそ、推測だけで特定のセンサだけを監視するのではなく、 LLDで全15基をまるごと検出し、普段の定常温度と波形を把握しておく ことに意味があります。「エアコン直下で本当に冷えているか」「高負荷時にも警告しきい値（既定80℃）に達していないか」を数値で裏付けられる安心感は、運用者にとって大きな価値です。

5. テンプレートの導入とセキュリティの注意点

今回開発したテンプレートは、GitHubリポジトリにてMITライセンスで全公開しています。
また、世界中のASUSルーターユーザーが利用できるよう、日本語版と英語版のバイリンガル対応を行い、 Zabbix公式コミュニティテンプレート（PR #865） にも寄稿・申請中です。

導入手順（3ステップ）

  1. テンプレートのインポート:
    • リポジトリから template/template_asus_rt_ax89x_ja.yaml をダウンロードします。
    • Zabbix Web UIの「データ収集」→「テンプレート」→「インポート」からインポートします。
  2. ホストの作成とリンク:
    • ルーターのホストを作成し、テンプレート ASUS-Router をリンクします。
    • インターフェースにはルーターのIPアドレス（例: 192.168.1.1 ）を設定します。
    • ルーター側でSSHサーバーを有効にしておきます（LANのみ。接続先ポートは22固定です）。
  3. ユーザーマクロの設定:
    • ホストの「マクロ」タブで、SSH接続情報を設定します。
マクロ名 デフォルト値 タイプ 説明
{$SSH_USER} (未設定・必須) テキスト ルーターのSSHログインユーザー名
{$SSH_PASS} (未設定) シークレットテキスト SSHログインパスワード
{$AX89X.TEMP.WARN} 80 テキスト サーマルゾーン温度の警告閾値 (°C)

⚠️ セキュリティ上の重要事項:
ASUSルーターの標準ファームウェア（Asuswrt）において、SSHログインアカウントは ルーターのWeb管理画面の管理者アカウントそのもの です。
セキュリティを確保するため、管理画面の「管理」→「システム」のSSH設定において WAN側からのSSH接続は絶対に許可せず（LAN側のみ許可） 、Zabbixホストマクロの {$SSH_PASS} には必ず 「シークレットテキスト」 を使用してパスワードの平文露出を防いでください。

設定後、30秒ほど待つとホストの「ダッシュボード」に3タブの画面が自動的に立ち上がります。

おわりに：AIを良き相棒として、監視をデザインする

2020年のRT-AC87Uから6年。
Zabbix 3.4からZabbix 7.0へ、そして手作業のシェル芸からAIエージェントとのペアプログラミングへと、技術の道具立ては大きく変わりました。

AIは、面倒なYAML構文の記述や組み込みコマンドの探索といった「実装の労力」を驚異的なスピードで引き受けてくれます。
しかし、 AIが出してきたもっともらしい解説の嘘を見抜き、実装の物理制約を理解し、「どのデータをどう描けば現場で読影できるか」という監視の文脈を与えること は、現場で機器と向き合うエンジニアにしかできません。

回線契約を見直す前に、まずは足元のルーターを科学してみませんか？

それでは、よいZabbixライフを。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?