New Relicを使用したOpenTelemetryのトラブルシューティングは、 ベストプラクティスに従っていることを確認するだけの問題かもしれませんが、問題を診断するために追加の手順を実行する必要がある場合があります。ここでは、発生する可能性のある特定の問題の例と、それらを解決するための手順とツールを示します。
OTLPを介して送信されたOpenTelemetryデータはクエリできません
問題
OTLPを使用してOpenTelemetryメトリック、ログ、またはトレースを送信しましたが、データを表示できません。深く掘り下げる前に、次のことを確認してください。
- 構成されたOTLPエンドポイントは、 文書化されたエンドポイントの1つと一致し、適切にフォーマットされており、OTLP / gRPCのデフォルトポート4317、またはOTLP/HTTPのデフォルトポート4318が含まれています。ポート443は、どちらのトランスポートでもサポートされています。該当する場合は、FedRAMPコンプライアンスの特定のエンドポイントに注意してください。
- お住まいの地域に基づいて、正しいエンドポイントを使用していることを確認してください。たとえば、ヨーロッパに拠点を置き、米国のエンドポイントにデータを送信するようにエクスポーターを構成している場合、エンドポイントは地域固有であるため、データのエクスポートに失敗します。
- アウトバウンドトラフィックはファイアウォールによって制限されていません。ネットワークドキュメントでは、明示的に許可する必要があるドメインとネットワークブロックについて説明しています。
- クライアントはTLS1.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エンティティまたは関係がありません
問題
サービスまたはインフラストラクチャコンポーネントから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）を参照してください。