Raspberry PiにZabbixを導入して、監視・Discord通知・APIでのデータ取得を試した

きっかけは「Zabbixの監視を自分でも試したい」

Raspberry PiにZabbixを導入した一番の理由は、監視の仕組みを自分の環境で試してみたかったからです。

当時はWebサイトを自宅環境で24時間公開していました。せっかく監視するなら、問題が起きたときに管理画面を開いていなくても気付けるようにしたいと考え、Discord webhookを使ってチャットへ通知する構成も用意しました。テスト送信がDiscordに届くことを確かめたうえで、常に動いている監視サーバーとルーターで警告以上の障害が起きたときに、Discordへ自動で通知するアクションも設定しています（詳しくは後述します）。

さらに、監視値を画面だけでなくAPIから取得し、最新値や履歴を数値で確認できるようにしました。この記事では、現在の設定例と、実際に取得できたデータを紹介します。

環境と監視対象

項目	今回の環境
監視サーバー	Raspberry Pi（Linux kernel 6.12 / aarch64）
OS	Raspberry Pi OS with desktop
Zabbix	6.0.14（取得時点の実環境）
監視サーバー側のAgent	Zabbix Agent 2
登録した対象	監視サーバー、ルーター、Linux監視対象の3ホスト
通知先	Discord webhook

Zabbix 6.0.14は今回動いている環境のバージョンであり、新規導入時の推奨バージョンとして示したものではありません。これから導入する場合は、その時点のサポート状況を公式サイトで確認してください。

IPアドレス、ユーザー名、トークン、Webhook URLは掲載していません。以下では監視対象を役割名で表記します。画像にある「Zabbix server」は、監視サーバー自身を表すZabbixの標準ホスト名です。同じように、画像の「TP-Link ER605」はルーター、「Ubuntu_Zabbix Agent」はLinux監視対象に付けたホスト名です。

監視と通知の流れは、次のようになります。

監視サーバー・ルーター・Linux監視対象
          ↓ Agent / SNMP / ICMPなど
    Raspberry Pi上のZabbix
          ├─ Web画面で監視値とグラフを確認
          ├─ Discord webhookへのテスト送信（受信まで確認）
          ├─ トリガー → アクション → Discord（監視サーバー・ルーターの警告以上の障害と復旧を通知）
          └─ APIで最新値・履歴・障害情報を取得

これは役割を示した図です。ホスト登録やテンプレートの適用だけで、すべての項目が取得できるとは限りません。

テンプレートを使って監視項目を用意する

APIで確認した適用テンプレートは次のとおりです。

対象	適用テンプレート
監視サーバー	`Linux by Zabbix agent`、`Zabbix server health`
ルーター	`TP-LINK by SNMP`
Linux監視対象	`Linux by Zabbix agent`

監視サーバーでは、CPU使用率、利用可能メモリ、ルートファイルシステムの使用率を取得できています。ルーターではICMP疎通、損失率、応答時間を確認できました。

ルーターにはSNMPテンプレートを適用していますが、今回の結果で値を確認したのはICMPの項目だけです。SNMPで取得する項目がすべて正常に取れているかは、今回は確認していません。

下の画像は、2026年10月14日に撮影した監視サーバーのダッシュボード（Zabbix server health）です。

このダッシュボードの障害欄は監視サーバーに絞った表示なので、「データがありません」となっていても、全ホストで障害がないという意味ではありません。実際、最初にAPIで確認したときは、ほかのホストで未復旧の障害が2件ありました（後述するとおり、現在は解消しています）。

Discordに通知を届ける

Discord連携には、以前に作成した独自のメディアタイプ「Discord障害通知」（タイプは Webhook）を使っています。

パラメータのうち、公開できる範囲は次のとおりです。Webhook URLを含む行と、管理画面の接続先は画像から除外しました。

パラメータ	設定
`HTTPProxy`	空欄
`Message`	`{ALERT.MESSAGE}`
`Subject`	`{ALERT.SUBJECT}`
`To`	`{ALERT.SENDTO}`

これは独自に作ったメディアタイプの設定例です。Zabbix公式のDiscordメディアタイプとはパラメータ構成が異なるため、新規に導入する場合は、使用するバージョンの公式資料もあわせて確認してください。

確認用メッセージを1件送る

2026年10月14日に、このメディアタイプのテスト機能を使って、既存の通知先へ1件送信しました。件名は「Zabbix × Discord 連携確認テスト（対応不要）」とし、本文にも実際の障害ではないことを明記したうえで、内部IPやホスト名を含めない確認用メッセージにしています。

Zabbix側では「メディアタイプのテストに成功しました。」と表示され、レスポンス OK を確認できました。

Discord側でも、通知先チャンネルに確認用メッセージの本文が届いていることを確認しました。

障害時に自動で通知するアクションを設定する

