OpenTelemetryロギング：概要

OTelロギングは、元の意味を維持しながら、さまざまなソース、システム、形式のログ・データを言語に依存しない単一のモデルに変換するための、統一的で明確なマッピング構造をITチームに提供します。

ベンダーにとらわれない構造化されたデータモデルにより、オブザーバビリティーツールは、より簡単かつ確実にログを解析し、メタデータを添付し、深いエンドツーエンドの可視化のためにログをメトリクスやトレースと相関させることができます。

OTelロギングを使用すると、企業がITアーキテクチャ全体を再計測することなくオブザーバビリティー・バックエンドを切り替えて混在させることが可能で、それが最新のクラウドネイティブなシステムにおける計測の業界標準となった理由です。これらの機能により、ITチームやサイトの信頼性エンジニア（SRE）は、すべてのベンダー、スタック、デバイスが独自のロギングスキーマや伝送プロトコルを持つ場合に発生するオブザーバビリティーのギャップやデータの断片化の問題を回避することができます。

OTelロギングは信号間の自動相関も促進するため、デバッグが劇的に改善され、オブザーバビリティーのベンダー・ロックインが軽減されます。

OpenTelemetryログは、OpenTelemetryの重要なコンポーネントです。OpenTelemetryは、ソフトウェア開発キット（SDK）、ベンダーに依存しないアプリケーション・プログラミング・インターフェース（API）、および、アプリケーション、システム、デバイス計測のための他のツールのコレクションを含む、オープンソースのオブザーバビリティー・フレームワークです。

かつて、インストルメンテーション・コードはさまざまに異なっており、ネットワーク上のすべてのアプリやサービスからデータを収集できるツールを提供する単一の商用プロバイダーは存在しませんでした。この機能のギャップにより、チームはさまざまなプログラミング言語、形式、ランタイム環境からデータを収集することが困難（多くの場合、不可能）になっていました。

また、従来のオブザーバビリティーのアプローチでは、バックエンド・インフラストラクチャーとコンポーネントの変更が、時間と労力がかかるプロセスになっていました。

例えば開発部門がバックエンド・ツールを入れ替えたいという場合、コードを全面的に再実装し、新しいエージェント（ビルドとリリースのタスクを自動で実行するソフトウェア・コンポーネント）を構成して、テレメトリー・データを新しいサーバーに送信する必要があります。断片化されたアプローチはデータのサイロ化と混乱を生み出し、性能の問題を効果的に解決することを困難にしていました。

OpenTelemetryは、テレメトリー・データを収集、分析、バックエンド・プラットフォームに送信する方法を標準化したため、オブザーバビリティーに大きな進歩をもたらしました。システムの動作とセキュリティーに関するデータを収集するための、コミュニティー主導の標準に基づくオープンソース・ソリューションを提供し、チームが分散型エコシステムにおける監視とオブザーバビリティーを効率化するのを支援しました。

OpenTelemetryロギングは、統合されたオブザーバビリティー・パイプラインの一部としてログ・レコードを作成・構造化・転送・配信する複数の連携コンポーネントに依存しています。主なポイントは次のとおりです。

ログ・レコードは、OpenTelemetryの単一のログ・イベントを表す中央データ構造です。フィールドとセマンティクスを定義する標準データ・モデルに従っているため、さまざまな言語やシステムのログをバックエンドで一貫して解釈できます。

ログ・レコードはスプレッドシート内の構造化された行のように表示され、1つのイベントを説明し、「何が起こったか」「いつ起こったか」「どれだけ重要か」「どこから来たのか」といった基本的な質問に答えます。

ログ・データ・モデルは、言語やシステムを問わず、すべてのレコードが従う共通のテンプレートです。これにより、どの最上位フィールドが存在し、それぞれのフィールドが何を意味するのかを定義します。

一般的なログ・データ・モデルでは、レコードに以下が含まれている必要があります。

• タイムスタンプと観察されたタイムスタンプ（イベントがいつ発生したか、いつそれが確認されたか）

• イベントの重大度レベルを説明する重大度の数値と重大度テキスト（別名ログ・レベル）

• 本文（メインログ・メッセージ、多くの場合、短い文字列またはJSONオブジェクト）

• 各イベントに関するより詳細な情報（ユーザーやHTTPの詳細など）を追加する属性

• 発生しているサービスおよびデプロイメント環境を識別するリソース情報

• イベントを特定のリクエストにリンクするトレースIDとスパンID（データ相関を簡素化）

