• EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

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

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

問題を作成する

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で New Relic に送信されるすべてのアプリケーション メトリック、トレース、ログ データは、同じエンティティに関連付けられます。

ログにservice.nameリソース属性の注釈を付ける方法の詳細は、アプリケーションの環境によって異なります。

  • アプリケーションは構造化されたJSONログを生成する場合があります。これは、別のフィールドとしてservice.nameを含めるように構成できます。
  • 専用のコレクタ エージェントインスタンスと一緒にアプリケーションをデプロイできます。これをリソース プロセッサで構成して、ログにservice.name属性の注釈を付けることができます。

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

GitHub の Log4j2 を使用したコンテキスト内のログの例は、 Log4j2 を使用した単純な Java アプリケーションのエンドツーエンドの動作例を示しています。

OpenTelemetryのログを見る

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

タイムフィールド

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

Copyright © 2024 New Relic株式会社。

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