【入門編】【Zabbix vs Prometheus】モダンインフラ監視における選定基準と棲み分けを徹底比較 – 運用監視・オブザーバビリティ活用バイブル

こんにちは！現場で毎日システムと格闘している君なら、「監視ツール、結局どれ使えばいいんだ…？」と頭を抱えた経験が一度はあるはずだ。

世の中には「Zabbixは古い、これからはPrometheusだ！」みたいな極端な意見があふれているけれど、現場のアーキテクトから言わせてもらうと、それは「トラックとスポーツカー、どっちが優れているか？」と議論するようなもの。走る路面も、積む荷物も違うんだから、比較する方がナンセンスさ。

今回は、伝統的インフラ監視の王様である「Zabbix」と、クラウドネイティブ時代の覇者である「Prometheus」の決定的な違いを解き明かしながら、それぞれの「Hello World（最初の一歩）」までを優しくガイドしていくよ。これを読めば、君のプロジェクトにどちらを導入すべきか、迷いなく即決できるようになるはずだ。

—

1. 思想の根本が違う：Zabbix vs Prometheus

まずは、この2つのツールが生まれた背景と「世界の見方」を知ろう。ここを理解しないと、選定で必ずミスをする。

Zabbixの思想：「なんでも一元管理する要塞」

Zabbixは、ネットワークのルーターから、古いLinuxサーバー、Windowsのイベントログまで、企業のITインフラ全体を一つのWeb画面で丸ごと監視するのに最適化されている。「エージェントを入れれば、とりあえず何でも監視できる」という安心感が最大の武器だ。

Prometheusの思想：「動的な世界を切り取るスキャナー」

一方、Prometheusは、Kubernetesのように「コンテナが数秒で消えては生まれる」ような流動的な世界のために生まれた。IPアドレスが変わろうとも、サービスディスカバリー（自動検出）でターゲットを追いかけ、HTTPのエンドポイントからメトリクスを「スクレイピング（削り取るように取得）」する。

—

2. アラートの考え方と「アラート疲れ」への対策

監視ツールで最も重要なのは「障害を検知すること」だが、それ以上に大切なのは「エンジニアを無駄なアラートで殺さないこと」だ。

Zabbixのアラート:

トリガー条件をWebGUIで柔軟に設定できる。障害復旧（Recovery）の検知や、複雑な依存関係（「ルーターが落ちたら、その下のサーバーのアラートは隠す」など）の制御が非常に得意。

Prometheusのアラート:

アラートの定義もすべてPromQL（Prometheus独自のクエリ言語）とYAMLファイルで行う。さらに、アラートのルーティングや抑制（抑制＝Silencing/Grouping）を専門に行うAlertmanagerという相棒がセットになっており、大量のアラートを巧みに束ねてSlackやPagerDutyに飛ばしてくれる。

—

3. 実践！それぞれの「Hello World」を踏み出そう

百聞は一見にしかず。それぞれの最もシンプルなセットアップと、メジャーな動作確認の方法を見ていこう。これをマスターすれば、今日からでも検証環境を立ち上げられるよ。

—

パターンA：Zabbixの「Hello World」（Dockerで5分構築）

まずは、すべてが詰まったZabbixをDockerでサクッと立ち上げてみよう。今回は一番簡単な「Zabbix Agent 2」を同じホストの死活監視に使う構成だ。

1. Docker Composeで一発起動

適当なディレクトリに `docker-compose.yml` を作成してほしい。

version: ‘3.8’
services:
zabbix-server:
image: zabbix/zabbix-server-mysql:alpine-6.4-latest
ports:

“10051:10051”

environment:

DB_SERVER_HOST=mysql
MYSQL_DATABASE=zabbix
MYSQL_USER=zabbix
MYSQL_PASSWORD=zabbix_password

depends_on:

mysql

zabbix-web:
image: zabbix-web-mysql:alpine-6.4-latest
ports:

“8080:8080”

environment:

ZBX_SERVER_HOST=zabbix-server
DB_SERVER_HOST=mysql
MYSQL_DATABASE=zabbix
MYSQL_USER=zabbix
MYSQL_PASSWORD=zabbix_password

depends_on:

zabbix-server

mysql:
image: mysql:8.0-debian
command: –default-authentication-plugin=mysql_native_password
environment:

MYSQL_DATABASE=zabbix
MYSQL_USER=zabbix
MYSQL_PASSWORD=zabbix_password
MYSQL_ROOT_PASSWORD=root_password

Terminalで `docker compose up -d` を叩けば、数分で `http://localhost:8080` にZabbixのWeb画面（初期ID: `Admin`, PW: `zabbix`）が立ち上がる。これがZabbixの「オールインワン要塞」だ。

—

パターンB：Prometheusの「Hello World」（圧倒的なシンプルさ）

次はPrometheusだ。こちらはデータベースも何もいらない。単一のバイナリと1つの設定ファイルだけで動き出す。

1. 設定ファイルを書く (`prometheus.yml`)

Prometheusは「自分自身」を監視することから始めるのがお約束（Self-monitoring）。

global:
scrape_interval: 15s # 15秒ごとにメトリクスをプル（取得）する

scrape_configs:

job_name: ‘prometheus’

# 自分自身の死活とメトリクスを監視する設定
static_configs:

targets: [‘localhost:9090’]

2. Dockerで起動する

たったこれだけのエントリポイントで、Docker経由ですぐに起動できる。

docker run -d \
-p 9090:9090 \
-v $(pwd)/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheus:latest

ブラウザで `http://localhost:9090` にアクセスしてみよう。
Prometheusの簡易Web UIが表示される。上部の検索窓（Expression）に `up` と打ち込んで「Execute」を押してみてほしい。

画面に `1` という数字が表示されただろうか？
これは、「Prometheusが自分自身（localhost:9090）にアクセスし、正常に生存している（＝1）」ということを示している。これが、Prometheusにおける最高のHelloWorldだ。

—

4. 現場のプロが教える「選定の極意」

さて、それぞれの基本を抑えたところで、現場でどちらを選ぶべきかの「判断基準」を授けよう。

1. Zabbixを選ぶべきケース

管理対象に「ネットワークスイッチ」「レガシーなWindowsサーバー」「社内ニッチな物理アプライアンス」が含まれている。
監視設定をWeb画面から直感的に行いたい（コードを書きたくないメンバーが多い）。
1台のサーバーで完結させたい。

2. Prometheusを選ぶべきケース

システムがKubernetesやDockerなどのコンテナベースで構築されている。
メトリクスをコード（IaC）としてGitでバージョン管理したい。
Grafanaと組み合わせて、美しくリッチなダッシュボードを作りたい。
オートスケーリングする環境で、動的にターゲットが増減する。

—

おわりに

監視ツールの選定は、プロジェクトの運命を左右する重要な意思決定だ。
「新しいから」「流行っているから」という理由だけでPrometheusを選んで、レガシーなWindowsサーバーの監視で泥沼にハマるチームを、僕は何度も見てきた。逆に、オンプレの巨大な要塞をPrometheusだけで監視しようとして、設定ファイルの山に溺れるチームも見てきた。

大切なのは、「君たちのシステムがどこに向かっていて、どんなインフラの上で息をしているか」を正しく見極めること。

それぞれの特徴と「Hello World」の手軽さを知った今なら、もう迷うことはないはずだ。
適材適所でツールを使いこなし、アラートに怯えない、優雅で平穏な運用ライフを手に入れよう！