オブザーバビリティ(Observability)
定義
システムの外部出力(ログ・トレース・メトリクス)だけを見て、内部状態を推測・診断できる度合い。
「モニタリング(既知の失敗を検知)」と異なり、オブザーバビリティは未知の問題を探索・診断できる能力を指す。
なぜ重要か
分散システムにおける障害の性質
モノリシックなシステムでは「どこで壊れたか」がスタックトレース1つで分かる。 分散システムでは、リクエストが複数のサービスをまたいで処理されるため:
- ユーザーから見た失敗(エラー応答・タイムアウト)の根因が、別サービスの奥深くに隠れている
- あるサービスが正常でも、依存先の遅延がカスケード障害を引き起こす
- ログを単独サービスで見ても全体像がつかめない
→ サービス間のリクエストの流れを一本の糸として追跡できなければ、診断が不可能になる。
AIエージェントシステムにおけるトレースの必要性
AIエージェントは以下の特性により、可観測性の難易度が通常のAPIより高い:
- 非決定的な実行フロー:LLMの判断によって呼び出すツール・ステップ数が変わる
- 多段階の連鎖:プランニング → ツール実行 → 評価 → 再試行が動的に組み合わさる
- 長い実行時間:非同期・バックグラウンド処理が多く、途中の状態が不可視になりやすい
→ どのステップで・なぜ・どんな判断をして・どこで失敗したかを追跡するトレースが必須。
3本柱の棲み分け
| シグナル | 問いに答える問い | 用途 |
|---|---|---|
| 構造化ログ | 何が起きたか(個別イベント) | 特定リクエストの詳細診断、監査 |
| トレース | どこを通ったか(リクエストの経路) | サービス間レイテンシ、根因特定 |
| メトリクス | どのくらいの頻度・量で起きているか(集計) | アラート、容量計画、SLO監視 |
Google SREの定義では、監視すべき4つのゴールデンシグナルとして以下を挙げる:
- レイテンシ(成功・失敗それぞれ)
- トラフィック(リクエスト数)
- エラー率
- 飽和度(リソースの使用率)
langfuse と OpenTelemetry の棲み分け
| ツール | 対象 | 強み |
|---|---|---|
| OpenTelemetry | あらゆる分散システム | 汎用計装標準。ログ・トレース・メトリクスすべてをカバー |
| Langfuse | LLM / AIエージェント特化 | プロンプト・補完・トークンコスト・評価スコアを可視化 |
AIエージェントシステムでは両者を層ごとに使い分けるのが現実的:
- インフラ・サービス間通信 → OpenTelemetry
- LLM呼び出し・エージェントの判断フロー → Langfuse
OpenTelemetryはLangfuseへのエクスポートにも対応しているため、計装は統一しつつ用途別に転送することも可能。
適用場面
- 分散システムの障害診断・ポストモーテム
- AIエージェントの応答品質・コスト・レイテンシの継続的改善
- SLO/SLAの達成状況の可視化
関連概念
- → メタデータ中心ロギング(ログに何を入れるべきか)
出典
- Google SRE Book — Monitoring Distributed Systems
- OpenTelemetry — Overview