New Relicを使用したOpenTelemetryのトラブルシューティングは、 ベストプラクティスに従っていることを確認するだけの問題かもしれませんが、問題を診断するために追加の手順を実行する必要がある場合があります。ここでは、発生する可能性のある特定の問題の例と、それらを解決するための手順とツールを示します。
OTLPを介して送信されたOpenTelemetryデータはクエリできません
問題
OTLPを使用してOpenTelemetryメトリック、ログ、またはトレースを送信しましたが、データを表示できません。深く掘り下げる前に、次のことを確認してください。
構成されたOTLPエンドポイントは、 文書化されたエンドポイントの1つと一致し、適切にフォーマットされており、OTLP / gRPCのデフォルトポート4317、またはOTLP/HTTPのデフォルトポート4318が含まれています。ポート443は、どちらのトランスポートでもサポートされています。該当する場合は、FedRAMPコンプライアンスの特定のエンドポイントに注意してください。
お住まいの地域に基づいて、正しいエンドポイントを使用していることを確認してください。たとえば、ヨーロッパに拠点を置き、米国のエンドポイントにデータを送信するようにエクスポーターを構成している場合、エンドポイントは地域固有であるため、データのエクスポートに失敗します。
アウトバウンドトラフィックはファイアウォールによって制限されていません。ネットワークドキュメントでは、明示的に許可する必要があるドメインとネットワークブロックについて説明しています。
クライアントは TLS 1.2 以降を使用するように構成されており、リクエストには有効な New Relic を含む
api-keyヘッダーが含まれています.
リクエストには有効なprotobufペイロードが含まれ、gRPCまたはHTTPトランスポートを使用します。できれば、 gzip圧縮を有効にします。リクエストのペイロードは1MB（10 ^ 6バイト）以下である必要があります。JSONでエンコードされたprotobufペイロードもサポートされています。
クライアントの出力とログは、
4xxまたは5xxの応答コードが返されていることを示していません。
解決
テレメトリ データがプラットフォームに正常に配信されたことを検証するために使用できるツールは多数あります。最初の適切なステップは、データ管理ハブをチェックしてデータの取り込みをファセット化し、さまざまなソースから到着するデータの量を判断することです。メトリクスとイベント、または クエリ ビルダーを使用して、 instrumentation.providerまたはnewrelic.source属性によってファセットされたデータを探すこともできます。
FROM Log, Metric, Span SELECT datapointcount() WHERE instrumentation.provider = 'opentelemetry' FACET instrumentation.provider, newrelic.sourceこのクエリは、データがOTLP経由で到着しているかどうかを示します。期待するデータが存在しない場合は、次の代替クエリを試してください。
FROM Log, Metric, Span SELECT count(*) where newrelic.source LIKE 'api.%.otlp'NrIntegrationErrorイベントを照会して、統合エラーをチェックすることもできます。これは、構成やフォーマットに問題があるかどうか、またはプラットフォームの制限に遭遇したかどうかを判断するのに役立ちます。
重要
OTLPを介したメトリック、ログ、およびトレースの取り込み制限は、他のデータ取り込みAPI制限と同じです。
New Relic UIのさまざまな部分は、適切に機能するために特定の属性の存在に依存しています。多くの場所でNRQLコンソール機能を使用して、クエリのWHEREまたはFACET句で必要な属性を確認できます。これらの句を編集してクエリを再実行し、これらの属性が欠落しているデータが存在するかどうかを判断することもできます。必要な属性の例には、 service.nameおよびservice.instance.idが含まれます。例のより完全なリストについては、 リソースを参照してください。
OpenTelemetry ログ相関が機能しない
問題
service.name ( OpenTelemetry ログ: ベスト プラクティス) を使用してログをサービスと関連付けたので、トレースに関連付けられたログを確認できますが、New Relic UI にはログが表示されません。このシナリオでは、ログ データは New Relic に送信されましたが、対応するスパンで分散トレース UI に表示されません。
解決
ログをトレース データと関連付けるには、 trace_idおよびspan_idに含まれるトレース コンテキストをログに含める必要があります。ただし、ログが New Relic UI に確実に表示されるようにするには、ログ パイプラインでルールを構成して、 trace_idとspan_idをtrace.idとspan.idに変換する必要があります。
OpenTelemetryエンティティまたは関係がありません
問題
サービスまたはインフラストラクチャコンポーネントからOpenTelemetryデータを送信しましたが、エンティティまたはその関係が欠落しているか、正しくありません。
解決
OpenTelemetryエンティティは、 EXT-SERVICEエンティティタイプについて説明されているパブリックルールに基づいて合成されます。照合する標準のルールは、OpenTelemetryのセマンティック規則に従うservice.nameディメンションの存在に依存しています。
OpenTelemetry Java SDKでservice.nameを設定するには、それを リソースに含めます。
var resource = Resource.getDefault() .merge(Resource.builder().put(SERVICE_NAME, serviceName).build());SDKによっては、 OTEL_RESOURCE_ATTRIBUTESまたはOTEL_SERVICE_NAME 環境変数で宣言してservice.nameを設定することもできます。
ログ管理の場合、構造化ログテンプレートを使用してservice.nameを挿入できます。ログの例を次に示します。
ヒント
New Relicを使用したOpenTelemetryのその他の例については、GitHubのnewrelic-opentelemetry-examplesリポジトリにアクセスしてください。
OpenTelemetryコレクターのトラブルシューティング
コレクターのトラブルシューティングのヒントと監視方法に最適な場所は、OpenTelemetryコミュニティの最新のガイドラインです。コミュニティのトラブルシューティングドキュメントについては、以下のリンクを参照してください。
コレクターログ
構成service::telemetry::logsでログレベルを設定します。デフォルトのレベルはINFOです。サポートされているレベルは、 DEBUG 、 INFO 、 WARN 、 ERROR 、 DPANIC 、 PANIC 、 FATALです。
トラブルシューティングのヒントについては、 ログのトラブルシューティング（GitHub）を参照してください。
コレクターメトリック
次のNRQLクエリは、NewRelicのコレクター自体から利用可能なすべてのメトリックを示しています。
FROM Metric SELECT uniques(metricName) WHERE metricName like ‘otelcol_%’ LIMIT MAXトラブルシューティングのヒントについては、以下を参照してください。
コレクタートレース
トラブルシューティングのヒントについては、 zPages（Github）を参照してください。