オブザーバビリティ

オブザーバビリティとは

オブザーバビリティ(Observability、可観測性)は、システムの外から見える情報だけで、内部で何が起きているかを把握できる状態を指します。「監視(Monitoring)」が既知の異常を検知するのに対し、オブザーバビリティは未知の問題にも対応できることを目指す、より広い概念です。

監視との違いはどこに出るか

監視は「CPU使用率が90%を超えたら知らせる」のように、あらかじめ想定した異常を見張ります。想定できるものは確実に守れますが、想定していなかった壊れ方には反応しません。

たとえば「特定のキャンペーンコードを使った注文だけが、外部の決済サービスが混み合う時間帯に限って失敗する」という障害を考えてみてください。CPUもメモリも全体のエラー率も平常どおりなので、しきい値ベースの監視には何も引っかかりません。

分かれ目は、あらかじめ質問を決めずに済むだけの情報を残しているかです。「注文IDごと」「決済プロバイダごと」と後から切り口を変えて絞り込めるなら、想定外の壊れ方にもたどり着けます。

3本柱

種類	内容	例
ログ	いつ・何が起きたかの記録	エラーログ、アクセスログ
メトリクス	数値で表した状態の推移	CPU使用率、リクエスト数、レイテンシ
トレース	1つのリクエストがシステム内をどう通ったかの経路	マイクロサービス間の呼び出し順序と所要時間

初学者向けポイント

「なぜ遅いのか」「なぜエラーが出たのか」を調べる場面で真価を発揮する。障害対応のスピードと精度に直結する
1台のサーバーなら ssh して[[シェルとコマンドライン|ログを直接見る]]だけでも足りるが、[[Kubernetes]] のような分散環境ではどのPodで何が起きたか把握しづらく、専用の仕組みが必須になる
構造化ログ([[JSON]] 形式で1行1レコード)にしておくと、後から検索・集計しやすい。人間が読みやすい自由文のログは分析が困難

トレースの考え方

複数サービスをまたぐリクエストに共通のトレースIDを付与し、どのサービスをどんな順序で経由し、それぞれ何ミリ秒かかったかを1本の線として可視化します。マイクロサービス構成で「どこがボトルネックか」を特定する決め手になります。

リクエスト(trace-id: abc123)
  → APIサーバー (12ms)
    → 認証サービス (3ms)
    → DB問い合わせ (45ms) ← ここが遅い

3本柱は行き来できて初めて効く

3種類のデータを別々の画面で眺めているだけでは調査は進みません。「メトリクスでエラー率の上昇に気づく → その時間帯の遅いトレースを開く → 詰まっている区間のログへ飛ぶ」という行き来ができて、はじめて原因までたどり着けます。

これを成り立たせているのは、すべてのログにトレースIDを埋め込んでおくという地味な下ごしらえです(何をどう残すかは [[ログ設計]] が扱います)。ここが欠けていると、3つの画面をタイムスタンプで目視照合するはめになります。

計測しなければ何も見えない

観測データは勝手には出てきません。アプリのコードに「ここで何ミリ秒かかった」「どのIDを処理した」と記録を仕込む作業を計測(インストルメンテーション)と呼びます。

自動計測 — ライブラリやエージェントを入れるだけで、HTTP通信やDBアクセスなど定型的な処理が自動で記録される。まずはここから始める
手動計測 — 「在庫の引き当て」「クーポンの適用」のような業務上の意味がある単位は、自分でコードに入れる。障害調査で本当に効くのはこちら

計測の書き方を特定ツール専用にすると、監視サービスを乗り換えるたびにアプリ全体へ手を入れることになります。これを避ける業界標準が OpenTelemetry で、アプリ側は共通の書き方で計測し、送り先だけを設定で切り替えられます。

全部を残そうとすると破綻する

観測データは量が多く、貯めるほど費用がかかります。踏みやすい失敗が2つあります。

