この記事は、Zabbix - Qiita Advent Calendar 2025 - Qiitaの9日目の記事です。
昨日は2box2boさんのホームIoTのお話でした！
ArubaのIAPについて
無線APとして使っている方の多いArubaには、いくつかの管理方式があります。
- スタンドアロン
- IAP(仮想クラスタ)
- Aruba Central
この中で、我が家にあるArubaは2番目のIAPを利用しています。
そのAPのメトリクスデータをZabbixで取得した話を記載します。
Aruba IAPのSNMP関連の実装
Aruba IAPは、なかなか変わったSNMPのつくりをしています。
ある特定ファームまで
- IAPの代表アドレス…クラスタ配下の全APのリソース情報(CPU/Memory)を返す
- 各APの実アドレス…以下の2種類を返す
- 自分自身のCPU/Memoryなどのリソース情報
- 自分自身のSSID毎に接続しているユーザの数
そして、以下の条件が厄介な縛りになっていました。
- IAPのマスターになっているAPの実アドレス…クラスタ配下の全APのリソース情報を返す
そのため、単純にディスカバリをかけると、このような事態になってしまいます。
監視対象のアドレスと取得できる情報の関係
| 監視対象のアドレス | 役割/状態 | 取得できる情報 |
|---|---|---|
| IAPの代表アドレス | クラスタ全体 | クラスタ配下の全APのリソース情報のアイテム |
| IAPのマスターになっているAPの実アドレス | マスターAP | (1)クラスタ配下の全APのリソース情報のアイテム (2)自分自身のSSID毎に接続しているユーザー数を示すアイテム |
| IAPのマスターになっていないAPの実アドレス | 非マスターAP | (1)自分自身のAPのリソース情報のアイテム (2)自分自身のSSID毎に接続しているユーザー数を示すアイテム |
これの厄介なのは、「マスターは確定の特定の1台ではない」という点です。
優先マスターというものを定義することは可能ですが、そのマスターがダウンした場合にはほかのAPがマスターの役目を引き継ぎます。
そうなるとどうなるか、みなさん、もうお分かりですね…そう、マスターのフェイルオーバー後にディスカバリをかけると、クラスタ内リソースアイテムの保有ホストが変わります。
ホストに依存したダッシュボードやScreenを作っている場合には阿鼻叫喚になります。
ちなみに、インデックスの値は、各APのMACアドレスが使われています。
私個人としては、物理ホストを監視するなら、アラートモニタリングもそのホストに寄せておきたい、という思いがありました。そのため、このファームの頃は、ディスカバリされたアイテムに対してMACアドレスの値でフィルタの機能を活用し、以下のように実装していました。
フィルタを活用した監視設計
| 監視対象のアドレス | 取得できる情報（元のデータ） | 監視・フィルタ処理の詳細 |
|---|---|---|
| IAPの代表アドレス | 監視しない | 監視対象外 |
| IAPのマスターになっているAPの実アドレス | (1)クラスタ配下の全APのリソース情報のアイテム (2)クラスタ配下の全APで合計されたSSID毎に接続しているユーザの数を示すアイテム | クラスタ配下の全APのリソース情報に対し、フィルタを適用し、自身のみのリソースアイテムを作成する。 |
| IAPのマスターになっていないAPの実アドレス | (1)自分自身のAPのリソース情報のアイテム (2)自分自身のSSID毎に接続しているユーザの数を示すアイテム | 取得データはもともと自身のリソース情報のみであるため、フィルタは同様にかかるが、実質的な変化はない。 |
マスターになっている機器のSSID毎のユーザ数は正確には把握できませんが、引き算すればなんとかなる！という状態にまで持ってきました。
さあ、これでメトリクスを取れるようになったーばんざーい、と喜んでいたのもつかの間でした。
特定のファームウェア以降からの動作
なんと、IAPのファームウェア更新により、上記の動作が以下のように変化しました。
ファームウェア更新後の動作
| 監視対象のアドレス | 役割/状態 | 取得できる情報 |
|---|---|---|
| IAPの代表アドレス | クラスタ全体 | クラスタ配下の全APのリソース情報のアイテム |
| IAPのマスターになっているAPの実アドレス | マスターAP | (1)クラスタ配下の全APのリソース情報のアイテム (2)クラスタ配下の全APで合計されたSSID毎に接続しているユーザー数を示すアイテム |
| IAPのマスターになっていないAPの実アドレス | 非マスターAP | (1)自分自身のAPのリソース情報のアイテム:取得不可 (2)自分自身のSSID毎に接続しているユーザー数を示すアイテム: 取得可能 |
このことを知らずに、私はそのままテンプレートを使い続けており、しばらくしてダッシュボードを見ると、「あれ？リソースの値なくない？」となり、焦りました。このバランスの悪さ、何と言っていいのかもう…多分Centralを使ってほしいのかなあ、という気がしています。
現在の状態とテンプレートの公開
結果的に、以下のような形で現在は運用しています。
最終的な監視設計
| 監視対象のアドレス | 監視アイテムの元の状態 | 最終的な監視設計の決定 |
|---|---|---|
| IAPの代表アドレス | クラスタ配下の全APのリソース情報のアイテムができる | 監視を再開し、各APのリソース情報はここの情報を採用する |
| IAPのマスターになっているAPの実アドレス | (1)クラスタ配下の全APのリソース情報のアイテムができる (2)クラスタ配下の全APで合計されたSSID毎に接続しているユーザの数を示すアイテムができる | (1)リソース情報:重複回避のため、テンプレートから外す (2)合計ユーザー数:過去実装と同じため、そのまま採用 |
| IAPのマスターになっていないAPの実アドレス | (1)自分自身のAPのリソース情報のアイテムができない (2)自分自身のSSID毎に接続しているユーザの数を示すアイテムができる | (1)リソース情報:取得不可のため、テンプレートから外す (2)ユーザー数:そのまま採用 |
テンプレートをこちらに掲載しておきます。動かなかったら教えてください。
テンプレートは2種類あります。
テンプレートの種類
| 監視テンプレート名 | 紐づけ対象のホストアドレス | 備考 |
|---|---|---|
| Aruba Resource Monitoring Template for VC | VC (代表アドレス) のホスト | Virtual Controller (VC) 全体のリソース監視用 |
| Template Aruba Wireless Users | 各APの実ホストアドレス | APごとの接続ユーザー数などの監視用 |
それぞれ、SNMPコミュニティ名をホストマクロで定義して利用してください。
なお、SSID毎のユーザ数取得については、Zabbix5系の頃に作っていた計算アイテムのままなので、ロジック決め打ちで作っています。今ならもう少し柔軟な記載方法があるはずです。
終わりに
駆け足で書いたので、絵などもなく申し訳ありません。また別途、イメージ画像付きで補足します。どなたかの何かのヒントになれば幸いです。
さあ、明日はどなたかな？！枠はあいているぞ！！
https://tenko.hatenablog.jp/entry/2025/12/09/210416
バックアップ日時: 2026年11月11日