テスト送信が成功しても、それだけでは障害が起きたときにDiscordへ通知は届きません。自動で通知するには、障害イベントを受けてメッセージを送るトリガーアクションが有効になっている必要があります。最初に確認したときは、無効になっている標準アクション「Report problems to Zabbix administrators」が1件あるだけだったので、Discord用のアクションを新しく作成しました。

項目	設定
アクション名	Discord 常時稼働ホスト警告以上
実行条件	深刻度が「警告」以上、かつ対象ホストが監視サーバーまたはルーター（`A and (B or C)`）
送信先メディア	Discord障害通知
送る通知	障害の発生時と復旧時に1回ずつ
メンテナンス期間中	通知を一時停止

対象を監視サーバーとルーターの2台に絞ったのは、この2台が常に動いている機器だからです。Linux監視対象は使うときだけ起動するPCなので、対象に含めると、電源を切るたびに障害の通知が届いてしまいます。

通知の件名と本文には、Zabbixのマクロで障害の内容を差し込んでいます。内部IPは入れず、ホスト名とイベントの情報だけを載せる形にしました。

件名: 【障害】{HOST.NAME}：{EVENT.NAME}

深刻度: {EVENT.SEVERITY}
発生: {EVENT.DATE} {EVENT.TIME}
対象: {HOST.NAME}
内容: {EVENT.NAME}
イベントID: {EVENT.ID}
Zabbix管理画面で状況を確認してください。

復旧時は件名を 【復旧】{HOST.NAME}：{EVENT.NAME} とし、本文には復旧日時（{EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME}）と障害の継続時間（{EVENT.DURATION}）を入れています。通知を受け取るユーザー側でも、Discordのメディアを有効にし、通知する深刻度を「警告」以上の4段階にしました。

自動通知までの設定は、次の順に確認すると整理しやすくなります。

Discordで通知先チャンネルのWebhookを用意する。
使用しているZabbixのバージョンに対応したDiscordメディアタイプを用意する。
通知先ユーザーにメディアを追加し、通知する深刻度と時間帯を設定する。
トリガーアクションに対象条件と送信先を設定し、有効にする。
テスト送信に加えて、意図した障害イベントで実際に通知が届くかを確認する。

今回は1から4までを設定し、保存した設定をAPIの action.get、host.get、user.get で読み出して、条件・送信先・ユーザーのメディア設定が意図どおりであることを確かめました。一方で、稼働中の機器を止めて障害を起こすことはしていないため、5の「障害イベントから実際に通知と復旧通知が届くか」はまだ確認していません。なお、テスト送信の際にテストフォームで件名や本文を入力しましたが、保存済みのWebhook設定は変更していません。

公式のDiscord連携ページでは、Zabbixのバージョンを切り替えて資料を確認できます。Webhook URLは、知られると誰でもそのチャンネルに投稿できてしまうため、認証情報と同じように扱い、記事やスクリーンショットに載せないようにしてください。

APIで最新値を取得する

Zabbix APIは、Webフロントエンドの api_jsonrpc.php にJSON-RPC形式のリクエストを送って利用します。Zabbix 6.0では、APIトークンをリクエスト本文の auth プロパティに指定します（参考: Zabbix 6.0 API マニュアル）。

Zabbix 6.4以降では、トークンを Authorization: Bearer ヘッダーで渡す方式が推奨されています。新しいバージョンを使う場合は、そのバージョンのマニュアルを確認してください。

今回、次のAPIメソッドで読み取りができることを確認しました。

メソッド	確認した内容
`apiinfo.version`	APIの応答とバージョン
`host.get`	登録ホストと適用テンプレート
`item.get`	最新値、単位、最終取得時刻、項目の状態
`history.get`	監視サーバーのCPU使用率の過去24時間分
`problem.get`	APIから見える未復旧障害の件数

たとえば監視サーバーの最新値を取る item.get のリクエストは、次の形です。hostid とトークンは説明用の置き換え箇所で、実際の値はローカル設定から読み込んでいます。

{
  "jsonrpc": "2.0",
  "method": "item.get",
  "params": {
    "output": ["name", "key_", "lastvalue", "lastclock", "units", "state"],
    "hostids": ["<host.getで取得したhostid>"],
    "filter": {
      "key_": [
        "system.cpu.util",
        "vm.memory.size[available]",
        "vm.memory.size[pavailable]",
        "vfs.fs.size[/,pused]"
      ],
      "status": 0
    }
  },
  "auth": "<ローカル設定から読み込むAPIトークン>",
  "id": 1
}

lastclock は最終取得時刻のUNIX時間で、state は項目が取得できているか（0 が正常、1 が取得不可）を表します。filter の status: 0 は、有効な項目だけに絞り込む指定です。

APIトークンは、それを発行したユーザーの権限でそのまま動作します。トークン自体に「読み取り専用」のような独立した権限を付けることはできないため、今回はAPIの読み取り専用ユーザーを作成し、そのユーザーでトークンを発行しています。このユーザーには対象ホストグループの読込権限だけを与え、ユーザーの役割（User roles）でAPIメソッドの許可リストを設定して、使えるメソッドを絞っています（参考: ユーザーの役割とAPIアクセス制限）。なお、今回の確認は読み取りメソッドだけで行っており、書き込み系のAPIが実際に拒否されるかは試していません。

