Zabbix vs Prometheus：モダンインフラ監視の「境界線」を見極め、開発速度を最大化する設計思想
監視ツールを選定する際、多くのエンジニアが「流行っているからPrometheus」「慣れているからZabbix」という安直な理由で設計を始め、後に必ず「地獄の運用フェーズ」で後悔する。
断言しよう。ZabbixとPrometheusは、監視ツールという皮を被った「全く異なる思想のプロダクト」だ。
この記事では、両者の本質的な棲み分けを定義し、現場の生産性を劇的に変える「プロの隠し味」を伝授する。
—
1. 思想の衝突：なぜ彼らは共存し、あるいは排斥し合うのか
Zabbix：エンタープライズの守護神（ステートベース）
Zabbixの強みは「状態（State）管理」にある。ネットワーク機器、レガシーなオンプレミス、あるいは「いつまで生きているか」が不明瞭なインフラを、強力なGUIで一元管理する。
- 適材適所： 物理サーバー、ネットワークスイッチ、複雑な依存関係を持つモノリシックなシステム。
Prometheus：クラウドネイティブの心臓部（タイムシリーズベース）
Prometheusは「時系列データの集計」に特化している。動的に増減するコンテナ、マイクロサービス間の疎結合な連携、そして「瞬時のクエリ実行」による現状把握。
- 適材適所： Kubernetes、マイクロサービス、短命なポッド、オートスケーリングする環境。
結論： インフラ構成が「静的」ならZabbix、「動的」ならPrometheus。これ以外の基準で選ぶ必要はない。
—
2. 【Zabbix】開発効率を跳ね上げる現場の小技
Zabbixを「重い、面倒」と感じるなら、それは使いこなせていない証拠だ。
チーム開発のための「テンプレート・プログラミング」
手動設定は悪である。ZabbixではXMLによるテンプレートのコード管理が必須だ。
- ベストプラクティス： 設定は必ずエクスポートしてGit管理せよ。APIを叩いて自動登録させるフローが構築できていないなら、それはZabbixを使っているとは言えない。
現場で役立つ「神設定」のベストプラクティス
アラート疲れを防ぐための必須設定：
- ヒステリシス設定： 閾値（例: 80%）を跨ぐ際、チャタリングを避けるために復旧閾値を低め（例: 70%）に設定せよ。これだけで夜中の無駄な電話が激減する。
- マクロの活用： `{$CPU.UTIL.CRIT}` のように、ホスト単位で閾値をオーバーライドできるマクロ構成を組め。
—
3. 【Prometheus】モダンな監視を極める実践テクニック
Prometheusの真価はPromQLにある。
絶対入れるべき「神」Exporter
- [node_exporter](https://github.com/prometheus/node_exporter): 基本だが、フィルタリングを怠るな。不要なメトリクスを収集し続けると、TSDBの肥大化で死ぬ。
- [blackbox_exporter](https://github.com/prometheus/blackbox_exporter): 外部からの疎通監視はこれ一択。HTTP(S)の応答時間だけでなく、SSL証明書の期限監視にも使え。
YAMLベストプラクティス（`prometheus.yml`）
冗長な記述を避け、チームで共有可能な設計にする：
prometheus.yml
global:
scrape_interval: 15s # 汎用的な収集間隔
scrape_configs:
- job_name: ‘kubernetes-nodes’
# サービスディスカバリを活用し、手動設定を排除する
kubernetes_sd_configs:
- role: node
# 重要なのは「再ラベル付け」でノイズを消すこと
metric_relabel_configs:
- source_labels: [__name__]
regex: ‘go_.|process_.’ # 開発言語特有のノイズを弾く
action: drop
—
4. プロの設計：オブザーバビリティの棲み分け戦略
私がテックリードとして現場に導入する際は、以下のように役割を分ける。
1. インフラの状態監視（Zabbix）： 「死活監視」「リソースの枯渇予測」。ここは信頼性がすべて。Zabbixの強力な通知ルーティング（エスカレーション機能）に任せる。
2. アプリケーションの振る舞い（Prometheus）： 「リクエストレート」「エラー率」「レイテンシ」。これらはPrometheusで収集し、Grafanaで可視化する。
3. イベントの相関（統合）： アラートはすべてPagerDutyやSlackに集約する。
最後に：エンジニアへの忠告
ツールは「目的」ではなく「手段」だ。Zabbixをモダンに見せようと無理をする必要もなければ、Prometheusで物理サーバーの複雑なステートを管理しようと奮闘する必要もない。
「観測対象の性質（性質の動的/静的）」を見極め、適切なツールを適材適所に配置せよ。それができるエンジニアこそが、真の意味で「システムを支配している」と言えるのだ。
—
「なぜその監視が必要なのか」という問いに対して、メトリクスの値ではなく「ビジネス価値」で答えられるようになろう。それが、運用監視の最高峰に立つ唯一の道だ。