Zabbix APIを使って、監視データを送信してみよう

本記事は TechHarmony Advent Calendar 2025 12/6付の記事です。

皆さん、師走のZabbixライフを満喫していますか？こんにちは、SCSK株式会社片井です。

今回はZabbixLTS Ver7.0で新しく実装されたZabbix APIメソッド「history.push」について紹介します。

Zabbix APIの基本的な使い方は、当ブログの記事「Zabbix APIの使用方法」にて解説していますので、まだ触ったことがない方は、
ぜひそちらからご覧ください。

Zabbix APIの使用方法

ZabbixはAPIが豊富に用意されており、データの抽出や外部システムとの連携が容易になっております。今回はcurlコマンドを使ってAPIを実行する方法を紹介いたします。

これは何？
既存方式の紹介 – Zabbix sender
使ってみよう
注意点
Zabbix senderとの比較
まとめと今後の展望

これは何？

シンプルに言うと「Zabbixの各アイテムに監視データを送信できるAPI」です。

history.push

さらに言うと「APIで指定したアイテムに任意の監視データを投入し、その値がZabbixのヒストリデータとして検知・モニタリングできるようにする」機能です。

Zabbixは様々なアイテムのタイプが用意されており、幅広い監視に対応しています。
しかし中には以下のような要件で、監視対象のホストからZabbixサーバに対して、監視データを送りつけたいケースが存在します。

NW制約の関係でZabbixサーバから監視対象のホストにポーリング（監視データを取りに行くこと）ができない
Zabbixサーバから定期的にデータを取りに行くのではなく、問題が起きた時にリアルタイムでデータを送信→検知させたい

上記は一例ですがこういったケースの場合、おなじみの「Zabbix Agent」や、後述する「Zabbix sender」、
そして今回紹介するhistory.pushメソッドを活用することによって、監視対象ホスト→Zabbixサーバという方向でのデータ送信によるリアルタイム監視を行うことができます。

具体的な処理の流れは以下のようになります。

監視機器など監視される側のホストから、curlなどHTTPクライアントを使用して、監視データをZabbix WebUIのAPIエンドポイントにPOSTする
POSTされたリクエストは、まずZabbix WebUIが受け取る
APIキーを元に認証されたデータは、その後ZabbixサーバによってDBに書き込まれる

既存方式の紹介 – Zabbix sender

ここまでの話を聞くと、Zabbix経験者の方は「あれ？それって”Zabbix sender”と同じじゃない？」と思われるかもしれません。

「Zabbix sender」とは、一言でいうと監視データをZabbixサーバに送信するためのコマンドラインユーティリティです。

6 zabbix_senderコマンド

APIとコマンドラインユーティリティということで方式は異なりますが、実現される機能としてはほぼ同一です。
Zabbix senderも同様に各アイテムに監視データを投入、ヒストリデータとして検知/モニタリングすることができます。

上記の方式の違いについては後述します。

使ってみよう

実際に使ってみましょう。

事前準備

今回はAPI実行が内容に含まれます。API実行が実践できていない方は、先に下記URLの[データの単純取得]が出来るところまで進めてみてください。

Zabbix APIの使用方法
ZabbixはAPIが豊富に用意されており、データの抽出や外部システムとの連携が容易になっております。今回はcurlコマンドを使ってAPIを実行する方法を紹介いたします。
blog.usize-tech.com
2023.07.27

APIパラメータ

今回の手順で必要なパラメータは以下になります。

パラメータ	入力内容
アイテムID	監視データを投入したいアイテムのID
ヒストリデータ	監視データの内容(ステータスの場合:FAILED,SUCCESSなど任意の数値/テキスト)
UNIX時刻	Zabbixで監視データ取得時刻として扱われる時刻 ※ZabbixはUNIXタイムで監視データを時刻管理するため形式を合わせる
ナノ秒	監視データ取得時刻の重複回避のために参照される時刻、ナノ秒単位で入力