接続先とトークンはローカルの .env に保存し、Gitの追跡対象から除外しています。取得処理では、リクエスト本文やトークンをログに出さないようにも気を付けました。.env は平文のファイルなので、フォルダごと共有したり添付したりするときにも含めないようにしています。

実際に取れた監視データ

2026年10月14日 20:03:56（JST）にAPIで取得した値です。各項目について、最終取得時刻からAPI取得時点までの経過時間も併記しました。

対象	項目	値	最終取得から
監視サーバー	CPU使用率	約0.93%	32秒
監視サーバー	利用可能メモリ	約6.88 GiB／87.33%	52〜53秒
監視サーバー	`/` のディスク使用率	約16.00%	60秒
ルーター	ICMP疎通	Up	41秒
ルーター	ICMP損失率	0%	41秒
ルーター	ICMP応答時間	約0.731 ms	41秒

利用可能メモリは、APIが返すバイト値を 1024^3 で割ってGiBに換算しています。これらは一時点の値であり、機器の性能評価や稼働率を保証するものではありません。

Linux監視対象は、この取得の時点では電源を切っていたため値がありませんでした（後述します）。起動してLANに接続したあと、2026年10月14日 21:24:48（JST）に取得した値は次のとおりです。

対象	項目	値	最終取得から
Linux監視対象	Agentの利用可否	利用可能	50秒
Linux監視対象	CPU使用率	約1.50%	52秒
Linux監視対象	利用可能メモリ	約6.12 GiB／80.29%	30〜31秒
Linux監視対象	`/` のディスク使用率	約48.00%	17秒
Linux監視対象	起動からの経過時間	749秒（約12分）	4秒

CPU使用率のグラフは21時22分ごろから線が始まっていて、起動してLANにつないだあとに値の取得が再開したことが分かります。画面の「Memory utilization」は使用率なので、APIで取得した利用可能メモリの割合（約80.29%）と足すとほぼ100%になります。

監視サーバーのCPU使用率は、history.get で過去24時間分の1,440件（1分間隔）を取得できました。取得件数の上限（limit）は2,000件に設定していたので、上限で打ち切られたデータはありません。

集計	CPU使用率
最小	約0.45%
平均	約0.57%
最大	約2.64%

同じ期間をZabbixのグラフで表示したものが次の画像です。最大値の約2.6%は、午前3時半ごろの突出した値と一致しています。

スクリーンショットはAPIで取得した数分後に撮影しているため、グラフの右端の値はAPIの表と少し異なります。グラフで波形の傾向をつかみ、APIで正確な数値と時刻を確かめる、という使い分けができました。

確認できたことと、残っている課題

今回、登録した3台すべてで監視値を取得できていることを確認しました。内訳は、監視サーバーの主要なリソース値とCPU使用率の履歴、ルーターのICMP疎通、Linux監視対象のAgent経由のリソース値です。Discordについては、テスト送信がチャンネルに届くことを確認したうえで、常に動いている2台で警告以上の障害が起きたときに通知するアクションを設定しました。

最初にAPIで取得したとき、Linux監視対象のCPU・メモリ・ディスクの項目には値がなく、最終取得時刻も 0 でした。原因は監視の設定ではなく、そのPCの電源を切り、LANケーブルも外していたことです。起動してLANにつなぐと、Agentが利用可能になり、数分で各項目の値が入り始めました。管理画面ではホストが登録されたまま表示されるので、テンプレートを適用していることと、今まさにデータが取れていることは別だと実感しました。最新値だけでなく、最終取得時刻やAgentの利用可否もあわせて見ることが大事です。

APIから見えていた未復旧障害2件も、Linux監視対象を起動したあとに解消しました。

残っている課題は次の3つです。

障害イベントを使って、自動通知と復旧通知が実際にDiscordへ届くかを確かめる。
ルーターはICMPの項目だけを確認しているので、SNMPで取得する項目も正常に取れているかを確かめる。
管理画面とAPIをHTTPS化する。

現在、管理画面とAPIへの接続はHTTPなので、トークンや監視データは暗号化されずにネットワークを流れています。ただし、この管理画面とAPIは自宅のネットワーク内からしか使っていません。外部に公開しているサーバーとはネットワークを分け、監視に必要な通信以外は通らないよう設定しているため、外からこの通信に触れられる経路は限られていると考えています。それでも、トークンが平文で流れる状態は残っているので、HTTPS化して解消する予定です。

まとめ

好奇心から始めたZabbixですが、グラフで状態を見る、チャットで異常に気付く、APIで結果を取り出す、という3つの役割をそれぞれ試すことができました。今後も、自宅環境で設定と取得結果を照らし合わせながら、監視の仕組みを学んでいきます。