日本語翻訳:

Charity Majors は、可観測性について「大量の混乱」が生じているとし、これは堅固な分類への過度な依存によって引き起こされていると論じます。具体的には、OpenTelemetry がデータをトレース、メトリクス、ログに強制的に分け、六十語を超える複雑な用語集を採用している点を指摘しています。彼女は、この断片化されたアプローチを置き換えるよう提唱し、「ワイドイベント（Wide Event）」モデル（Meta の Scuba システムに着想を得たもの）を導入することを提案します。このモデルでは、すべてのコンテキストが包括的な JSON ログのような単一の柔軟なドキュメントに記録されます。この手法により、エンジニアは事前定義されたフィールド定義や従来の用語集に依存せず、「未知の未知」を調査できます。Majors は、従来のカテゴリであるトレースやメトリクスはワイドイベントの特別なケースに過ぎると主張し、ユーザーがデータを自由に探索できるようにし、運用の複雑性を削減し、予期せぬ問題の効果的なデバッグを可能にするとしています。

可視性（Observability）の混乱を解く：OpenTelemetry vs. ワイドイベント

チャーリー・メイズ氏による引用は、現代のテクノロジー業界における可視性の現状を的確に捉えています。単なる混乱ではなく、大規模な混沌です。「トレースとは何か？」「ログとスパンの関係は？」といった疑問が尽きません。OpenTelemetry（OTel）などのオープンソース規格こそが、この混乱の主要な要因である可能性が高いのです。優れたツールである OTel は、しかし使い方の解説やプレゼンテーション方法が可視性を複雑化・困難化させていると指摘されています。

OpenTelemetry のアプローチ：過度な構造化と学習コスト

OpenTelemetry は当初から「トレース」「メトリクス」「ログ」という明確な区別を設け、以下のような複雑な用語体系を定義しています。

API、SDK、ツールのコレクションとして機能します。
インストルメンテーション（計測器の設定）、生成、収集、エクスポートを管理します。
60 を超える専門用語（スパン、ルートスパン、ネステッドスパンなど）で構成される語彙リストが存在します。

このアプローチの問題点

可視性を「聖域化」しすぎており、学習コストが高く設定されています。
「トレース」「メトリクス」「ログ」という3 つの柱に焦点が当たりすぎています。
分散システムにおける重要な要素である「データの掘り下げ」「切り分け分析」「相関付け」「異常検出」をカバーする視点が不足しています。

対案：Meta の Scuba と「ワイドイベント（Wide Event）」

以前 Meta で使用されていた可視性システム「Scuba」は、複雑な用語体系に頼らずシンプルで強力なアプローチを採用していました。

ワイドイベントの基本概念

定義: JSON ドキュメントと同様に、名前と値を持つフィールドのコレクション。
哲学: システムの状態、API 呼び出し、背景ジョブなどの「事実」を記録する際に、可能な限り多くの情報を含める（Wide）。
メリット: 「未知の未知（unknown unknowns）」への対処が可能になります。今考えられないが、インシデント調査で役立つ情報を後で使用できます。

実装例：広告インプレッション

単なる「表示回数」だけでなく、コンテキストを全て記録します。

{
    "Timestamp": "1707951423",
    "AdId": "542508c92f6f47c2916691d6e8551279",
    "UserCountry": "US",
    "Placement": "mobile_feed",
    "CampaignType": "direct_ads",
    "UserOS": "Android",
    "OSVersion": "14",
    "AppVersion": "798de3c28b074df9a24a479ce98302b6",
    ...
}

スクーバの強力な機能

1. ネイティブサンプリングと自動補正

イベント記録時に
```
samplingRate
```
フィールドを同様に保存します。
UI はこの情報に基づき、結果を自動的にアップスケーリング（補正）して表示します。
ユーザーはクエリ計算を気にする必要がありません。

2. 自由な探索と切り分け（Slice and Dice）

初期の直感的な分析後、フィルタリングやグループ化によって問題を特定できます。
- ```
CampaignType
```
  でグループ化 → 異常を検出
- ```
UserOS
```
  で絞り込み → クライアントサイドの問題へ到達
- ```
AppVersion
```
  でさらに詳細化 → 特定のバージョンで不具合が発生していることを発見
事前集約を行わないため、カルディナリティ（一意な値の組み合わせ数）を気にする必要がありません。
すべてのフィールド（関数、フィルタなど）が探索可能であり、詳細な説明が付いています。

3. ワイドイベントと「3 つの柱」のマッピング

Scuba のメンタルモデルを OTel に置き換えると以下のような関係性が浮かび上がります。

トレースとスパン
- 単なるワイドイベントであり、
```
SpanId
```
  、
```
TraceId
```
  、
```
ParentSpanId
```
  フィールドを持っています。
- これらをフィルタリングしソートすることで、分散トレーシングビューを再構築できます。
ログ
- OpenTelemetry の「ログ」は構造化されたワイドイベントの一つです。
- ```
logger.info(…)
```
  型の呼び出しに加え、動的なテンプレート抽出やハッシュ化によるグループ化も可能です。
メトリクス
- 一定間隔でシステム状態を含むワイドイベントを連続的に発射するだけです。
- Prometheus のスクレイピングアプローチと同様に機能しますが、カルディナリティ制限がなくなります。

ワイドイベントの追加価値

「3 つの柱」だけではカバーできない領域も存在します。

継続的プロファイリング: フレイムグラフ生成を含む単一のシステムで実現可能。
クロス相関付けと根本原因分析: 全てのデータが同じ場所で保存されるため、AI ツールとの親和性が高く、データ内の相関発見に優れています。

結論：シンプルさと探索性が重要

可視性の本質は、「ログ？トレース？メトリクス？」という分類や、60 の用語を暗記することではありません。 **「ものを自由に探索し、文脈を持ったデータを収集し、未知の現象に対応できること」**です。

混乱への対応: OpenTelemetry などの複雑なメンタルモデルから脱却する必要があります。
理想の姿: Scuba のような、「ワイドイベント」という単一基盤で、トレース・ログ・メトリクス・プロファイリングをすべて自然にカバーできるシステムです。
期待: Honeycomb や Axiom などのベンダーが、シンプルで自然な対話を提供する方向に進化することを願っています。

「未知の未知」に対処するためには、単一の基盤であるワイドイベントが不可欠です。

「計測指標・ログ・トレース」ではなく、すべてに必要なのはワイドイベントだけです