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

監視を考える時に、最初から Zabbix、Prometheus、Grafana のどれを使うかに入ると、話がずれやすくなります。

本来先に決めるべきなのは、ツールではありません。何を見るのか。どの状態を異常とするのか。誰が、その情報を見て判断するのか。そこが決まっていない監視は、画面やアラートが増えても運用にはつながりません。

死活監視、リソース監視、メトリクス収集、ログ監視、SNMP Trap、アラート通知、ダッシュボード表示、障害分析は、まとめて「監視」と呼ばれがちです。しかし、それぞれ見ているものも、判断したいことも違います。

Zabbix を入れたから監視できている。Prometheus を入れたから可観測性がある。Grafana のダッシュボードがあるから状態が見えている。そう考えると、監視設計の中心を見失います。

重要なのは、何を見るために、どの情報を、どの粒度で、誰が判断できる状態にするのかです。

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

監視の設計では、まず目的を分けます。大きく分けると、次のようになります。

領域	主な目的	例
死活監視	動いているか確認する	ping、HTTP status、プロセス確認
リソース監視	枯渇や逼迫を見る	CPU、メモリ、ディスク、IO、ネットワーク
メトリクス監視	状態の変化を時系列で見る	request rate、latency、error rate
ログ監視	事象の内容を読む	syslog、application log、audit log
Trap / Event	機器側からの通知を受ける	SNMP Trap、linkDown、hardware alert
アラート	人間に判断を促す	障害通知、しきい値超過、異常検知
ダッシュボード	状態を俯瞰する	Grafana、Zabbix screen

これらは似ていますが、同じではありません。CPU 使用率が高いことは「状態」です。HTTP が 500 を返していることは「サービス影響」です。linkDown の SNMP Trap は「機器が発したイベント」です。ログに出たエラーは「原因調査の材料」です。

これを全部まとめて「監視」と呼ぶと、何が足りていて、何が足りていないのか分からなくなります。

Zabbix は運用監視に強い

Zabbix は、伝統的なインフラ監視として非常に分かりやすい位置にあります。

サーバー、ネットワーク機器、プロセス、ポート、SNMP、ICMP、ログ監視、アラート通知などを一通り扱えます。特に、機器やホストを管理対象として登録し、それに対してテンプレートを適用し、障害イベントとして管理する発想は、一般的なインフラ運用と相性が良いです。

Zabbix の強みは、単なるメトリクス収集ではなく、運用上の障害イベントとして扱いやすいことです。

一方で、Kubernetes やクラウドネイティブなワークロードのように、対象が動的に増減する環境では、Prometheus 型の考え方の方が自然な場合があります。

Prometheus はメトリクスを時系列で見る仕組み

Prometheus は、メトリクスを時系列データとして収集し、PromQL で問い合わせる仕組みです。

Prometheus の本質は、単に監視対象へ ping を打つことではありません。対象が公開する metrics endpoint から値を取得し、その変化を時系列で扱うことです。

Kubernetes では、Pod、Service、Node、Container、Ingress、Application など、監視対象が静的なサーバー単位ではなくなります。このような環境では、ラベルを使って対象を分類し、時系列データとして状態を見る Prometheus の考え方が合います。

ただし、Prometheus を入れたからといって、自動的に運用監視が完成するわけではありません。

• どのメトリクスを見るのか
• どの条件を異常とするのか
• どの単位でアラートを出すのか
• どのアラートは人間を起こす価値があるのか

ここを設計しないと、Prometheus は単なるメトリクス置き場になります。

Grafana は監視そのものではない

Grafana は非常に便利ですが、Grafana 自体は監視対象から情報を集める仕組みではありません。基本的には、Prometheus、Loki、InfluxDB、Elasticsearch、Zabbix などのデータソースを可視化するための道具です。

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

Grafana を使う場合に重要なのは、見た目ではなく、次のような設計です。

• 障害時に最初に見る画面はどれか
• サービス影響を見る画面と、原因調査を見る画面を分けているか
• CPU やメモリだけでなく、レイテンシやエラー率を見ているか
• Kubernetes、ネットワーク、アプリケーションをどう関連付けて見るか
• 通常時のダッシュボードと障害時のダッシュボードを分けているか

Grafana は強力ですが、監視設計がないまま導入すると、きれいなグラフ置き場になります。

SNMP Trap は主役ではなく補助情報

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

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

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

アラートは人間の注意力を消費する

監視設計で特に重要なのはアラートです。アラートは出せばよいものではありません。アラートは人間の注意力を消費します。

どうでもよいアラートが大量に出る環境では、本当に重要なアラートが埋もれます。これは監視ができているのではなく、監視ノイズを発生させているだけです。

アラートを設計する時は、次の観点が必要です。

• それは人間が対応すべき事象か
• すぐ対応しないと影響が拡大するか
• 自動復旧する一時的な事象ではないか
• 原因ではなく影響を見ているか
• 同じ障害で大量のアラートが出ないか

特に重要なのは、原因よりも影響を見ることです。CPU 使用率が高いこと自体は原因候補です。しかし、ユーザーがアクセスできない、レスポンスが遅い、エラー率が高い、という方がサービス影響に近いです。

運用で本当に起こすべきアラートは、サービス影響に近いものから設計するべきです。

監視設計は責務分界で考える

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

役割	向いているもの
サーバー・ネットワーク機器の運用監視	Zabbix
Kubernetes / アプリのメトリクス収集	Prometheus
メトリクスの可視化	Grafana
機器イベントの補助通知	SNMP Trap
詳細調査・事後分析	ログ基盤
サービス影響の判断	SLI / SLO / 外形監視

もちろん、環境によって使い方は変わります。Zabbix でメトリクスを取ることもできますし、Prometheus Alertmanager で通知することもできます。Grafana からアラートを出すこともできます。

ただし、ツールの機能が重なっていることと、責務を曖昧にしてよいことは別です。どのツールが何を担当するのか。どこを見れば一次切り分けができるのか。どこから先は詳細調査なのか。ここを決めることが監視設計です。

まとめ

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

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

監視が弱い環境では、障害が起きた時に何を見るべきか分かりません。逆に、監視が過剰な環境では、アラートが多すぎて人間が疲弊します。

必要なのは、監視項目を増やすことではありません。見るべきものを決め、見なくてよいものを捨て、判断できる形に整理することです。

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