この機械翻訳は、参考として提供されています。

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

問題を作成する

OpenTelemetryのNew Relic

このドキュメントでは、New Relic が専用の OTLP エンドポイントを通じて受信した OpenTelemetry ログを処理する方法に焦点を当てています。

OpenTelemetry ログを New Relic に送信するための一般的なワークフローは 2 つあります。

選択した収集方法に関係なく、統合を成功させるには、ログをこのエージェントにエクスポートするようにログ ソースを構成する必要があります。 続行する前に、必ず デバイスの設定要件を確認してください。

OTLP ログレコードのマッピング

New Relic は OTLP ログ レコードをLogデータ型にマッピングします。 以下の表は、 LogRecord proto メッセージのフィールドが New Relic Logにどのようにマッピングされるかを示しています。

OTLP logs.protoフィールド

New Relic Logフィールド

ResourceLogs.Resource.attributes

各キー値はLogフィールドの属性である[1]

ScopeLogs.InstrumentationScope.name

otel.library.name

ScopeLogs.InstrumentationScope.version

otel.library.version

ScopeLogs.InstrumentationScope.attributes

各キー値はLogフィールドの属性である[1]

LogRecord.time_unix_nanos

timestamp [2]

LogRecord.severity_number

severity.number

LogRecord.severity_text

severity.text

LogRecord.body

message、および解析された属性[3]

LogRecord.attributes

各キー値はLogフィールドの属性である[1]

LogRecord.dropped_attribute_count

otel.dropped_attributes_count

LogRecord.flags

w3c.flags （整数）

LogRecord.trace_id

trace.id

LogRecord.span_id

span.id

表の脚注

[1]リソース属性、スコープ属性、ログレコード属性、最上位ログレコードフィールド、およびLogRecord.body [3]からの解析された属性に競合がある場合、優先順位（最高から最低）は次のようになります： LogRecord.bodyからの解析された属性 -> 最上位LogRecord.*フィールド > LogRecord.attributes > ScopeLogs.InstrumentationScope.attributes > ResourceLogs.Resource.attributes 。

OTLP New Relicエンドポイントでサポートされるプロパティ タイプ の詳細については「OTLP プロパティ タイプ」を、プロパティに対して実行される検証の詳細については 「OTLP プロパティ制限」を 参照してください。

[2] LogRecord.time_unix_nanosが存在しない場合は、 timestamp New Relicがデータを受信した時刻に設定されます。

[3]ログ解析はLogRecord.bodyに適用され、次の属性を抽出しようとします:

  • プレーン ログ テキスト: 文字列値がmessage属性として設定されます。
  • 文字列化された JSON: ログが JSON としてフォーマットされていて、プレーン テキスト文字列として送信された場合、キーの値のペアが結果のログのプロパティになります。 詳細については、 JSON 解析のドキュメントを参照してください。 これは、ファイルまたはstdoutからログを収集する場合に特に便利です。 この場合、ログ レコードに関連付けられたリソース属性 ( APM サービス相関に必要) がなく、 LogRecord.trace_id / LogRecord.span_idの値 (トレース相関に必要) がないのが一般的です。 必要なフィールドを正常に解析できる場合、コンテキスト内のログは意図したとおりに機能します。
  • マップ構造: データがOTLP 仕様に従ってマップとしてフォーマットされている場合、JSON 解析と同様に解析され、属性にフラット化されます。 詳細については、 JSON 解析のドキュメントを参照してください。

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[トレースの詳細]に移動できます。

New Relicカスタムイベントとしてログオン

OpenTelemetry は、空でない LogRecordEventName を持つ として イベント を定義します。カスタムイベントは、 New Relicプラットフォームのコア信号です。 ただし、同じ名前を使用しているにもかかわらず、 OpenTelemetryイベントとNew Relicカスタムイベントは同一の概念ではありません。

  • OpenTelemetry EventNameは、カスタムイベント タイプと同じ形式または セマンティクスを共有しません。 OpenTelemetryイベント名はネームスペースで完全修飾され、小文字のスネークケースに従います。 com.acme.my_event .カスタムイベントタイプはパスカルケースです。例:MyEvent .
  • OpenTelemetry イベントは、拡張された構造化ログと考えることができます。構造化ログと同様に、データは自由形式のテキストではなくキーの値のペアでエンコードされます。 さらに、 EventNameは発生したイベントのクラス/タイプを明確に示すシグナルとして機能します。カスタムイベントはまったく新しいイベント タイプとして扱われ、 SELECT * FROM MyEventを使用してNRQL経由でアクセスできます。

これらの違いにより、OpenTelemetry New RelicLogsイベントは、ほとんどの場合、OpenTelemetry New RelicLogsNew RelicRelicカスタムイベントよりも に類似しているため、 イベントは として取り込まれます。

ただし、 newrelic.event.type=<EventType>形式に従ってLogRecord.attributesにエントリを追加することで、 OpenTelemetry LogRecordカスタムイベントとして取り込む必要があることを明示的に通知できます。

たとえば、プロパティnewrelic.event.type=MyEventを持つLogRecordは、 type=MyEventのカスタムイベントとして取り込まれ、 SELECT * FROM MyEventを使用してNRQL経由でアクセスできます。