ログは、アプリケーションログ、マシンで生成されたイベント、またはシステムログを表す場合があります。 OpenTelemetryは、ログデータを表すためのログデータモデルを定義しました。
OpenTelemetryツールを使ってログを送信し、アプリケーションと相関させ、New Relicで表示することができます。
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
を含めるように構成できます。 service.name
属性でログに注釈を付けるようにリソース プロセッサで構成できる、専用のコレクタ エージェントインスタンスと一緒にアプリケーションをデプロイできます。
必要に応じて、追加のアプリケーショントレース コンテキスト(実行コンテキストと呼ばれることもあります) をログ メッセージに伝達できます。これのセットアップと可用性は、アプリケーションで使用される言語とロギング フレームワークによって異なります。一般的な戦略は、構造化された JSON ログを書き込むようにアプリケーションをセットアップし、使用可能なログ メッセージの指定されたトレース コンテキスト フィールドにトレース コンテキストを抽出するようにアプリケーションを構成することです。詳細については、UI: ログ ページの OpenTelemetry を参照してください。
GitHubの Logs in Context with Log4j2 exampleでは、Log4j2を使ったシンプルなJavaアプリケーションのエンド・ツー・エンドの作業例を紹介しています。
OpenTelemetryのログを見る [#view-logs]
- New Relicを見る Logs UI.
- ログがアプリケーションと関連している場合、アプリケーションの コンテキストでログを表示します 。
タイムフィールド
ログデータのOpenTelemetry仕様によれば、 timeUnixNano
フィールドはオプションです。 timeUnixNano
が存在しない場合、NewRelicはデータが受信された時刻をNewRelicログのタイムスタンプに使用します。