OpenTelemetry データを送信し、UI でサービス (エンティティ) を開いた後、[ JVM ] をクリックして、Java 仮想マシンの動作に関連する異常または異常なパフォーマンス パターンを持つサービス インスタンスを特定します。
主要なメトリック（応答時間、スループット、エラー率、ガベージコレクション時間、メモリ使用量）の要約に基づいて、比較する複数のサービスインスタンスを選択できます。次に、時系列チャートを使用してOpenTelemetryインストルメンテーションによって収集されたすべてのインスタンスのJVMメトリックを比較し、問題を特定できます。
典型的なワークフローをご紹介します。
JVMs をクリックします。
要約されたヘルスメトリクスのテーブルを使用して、興味深いJVMを見つけます。
- フィルターバーを使用して検索を絞り込みます
- メトリクス値の列を並べ替えて外れ値を見つける
それらの興味深いJVMを選択します。
Compare をクリックすると、JVMでファセットされたヘルスメトリクスとランタイムメトリクスが表示されます。
テーブル内のインスタンスの名前をクリックして、単一の JVM のすべてのランタイム メトリックを表示することもできます。
JVM を比較したり、単一の JVM にドリルダウンしたりすると、ガベージ コレクションやメモリ使用量など、ランタイム メトリック データの複数の時系列グラフが表示されます。JVM 固有のランタイム メトリックは、 OpenTelemetry セマンティック規則で指定され、最近のバージョンの OTel 自動計測エージェントに実装されています。
このセクションに表示されるデータは、以下の条件を満たしている必要があります。
- インスタンスごとに JVM メトリックをグループ化するために使用される OpenTelemetry リソース属性
service.instance.id
JVM メモリ使用量を非同期ゲージとして収集する OpenTelemetry Java エージェント 1.13.0 以降を使用することをお勧めします。これらのエージェント バージョンを使用すると、古いエージェントを使用していた場合に必要となる回避策を講じなくても、New Relic でメトリクスを表示できます。
古い OpenTelemetry Java エージェント (バージョン 1.10.0 から 1.12.0) を使用している場合は、JVM メモリ使用量が非同期ゲージとして収集されることから非同期 UpDownCounter に切り替わることに注意してください。これは、エクスポートされたデータに影響を与えます。ゲージとカウンターのエクスポート方法は異なります。
非同期ゲージは OTLP ゲージとしてエクスポートされます。
非同期 UpDownCounters は、OTLP 非単調合計としてエクスポートされます。
デルタ集約の一時性を使用してメトリクスをエクスポートするように SDK を構成する場合 (New Relic で機能するカウンターおよびヒストグラム インストルメントに必要)、非同期の UpDownCounters が非単調なデルタサムとしてエクスポートされます。New Relic は、非単調なデルタサム データの有用な分析を実行できません。
OpenTelemetry Java エージェント バージョン 1.10.0 から 1.12.0 を使用する必要がある場合の回避策は、ビュー API を使用して、デフォルトの合計集計ではなく、 最後の値の集計 を使用して非同期の UpDownCounters を集計する必要があることを示すことです。 これにより、JVM メモリ使用量がゲージ データとしてエクスポートされます。これは、New Relic での有用なエクスペリエンスに必要です。
View API を構成する方法は、OpenTelemetry Java エージェントを使用しているかどうかによって異なります。
OpenTelemetry Java エージェントを使用している場合は、 拡張機能で View API を構成する必要があります。拡張機能を使用すると、(とりわけ) SDK 構成にフックし、環境変数やシステム プロパティでは利用できないプログラムによる構成を適用できます。この例では、拡張機能を使用してSdkMeterProviderのビューをカスタマイズする方法を示します。
OpenTelemetry Javaエージェントを使用していない場合は、 SdkMeterProviderの構成時にビューを登録する方法を示すこの簡単な例を確認してください。
他のUIページでのOpenTelemetryについては、 UIの概要を参照してください。