この記事は、Zabbix - Qiita Advent Calendar 2025 - Qiita 18日目の記事です。
昨日の投稿は@hameko さんの記事です！
Zabbix6.0LTSを前提としたZabbix環境構築を丁寧にまとめてくださっています。これまで作ってみたことがない方も必見です！！
@hameko さんのQiitaを眺めていて、こちらの記事も大変良かったです。Zabbixを使ったモニタリングをどう業務に生かすか、みたいな視点で見てみるのも面白いかもしれません
（いいなあ、と思ってツイートしたら、思いのほか伸びてしまいました）
めちゃいい
運用オペレータを底辺とかいう人たちは、こういう学習の視点が芽生える場でもあることを知ってほしい
概要
本日は以前公開したSwitchBotのAPIを活用してZabbixで自宅メトリクスを取るのお話の続きです。
過去記事はこちらからご参照ください。
https://blog.t-techlab.work/posts/zabbix-switchbot/
別の記事でも書きましたが、反応を頂けるのは本当に励みになります。ありがとうございます。
現在の我が家のIoTダッシュボードはこちらです。ちゃくちゃくとSwitchBotさんのデバイスが増えてます。
いろいろあってZabbixデータをすべて吹き飛ばしてしまったので、自宅レイアウトにアイテム情報を表示させるMapが消えてます。こだわりのあるポイントなので、早く直さねば。
これを読むとわかること
- SwitchBot API Ver1.1の使い方と1.0との違い
- SwitchBot APIのリクエスト上限との戦い方
- SwitchBot の自作テンプレートの活用方法
- Zabbixでの未サポートアイテム停止の自動化
- SELINUX環境での動作不調の乗り越え方
また、いつものごとく先にテンプレートを公開しておきます。
今回、1.1対応にともない、テンプレートと外部スクリプトの2種類になりました。無念。
使い方ですが、ユーザマクロで以下２点のパラメータを定義してください。
- {$API_SECRET}
- {$API_TOKEN}
なお、まだ未完成なので、アドカレ外でまだ記事を書くと思います。
環境情報
SwitchBotを含む仕組みの概要構成図がこちらです。前回から変わりありません。
主な環境情報
- Zabbixバージョン: 7.2.14 - おかげでGPU監視ができるようになりました。
- SwitchBotAPI バージョン: 1.1 - JavaScript単体での実装はあきらめ、外部スクリプトに屈しました。
保有しているSwitchBotデバイス
多くなったので折り畳みにしておきます。
▼所有デバイスリスト(クリックして開く)▼
- ハブ
- 温湿度計
- スマートプラグ
- プラグミニ(JP)…2台(+1)
- CO2メーター…1台
- 人感センサー…1台
- 開閉センサー…1台
- ロボット掃除機＆スティッククリーナー…1台
- セキュリティロック…2台セット
- 顔認証パッド…1台
- プッシュボタン…1台
- リモートボタン…1台
- 見守りカメラ…1台
SwitchBot API Ver1.1の使い方と1.0の違い
SwitchBot APIでは、セキュリティ製品などの販売にともない、POSTメソッドなどを使って鍵の解錠をするなどができるようになっています。
ここで固定トークンだとセキュリティ強度が弱い、という理由から、シークレットキーを活用した乱数生成をAPI利用のヘッダに必要とするようになりました。
なお、私が試した限りでは、GETメソッドで取れる値は1.0 と1.1に差はありません。ただ、1.0はEoLということもあり、GETのみだったとしても1.1に切り替えることをお勧めします。
SwitchBot APIの公開サイトに、各コードのサンプルコードが載っているので、Zabbixで使いやすいJavaScript単体でもいけるのでは？？と思っていろいろと格闘したのですが、撃沈しました。
理由は以下の通りです。
- API利用のためのヘッダに必要なnonce,signの計算に必要なライブラリが利用できない
- hash() - 代替手段でhmac()が利用できることは確認できたが、base64encode()がNGなので無理
- base64encode() - base64encode()をライブラリレスで別のコードで個別実装させようとしたが、それも無理だった。
なお、Geminiくんは、何度も何度も「外部スクリプトの利用を強く推奨します」と言ってくれました。わがままな利用者でごめん。大好きだよ。
なので、結果的にはPythonで書いた外部スクリプトを使う、という実装に落ち着きました。
SwitchBot APIのリクエスト上限との戦い方
SwitchBot APIでは1日に10,000リクエストという上限が決まっています。
こちらを視覚的に把握しやすくするために、以下のアイテムを作成しました。
- 過去1日間で実際に利用したAPIリクエストの計算アイテム
- 直近1時間の実績から、このまま1日経過すると合計でどの程度のリクエスト数になるかを予測するためのアイテム
以下の画像は、試しに5分間隔で取得していたアイテムを10分間隔に修正した際の、予測と実績の推移です。いい感じで予測通りになっています。（当たり前）
これがあればパラメータチューニングがしやすくなります。
SwitchBot の自作テンプレートの活用方法
前回と今回の大きな差異
前回は、1つの代表ホストの中に、各SwitchBotデバイスのIDを持ったアイテムが作成される、という実装にしていました。
今回は、各SwitchBotデバイスを個別のホストとするよう、ディスカバリでホストプロトタイプを定義し、自動で各デバイスがホストとして登録される、という実装に変更しました。
主な理由としては、Key情報が同じになるためラベルが使いやすくなり、ホストグループを活用することでMAP上での表現が容易になるなど、様々な改善が期待できるためです。
また、現時点でSwitchBot APIのリファレンスで参照可能な各デバイスのアイテムをすべて作成する形に変更しています。
まず外部スクリプトを配置する
まず初めに、忘れないように、ダウンロードしてきた外部スクリプトを、SCPなどでZabbixサーバにアップロードし、externalscriptsのフォルダに配置します。
なお、以下コマンドで実行権限を与えるのを忘れないようにしてください。
sudo chmod +x /usr/lib/zabbix/externalscripts/switchbot-api11-get.pyZabbixでの未サポートアイテム停止の自動化
上記のような運用回避方法をご案内したのですが、私は怠惰なので、その作業すら自動化したい、と考えました。
そこで役に立つのが、トリガーアクションです。トリガーアクションは、スクリプトを用いてzabbix-apiを利用することが可能です。
そのため、上述した「データが取れない」というイベントをトリガーとして、以下のような制御をさせることが可能です。
- 対象アイテムを無効化する
- その結果、そのアイテムをトリガーとするトリガーイベントも動かなくなる
上記の結果、特定な情報をアイテムパターンなどを使って表示したり、グループで特定アイテムの一覧を表示するときなどに不要なホストが出なくなります。また、NVPSが低下しzabbix的にもリソースの無駄遣いをさけることができるようになります。
SELINUX環境での動作不調の乗り越え方
ところがどっこい、私の環境ではこれでもうまく動きませんでした。
色々と確認していったところ、SELINUXのポリシーではじかれていることがわかりました。
切り分けとしては、#setenforce 0のコマンドを入力し、動くかどうかを確認します。
SELINUXを無効化した場合には動作し、有効にしたら動かない、という状況だったため、以下対応を行いました。
#1.拒否された（あるいはPermissiveで記録された）ログからポリシーソースを作成
sudo ausearch -m avc -ts recent | audit2allow -M zabbix_api_fix
#2.生成された zabbix_api_fix.pp をシステムにインストール（適用）
sudo semodule -i zabbix_api_fix.ppこれで、デバイスが増えても、自動でデバイスを作成してくれたり、自動でいらないアイテムを無効化してくれる快適ライフが送れるようになりました！！！！！
終わりに
今回、色々と悩みながら一通りの環境は作り上げました。今回もGeminiくんに大変お世話になりました。
1.1対応をJavaScriptでやれなんて無理をずっと言い続けて本当にごめん。
ただ、テンプレート作成を手伝ってもらったたときに、UUIDv4を規則に沿って作らなかったのは本当に許さない。信じてたのに。
ただ、まだまだ足りない点はいくつもあります。このあたりは、テンプレートに残骸が残っているので、お察しください。
まだまだこれからも改良を続けていきますので、気が向いたらこのＨＰを覗いてみてください。疲れた！！！
https://tenko.hatenablog.jp/entry/2025/12/18/202950
バックアップ日時: 2026年11月11日