こちらは Zabbix - Qiita Advent Calendar 2025 - Qiita の9日目の記事です。
どなたもいらっしゃらなかったので枠をいただきました。
昨日は 2box2bo - Qiita さんのホームIoTのお話！
我が家もラズパイを活用して無線リモコン(not 赤外線)の回路に介入してAlexaで操ったりしてるのですが、そちらはメトリクスはいまいちな感じです。ソーラー関係もあるので、気持ちとしてはそちらもメトリクス取りたい…ソーラーだけでなく全体管理するためにHEMS入れたい…(沼)
11日目のキラーパスなんですが、ちょっとテンプレートのデータをすっ飛ばしまして、Unifi のやつが書けるか微妙です。概念論だけになるかもしれません。
さて、本題です。（ちょっと絵がないとわかりにくいと思うので、後日補足します）
ArubaのIAPについて
無線APとして使ってらっしゃる方の多いArubaには、いくつかの管理方式があります。
この中で、我が家にあるArubaは2番目のIAPを利用しています。
そのAPのメトリクスデータをZabbixで取得した話を記載します。
Aruba IAPのSNMP関連の実装
Aruba IAPは、なかなか変わったSNMPのつくりをしています。
ある特定ファームまで
- IAPの代表アドレス…クラスタ配下の全APのリソース情報(CPU/Memory)を返す
- 各APの実アドレス…以下の2種類を返す
- 自分自身のCPU/Memoryなどのリソース情報
- 自分自身のSSID毎に接続しているユーザの数
そして、以下の条件が厄介な縛りになっていました。
- IAPのマスターになっているAPの実アドレス…クラスタ配下の全APのリソース情報を返す
そのため、単純にディスカバリをかけると、このような事態になってしまいます。
| 監視対象のアドレス | 役割/状態 | 取得できる情報 |
|---|---|---|
| IAPの代表アドレス | クラスタ全体 | (1)クラスタ配下の全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)ユーザー数: そのまま採用 |
テンプレートをこちらに掲載しておきます。動かなかったら教えてください。
https://gist.github.com/tk-4/c3f42cfe8b571009933d70354831bbe1
テンプレートは2種類あります。
| 監視テンプレート名 | 紐づけ対象のホストアドレス | 備考 |
|---|---|---|
| Aruba Resource Monitoring Template for VC | VC (代表アドレス) のホスト | Virtual Controller (VC) 全体のリソース監視用 |
| Template Aruba Wireless Users | 各APの実ホストアドレス | APごとの接続ユーザー数などの監視用 |
それぞれ、SNMPコミュニティ名をホストマクロで定義して利用してください。
なお、SSID毎のユーザ数取得については、Zabbix5系の頃に作っていた計算アイテムのままなので、ロジック決め打ちで作っています。今ならもう少し柔軟な記載方法があるはずです。
終わりに
駆け足で書いたので、絵などもなく申し訳ありません。
また別途、イメージ画像付きで補足します。
どなたかの何かのヒントになれば幸いです。
さあ、明日はどなたかな？！枠はあいているぞ！！