データ・モデルが課す構造により、異なるサービスやテクノロジーのログが、オブザーバビリティー・パイプラインに入ったときに同じように動作する、豊富でクエリー可能なテレメトリー・エンティティーに変わります。ログ・データ・モデルを使用すると、ITチームはログとトレースを関連付け、サービスまたはユーザーごとにグループ化し、IT環境全体で同じ種類のクエリを実行できるようになります。これにより、互換性のないログ形式を数多く扱う必要がなくなります。

また、ログ・モデルはオープンでコミュニティー主導であるため、OTelのインストルメンテーションとログ・パイプラインは移植性が高くなります（単一のSoftware-as-a-Service（SaaS）製品や独自のエージェントに縛られることはありません）。フレームワークとプラットフォーム間で動作するため、多言語のマイクロサービス環境では特に価値があります。

ロガーは、他のロギング・フレームワーク（JavaやPythonなど）のロガー・インスタンスと同様に、ログ・レコードを記述するオブジェクトです。オブザーバビリティー・プラットフォームが「このエラーをログに記録」または「この情報メッセージをログに記録」コマンドを送信すると、そのメッセージがロガーに送信されます。

アプリケーションやシステムの異なる部分で独自のロガー（例えば、「チェックアウト」用と「支払い」用）を要求することもできますが、ログの生成に関してはすべて同じルールに従います。

ロガーは、ロガーを作成し、適切なパイプライン、属性、エクスポーターで構成する役割を担うロガー・プロバイダーから取得されます。ソフトウェア・コードがロガーを要求すると、すでに適切に構成済みのロガーがプロバイダーから提供されます。

この設計により、システムのさまざまな部分で、共通の構成を共有しつつ、すべてロガー・プロバイダーによって一元管理されるさまざまなロガーを使用できるようになります。また、ITチームがすべての呼び出しサイトを変更することなく、実装を交換し、ロギング動作をグローバルに調整することが容易になります。

OTel Collector は、多数のソースからの（ログレコードを含む）テレメトリデータを受信、処理、およびエクスポートする独立したサービスです。アプリケーションは、ログ（およびトレースとメトリクス）をコレクターに送信します。コレクターはさまざまな形式のデータを受信し、それを標準化し、1つ以上のバックエンドに送信できます。

コレクターは、レシーバー、プロセッサー、エクスポーターという3つの主要サブコンポーネントを中心に構築された専用のログ・パイプラインをサポートします。

レシーバーは、OpenTelemtetry Protocol（OTLP）ストリームやファイルテーリング・レシーバーからのログファイルなど、さまざまなインプットからログを取り込みます。プロセッサーは、バッチ処理、属性変更、コンテキスト・エンリッチメント（Kubernetes ポッド・メタデータの追加など）、フィルタリング、ログ・レコードでのサンプリングなどのオペレーションを実行します。その後、コレクター内のエクスポーターは、処理されたログを1つ以上の宛先に転送します。

ログ・レコード・エクスポーターは、OTelコレクターまたはアプリケーションSDK内に配置され、テレメトリー・データをバックエンド・システムに配信する場所と方法を定義します。

Logs SDKがログ・レコードを作成して処理した後、エクスポーターがログ・データ・モデルを特定のプロトコルまたは形式にエンコードし、レコードを下流の「コンシューマー」に送信します。コンシューマーには、OTelコレクター、オブザーバビリティー・ソリューション、オープンソース・ストアなどがあります。

エクスポーターはプッシュベースまたはプルベースにすることができ、それらを交換して結合することで、アプリケーション・コードを変更することなく、同じログ・レコードを異なるバックエンドに同時に送信できます。エクスポーターが提供する柔軟性により、企業は要件の変化に応じてオブザーバビリティー・アーキテクチャーを簡単に進化させることができます。

Logs APIとLogs SDKは、電源タップのコンセントのような形で機能します。APIはコンセントの型で、SDKが電力を伝送する電源タップです。

OpenTelemetry APIは、統一されたログ・エントリーを作成するために、コード・ライブラリーとロギング・ライブラリーが呼び出す一連の関数を構成しています。基本的に、Logs API は、ログが OTel に「プラグイン」されるために必要な「形状」を決定します。Logs APIを使用すると、ITチームが後でどのオブザーバビリティー・バックエンドやベンダーを選択しても、同じAPI呼び出しが機能することが保証されます。