実施手順

Zabbix WebUIのURLに対して、http/httpsで疎通可能なサーバにログインしてください。

以下のcurlコマンドを実行してください。(LinuxOS,curlコマンドインストール環境を想定しています)

curl -s -k -d '
{
"auth": "<APIキー>",
"method": "history.push",
"id": 1,
"params": [
{
"itemid": <アイテムID>,
"value": <ヒストリデータ>,
"clock": <UNIX時刻>,
"ns": <ナノ秒>
}
],
"jsonrpc": "2.0"
}
' -H "Content-Type: application/json-rpc" http://<ZabbixURL>/zabbix/api_jsonrpc.php | jq '.result'

curlコマンド実行後、以下のように応答結果が返ってきます。
今回は”6″という監視データの値を、ID:48474のアイテムに投入しています。

※失敗した場合は、errorのカラムとerror内容が出力されます。
ZabbixのWebUIで投入先のアイテム最新データを見ると、入力したパラメータに従って、”6″の監視データが
アイテムのヒストリデータとして投入されていることが分かります。

注意点

アイテムタイプは「Zabbixトラッパー」もしくは「HTTPエージェント」タイプで[トラッピングの有効化]のオプションを指定することが必須になります。
そのため例えば、「Zabbixエージェント」のアイテムタイプを指定して、普段は監視データをエージェントから取得、問題が起きた際にhistory.pushで直接監視データを投入する、といった使い方は不可になります。
後述のZabbix senderとの比較で記載していますが、データ送信先はZabbixサーバではなく、Zabbix WebUIのURLになります。
そのため、上記WebUIがZabbixサーバから独立している構成の場合は、WebUIサーバとの疎通が確保されている必要があります。

Zabbix senderとの比較

冒頭でZabbix Senderと機能が似ていると触れましたが、実際には以下のような比較ポイントがあります。

比較項目	History Push API	Zabbix sender
ソフトインストール	HTTP,JSON関連ライブラリがインストール済みであれば不要	Zabbix Senderのインストール必須
監視データ送信先	Zabbix WebUI	Zabbixサーバまたは Zabbixプロキシ
データ形式	JSON形式	Zabbix Senderコマンド/Senderプロトコル（内部的にはJSON形式で処理）
使用ポート	Zabbix WebUIのHTTP,HTTPSポート(80, 443)	Zabbixサーバまたは Zabbixプロキシの Trapperポート（デフォルト: 10051）
セキュリティ認証	APIトークンベースでの認証	なし（Zabbixサーバ側設定で監視データを受け入れるIPを指定）

インストールさえできれば、データ形式の観点からAPI実行文とコマンド文を書く労力の差でZabbix Senderの方が手軽な印象です。
より対応幅が広いのはhistory.push方式になります。エージェントレスの監視をせざるを得ない、アプライアンス機器やアプリ製品では、Zabbix Senderはインストールできないが、HTTP関連ライブラリとJSONは扱える、というケースが多いです。
セキュリティ観点では、API認証で認証情報を管理できるhistory.push方式の方がよりセキュアです。

まとめと今後の展望

今回は、監視データ送信方法として、history.push APIの紹介をさせていただきました。
監視データ送信については、既存の方式としてZabbix senderがありますが、上記比較のように使い分けができるポイントが何点かあるため、
これまでZabbix senderでは実現できなかったと諦めていた監視についても、この実装を機に再考してみてはいかがでしょうか？

所感ですが、生成AIの活用によりZabbix APIの学習・作成コストが非常に低減されており、Zabbix sender方式とのコスト差がより縮まっていくと感じています。
上記比較のように、history.pushはsender方式と比較して、よりセキュア・モダンな方法での監視方式となり、
今後Zabbixのセキュリティ要件がより厳格に求められる方向性で発展していった際は、こういった方式でのデータ投入が必須になっていくのではないでしょうか。

SCSK Plus サポート for Zabbix