> Source: https://www.ymotongpoo.com/works/oteps/logs/otep-0092/


# OTEP-0092: OpenTelemetryログビジョン

以下は、OpenTelemetryプロジェクトにおけるログサポートの長期的なビジョンを定義する、私たちが達成したいと望む高レベルの項目です。

これは、私たちの現在の願望を反映したビジョンドキュメントです。
記載されている内容をすべて正確に実装するというコミットメントではありません。
このドキュメントの主な目的は、すべてのコントリビューターが足並みを揃えて作業できるようにすることです。
私たちのビジョンは時間とともに変化するため、メンテナーはこのドキュメントの項目を追加・変更・削除する権利を留保します。

このドキュメントでは、<https://github.com/open-telemetry/oteps/pull/91> で導入された語彙を使用します。

## First-class Citizen {#first-class-citizen}

ログは、トレースやメトリクスとともに、オブザーバビリティにおけるファーストクラス市民です。
私たちは、OpenTelemetryにおいてログの最高水準のサポートを実現することを目指します。

## Correlation {#correlation}

OpenTelemetryは、ログがどのようにトレースやメトリクスと相関付けられるか、そしてこの相関情報がどのように保存されるかを定義します。

相関は、2つの主要な次元にわたって機能します。

- 同一のリクエストに対して発行されたテレメトリーを相関付けること（Request CorrelationまたはTrace Context Correlationとも呼ばれます）。
- 同一のソースから発行されたテレメトリーを相関付けること（Resource Context Correlationとも呼ばれます）。

## Logs Data Model {#logs-data-model}

私たちは、あらゆる種類のログを正しく表現することを目指したLog Dataモデルを設計します。
このデータモデルの目的は、ログレコードとは何か、ロギングシステムによって記録・転送・保存・解釈される必要があるデータは何かについて、共通の理解を持つことです。

既存のログフォーマットは、このデータモデルに一意にマッピングできます。
対象のログフォーマットが同等の能力を持つ範囲において、このデータモデルからの逆マッピングも可能です。

私たちは、一般的に使用されるログフォーマットに対するマッピングの推奨事項を作成します。

## Log Protocol {#log-protocol}

Log Dataモデルを武器に、私たちはログのための高性能なプロトコルの設計を目指します。
このプロトコルは、トレースおよびメトリクスのプロトコルで採用したのと同じ[設計目標](https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/design-goals.md)を追求します。

とりわけ、このプロトコルは高い信頼性を持ち、リソース消費が少なく、すべての参加ノードに適しており、高いスループットを確保し、バックプレッシャーのシグナリングを可能にし、ロードバランサーフレンドリーであることを目指します（詳細は上記の設計目標へのリンクを参照してください）。

このように設計する理由は、単一のOpenTelemetryプロトコルによって、1つの接続でログ・トレース・メトリクスを配送し、すべての設計目標を満たせるようにするためです。

## Unified Collection {#unified-collection}

私たちは、ログ・トレース・メトリクスの3種類すべてのテレメトリーデータを、対称的かつ均一に1つのパッケージでサポートする、高性能で統合された[Collector](https://github.com/open-telemetry/opentelemetry-collector/)を実現することを目指します（[Collectorのビジョン](https://github.com/open-telemetry/opentelemetry-collector/blob/8310e665ec1babfd56ca5b1cfec91c1f997f4f2c/docs/vision.md)も参照してください）。

統合されたCollectorは、新しく設計されるOpenTelemetryログプロトコルを含む複数のログプロトコルをサポートします。

統合収集が重要である理由は、以下のとおりです。

- デプロイ・管理すべきエージェント（またはコレクター）が1つで済むこと。
- 送信先エンドポイントや認証トークンなどの設定箇所が1か所で済むこと。
- 3種類すべてのテレメトリーデータに対する均一なタグ付け（データの発生元であるリソースの属性、またはユーザー定義の属性によるエンリッチメント）が可能になり、これによって後段のバックエンドでリソース次元にわたる正しい相関付けが実現できること。

## Cloud Native {#cloud-native}

私たちは、そのような環境で動作するレガシーアプリケーションを含め、クラウドネイティブ環境（Kubernetesやサーバーレスなど）で発行されるログに対して、最高水準のサポートを提供します。
これは、私たちのCNCFのミッションに沿ったものです。

## Support Legacy {#support-legacy}

私たちは、レガシーアプリケーションがOpenTelemetryのアプローチと互換性を持ち、テレメトリーデータの相関付けを可能にする方法でログを発行できるようにするためのガイドラインを作成します。
また、私たちが制御できないソースから、あらかじめ定められたメディア（フラットファイルログやSyslogなど）を介して、あらかじめ定められたフォーマットで発行されるログについても、合理的な方針を用意します。

私たちは、広く使われているロギングライブラリをOpenTelemetryと互換性のある方法で使用するための技術的なソリューションやガイドラインを用意し、ギャップが存在する言語についてはロギングライブラリを作成することもあります。

これが重要である理由は、OpenTelemetryが登場する前に作られたソフトウェアを軽視すべきではなく、可能な限りOpenTelemetryの取り組みから恩恵を受けられるべきだと、私たちは考えているからです。

### Auto-instrumentation {#auto-instrumentation}

ログの発行方法の変更を必要とする機能を実現するために、私たちは自動計装のソリューションに取り組みます。
これにより、既存のデプロイメントにおける採用の障壁が下がります。

### Applicable to All Log Sources {#applicable-to-all-log-sources}

OpenTelemetryにおけるロギングのサポートは、システムログ、インフラストラクチャログ、サードパーティおよびファーストパーティのアプリケーションログなど、あらゆる種類のログソースに適用可能です。

### Standalone and Embedded Logs {#standalone-and-embedded-logs}

OpenTelemetryは、[Span](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#span)の内部に埋め込まれたログと、それ以外の場所に記録されるスタンドアロンなログの両方をサポートします。
埋め込みログのサポートは、エラーや例外をSpanに埋め込む必要がある、OpenTelemetryの主要なユースケースにとって重要です。
スタンドアロンログのサポートは、Spanをまったく発行しない可能性があるレガシーアプリケーションにとって重要です。

## Legacy Use Cases {#legacy-use-cases}

ロギング技術には、数十年にわたる歴史があります。
ロギングライブラリ、収集エージェント、ネットワークプロトコル、オープンソースおよびプロプライエタリなバックエンドが、数多く存在します。
私たちはこの事実を認識しており、正当なレガシーのユースケースを尊重しつつ、必要な箇所ではより良いソリューションを提案するという方針で、提案を行うことを目指します。