ただし、APIは単なるインターフェースにすぎません。ログの送信先や送信方法を決定できません。ここでOpenTelemetry SDK、またはLogs SDKの出番です。

Logs SDKはAPIエンドポイントからログを取得し、それらに対し実際の作業を行います。ログレコードを受け取り、（サービス名や環境を追加するなどして）情報を充実させ、バッチ処理して出力の準備をします。次に、エクスポーターを使用して、処理されたログをコレクターまたはログ・プラットフォームに送信します。

ログ・アペンダー（別名、ログ・ブリッジ）は、既存のロギング・ライブラリー（Log4j、SLF4J、同様のフレームワークなど）をOpenTelemetryログ・データ・モデルに接続します。

ソフトウェア開発者は、Logs APIを直接呼び出す代わりに、既存のロギング・フレームワークを構成すれば、従来の各ログ・イベントをOTelログ・レコードに変換するアペンダーを使用できます。

ログ・ブリッジは、ログ・レコードにスパンとトレースのコンテキストを挿入することもできるため、アプリケーション・コード自体がトレースの詳細を認識していない場合でも、ログとトレースの相関付けが可能になります。

コンテキスト伝播と相関のメカニズムは、OpenTelemetryロギングの重要なコンポーネントです。トレース・スパンがアクティブな場合、ロギング・ブリッジまたはSDKは、現在のトレースIDとスパンIDを、出力される各ログ・レコードに自動的に追加できます。

相関関係は、オブザーバビリティーのバックエンドが、同じリクエストまたはワークフローを表す分散トレースとログを結び付けるのに役立ちます。これらの接続により、チームは問題のあるログ・エントリーからリクエストのフルパスを示すトレースに直接移動できます。また、共通のリソースとコンテキストフィールドを共有するメトリクス、トレース、ログのクロスシグナル分析も容易になります。

OTelでは、構造別、ソース別、エンコードまたは伝送プロトコル別など、いくつかの異なる方法でログの「種類」について表現されます。

構造化ログには一貫したスキーマ（同じフィールド、安定した名前とデータ型）があるため、オブザーバビリティー・ツールは信頼性のある解析とクエリーを実行できます。ログはJSONや他の形式でエンコードされる場合がありますが、予測可能なデータ・フィールドのセットによりログが構造化されます。

半構造化ログには、認識可能な構造（キーと値のペアやJSONのようなblobなど）が含まれていますが、そのスキーマは時間の経過とともに一貫性を保ちません。これらは、自由形式のテキストよりも機械で読みやすいものですが、チームが効果的に分析するには、追加の解析と正規化が必要です。

非構造化ログは、安定したスキーマを持たない（アドホックなPrintステートメントやプレーン・テキストのサーバー・ログなど）自由形式のテキスト・メッセージです。人間が書いたり読んだりするのは簡単ですが、自動化されたシステムが検索、相関付け、集約を行うには、大規模な追加解析が必要です。

システムおよびインフラストラクチャのログは、アプリケーションコードではなく、オペレーティングシステム、ネットワーク・デバイス、クラウド・インフラストラクチャー・サービス、その他のラットフォームコンポーネントによって生成されます。これらは、OSエラー、ネットワークの問題、インフラステータスなどのイベントをキャプチャーし、基盤となる環境のヘルスや性能をチームが把握するのに役立ちます。

ファースト・パーティー・アプリケーション・ログは、通常はOTel SDK、ロギング・ライブラリー、サイドカー（プライマリー・コンテナと並行して実行され、同じリソースを使用する2番目のアプリ・コンテナ）、またはエージェントを介し、内部サービスやアプリケーションから取得されます。これらは、ビジネス・イベント、要求処理、ユーザー・アクション、および内部エラーを記述します。リソース属性とインストルメンテーション範囲（ログを生成したエンティティ内のログの発生源を記述）で強化することで、アプリケーションの動作のより完全な全体像を提供できます。

サードパーティーのログは、多くの企業のIT環境が依存している（外部APIやデータベースなどの）外部サービス、マネージド・コンポーネント、SaaS製品によって出力されます。OTelは、これらのログを内部ログとともに取り込むことができるため、ITチームは外部依存がエコシステムにどのような影響を与えるかを確認できます。

OTLPログは、ネイティブなOTLPデータ・モデル内で表現され、OTLP gRPCまたはHTTP経由で送信されます。各ログは、ベンダーへの非依存性と、トレースおよびメトリクスとの迅速な関連付けのために標準化されています。

