ログは、アプリケーションログ、マシンで生成されたイベント、またはシステムログを表す場合があります。 OpenTelemetryは、ログデータを表すためのログデータモデルを定義しました。
OpenTelemetryツールを使ってログを送信し、アプリケーションと相関させ、New Relicで表示することができます。
重要
OpenTelemetryプロトコルが成熟し、より多くのコンポーネントが安定していると宣言されたため、2022年9月までに、OTLPエンドポイントでサポートされるバージョンをv0.10.0からより新しいリリース（少なくともv0.16.0）に移行する予定です。
コミュニティがOTLPのより安定したリリースに向けて動くにつれて、v0.10.0サポートのEOLタイムラインと、混乱を最小限に抑えるために実行できるアクションに関して、追加の連絡が予定されています。
New Relicへのログ送信
OpenTelemetry Collector と OpenTelemetry Collector Contrib リポジトリには、ログデータを消費するためのコンポーネントが多数含まれています。一般的なパターンは、コレクターを以下のように構成することです。
- 任意のログレシーバーからログを受信します。レシーバーのオプションには、 Filelog Receiver 、 Fluent Forward Receiver 、 Syslog Receiver があります。
- ログを処理し、リソース情報でアノテーションすることができます。プロセッサのオプションには、 Resource Detection Processor や Resource Processor などがあります。
- OTLP エクスポーターを使ってログを New Relic にエクスポートします。
アプリケーションログを関連付けます
アプリケーションログは、アプリケーションによって生成された他のテレメトリデータと相関している場合にさらに役立ちます。 サービスのOpenTelemetryセマンティック規則では、必須フィールドとしてservice.nameが指定されています。同じservice.nameでNewRelicに送信されるすべてのアプリケーションメトリック、トレース、およびログデータは、同じエンティティに関連付けられます。
ログにservice.nameリソース属性の注釈を付ける方法の詳細は、アプリケーションの環境によって異なります。
- アプリケーションは構造化されたJSONログを生成する場合があります。これは、別のフィールドとして
service.nameを含めるように構成できます。 - 専用のCollectorAgentインスタンスと一緒にアプリケーションをデプロイできます。このインスタンスは、 リソースプロセッサーを使用して構成し、ログに
service.name属性の注釈を付けることができます。
オプションとして、追加のアプリケーション トレースコンテキスト （実行コンテキストと呼ばれることもあります）をログメッセージに伝搬することができます。この設定と利用可能性は、アプリケーションが使用する言語とロギングフレームワークに依存します。一般的な戦略は、構造化されたJSONログを書くようにアプリケーションを設定し、利用可能なログメッセージ上の指定された トレースコンテキストフィールド にトレースコンテキストを抽出するように設定することです。
GitHubの Logs in Context with Log4j2 exampleでは、Log4j2を使ったシンプルなJavaアプリケーションのエンド・ツー・エンドの作業例を紹介しています。
OpenTelemetryのログを見る [#view-logs]
- New Relicを見る Logs UI.
- ログがアプリケーションと関連している場合、アプリケーションの コンテキストでログを表示します 。
タイムフィールド
ログデータのOpenTelemetry仕様によれば、 timeUnixNanoフィールドはオプションです。 timeUnixNanoが存在しない場合、NewRelicはデータが受信された時刻をNewRelicログのタイムスタンプに使用します。