これらは可観測性の3つの柱です。異なる質問に答えます:メトリクスは何かが間違っていることを教え、ログは何が起こったかを教え、トレースは分散フロー内のどこで時間またはエラーが発生したかを教えます。
これらは可観測性の3つの柱です。異なる質問に答えます:メトリクスは何かが間違っていることを教え、ログは何が起こったかを教え、トレースは分散フロー内のどこで時間またはエラーが発生したかを教えます。
METRICS aggregate numbers over time (counters, gauges, histograms)
→ cheap, low cardinality, great for trends & ALERTING
→ e.g. error rate = 2%, p99 latency = 800ms
LOGS discrete, timestamped events with detail (often structured JSON)
→ rich context for DEBUGGING a specific request
→ e.g. {"level":"error","user":123,"msg":"payment declined"}
TRACES the path of one request across services, with timing per span
→ shows latency BREAKDOWN and where a call fails
→ e.g. checkout 800ms = api 50ms + db 700ms + email 50ms
1. METRIC alerts: "checkout p99 latency jumped to 2s" → you know THERE's a problem
2. TRACE a slow request: 1.8s of 2s is spent in the inventory service
→ you know WHERE it is
3. LOGS of the inventory service at that time: "slow query: missing index"
→ you know WHAT happened
メトリクスは症状と時間ウィンドウに範囲を絞り込みます。トレースはそれをサービスまたは呼び出しに特定し、ログは正確な原因を提供します。メトリクスなしでログに直接向かうことは、盲目的に検索することを意味します。
メトリクスは集計されるため、スケーラビリティが高い場合でもコストが低く保たれます — 常時オンのダッシュボードとアラートに最適です。ログとトレースはイベントごとであり、費用がかかるため、通常サンプリングされ、調査中のオンデマンドで照会されます。
間違った柱を使うと時間が無駄になります:生のログで効果的にアラートを出すことはできません(ノイズが多すぎ、コストがかかりすぎます)、また集計メトリクスから特定の失敗したリクエストをデバッグすることはできません。メトリクスが検出し、トレースが特定し、ログが説明することを知ることで、"何かが間違っている"から根本原因まで、迅速で反復可能なパスが得られます。
ジュニアからシニアまで、詳細な回答付きのIT面接質問ライブラリ。
寄付する