オブザーバビリティとは ― 監視との違いとメトリクス・ログ・トレース

CPU使用率もエラー率も正常なのに、注文の画面だけが遅いと問い合わせが来ることがあります。オブザーバビリティは、こんなときに原因を調べられるかどうかを表す言葉です。システムが外に出すデータから、中で起きていることを理解できる度合いを指し、日本語では可観測性と呼びます。

処理を複数のサービスに分けたマイクロサービスでは、1つの画面の裏で多くのサービスが動きます。どれか1つが遅いだけで画面全体が遅くなるのに、サーバごとの数値を見ても、どの処理が原因かまでは分かりません。「ここはオブザーバビリティが足りない」と言われたら、原因を調べる材料が足りないという意味です。

材料になるのは、メトリクス・ログ・トレースの3種類のデータです。それぞれ得意な問いが違うので、組み合わせて原因を絞ります。アプリのコードがこれらのデータを出すようにすることを計装と呼びます。アプリが出していないデータは、ツールを入れても集まりません。

監視は、あらかじめ決めた指標を集めて見張り、異常があれば知らせる活動です。CPU使用率が90%を超えたら通知する、といった決まりを先に作っておきます。見つけられるのは、基本的に先に想定しておいた問題です。

オブザーバビリティは、想定していなかった問題でも、あとから問いを立てて調べられる性質です。対象の画面や商品、時間帯を変えながらデータを絞り込めれば、原因に近づけます。言葉のもとは制御工学で、外に見える出力から内部の状態をどれだけ推定できるかを表します。

2つは対立するものではありません。監視はシステムを見張る活動で、オブザーバビリティはシステムの性質です。異常に気づくには監視が要り、その原因を調べるときにオブザーバビリティが効きます。

監視の具体的な仕組みは、対象によって変わります。ネットワーク機器の数値を集める代表はSNMPで、機器のログを1か所に集める代表はSyslogです。AWSでメトリクス・ログ・アラームをまとめて使うなら、Amazon CloudWatchがあります。

1つのリクエストが、注文サービス、在庫サービス、データベースを順に通る例で比べます。次の図は、3種類のデータがそれぞれ何を記録するかを、この流れに重ねたものです。

この3つを3本柱と呼ぶ文書は多くあります。ただ、クラウド向けのオープンソースを支える団体CNCFの白書は、3つを常に同時にそろえる必要はないとして、主要なシグナルと呼んでいます。費用を考えて、メトリクスとログを中心にし、トレースは必要なときだけ使う組み合わせも挙げています。

メトリクスは、一定の時間で集計した数値

メトリクスは一定の時間で集計した数値で、エラー率、CPU使用率、1秒あたりのリクエスト数などがあります。リクエストが増えてもデータの量は増えないので、費用を見積もりやすく、変化をグラフですぐに確かめられます。その代わり、集計すると個々のリクエストの情報は消えます。

何から測るかに迷ったら、GoogleのSREの本がゴールデンシグナルとして挙げる4つの指標が目安になります。

• 遅延：リクエストの処理にかかる時間
• トラフィック：システムにかかる需要の量。Webなら1秒あたりのHTTPリクエスト数
• エラー：失敗したリクエストの割合
• サチュレーション：メモリなどの資源が、どれだけ埋まっているか

遅延は平均だけで判断しないようにします。同じ本は、平均が100ミリ秒のサービスでも、リクエストの1%が5秒かかることがあると書いています。そこで、速い順に並べて99%の位置にくる値を見ます。この値を99パーセンタイルと呼びます。

ログは、時刻の付いた個々の出来事の記録

ログは、ある時刻に何が起きたかを1件ずつ残した記録です。エラーの内容や処理した件数のような、細かい事情まで書けます。ただし、リクエストを示すIDを書いていないログからは、それがどのリクエストの一部なのか分かりません。

ログは、項目の名前と値を決まった形で書いておくと調べやすくなります。この形のログを構造化ログと呼び、項目を指定して検索や集計ができます。オープンソースの仕組みOpenTelemetryの文書も、構造化ログを勧めています。条件に挙げているのは、JSONで書くことより、項目の名前と型が一定であることです。

トレースは、1つのリクエストがたどった道筋の記録

トレースは、1つのリクエストが通ったサービスと、それぞれの処理にかかった時間の記録です。どこで時間を使ったかが分かるので、遅さの場所を絞るときに役立ちます。その代わり、1つのトレースから分かるのは1件のリクエストのことだけで、全体の傾向は見えません。

分散トレーシングは、複数のサービスをまたぐ1つのリクエストを追う方法です。各サービスは、処理の1単位ごとに名前と開始・終了の時刻を記録します。この1単位をスパンと呼び、1つのリクエストのスパンを集めたものがトレースです。

