• ログイン今すぐ開始

本書は、お客様のご参考のために原文の英語版を機械翻訳したものです。

英語版と齟齬がある場合、英語版の定めが優先するものとします。より詳しい情報については、本リンクをご参照ください。

問題を作成する

OpenTelemetryログ:ベストプラクティス

ログは、アプリケーションログ、マシンで生成されたイベント、またはシステムログを表す場合があります。 OpenTelemetryは、ログデータを表すためのログデータモデルを定義しました。

OpenTelemetryツールを使ってログを送信し、アプリケーションと相関させ、New Relicで表示することができます。

重要

OpenTelemetryプロトコルが成熟し、より多くのコンポーネントが安定していると宣言されたため、2022年9月までに、OTLPエンドポイントでサポートされるバージョンをv0.10.0からより新しいリリース(少なくともv0.16.0)に移行する予定です。

コミュニティがOTLPのより安定したリリースに向けて動くにつれて、v0.10.0サポートのEOLタイムラインと、混乱を最小限に抑えるために実行できるアクションに関して、追加の連絡が予定されています。

New Relicへのログ送信

OpenTelemetry CollectorOpenTelemetry Collector Contrib リポジトリには、ログデータを消費するためのコンポーネントが多数含まれています。一般的なパターンは、コレクターを以下のように構成することです。

  1. 任意のログレシーバーからログを受信します。レシーバーのオプションには、 Filelog ReceiverFluent Forward ReceiverSyslog Receiver があります。
  2. ログを処理し、リソース情報でアノテーションすることができます。プロセッサのオプションには、 Resource Detection ProcessorResource Processor などがあります。
  3. 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]

ここでは、ログを表示する方法を2つご紹介します。

タイムフィールド

ログデータのOpenTelemetry仕様によれば、 timeUnixNanoフィールドはオプションです。 timeUnixNanoが存在しない場合、NewRelicはデータが受信された時刻をNewRelicログのタイムスタンプに使用します。

Copyright © 2022 New Relic株式会社。