ファイル・ベースのログはファイル（アプリケーション・ログ・ファイルまたはWebサーバー・アクセス・ログ）に書き込まれものであり、syslogスタイルのログはsyslogプロトコルを使用して出力されるメッセージです。OTelは通常、ファイルに付随したりシスログ・メッセージをリッスンしたりするレシーバーを使用してこれらのログを収集し、統合処理のためにOTelログ・レコードに変換します。

HTTPおよびJSONログは、JSON形式でHTTPにより配信されます。OpenTelemetryは、CSV、共通ログ形式（CLF）、LTSV、キーと値のペアもサポートしています。これらの形式は、コレクターによって共通のOTelログ・データ・モデルに解析されるため、ネイティブのOTLPログと同じ方法で照会し、関連付けることができます。

SREが、チェックアウト・マイクロサービスのオブザーバビリティー・ダッシュボードで「チェックアウト失敗」エラーの増加を確認したとします。OTelログはすでに標準化されており、すべての「注文済み」ログ・レコードの構造化された属性（注文金額、商品数、追跡IDなど）が含まれているので、トラブルシューティング・プロセスを開始できます。

エンジニアは、ログ属性をクエリするだけで、障害が注文量の増加や、特定の配送方法、または特定の地域と相関しているかどうかを迅速に確認できます。また、OTelはすべてのテレメトリー信号で一貫したタイムスタンプとリソース・メタデータを使用するため、ログ、トレース、メトリクスの全体で時間枠を並べることができます。

エンジニアは、特定の決済プロバイダーにルーティングされた注文のみが失敗していることを確認します。彼らは、そのプロバイダー属性を共有するすべてのログまでトレース・バックし、そこで繰り返しセッションがタイムアウトしていることを発見します。その証拠により、ITチームはインシデントを適切な所有者に迅速にルーティングし、軽減ストラテジー（別のプロバイダーにフェイルオーバーするなど）を実装できます。

OTelロギングは、その収集、標準化、関連付け、およびログ送信手順において、従来のロギングとは大きく異なります。

従来のロギング・システムは、ログ・パターンに基づくログ集約、インデックス作成、検索、アラートに重点を置いています。これらは、テキスト検索と履歴分析のための強力なツールですが、通常は他のテレメトリー・データとは分離された状態でログを検査します。

従来のロギング・アプローチは、主にテキスト・メッセージをローカルで記録するものであるため、開発者がデバッグできるのは、単一のアプリケーションまたはホストの問題です。これらは、ユーザーがファイルを読み取って、フィルタリングし、後でログ集約ツールに送信することを想定しています。また、通常、プレーン・テキスト行、緩く構造化されたJSON、またはクロスサービス標準のないフレームワーク固有のパターンなどのアドホック形式を使用します。

また、各開発チームが独自のフィールドや命名を選択できるため、システム間での分析は面倒なプロセスになります。

従来のロギング・ツールには、関連付けや移行機能が組み込まれていないことが多いため、データの関連付けやオブザーバビリティー・バックエンドとの統合には、手動のプロセスと追加の手順が必要になります。ITチームは、サービス全体でイベントをつなぎ合わせるためにカスタム規則と解析ルールを作成する必要があり、ログデータをオブザーバビリティー・スタックに統合するには通常、カスタム・シッパーまたはフォーマット・アダプターが必要です。

OpenTelemetryロギングは、ログ、メトリクス、トレースを共有セマンティック規則によって管理される第一級の相互運用可能な信号として扱う、統合オブザーバビリティー・フレームワークの一部です。システムの動作をエンド・ツー・エンドで理解することを目的としているため、分散システム全体でログを相関および分析できるようなデザインが、最初から与えられています。

従来のロギングはスタックおよびバックエンドに固有ですが、OTelロギングは意図的に非依存です。これがブリッジとアペンダーを提供するため、既存のロギング・フレームワークは、すべてのログ呼び出しを書き直さなくても、OTel形式でデータを出力できます。

この統一された範囲とアプローチにより、ITチームは、ダッシュボードとデータ・タイプ間をシームレスに移動して、複雑で分散した障害を把握できる、総合的なトラブルシューティング・ワークフローを作成できます。

OTelロギングは、トレースやメトリクスと緊密に統合され、標準化されたコンテキスト豊富なログを提供するので、トラブルシューティングと分析を従来のアプローチよりもはるかに効果的なものにしています。メリットには以下が含まれます: