【入門編】ZabbixのPrometheusエグスポーター連携:PrometheusメトリクスをZabbixに直接スクレイピングして一元監視する方法 – 運用監視・オブザーバビリティ活用バイブル

こんにちは!クラウドネイティブなシステムからレガシーな基盤まで、日々のインフラ運用に奔走しているエンジニアの皆さん、お疲れ様です。

現代のシステム運用において、「Prometheus」はクラウドネイティブ・K8s環境のデファクトスタンダードですよね。マイクロサービスから吐き出される膨大なメトリクスを時系列でガンガン収集し、Grafanaで美しく可視化する――この構成は本当に強力です。

しかし、現場の現実はどうでしょうか?
「新しいシステムはPrometheusで監視しているけれど、社内の既存システムやネットワーク機器はZabbixでがっつり監視している」
「結局、障害通知やインシデント管理の窓口がバラバラで、オンコール当番の夜間対応がつらい……」

そんな分断された監視の壁をぶち壊し、「Prometheus形式のメトリクスを、みんな大好きZabbixに直接取り込んで一元監視しちゃおう」というのが今回のテーマです。

これをマスターすれば、既存のZabbixの強力なトリガー(障害検知)やイベント相関関係の仕組みに、Prometheusのエコシステムを丸ごと取り込むことができます。毎日の運用が劇的に楽になりますよ。さあ、一緒にその仕組みを紐解いていきましょう!

—

なぜ「Zabbix × Prometheus」なのか?(ツールの役割と設計思想)

まず、今回のアーキテクチャの全体像を整理しておきます。

  • Prometheusの役割:

アプリケーションやミドルウェアから、`/metrics` というエンドポイントを通じて `http_requests_total 1024` のようなプレーンテキスト(Prometheus exposition format)のメトリクスを「スクレイピング(ポーリング)」の要領で収集することに特化しています。

  • Zabbixの役割:

収集したデータに対する「高度な閾値判定(N回連続で異常、時間帯による動的閾値など)」、障害時の「エスカレーション・アクション(SlackやPagerDuty連携)」、そして長期間の「ITインフラ総合台帳としての管理」が得意です。

「じゃあPrometheusだけで完結させればいいじゃないか」と思われるかもしれません。しかし、エンタープライズの現場では、「すでに構築されたZabbixの通知フローや権限管理の仕組みを変えたくない」という強い要望が必ず発生します。

Zabbix 4.2以降(特にZabbix 6.0/7.0 LTSの現代においてはさらに強力に)、Zabbix自身がHTTPエージェントと強力なプリプロセス(前処理)エンジンを持つようになったため、専用のエクスポーターを挟まなくても、Zabbixが直接Prometheusのエンドポイントを叩いてデータを料理できるようになりました。

—

基礎セットアップ:ZabbixからPrometheusメトリクスを迎え撃つ

それでは、実際に手を動かしていきましょう。今回は、適当なアプリケーション(またはPrometheusのNode Exporterなど)が発信する `/metrics` を、Zabbix Server(またはProxy)が直接スクレイピングする設定を作ります。

ステップ1:ホストの作成

まずはZabbixフロントエンドから、監視対象となるアプリケーション(あるいはターゲット)を登録します。

1. [データ収集] -> [ホスト] -> [ホストの作成] をクリック。
2. ホスト名:`App-Service-01`
3. グループ:`Linux servers` など適当なグループへ追加。
4. インターフェースは不要(今回はHTTPエージェントアイテムで直接URLを叩くため、ZabbixエージェントのIP設定などは空でもOKです)。

ステップ2:HTTPエージェントアイテムの作成

ここが今回の核心です。Zabbixの「HTTPエージェント」というアイテムタイプを使用することで、指定したURLから直接テキストを取得します。

1. 作成したホストの [アイテム] -> [アイテムの作成] をクリック。
2. 各項目を以下のように設定します:

| 項目 | 設定値 |
| :— | :— |
| 名前 | `App CPU Usage (Prometheus)` |
| タイプ | `HTTPエージェント` |
| キー | `app.metrics.scrape` |
| URL | `http://<ターゲットのIP>:8080/metrics` (実際のメトリクスURL) |
| 更新間隔 | `1m` (1分ごとにスクレイピング) |
| 情報のタイプ | `テキスト` (※最初はテキストとして受け取ります) |

