このドキュメントでは、New Relic が専用の OTLP エンドポイントを通じて受信した OpenTelemetry ログを処理する方法に焦点を当てています。
OpenTelemetry ログを New Relic に送信するための一般的なワークフローは 2 つあります。
- アプリケーションは、ログを New Relic OTLP エンドポイントに直接送信できます。
- 具体的な実装の詳細については、関連するOpenTelemetry 言語ドキュメントを参照してください。New Relic を使用したサービスの監視の詳細については、 OpenTelemetry APM 監視を参照してください。
この方法では、ファイルまたは標準出力 (
stdout) に書き込まれたアプリケーション ログをスクレイピングします。このタスクには通常、OpenTelemetry コレクターが使用されます。 スクレイピングされたログは New Relic OTLP エンドポイントに転送されます。
詳細な設定情報については、次のOpenTelemetryリソースを参照してください。
選択した収集方法に関係なく、統合を成功させるには、ログをこのエージェントにエクスポートするようにログ ソースを構成する必要があります。 続行する前に、必ず デバイスの設定要件を確認してください。
OTLP ログレコードのマッピング
New Relic は OTLP ログ レコードをLogデータ型にマッピングします。 以下の表は、 LogRecord proto メッセージのフィールドが New Relic Logにどのようにマッピングされるかを示しています。
OTLP | New Relic |
|---|---|
| 各キー値は |
|
|
|
|
| 各キー値は |
|
|
|
|
|
|
|
|
| 各キー値は |
|
|
|
|
|
|
|
|
表の脚注
[1]リソース属性、スコープ属性、ログレコード属性、最上位ログレコードフィールド、およびLogRecord.body [3]からの解析された属性に競合がある場合、優先順位（最高から最低）は次のようになります： LogRecord.bodyからの解析された属性 -> 最上位LogRecord.*フィールド > LogRecord.attributes > ScopeLogs.InstrumentationScope.attributes > ResourceLogs.Resource.attributes 。
[2] LogRecord.time_unix_nanosが存在しない場合は、 timestamp New Relicがデータを受信した時刻に設定されます。
[3]ログ解析はLogRecord.bodyに適用され、プレーンログテキストから属性を抽出しようとします。 たとえば、JSON 構造化ログ形式が使用される場合、キー値は結果のログの属性になります。 これは、ファイルまたはstdoutからログを収集する場合に特に便利です。 この場合、ログ レコードに関連付けられたリソース属性 ( APM サービス相関に必要) がなく、 LogRecord.trace_id / LogRecord.span_idの値 (トレース相関に必要) がないのが一般的です。 必要なフィールドを正常に解析できれば、相関関係は意図したとおりに機能します。
OpenTelemetry APM サービスとの相関
ログは、 必要な属性が含まれている場合、サービス エンティティと相関関係にあります。 通常、これらはResourceLogs.Resource.attributesなどのログのリソース属性から取得されますが、 OTLP マッピングの脚注 3で説明されているようにLogRecord.bodyから解析することもできます。
サービスのログを表示するには、そのサービスのログ ページに移動します。
トレースとの相関
trace.id属性とspan.id属性を解決できる場合、ログはトレースと相関付けられます。 通常、これらはLogRecord.trace_idフィールドとLogRecord.span_idフィールドから取得されますが、 OTLP マッピングの脚注 3 で説明されているようにLogRecord.bodyから解析することもできます。
特定のトレースのコンテキストで記録されたログを表示するには、次の 2 つのオプションがあります。
- トレースの詳細ページ 内の Logs [ログ]タブに移動します。
- サービスのログ ページに移動し、ログをクリックしてログの詳細を開きます。 トレースに関連付けられている場合は、Log details[ログの詳細]からTrace details[トレースの詳細]に移動できます。