1つはカーディナリティの爆発です。メトリクスにユーザーIDやリクエストIDのような「値の種類がほぼ無限にある」ラベルを付けると、時系列データの本数が利用者数の分だけ増え、収集基盤のほうが先に音を上げます。ラベルにするのは値の種類が限られるもの(エンドポイント名、ステータスコード、リージョンなど)だけにして、個別のIDはログやトレース側に持たせます。

もう1つはトレースの全件保存です。正常に終わったリクエストのトレースはほとんど見返されないため、実務では一部だけを残すサンプリングを行います。ただし機械的に1%だけ残すと、1日に数件しか起きないエラーのトレースは99%の確率で捨てられます。エラーになったもの・極端に遅かったものは必ず残す、という条件付きの残し方を選びます。

代表的なツール

Prometheus(メトリクス)、Grafana(可視化)、OpenTelemetry(計測の標準規格)、Datadogやニューレリックのような統合SaaSが広く使われています。

ここから先の読み進め方

隣接する話題が広いので、目的別に入口を分けておきます。

3本柱を1本ずつ深める — [[ログ設計]] はレベル分け・構造化・出してはいけない情報まで、記録を残す側の作法です。[[監視とアラート]] は集めた値から「いま人を呼ぶか」を判断する側で、しきい値とノイズの話が中心になります。この2本を読むと、集める役と鳴らす役の分担が見えます。

分散した環境で使う — [[マイクロサービス]] はサービスをまたぐ調査でトレースが必須になる代表的な構成です。[[Kubernetes]] はPodが入れ替わるとログごと消えるため、外部へ集約する前提が要ります。[[データパイプライン・ETL]] のような定期実行の処理では、止まったことより「静かに遅れている・件数が減っている」ことの検知が課題になります。

観測を運用の判断につなげる — [[SRE]] は観測した値をSLI・SLOとエラーバジェットという意思決定の材料に変えます。[[DevOps]] は復旧までの時間(MTTR)を成果指標に組み込む立場、[[インシデント対応]] は実際に障害が起きたときの手順です。「測って終わり」にしないための3本です。

「遅い」の原因を掘り下げる — トレースでボトルネックの区間まで絞れたら、次はその中身です。DBが遅いなら [[実行計画とクエリチューニング]] で、どのクエリが総時間を食っているかを見ます。外部との通信なら [[HTTPステータスコード]] の内訳が手がかりです。

関連技術とのつながり

[[Kubernetes]] — Pod単位で分散するため、可観測性の仕組みがほぼ必須になる環境
[[CI/CD]] — デプロイ直後の異常検知はオブザーバビリティが支える
[[クラウドコンピューティング]] — 主要クラウドは監視・ログ基盤をマネージドサービスとして提供
[[HTTP]] — レイテンシや [[HTTPステータスコード]] など、監視の基本単位となる通信

Q: メトリクスのラベルに付けるべきでないものとして、本文が挙げているのはどれ?
- [ ] エンドポイント名
- [x] ユーザーIDやリクエストIDのような、値の種類がほぼ無限にあるもの
- [ ] HTTPステータスコード
解説: 種類が無限に増えるラベルは時系列データの本数を爆発させます(カーディナリティの爆発)。個別のIDはログやトレース側に持たせます。

Q: OpenTelemetry を使う利点として本文が挙げているのはどれ?
- [x] アプリ側は共通の書き方で計測し、送り先だけを設定で切り替えられる
- [ ] 計測用のコードを書かなくても業務固有の処理が自動で記録される
- [ ] 保存するデータ量が自動的にゼロになる
解説: 計測の書き方を特定ツール専用にすると乗り換えのたびにアプリを直すことになります。それを避ける業界標準がOpenTelemetryです。

Q: トレースのサンプリングで注意すべき点はどれ?
- [ ] 正常なリクエストほど優先して残す必要がある
- [ ] サンプリングをすると保存費用がかえって増える
- [x] 機械的に一部だけ残すと、まれにしか起きないエラーのトレースが捨てられてしまう
解説: 1%だけ残す設定では、1日数件のエラーは99%の確率で失われます。エラーや極端に遅かったものは必ず残す条件付きの残し方を選びます。