Prometheus と Loki は何が違うのか – メトリクス、ログ、トレース、アラートの役割を分ける

監視やオブザーバビリティでは、複数の情報を同時に見ます。CPU 使用率、メモリ使用量、HTTP レイテンシ、エラーログ、分散トレース、外形監視、アラート、SLO の達成状況。どれもシステムを理解するために必要ですが、同じ時間軸の情報ではありません。瞬間的なスパイクを長期傾向の根拠にしたり、月次の SLO 違反を 1 回のログで説明しようとしたりすると、判断が崩れます。

問題は、情報が多いことではありません。何を、どの粒度で、何の判断に使うのかを分けないまま見ることです。監視設計では、収集するデータの種類だけでなく、そのデータが答える問いと時間幅を先に決める必要があります。

メトリクスとログは同じ異常を見ていない

メトリクスは、時間に沿って集計できる数値です。リクエスト数、エラー率、レイテンシ、CPU 使用率、キュー長、空き容量のように、状態や変化を継続的に追う用途に向いています。Prometheus のようなメトリクス基盤では、時系列として保存し、一定の評価窓でアラートやダッシュボードに使います。

一方でログは、ある時点で発生したイベントの記録です。何が起きたのか、どのリクエストで失敗したのか、どの設定値が読み込まれたのか、どの例外が出たのかを確認するための材料です。ログを眺めれば原因に近づけることはありますが、ログだけでサービス全体の健康状態を連続的に判断するのは苦しくなります。

観測対象	得意な問い	苦手な使い方
メトリクス	今の状態は通常範囲から外れているか。傾向は悪化しているか。	個別リクエストで何が起きたかを詳細に説明する。
ログ	特定の時点で何が発生したか。例外や処理分岐は何だったか。	サービス全体の状態を継続的な数値として判断する。
トレース	一つのリクエストがどのサービスを通り、どこで遅くなったか。	システム全体の長期傾向を単独で判断する。
合成監視	利用者に近い経路から到達性や応答時間を確認できるか。	内部処理の詳細な原因を直接説明する。
SLO / SLI	一定期間で利用者に提供した信頼性は十分だったか。	いま発生している単一インシデントの原因を特定する。

同じ HTTP 500 でも、メトリクスではエラー率として見えます。ログでは例外やリクエスト ID として残ります。トレースでは、どのサービスや依存先で遅延や失敗が起きたかを追えます。これらは競合する情報ではなく、別の粒度で同じ事象を観測している情報です。

短期の異常と長期の傾向を混ぜない

運用判断で混乱しやすいのは、短期の異常と長期の傾向を同じ判断に混ぜる場合です。たとえば、5 分間だけ CPU 使用率が 95% になったとしても、それだけで恒久的な増強が必要とは限りません。バッチ処理、デプロイ直後のウォームアップ、キャッシュの再生成、特定時間帯のアクセス集中など、一時的な理由で発生している可能性があります。

反対に、1 カ月単位で p95 レイテンシがじわじわ悪化している場合、直近 5 分が平穏だからといって問題がないとは言えません。容量、依存サービス、データ量、クエリ、キャッシュ効率、ネットワーク経路など、長期的に効いてくる要素を見なければなりません。

時間幅	主に見るもの	判断の例
数秒から数分	現在のエラー率、レイテンシ、到達性、キュー長、リソース逼迫。	インシデント対応、切り戻し、緊急回避。
数十分から数時間	デプロイ前後の変化、ピーク時間帯、外部依存の影響。	変更影響の確認、暫定対処の継続判断。
数日	日次の負荷パターン、ジョブ、バックアップ、定期処理。	運用設計やスケジュールの見直し。
数週間から数カ月	容量増加、SLO 達成率、エラー予算、利用傾向。	増強計画、設計変更、投資判断。

短期のアラートは、今すぐ人間が反応すべきかを決めるためにあります。長期の SLO やキャパシティ分析は、設計や投資の判断に使います。どちらも重要ですが、役割を混ぜると、短期のノイズで設計を変えたり、長期の傾向を理由に現在の障害対応を遅らせたりします。

