• English日本語한국어
  • ログイン今すぐ開始

この機械翻訳は参考用に提供されます。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、 を参照してください。

問題を作成する

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

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

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

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を含めるように構成できます。
  • service.name属性でログに注釈を付けるようにリソース プロセッサで構成できる、専用のコレクタ エージェントインスタンスと一緒にアプリケーションをデプロイできます。

必要に応じて、追加のアプリケーショントレース コンテキスト(実行コンテキストと呼ばれることもあります) をログ メッセージに伝達できます。これのセットアップと可用性は、アプリケーションで使用される言語とロギング フレームワークによって異なります。一般的な戦略は、構造化された JSON ログを書き込むようにアプリケーションをセットアップし、使用可能なログ メッセージの指定されたトレース コンテキスト フィールドにトレース コンテキストを抽出するようにアプリケーションを構成することです。詳細については、UI: ログ ページの OpenTelemetry を参照してください。

GitHubの Logs in Context with Log4j2 exampleでは、Log4j2を使ったシンプルなJavaアプリケーションのエンド・ツー・エンドの作業例を紹介しています。

OpenTelemetryのログを見る [#view-logs]

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

タイムフィールド

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

Copyright © 2023 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.