ロギングは今日のアプリケーションに不可欠なコンポーネントだ。OpenTelemetry（OTel）は、ツール、API、SDKのコレクションで構成されるオープンソースのオブザーバビリティフレームワークで、プロジェクト内で利用可能なもう1つの "シグナル "としてロギングを安定させた。他のOTel シグナルには、トレース、メトリクス、バゲージがある。
OpenTelemetry ロギングは、以下のような従来のロギングへの改善を提供する。
- オブザーバビリティデータの共通エージェントの共有
- テレメトリーシグナル間のコンテキスト伝播による相関の拡張
- 一般的に観測される概念、プロトコル、操作のセマンティック規約を活用する。
- OTelプロトコルを使用することで、オーバーヘッドされるロギング計算を削減する。
さらに、OpenTelemetry メトリクスとトレースで取られたアプローチとは異なり、クリーンシートのアプローチが使用され、OTel Logging は、既存のロギングフレームワークとライブラリとうまく動作することを第一級の関心事としている。
"我々は、OpenTelemetry Loggingが1.0に到達したことを発表する" OpenTelemetryの共同開発者であるMorgan McClean氏は、今月初め、KubeCon NA 2023でそう語った。McClean氏は、これが何を意味するのかを説明した。"ロギングに関しては、コア機能はかなり前からあった（様々な機能強化が行われ、ほぼ2年）。今変わったのは、[OpenTelemetry Logging]も安定したと宣言されたことだ。さらに、コンフィギュレーションは変わらない。"
OpenTelemetry Loggingは、4つのコアコンポーネントで構成されている。コンポーネントは、テレメトリ・ソース間のテレメトリ・データのエンコーディング、トランスポート、デリバリー・メカニズムを記述するプロトコル、ログのバックエンドAPIであるLogs Bridge API、ユーザーがOTelとやりとりするためのOpenTelemetry APIの実装であるLogs SDKである。
これら3つのコンポーネントは現在、"stable" （OpenTelemetryがコンポーネントの成熟度を示すために使用するコアの状態）とマークされている。4番目のコンポーネントであるイベントAPIは、ログレコードを発行し、イベントのセマンティック規約に適合させる。既存のログフレームワークから OpenTelemetry にログをブリッジするアペンダーを書くことを可能にし、エンドユーザー向けに設計されていない Log Bridge API とは対照的に、Event API はエンドユーザーによって呼び出されることを意図している。これはまだ実験段階であり、活発に開発中だ。
OTel コンポーネントは、Draft、Experimental、Stable、Deprecated、そして Removed のタグを含む開発ライフサイクルに従う。
- Draftコンポーネントは設計中であり、仕様には追加されていない。
- Experimentalコンポーネントはリリースされ、ベータテストが可能である。
- Stableコンポーネントは、後方互換性があり、長期サポートの対象である。
- Deprecatedコンポーネントは安定しているが、いずれ削除(Removed)される。
OpenTelemetryは、分散システム間でデータを相関させるための共有メカニズムであるコンテキスト伝搬の上に、単一のエージェントでコアなオブザーバビリティの計測ツール（ログ、メトリクス、トレース）を収集できるようになった。典型的なオブザーバビリティ収集シナリオでは、ロギングは別個に行われ（通常、ファイルのOSコレクションとFluentBitのようなエージェントを使用）、トレースは別のエージェント（Jaegerエージェントのような）を使用し、メトリクスはしばしば別のもの（OpenCensusエージェントのような）である。OTel Logging を追加することで、OpenTelemetry Collector はこれらのソースのそれぞれを収集することができ（追加的な名前/値のペアデータのための Baggage と呼ばれる4つ目のソースとともに）、それぞれをサポートする仕様のデータモデルに支えられている。
共通のコレクターを活用することで、ログを残りのオブザーバビリティデータと相関させることができ、トレース、メトリクス、ログの相互運用性を高めることができる。さらに、すべてのインスツルメンテーションが同じセマンティック規約を共有することで、HTTPリクエストのような共通のオペレーションを観測する際に、シグナルが同じデータを生成することを保証する。
「他の利点の1つは、ログを取得するには比較的計算コストがかかることです」とMcClean氏は言う。「ロギングエージェントは、人々が思っている以上にCPUを使う傾向があり、第二に、ログは乱暴な方法でフォーマットされる傾向がある。
新しいCPU負荷の低いログ収集アプローチと定義されたログ・データ・モデルは、これらの懸念に対処することを目的としている。適用可能な言語とフレームワークについては、自動計測か、OpenTelemetryログアペンダーを使用するためのロギングライブラリの単純なコンフィギュレーションが、コンテキストに富んだログを出力し、収集のための摩擦の少ないパスを提供する。新しいファーストパーティアプリケーションログに加えて、OpenTelemetry ロギングは、システムログ、インフラログ、サードパーティアプリケーションログ、レガシーファーストパーティログ、ファイル/stdout ログ、コレクターへの直接アクセスを含む、レガシーと最新のログソースをサポートする。
/filters:no_upscale()/news/2023/11/otel-logging-stable/en/resources/1application-api-sdk-1700684960145.png)
OpenTelemetryは、Cloud Native Computing Foundation (CNCF)がOpenTracingとOpenCensusプロジェクトを統合したときに作られたオープンソースのオブザーバビリティフレームワークだ。OpenTelemetryは、利用可能な信号のセットを通して遠隔測定データを統一するというビジョンを持っている。CNCFプロジェクトの中で2番目に活発なプロジェクトである。