アラートはデータソースではなく判断境界である

アラートは観測データそのものではありません。メトリクス、ログ、合成監視、外部サービスの状態などをもとに、人間または自動化へ通知するための判断境界です。そのため、アラート設計では、どのデータを見るかだけでなく、どの時間幅で評価し、誰が、何をするのかまで決める必要があります。

一瞬のスパイクで毎回通知すると、運用者はアラートを信用しなくなります。逆に、評価窓を長くしすぎると、実際の障害に気づくのが遅れます。通知するアラートと、ダッシュボードで見るだけのメトリクスと、後から分析するログは分けるべきです。

たとえば、HTTP 500 が 1 件出たことはログとして重要です。しかし、必ずしも深夜に人を起こす条件ではありません。5 分間のエラー率が一定以上に上がり、利用者影響が継続しているなら、アラートとして扱う価値があります。さらに、月間の可用性やレイテンシが SLO を満たせないなら、設計改善やリソース配分の問題として扱うべきです。

トレースは原因の経路を見るためのもの

分散トレースは、メトリクスやログだけでは見えにくい依存関係を確認するために有効です。1 つのリクエストが API、認証、データベース、外部 API、メッセージング基盤を通る場合、どの区間で時間を使ったのか、どのサービスで失敗したのかを追いやすくなります。

ただし、トレースを万能な監視基盤として扱うと設計が崩れます。トレースはリクエスト単位の因果関係を見るための情報であり、システム全体の状態を低コストに継続監視するものではありません。まずメトリクスで異常の発生を把握し、ログやトレースで原因に近づく、という役割分担が自然です。

外形監視は利用者に近い問いへ答える

内部メトリクスが正常でも、利用者から見てサービスが正常とは限りません。DNS、TLS、CDN、プロキシ、SaaS、クラウドネットワーク、拠点間回線など、利用者とサービスの間には複数の経路があります。合成監視や外形監視は、利用者に近い場所から到達性や応答時間を見るための手段です。

一方で、外形監視だけでは内部の原因は分かりません。外から見て遅いことは分かっても、それがアプリケーション、データベース、ネットワーク経路、名前解決、TLS、外部 API のどれに起因するのかは別途切り分けが必要です。外形監視は、利用者影響の検知として強い一方で、原因分析には内部のメトリクス、ログ、トレースと組み合わせる必要があります。

観測データごとに使う判断を決めておく

監視設計では、先にデータを集めてから考えるのではなく、どの判断に使うのかを決めてから集める方が整理しやすくなります。CPU 使用率を見るなら、緊急対応に使うのか、容量計画に使うのか、ノード配置の見直しに使うのかを分けます。ログを集めるなら、監査、障害調査、セキュリティ検知、利用分析のどれに使うのかを分けます。

設計項目	決めること
対象	どのサービス、コンポーネント、経路、利用者影響を見るのか。
粒度	秒、分、時間、日、月のどの幅で判断するのか。
用途	検知、原因調査、容量計画、SLO 評価、監査のどれに使うのか。
保持期間	直近確認用か、傾向分析用か、監査証跡用か。
通知条件	人を起こすのか、営業時間内に見るのか、記録だけでよいのか。
関連付け	メトリクス、ログ、トレース、変更履歴、チケットをどう結び付けるのか。

この整理をしないまま監視項目だけ増やすと、ダッシュボードは豪華になりますが、判断は遅くなります。見える情報が増えても、何を根拠に判断するかが決まっていなければ、障害時に人間が画面を横断して意味を探すことになります。

Prometheus と Loki は同じ監視ではない

最近の構成では、Prometheus、Loki、Grafana が同じ画面で扱われることが多くなりました。そのため、どちらも Grafana で見える監視データとしてまとめてしまいがちです。しかし、Prometheus と Loki は同じ役割の道具ではありません。

Prometheus は、状態の変化を継続的な数値として見るためのものです。CPU 使用率、メモリ使用量、HTTP 5xx の比率、キュー長、ディスク容量、Ceph の PG 状態や I/O レートのように、時間に沿って集計し、閾値や傾向で判断する情報に向いています。

