# 構造化イベント ## 定義 構造化イベント(structured event)は、ネストしたフィールドを持たない、キーと値のペアの集合として表現できるイベントである。JSONオブジェクトとして可視化でき、メトリクス・ログ・トレースというオブザーバビリティの三本柱(three pillars)はいずれもこの単一のデータ型として表現・保存できる。メトリクスは「集計済みの構造化イベント」、構造化ログは「タイムスタンプとメッセージを持つ構造化イベント」、トレーススパンは「トレースID・スパンID・親IDで相互接続された構造化イベント」とみなせる。事前にどのデータ型(集計済みメトリクスか、構造化されていないログか)として保存するかを決め打ちすることは、後の調査で問える質問の範囲を事前に制約してしまう。構造化イベントを単一の下部構造(substrate)として保持しておけば、メトリクス・ログ・トレースのいずれの見方(view)も、調査のたびに事後的に(post-decide)導出できる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 5 Structured Events Are the Building Blocks of Observability]] "What Is a Structured Event?", "Dynamically Generating the Right System Views") ## 横断的知見 - **「ワイドイベント」パターンは長時間非同期ジョブのトレース設計の代替解として第7章で再登場する**: 第5章は構造化イベントを「メトリクス・ログ・トレースを事後に導出できる単一の下部構造」として理論的に位置づけたのに対し、第7章はこれを実務的なトレードオフの解として使う。夜間ETLのような数時間〜数日にわたる長時間ジョブでは、各ステージを直接の子スパンにすると「百万個の子スパン」問題を招く。安全網が目的で細粒度の性能最適化が目的でない場合、第7章は「単一の要約スパン(または構造化ログイベント)に、成功・失敗・理由を含む数百〜数千の属性を持たせてジョブ完了時に書き出す」というワイドイベントアプローチを推奨する。これは第5章の「型を決め打ちしない」という理論的動機とは別に、「トレースストアの多くは既存スパンへの更新を扱えない」という実装制約への実務的回避策として同じパターンが導かれた例であり、理論的な望ましさと実務上の必要性の両方からワイドイベントパターンが支持されることを示す。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 5 Structured Events Are the Building Blocks of Observability]], [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]]) - **第6章は「幅広さ」の抽象的な望ましさを、22カテゴリ・数百属性の具体的なカタログへ翻訳する**: 第5章は「事前にデータ形状を決めない」という理論的動機を示すにとどまり、実際にどれだけの属性を1つの構造化イベントへ載せるべきかは示さなかった。第6章はサービス・コードコンテキスト、ビルド情報、HTTP・ルート・タイミング、ユーザー・ビジネスコンテキスト、運用情報という6分類・22表にわたる具体例を通じて「十分に計装されたコードベースでは典型的に数百の属性が存在する」ことを実証し、第5章が理論として提示した「単一の幅広い構造化イベント」の実務的な中身を埋める関係にある。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 5 Structured Events Are the Building Blocks of Observability]], [[@2026__OReilly__Observability Engineering 2E - Chapter 6 Making Structured Events Arbitrarily Wide]]) - **モバイル領域は「幅広く構造化されたイベント」を、後から任意のビュー(メトリクス・セッションリプレイ)を導出するための下部構造としてさらに徹底した形で使う**: 第5・6章はサーバーサイドの文脈で「事前にデータ形状を決め打ちしない」という利点を論じたのに対し、第19章はモバイルのディスク永続化された循環バッファそのものを「任意に幅広い構造化イベント」の集合として設計し、サーバーからの指示(リアルタイム制御プレーン)に応じて、圧縮メトリクスとしても、セッションリプレイ全体としても事後的に(post-decide)導出できるようにする。制約(帯域・ストレージコスト・端末リソース)がサーバーサイドより厳しいモバイルでこそ、構造化イベントを単一下部構造として持つ設計思想がより強い必然性を持って現れる例といえる。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 5 Structured Events Are the Building Blocks of Observability]], [[@2026__OReilly__Observability Engineering 2E - Chapter 19 Observability for Mobile and Frontend]]) ## 未解決の問い - 構造化イベントを単一の下部構造として保持する設計は、ストレージコストと保持期間の面でメトリクス専用ストア(TSDB)や構造化ログ専用ストアと比べてどの程度不利になるか。**第6章は数百属性規模のワイドイベントを推奨する一方でストレージコストには一切言及していない**ため、この問いは未解決のまま残る。 - 「構造化イベントからP99等のメトリクスを事後導出する」アプローチは、リアルタイム性が要求されるアラート(秒〜分単位のバーンレートアラート等)にどこまで適用できるか。ストリーミング分位点スケッチとの併用が前提になるのか、常時ストリーミング集計が必要になるのかは本章内では詳述されていない。 - OpenTelemetryの「メトリクス」「ログ」「トレース」という3つの独立したシグナル種別(Signal)の設計は、本章が主張する「単一の構造化イベント」思想とどこまで整合するか、あるいは実装上の歴史的制約による分離なのか。 - 第7章のワイドイベントは「ジョブ完了時に書き出す単一要約」だが、第5章の構造化イベント思想は本来イベント単位(リクエスト単位)の粒度を想定する。ジョブ全体を1イベントに集約する粒度の選択は、どの条件で「粒度が粗すぎて調査に使えない」問題に転化するか。 - 第6章は`main`属性で「ワイドイベントとして設計されたスパン」を識別する慣習を提示するが、この慣習をチーム全体・複数サービス間でどう強制・レビューするか(lintルール化は可能か)は本章では扱われない。 ## 関連 - 概念: [[オブザーバビリティ]] / [[テレメトリ]] / [[分散トレーシング]] / [[ヒストグラムメトリクス]] / [[フィーチャーフラグ]] / [[モバイルオブザーバビリティ]] - ソース: [[@2026__OReilly__Observability Engineering 2E - Chapter 5 Structured Events Are the Building Blocks of Observability]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 6 Making Structured Events Arbitrarily Wide]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 7 Instrumenting Your Code with OpenTelemetry]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 19 Observability for Mobile and Frontend]] - エンティティ: [[OpenTelemetry]] / [[Jeremy Morrell]] ## 出典 - Charity Majors, Liz Fong-Jones, George Miranda, with Austin Parker, *Observability Engineering*, 2nd Edition, O'Reilly Media, 2026, Chapter 5・Chapter 6(Jeremy Morrell 主要寄稿)・Chapter 19。