監視とは何を見ることなのか – Zabbix、Prometheus、Grafana の責務分界で考える

監視を考える時に、最初から Zabbix、Prometheus、Grafana のどれを使うかに入ると、話がずれやすくなります。監視の中心にあるのはツール名ではなく、システムの状態をどの粒度で観測し、どの状態を異常とみなし、誰がその情報をもとに判断するのか、という設計です。

死活監視、リソース監視、メトリクス収集、ログ監視、SNMP Trap、アラート通知、ダッシュボード表示、障害分析は、まとめて「監視」と呼ばれがちです。しかし、それぞれ見ているものも、運用で使う場面も違います。CPU 使用率が高いこと、HTTP が 500 を返していること、ネットワーク機器が linkDown の Trap を送ったこと、アプリケーションログに例外が出たことは、同じ障害に見えても情報の性格が違います。

Zabbix を入れたから監視できている。Prometheus を入れたから可観測性がある。Grafana のダッシュボードがあるから状態が見えている。そう考えると、監視設計の中心を見失います。重要なのは、何を見るために、どの情報を、どの粒度で、誰が判断できる状態にするのかです。

監視はツール名ではなく目的で分ける

監視の設計では、まず目的を分けます。何が動いているかを確認したいのか、リソースの逼迫を見たいのか、サービス影響を見たいのか、原因調査の材料を残したいのかで、必要なデータもツールの役割も変わります。

領域	主な目的	例
死活監視	対象が応答しているかを見る	ICMP、TCP connect、HTTP status
リソース監視	枯渇や逼迫を見る	CPU、メモリ、ディスク、I/O、ネットワーク
メトリクス監視	状態の変化を時系列で見る	request rate、latency、error rate、queue length
ログ監視	事象の内容や前後関係を読む	syslog、application log、audit log
Trap / Event	機器側からのイベントを受ける	SNMP Trap、linkDown、hardware alert
アラート	人間に判断を促す	障害通知、しきい値超過、SLO 違反
ダッシュボード	状態を俯瞰する	Grafana、Zabbix dashboard、運用画面

この分類を曖昧にしたまま監視項目だけを増やすと、何が足りていて、何が足りていないのか分からなくなります。監視は「項目数」ではなく「判断に接続できるか」で評価するべきです。

Zabbix は状態とイベントを運用に接続しやすい

Zabbix は、サーバー、ネットワーク機器、プロセス、ポート、SNMP、ICMP、ログ監視、通知などを一通り扱える、伝統的なインフラ監視として分かりやすい位置にあります。ホストを登録し、テンプレートを適用し、item で値を取り、trigger で問題化し、event として扱う流れは、一般的な運用監視と相性が良いです。

Zabbix の強みは、単にメトリクスを保存することではなく、運用上の障害イベントとして扱いやすいことです。ネットワーク機器、物理サーバー、NAS、UPS、プリンター、古いアプライアンスのように、SNMP や ICMP を中心に管理したい対象では、Zabbix のモデルは今でも有効です。

一方で、Kubernetes やクラウドネイティブなワークロードのように、Pod や Service が動的に増減し、ラベル単位で状態を見たい環境では、Zabbix だけで無理に表現しようとすると苦しくなる場合があります。Zabbix が古いという話ではなく、対象の変化の仕方に対して、監視モデルが合っているかを見る必要があります。

Prometheus はメトリクスを時系列で扱う

Prometheus は、監視対象が公開する metrics endpoint から値を収集し、時系列データとして扱う仕組みです。Prometheus の公式ドキュメントでも、多次元データモデル、PromQL、HTTP pull model、service discovery などが特徴として説明されています。

Prometheus の本質は、単に監視対象へ ping を打つことではありません。http_requests_total、request_duration_seconds、container_cpu_usage_seconds_total のようなメトリクスを、ラベルと時系列で扱うことにあります。Kubernetes では、Pod、Service、Node、Container、Ingress、Application など、監視対象が固定的なサーバー単位ではなくなるため、この考え方が合います。

ただし、Prometheus を入れたからといって、自動的に運用監視が完成するわけではありません。どのメトリクスを見るのか。どのラベル粒度で集計するのか。どの条件を異常とするのか。どのアラートは人間を起こす価値があるのか。ここを設計しないと、Prometheus は単なるメトリクス置き場になります。

Grafana は監視そのものではなく、見るための画面である

Grafana は非常に便利ですが、Grafana 自体は監視対象から情報を集める仕組みではありません。Grafana の公式ドキュメントでも、data source は Grafana がクエリするデータの置き場所であり、Prometheus、Loki、Elasticsearch、CloudWatch、PostgreSQL などを接続先として扱うものとして説明されています。

つまり、Grafana は「見るための画面」です。画面がきれいでも、元データが悪ければ意味はありません。ダッシュボードが多くても、障害時に最初に見るべき画面が決まっていなければ、運用には使えません。

Grafana を使う場合に重要なのは、見た目ではなく、サービス影響を見る画面、原因調査を見る画面、容量計画を見る画面、通常時の状態確認画面を分けることです。CPU やメモリだけでなく、レイテンシ、エラー率、リクエスト数、キュー滞留、外部依存先の応答など、判断に必要な軸が揃っているかを見る必要があります。