Loki は、出来事の理由を後から読むためのものです。WAF がなぜ遮断したのか、どの request line が多かったのか、どの unit がエラーを出したのか、設定変更後にどのメッセージが出たのかを確認する用途に向いています。Loki でも件数集計はできますが、ログの本質は事象の説明にあります。

観点	Prometheus	Loki
主な役割	状態と傾向を見る	出来事と理由を読む
得意な情報	数値、比率、時間変化、閾値	イベント、エラー文、request line、判定理由
向いている判断	現在異常か、悪化傾向か、容量が足りるか	何が起きたか、なぜ止めたか、どの条件に一致したか
アラート	継続条件や比率で作りやすい	特定イベントの検知に使えるが、ノイズ管理が必要
保存する粒度	時系列サンプル	ログ行、JSON フィールド、イベント本文

たとえば Ceph の容量や PG 状態を知りたいなら Prometheus が自然です。一方で、Ceph がなぜ特定のログを出したのか、通常運用で DEBUG ログが多すぎるのかを確認する場合は Loki のログが必要です。WAF でも同じです。遮断件数の増減は Loki から集計できますが、遮断理由は audit log の本文を読まなければ分かりません。

ログをメトリクスの代わりに使いすぎると、毎回ログ本文の検索に依存します。反対に、メトリクスだけで理由まで説明しようとすると、原因の文脈が落ちます。状態は Prometheus、理由は Loki、画面上の導線は Grafana、という分担で考えると整理しやすくなります。

監視設計として残すもの

この記事の主題は、メトリクス、ログ、トレースを説明することではありません。監視設計として重要なのは、どの情報をどの判断に使うかを成果物として残すことです。運用者が障害中にダッシュボードを探し回らなくても、どの異常をどの信号で見つけ、どの情報で原因に近づくのかが分かる状態にしておく必要があります。

判断	主に使う情報	設計として残すもの
利用者影響が出ているか	外形監視、エラー率、p95 / p99 レイテンシ。	影響判定に使う SLI、評価窓、通知先。
どこで遅くなっているか	トレース、依存先メトリクス、キュー長。	主要リクエスト経路と依存サービスの対応表。
何が起きたか	ログ、イベント、変更履歴。	相関 ID、ログ保持期間、検索軸。
一時的な揺れか傾向悪化か	時系列メトリクス、SLO、キャパシティ指標。	短期アラートと長期レビューの分離。
誰が動くべきか	アラート種別、サービス責任者、Runbook。	通知条件、一次対応、エスカレーション先。

この表がない監視は、データは集まっていても判断が個人に寄ります。監視設計は、ツールに何を送るかではなく、障害時にどの順番で何を見るかを固定する作業です。

まとめ

監視やオブザーバビリティでは、観測する時間軸を混ぜないことが重要です。メトリクス、ログ、トレース、合成監視、アラート、SLO は、それぞれ答える問いが違います。短期の異常検知、原因調査、利用者影響の確認、容量計画、信頼性評価を同じ粒度で扱うと、判断基準が曖昧になります。

システムを見るときは、まず何を判断したいのかを決めるべきです。今すぐ対応する障害なのか。変更による一時的な揺れなのか。長期的な容量不足なのか。利用者体験の悪化なのか。監査として残すべき事実なのか。問いが変われば、見るべきデータ、時間幅、通知条件、保持期間も変わります。

観測データは、多ければよいわけではありません。役割が分かれていて、相互にたどれることが重要です。メトリクスで異常を把握し、ログで事象を確認し、トレースで依存関係を追い、外形監視で利用者影響を確認し、SLO で長期的な信頼性を評価する。この分担を決めておくことが、監視設計の出発点になります。

参考書籍

参考資料

• OpenTelemetry: Signals
• Prometheus: Overview
• Grafana Loki documentation
• Grafana documentation
• Google SRE Book: Monitoring Distributed Systems

関連する記事