スパンをつなげる目印が、トレースIDです。最初のサービスがIDを作り、次のサービスを呼ぶときに渡します。受け取ったサービスは同じトレースIDで自分のスパンを作り、呼び出し元のスパンを親として記録します。

HTTPでは、このIDをヘッダに入れて渡します。形式はWebの標準化団体W3CがTrace Contextとして勧告していて、次のように書きます。

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01

2つ目の32桁がトレースIDで、3つ目の16桁が呼び出し元のスパンのIDです。集めたスパンを時間の軸に並べると、どこで時間を使ったかが分かります。

同じトレースIDをログにも書いておくと、トレースからそのリクエストのログだけを取り出せます。OpenTelemetryのSDKは、この関連付けを自動で行えます。トレースとログを1つのIDで行き来できるので、場所を絞ってから理由を確かめられます。

注文の画面が遅いという問い合わせを例に、原因を探します。3つの問いそれぞれで、どのデータを見れば答えが出るかを選びます。3問目には、構造化ログの実例も出てきます。

調べる順番は決まりではありません。ただ、範囲の広いデータから狭いデータへ進むと、読むデータの量を減らせます。画面が遅い場合は、いつから・どこで・なぜ、の順に絞っていくと迷いません。

CPU使用率が90%を超えたら通知する、のように原因の側で通知を作ると、利用者が困っていないときにも鳴ります。調べても問題がない通知が続くと、担当者は通知を読み飛ばすようになります。GoogleのSREの本は、通知が多すぎると本物の通知まで無視され、障害が長引くと書いています。この状態を通知疲れと呼びます。

通知は、利用者への影響が出ているかどうかで鳴らします。SREの本は、これを症状と原因の区別として説明しています。応答が遅いのは症状で、CPUの過負荷はその原因の1つです。症状で人を呼び、原因は呼ばれたあとで3本柱を使って調べます。

利用者への影響を数字で表すのが、SLOとエラーバジェットです。SLOを使う通知では、エラーバジェットを使う速さを見ます。この速さをバーンレートと呼び、1なら期間の終わりにちょうど使い切る速さです。Googleのワークブックは、30日のSLOの出発点として次の組み合わせを挙げています。

SLOが99.9%なら、バーンレート14.4はエラー率1.44%が続く状態です。この速さでは、30日分のエラーバジェットを約2日で使い切ります。一時的な小さな揺れでは鳴らさず、放っておけない速さのときだけ人を呼ぶための決め方です。値はサービスに合わせて調整します。

ツールごとに計装の方法が違うと、ツールを替えるたびにコードを直すことになります。OpenTelemetryは、メトリクス・ログ・トレースの作り方と送り方をそろえるオープンソースの仕組みです。特定の製品に依らないので、同じデータを別のツールへ送れます。

OpenTelemetryそのものは、データの保存先ではありません。保存と画面の表示は、JaegerやPrometheusのようなオープンソースのツールや、商用の製品に任せます。OpenTracingとOpenCensusが統合してできたCNCFのプロジェクトです。2026年5月に、CNCFの成熟度の最上位であるGraduatedになりました。

一度にすべてをそろえる必要はありません。手間の少ないものから進めるなら、次の順番が目安になります。すでにある仕組みによって、順番は入れ替わります。

1. ログを構造化ログにして、時刻・サービス名・処理の結果などの項目をそろえる
2. 4つの指標をメトリクスとして集め、SLOを決めて通知を作る
3. サービスどうしの呼び出しがある部分に、トレースを入れる
4. ログにトレースIDを書き、ログとトレースを行き来できるようにする

1つのサービスで完結するアプリなら、1と2でも多くの調査ができます。トレースはリクエストの数だけ増えるので、一部だけを残すサンプリングを使います。OpenTelemetryの文書は、成功して遅くもないリクエストが大半なら、すべてのトレースは要らないと説明しています。

OpenTelemetryには、コードを変えずにデータを出す自動計装の仕組みもあります。Kubernetesは、ログの収集や監視の方式を決めていません。コンテナで動かすアプリでは、データを集めて保存する先を別に用意します。

• Google「Site Reliability Engineering」Chapter 6 Monitoring Distributed Systems
• Google「The Site Reliability Workbook」Chapter 5 Alerting on SLOs
• OpenTelemetry「What is OpenTelemetry?」
• OpenTelemetry「Observability primer」
• OpenTelemetry「Context propagation」
• OpenTelemetry「Logs」
• OpenTelemetry「Sampling」
• W3C「Trace Context」（2021年11月の勧告）
• CNCF「Observability」（用語集）
• CNCF TAG Observability「Observability Whitepaper」
• CNCF「OpenTelemetry」（プロジェクトの成熟度）
• Kubernetes「Overview」