Alertmanager は通知の責務を分けるためにある

Prometheus の文脈では、アラートルールと通知処理を分けて考える必要があります。Prometheus はルールに基づいてアラートを生成できますが、その後の grouping、inhibition、silencing、通知先への routing は Alertmanager が担います。

この分離は重要です。アラート条件を定義することと、人間にどう通知するかは同じではありません。同じ障害で大量の通知を出さない。メンテナンス中は抑止する。上位障害が出ている時は下位の派生アラートを抑える。担当チームや重要度に応じて通知先を変える。こうした設計は、監視項目そのものではなく、通知設計の責務です。

Zabbix にも通知、エスカレーション、メンテナンス、依存関係の考え方があります。Prometheus / Alertmanager を使う場合でも、Zabbix を使う場合でも、アラートは「出す」だけでなく「人間の注意力をどこに使わせるか」として設計する必要があります。

SNMP Trap は主役ではなく補助情報として扱う

ネットワーク機器では SNMP Trap がよく使われます。linkDown、linkUp、電源異常、ファン異常、温度異常など、機器側からイベントを送ってくれるため便利です。

しかし、SNMP Trap だけで監視を成立させるのは危険です。Trap は、機器が送ってくれなければ受け取れません。途中の経路で落ちる可能性もあります。また、Trap を受け取ったとしても、それがサービス影響を意味するとは限りません。

そのため、SNMP Trap は主監視というより、補助的なイベント情報として扱う方が自然です。基本はポーリングや外形監視で状態を確認し、Trap は変化を早く知るための補助情報と考える。この方が運用としては安定します。

外形監視と SLI / SLO を入れないとサービス影響が見えない

インフラ監視で抜けやすいのが、利用者から見たサービス状態です。CPU 使用率、メモリ使用量、ディスク使用量、interface status は重要ですが、それだけでは利用者がサービスを使えているかは分かりません。

ここで外形監視、SLI、SLO の考え方が必要になります。HTTP の応答が返るか。ログインできるか。主要 API が期待時間内に返るか。エラー率が許容範囲に収まっているか。こうした指標は、個々のサーバーやネットワーク機器の状態よりも、サービス影響に近い場所にあります。Google の SRE でも、SLI はサービスレベルを測る指標、SLO はその目標値として扱われます。

つまり、Zabbix でホストや機器を見ること、Prometheus でメトリクスを見ること、Grafana で可視化することに加えて、サービスとしての到達性や体験を測る軸が必要です。監視対象が正常に見えても、利用者から見て失敗しているなら、それは監視設計として穴があります。

責務分界で監視を設計する

Zabbix、Prometheus、Grafana、Alertmanager、SNMP Trap、ログ基盤、外形監視を並べると、どれを使うべきかという話になりがちです。しかし、本来は責務で分けた方が分かりやすいです。

役割	向いているもの	設計で見ること
サーバー・ネットワーク機器の運用監視	Zabbix	ホスト、インターフェース、プロセス、SNMP、障害イベント
Kubernetes / アプリのメトリクス収集	Prometheus	ラベル、時系列、PromQL、サービスディスカバリ
通知の集約・抑止・ルーティング	Alertmanager / Zabbix actions	通知先、抑止、重要度、メンテナンス
メトリクスの可視化	Grafana	一次切り分け画面、原因調査画面、容量計画画面
機器イベントの補助通知	SNMP Trap	イベントの早期把握、ポーリングとの突き合わせ
詳細調査・事後分析	ログ基盤	エラー内容、前後関係、監査、検索性
サービス影響の判断	SLI / SLO / 外形監視	到達性、レイテンシ、エラー率、ユーザー影響

もちろん、環境によって使い方は変わります。Zabbix でメトリクスを取ることもできますし、Grafana からアラートを出すこともできます。Prometheus 以外の時系列データベースを使う場合もあります。重要なのは、ツールの機能が重なっていることと、責務を曖昧にしてよいことは別だという点です。

どのツールが何を担当するのか。どこを見れば一次切り分けができるのか。どこから先は詳細調査なのか。どのアラートは人間を起こすのか。どの指標をサービス影響とみなすのか。ここを決めることが監視設計です。

まとめ

監視とは、ツールを入れることではありません。監視とは、システムの状態を観測し、異常を判断し、必要な対応へつなげるための設計です。

Zabbix、Prometheus、Grafana、Alertmanager、SNMP Trap、ログ基盤、外形監視は、それぞれ役割が違います。どれが優れているかではなく、何を見るために使うのかを決める必要があります。

監視が弱い環境では、障害が起きた時に何を見るべきか分かりません。逆に、監視が過剰な環境では、アラートが多すぎて人間が疲弊します。必要なのは監視項目を増やすことではなく、見るべきものを決め、見なくてよいものを捨て、判断できる形に整理することです。

監視とは、情報を集めることではなく、運用判断のために情報を構造化することだと思います。

参考情報

関連する記事