—

魔法のレシピ:プリプロセス(前処理)で生データを料理する

URLを叩いて取得できるデータは、以下のようなカオスなテキスト(Prometheusフォーマット)です。

HELP http_requests_total Total HTTP requests.
TYPE http_requests_total counter
http_requests_total{method=”post”,handler=”submit”} 1027
http_requests_total{method=”get”,handler=”index”} 48921
HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
TYPE node_cpu_seconds_total counter
node_cpu_seconds_total{cpu=”0″,mode=”idle”} 1.23456e+06

「この中から、特定のメトリクスの値だけをどうやって抜き出すの?」
ここで登場するのが、Zabbixのプリプロセス(前処理)です。Zabbixには、Prometheusフォーマット専用のパーサーが標準搭載されています。

先ほど作ったアイテムの設定画面に戻り、[前処理] タブを開いてください。以下のステップでデータを加工します。

1. Prometheusから特定の値を取り出す

  • 前処理のステップ: `Prometheusの値` を選択。
  • パラメータ: 抽出したいメトリクスとラベル条件を記述します。
  • 例: `http_requests_total{method=”get”,handler=”index”}`

これだけで、Zabbixは自動的にPrometheusのテキストフォーマットを解釈し、該当行の数値(この場合は `48921`)だけをキレイに抽出してくれます。

2. 型の変換

テキストとして取得したデータを、Zabbixがグラフ化や閾値判定できるように数値に変換します。

  • 前処理のステップ: `数値に変更` (あるいは `カスタム乗数` や `変更のチェック` など必要に応じて追加)

> 💡 先輩エンジニアからの知見:
> もし取得したいメトリクスが標準のPrometheus形式ではなく、独自のJSONやXMLで返ってくるレガシーなAPIだったとしても絶望しないでください。Zabbixのプリプロセスには JSONPath や XPath も完備されています。
> 例:JSONの場合、前処理に `JSONPath` を選択し、`$.data.metrics.cpu_usage` のように記述するだけで、ネストしたデータから一発で値を取り出せます。Zabbixのパース能力は、皆さんが思っているはるかに先を行っています。

—

精度高いHelloWorld的な動作確認

設定が終わったら、正しくデータが取れているか「最新データ」で確認しましょう。

1. [監視データ] -> [最新データ] に移動。
2. ホスト `App-Service-01` でフィルタリング。
3. アイテム `App CPU Usage (Prometheus)` の値が、ちゃんと数値として(例: `48921`)表示されていることを確認します。

もし値が取れない(「取得不可」になる)場合は、以下のポイントをチェックしてください:

  • Zabbix Serverからターゲットの `/metrics` エンドポイントへネットワーク的に到達できるか(ファイアウォールやセキュリティグループの穴あけ忘れに注意!)。
  • URLやポート番号が間違っていないか(Zabbix Serverのシェルから `curl http://:8080/metrics` を叩いてみるのが一番確実です)。

—

まとめ:監視の一元化がもたらす平穏な夜

いかがでしたでしょうか?
「Cloud NativeなツールだからZabbixとは混ぜるな危険」といった固定観念を捨て、HTTPエージェントと強力なプリプロセスを組み合わせれば、Zabbixはどんなモダンなフォーマットも飲み込む巨大なオブザーバビリティのハブに変貌します。

これをマスターすれば、

  • Prometheusで収集したメトリクスを、使い慣れたZabbixのトリガーで監視。
  • 障害時は既存のZabbixアラート連携基盤(Slack、Teams、PagerDuty等)へ即座に通知。
  • Grafanaを使わずとも、Zabbixの標準画面でざっくりトレンドを把握。

といった、運用者にとって最高に居心地の良い環境が手に入ります。分散した監視ツールを行き来する無駄なストレスから解放され、本当に向き合うべきシステムの設計や開発に集中できるようになりますよ。

あなたのインフラストラクチャが、今日も静かに、そして健やかに稼働することを願っています。それではまた別の現場でお会いしましょう!

タイトルとURLをコピーしました