オブザーバビリティとは何か

監視と何が違うのか—観測可能性の3本柱

オブザーバビリティは「外から観測できる振る舞いから、内側の状態を推論できる力」を指します。従来の監視が「想定している故障を見張る」アプローチだとすれば、オブザーバビリティは「想定外まで含めて、原因を素早く絞り込む」ための設計思想です。未知の障害や複雑な依存関係を前提に、答えにたどり着くまでの時間を短縮します。

監視の限界

CPUが90%を超えたらアラート、HTTP 500が一定数出たら通知——これだけでは、なぜ遅いのか、どのサービス間で詰まりが起きたのかは見えてきません。マイクロサービス、キュー、キャッシュ、外部API、コンテナのスケールなどが絡むと、単発のメトリクスやログでは相関が見えず、復旧までの時間が伸びがちです。

3本柱（メトリクス・ログ・トレース）

オブザーバビリティは一般に次の3つで土台を作ります。

• メトリクス: 時系列の数値。RED法（Rate/Errors/Duration）やUSE法（Utilization/Saturation/Errors）で収集範囲を決めると漏れが減ります。
• ログ: 構造化（JSON）とコンテキスト付与（trace_id, user_idなど）。検索性と集計性を両立します。
• トレース: 分散処理の因果関係を可視化し、どの区間が遅いかを特定します。スパン属性にビジネス指標（cart_valueなど）を載せると意思決定に直結します。

この3つをSLO/SLIと結びつけ、「何が壊れた？」ではなく「顧客体験は守られているか？」から逆算するのがポイントです。

実装の勘所—指標設計からダッシュボード運用まで

指標とアラート設計

まずユーザ体験のSLIを決めます。例として「チェックアウトのp95レイテンシ1.5秒未満」「成功率99.5%以上」。SLOに違反しそうなときだけ鳴るアラートに絞り、誤検知を抑えます。実務ではマルチウィンドウのバーンレート監視（例: 1時間でSLOエラーバジェットの2%超、かつ6時間で5%超）を使うと、瞬間風速と長期悪化を両取りできます。

データ収集と相関付け

OpenTelemetryで各サービスにトレースを仕込み、ログにもtrace_idを埋め込みます。メトリクスはPrometheusでスクレイプし、GrafanaでSLOダッシュボードを1〜2画面に要約。大量ログの保管や相関検索はDatadogのようなマネージド基盤に寄せると運用負荷を下げられます。クエリや正規表現の初稿はChatGPTに生成させ、レビューして取り込むと速度が上がります。

コストとノイズ管理

現場で効くのは「やりすぎない」設計です。高頻度ログはサンプリング1〜10%、トレースはヘッドベース10%＋テイルベースで遅延スパンのみ昇格。ラベルはcardinalityを抑え、動的IDをそのまま載せない。保持は「ホット30日・コールド180日」を目安に、法務/セキュリティ要件で調整します。

身近な企業活用例—ECスタートアップ「ネコノテ商店」の失敗と改善

従業員20名のEC「ネコノテ商店」。週末セールで決済が断続的に失敗し、監視はPingとCPU/メモリのみ。顧客からの問い合わせで初めて異常に気づき、復旧まで90分。広告費も無駄になりました。

改善では、まずSLI/SLOを定義（チェックアウト成功率99.5%、p95レイテンシ1.5秒）。Prometheusでフロント、API、DB、決済ゲートウェイのREDメトリクスを収集し、Grafanaに「経路別レイテンシ」「SLO残バジェット」の2枚だけを常用。OpenTelemetryで分散トレースを導入し、全リクエストにcorrelation_idを付与。ログはDatadogに集約し、ホット30日・アーカイブ180日。アラートはSLOバーンレート基準に置換、Slackルーティングと当番表連動、Runbookリンクを必須にしました。PromQLの集計式はエンジニアがChatGPTでたたき台を作り、レビューで品質を担保。

結果、セール時のボトルネックが「決済APIリトライの指数バックオフ設定ミス」と判明。修正後はMTTRが90分→20分、アラート件数は月間60%減、SLO違反はゼロに。障害対応の主語が「CPUが高いから」から「顧客の支払いフローp95超過だから」へ変わり、施策の優先度付けも楽になりました。

よくある落とし穴と回避策

• ダッシュボード増殖: 役割ごとに「常用1枚＋詳細1枚」。使われない板はアーカイブ。
• アラート疲労: SLOファーストに再設計。通知時に「影響範囲・想定原因・次の1手」をテンプレ化。
• ラベル地獄: 命名規約（env, service, version, regionのみ必須）。高カーディナリティはサンプリング。
• トレース過多/過少: ヘッド10%＋テイル昇格。重いスパンのみ属性詳細を残す。
• 個人情報の混入: ログを前処理でマスキング。閲覧権限と監査ログを整備。
• リリースと観測の分離: 「計測がない機能はリリース不可」をDoDに追加。フィーチャーフラグで段階展開。

オブザーバビリティは派手なツール選定より、SLO中心の設計と運用の一貫性が成否を分けます。サーバ監視運用はその土台です。既存の監視から一歩進め、観測設計・SLO・アラート運用・データ保持ポリシーまでをひと続きに整えることで、故障検知だけでなく「最短で原因にたどり着く」日常運用が実現します。