observability・2分で読める

Observability入門：概念で整理する（計測→収集→保管/可視化→運用）

Observabilityはツール名で追うとすぐ迷子になります。本記事では「なぜ必要か」「何を集めるか」「どう流すか」「どう運用するか」をレイヤで整理し、変わりにくい概念と判断軸だけで最小構成まで落とし込みます。

#observability#monitoring#sre#logging#metrics#tracing#error-tracking#opentelemetry

Observability入門：概念で整理する

Observability（可観測性）は、**障害対応のスピードと質を上げるための「設計」と「運用の型」**です。
ツールは流行りや入れ替わりがあるので、まずは 概念（何を・なぜ・どの粒度で） を押さえると、どのベンダー/OSSに乗り換えても判断がブレません。

この記事のゴールは次の3つです。

  • 全体像: 計測→収集→保管/可視化→運用、のレイヤで整理できる
  • 判断軸: 何から始め、どこにコストをかけるべきかが分かる
  • URL集: 概念と代表的な実装（ツール）の公式ドキュメントにすぐ飛べる

監視（Monitoring）とObservabilityの違い

  • Monitoring: 「既知の失敗モード」を検知する（例：CPUが閾値超え、エラー率が閾値超え）
  • Observability: 「未知の失敗モード」でも原因を辿れるようにする（例：特定顧客だけ遅い、特定パスだけ失敗する、依存先の揺らぎに弱い）

実務では二者択一ではなく、Monitoringで検知し、Observabilityで調査して直す、が基本になります。

何を集めるのか：Signals（シグナル）

よく使われる観測シグナルは次の4つです。

  • Logs（ログ）: 事実の記録（イベントの詳細、デバッグに強い）
  • Metrics（メトリクス）: 数値の時系列（傾向/異常検知/容量計画に強い）
  • Traces（トレース）: 1リクエストの流れ（ボトルネック/依存関係の把握に強い）
  • Errors（エラー/例外/クラッシュ）: 直すためのワークフロー（Issue化、影響範囲、再現条件）

「まず何を集めるべき？」の答えは、運用目的で変わります。

  • 障害を最短で検知したい: Metrics（率・遅延・飽和）→ Alert
  • 原因を掘りたい: Traces（遅い区間の特定）＋ Logs（具体的事実）
  • ユーザー影響を直結で追いたい: Errors（例外/クラッシュ）＋ Traces

レイヤで整理する（全体像）

Observabilityは「何のレイヤの役割か」で分類すると迷いが消えます。

  • レイヤA：計測（Instrumentation）
    アプリに仕込んで観測データを生成する（ログ出力、メトリクス計測、分散トレースの開始/伝搬）
  • レイヤB：収集・加工・ルーティング（Collector/Agent）
    観測データを集め、整形し、必要ならサンプリング/フィルタ/分岐して送る
  • レイヤC：保管・可視化・分析（Backend/Platform）
    検索・ダッシュボード・アラート・集計・相関分析を提供する
  • レイヤD：運用ワークフロー（Incident / Error Tracking / On-call）
    直すための運用（通知、トリアージ、優先度、再発防止）を回す

OTLP と Fluent Bit の位置づけ（混同しやすいポイント）

Observabilityの議論で混同されやすいのが、OTLP と Fluent Bit です。
両者は競合ではなく、役割が違います。

  • OTLP（OpenTelemetry Protocol）
    • OpenTelemetryのテレメトリ転送プロトコル
    • 主に SDK/Collector/Backend 間でメトリクス・ログ・トレースをやり取りする共通仕様
    • ツールというより、配線のルール
  • Fluent Bit
    • 軽量なログ/イベント収集・転送エージェント
    • ログ収集・変換・フィルタ・転送に強い
    • レイヤで言えば Collector/Agent（レイヤB）の実装

実務での使い分け

  • トレース/メトリクス中心で統一したい
    OTel SDK + OTel Collector + OTLP を軸にする
  • ログ経路を軽量に強化したい
    Fluent Bit をログ収集に使い、必要なら OTel Collector やBackendへ中継する
  • ハイブリッド構成
    アプリ計測は OTel（OTLP）、ノード/コンテナログは Fluent Bit という分担が現実的

覚え方としては、**OTLPは「プロトコル」、Fluent Bitは「収集エージェント」**です。

配線図（概念）

設計のコツ（ツールに依存しない）

1) 相関できない観測データは「ただの断片」

ログ、メトリクス、トレース、エラーが 同じリクエスト/同じユーザー/同じデプロイ を指せないと調査が遅くなります。

  • 必須: trace_id（トレースID）や request_id の伝搬・出力
  • 推奨: service.name / environment / version（デプロイ識別）を統一タグとして付与

2) 粒度（Cardinality）でコストと検索性が決まる

  • メトリクスは高カーディナリティ（ユーザーID、リクエストIDなど）に弱い
    → 集計が爆発してコスト/性能が悪化しやすい
  • ログ/トレースは高カーディナリティに向くが、量が増える
    → 取りすぎると保存/検索コストが跳ねる

結論として、だいたい次の住み分けが安定します。

  • Metrics: 低〜中カーディナリティ（status_code、route、region 程度）
  • Logs/Traces: 高カーディナリティ（具体的なリクエスト、ユーザー、エラー詳細）

3) サンプリングは「後で効く」設計要素

トレースは全量取ると高コストになりやすいので、設計として以下を分けると強いです。

  • ヘッドサンプリング: 入口で間引く（コストに優しいが、欲しい事象を落とす可能性）
  • テイルサンプリング: 結果を見て残す（エラーや遅延だけ残すなど、調査に強い）

4) 「まず揃えるべき」最小セット（おすすめ）

いきなり全部やるより、まずは次の順が失敗しにくいです。

  1. SLIの決定（例：エラー率、p95レイテンシ、可用性）と、最低限のアラート
  2. 重要パスだけトレース（入口と主要依存先が辿れる程度）
  3. ログに相関IDを付与（トレースID/リクエストIDで辿れる）
  4. エラー運用（例外の集約、影響範囲、再発防止のテンプレ）

ありがちな採用パターン（概念だけ）

ツール名ではなく「構成の型」として捉えると選び替えが簡単です。

  • パターンA：単一プラットフォーム集約型
    収集→保管→可視化→アラートを一つの場所に寄せる（運用は軽くなる）
  • パターンB：クラウドネイティブ完結型
    クラウド標準の監視基盤で完結させ、必要に応じてエラー運用だけ別に強化する
  • パターンC：配線（Collector）で分岐するハイブリッド型
    同じ計測で複数宛先に送り、段階的移行や比較検証をしやすくする

URL集（概念 / 仕様 / 代表的な実装）

概念（考え方）

仕様（相関・伝搬）

共通配線（ベンダーに依存しにくい）

代表的な実装（例：保管・可視化）

ここは「例」です。採用は要件と運用体制で決めるのが本筋です。

エラー運用（例外・クラッシュ）

RK

1997年生まれ

ITエンジニア

インフラ・SRE

Observability入門：概念で整理する（計測→収集→保管/可視化→運用）