OpenTelemetry APM UI 、 OpenTelemetryでインストゥルメントされたサービスの包括的な監視エクスペリエンスを提供し、 New Relicの従来の言語エージェントに期待されるのと同じ強力なAPM機能を提供します。
前提条件
OpenTelemetry APM UI を使用する前に、次のものを用意してください。
- OpenTelemetry計装を使用してサービスを構成しました
- New Relicにデータを送信するためのサービスを設定する
- OpenTelemetryサービスエンティティを作成しました
これらの手順をまだ完了していない場合は、 OpenTelemetry APM監視のセットアップ手順を参照してください。
OpenTelemetryサービスを見つける
OpenTelemetry -インストゥルメントされたサービスを見つけるには:
- New Relic UIで、 All entities > Services - OpenTelemetryまたはAPM & Servicesに移動します。
- サービスを選択して概要ページを開きます
ヒント
エンティティ エクスプローラーのエンティティ タグを使用してサービスをフィルターします。New Relic の OpenTelemetry リソースでエンティティ タグが計算される方法について詳しく説明します。
OpenTelemetryとNew Relic APMの連携
OpenTelemetry -インストゥルメントされたサービスは、 New Relicの言語エージェントを使用するサービスと同じ厳選されたAPMエクスペリエンスを提供します。 仕組みは以下のとおりです:
データマッピングプロセス
New Relic は、次の方法で OpenTelemetry データを APM 規則に自動的にマッピングします。
- APMメトリクスの生成: APMエクスペリエンスに必要なメトリクスをOpenTelemetryデータから直接作成します。
- オリジナルデータの保存: オリジナルの OpenTelemetry データは、カスタムダッシュボードやアラートで引き続き利用できます。
- 規則の標準化: OpenTelemetryの進化するセマンティック規則を処理するため、バージョンの違いを追跡する必要はありません。
既存のNew Relicユーザーのメリット
New RelicエージェントからOpenTelemetryに移行する場合は、 OpenTelemetry標準を採用しながら、使い慣れたメトリクスと書き込みを引き続き使用できます。
重要
OpenTelemetryデータを正規化する理由
OpenTelemetry のセマンティック規則はまだ進化しており、その多くはまだ安定していません。データを New Relic 規則に正規化することで、次のことが可能になります。
- 計装が使用するOpenTelemetry規約バージョンを追跡する複雑さを軽減します
- New RelicエージェントからOpenTelemetryへの移行時に一貫したエクスペリエンスを提供
- OpenTelemetry の変更に関係なく、APM エクスペリエンスが安定していることを保証します。
データソースと優先順位付け
APM エクスペリエンスでは、次の 3 種類の OpenTelemetry データが使用されます。
- メトリクス(プライマリ): スループット、応答時間、エラー率などの正確なサービス統計を提供します。
- スパン(補足):メトリクスが利用できない場合や、トランザクショントレースなどの特定の機能に使用されます。
- ログ: トラブルシューティングと相関関係のために統合されています
メトリクスが推奨される理由: メトリクスはサービスのパフォーマンスの全体像を示しますが、スパンは通常サンプリングされており、すべてのトラフィックを表しているわけではありません。
APM エクスペリエンスでは、主に次の OpenTelemetry セマンティック規則を活用します。
OpenTelemetryデータからトランザクションがどのように生成されるか
New Relic の APM エクスペリエンスは、 トランザクションの概念を中心にしています。New Relicエージェントを使用する場合、トランザクション(単一のWebリクエストなど)の範囲を定義するのはエージェントの計装の責任です。 エージェントは、トランザクションの継続時間とその個々の操作 (外部呼び出しやデータベース呼び出しなど) を測定するトランザクション メトリクスを記録することによりNew Relic APMエクスペリエンスの大部分を推進するメトリクス データを生成します。
OpenTelemetry計装にはNew Relicトランザクションに直接類似するものがないため、トランザクションの概念をOpenTelemetryデータに適合させることが重要です。
OpenTelemetryのセマンティック規約を活用することで、 New Relicのエージェントと非常によく似た方法でAPMエクスペリエンスを推進するために、テレメトリーを記述するOpenTelemetryの高度に構造化され標準化された手段を利用できます。
セマンティック規則は、 HTTPまたはRPC requests処理などの一般的な操作を測定するための標準メトリックを定義します。 これらのメトリクスは、 New Relicエージェントがウェブサイトを記述するために生成するトランザクション メトリクスに似ています。 OpenTelemetryの HTTP および RPC メトリクスを利用して、 apm.service.transaction.duration
メトリクスなどのAPM UIを駆動するメトリクスを合成します。
New Relic 、非ウェブサイトの概念も提供します。 非ウェブサイトは、メッセージ処理を実行するシステムによく使用されます。 OpenTelemetryのメッセージング規約を活用した計装により、非ウェブサイトを表すメトリクスが合成されます。
重要
メッセージング操作とスパンデータ
OpenTelemetry のメッセージング規則は、HTTP 規則や RPC 規則ほど成熟していません。現在、メトリクス データではなくスパン データからメッセージング操作用の非ウェブサイト メトリクスを生成しています。 このアプローチはメッセージングのセマンティック規則に従いますが、サンプリング戦略の影響を受ける可能性があります。
取引名
各トランザクションには、OpenTelemetry のセマンティック規則に必要な属性から派生した名前が付けられます。この名前の由来については、 APMサービス メトリクス」セクションを参照してください。
不明な取引名
名前にunknown
が含まれるトランザクションが表示される場合があります。これは、トランザクションを導出するために使用されるソース データが、現在サポートされている確立された OpenTelemetry セマンティック規則のいずれにも従っていないことを示しています。
いくつかの例:
- HTTP メトリクスに
http.request.method
またはhttp.route
がありません。 たとえば、http.server.request.duration
メトリクスにhttp.route
プロパティがない場合、トランザクション名はWebTransaction/server/GET unknown
になります。 - OpenTelemetryが現在セマンティック規約を定義していないフレームワークまたはプロトコル (バックグラウンド ジョブや CI フレームワークなど)。
APMエクスペリエンスのナビゲーション
概要
概要ページには、サービスの健全性の概要が表示され、New Relic のトランザクションの概念を中心に展開されます。詳細については、「OpenTelemetry データからトランザクションがどのように派生されるか」を参照してください。
概要ページを駆動する New Relic メトリックは、apm.service.transaction.duration
メトリックと apm.service.error.count
メトリックです。OpenTelemetry データからどのように導出されるかの詳細については、それらを参照してください。
Apdex ターゲットのカスタマイズ
New Relic計装では、カスタムapdex目標をエージェント設定を使用して設定します。 OpenTelemetry の場合、サービスを表示するときに、 Settings > Applicationに移動して、Apdex ターゲットを構成します。
ディストリビューティッド(分散)トレーシング
ディストリビューティッド(分散)ト レーシング ページでは、 OpenTelemetryトレース データの詳細が提供されています。 ページの使用情報については、ディストリビューティッド(分散)トレーシングを参照してください。 データが OpenTelemetryNew Relicに取り込まれる方法の詳細についてはOpenTelemetryNew Relic 、 Relic の を参照してください。
ゴールデンシグナルと同様に、スパンのステータスがERROR
に設定されている場合 (たとえば、 otel.status_code = ERROR
)、スパンはエラーとして分類されます。 スパンはエラーの場合、エラーの詳細にスパンのステータスの説明(たとえば、 otel.status_description
)が表示されます。
OpenTelemetryスパン イベントは、追加のイベント コンテキスト情報を特定のスパンに添付します。 これらは例外情報をキャプチャするために最もよく使用されます。 利用可能な場合は、trace details [トレースの詳細]でスパンのイベントを表示できます。
ヒント
スパンの例外イベントが存在するだけでは、スパン自体がエラーであるとはみなされません。 スパン ステータスがERROR
に設定されているスパンのみがエラーとして分類されます。

サービスマップ
サービス マップ ページでは、アーキテクチャ全体を視覚的に表現します。 詳細については、サービス マップを参照してください。
トランザクション
トランザクション ページには、サービスのトランザクションに関する問題を特定し、分析するためのツールが提供されています。
OpenTelemetry には、New Relic のトランザクションの概念に直接類似するものはありません。詳細については、「OpenTelemetry データからトランザクションがどのように派生されるか」を参照してください。
トランザクション ページを駆動するNew Relicメトリクスは、 apm.service.transaction.duration
メトリクスとapm.service.error.count
メトリクスです。 OpenTelemetry データからどのように導出されるかの詳細については、それらを参照してください。
トランザクショントレース
OpenTelemetryの場面トレースは、スパン データから派生します。 取引ページでは、遺跡トレースのリストを見つけることができます。 このリストでは、特定のトランザクションのスパン データとメトリクス データが相互に関連付けられている必要があります。 これを行うには、境界トレースのルート スパンにtransaction.name
プロパティを追加します。
セグメント内訳
取引をクリックすると、取引の詳細ビューが開き、セグメントの内訳が表示されます。New Relicエージェントとは異なり、 OpenTelemetry個々のセグメントのメトリクスを出力しません。 したがって、セグメントの内訳を推進するために必要なNew Relicメトリクスは、スパン データから導出されます。
スパン データからセグメントの内訳を計算する際の顕著な欠点は、スパンが通常はサンプリングされることです。ただし、サンプリングを行った場合でも、セグメントの内訳は、トランザクション内で最も多くの時間を消費する特定のメソッドまたは操作を識別するのに役立ちます。
スループットデータから、受信したスループットデータに基づいてスループットを計算してサンプリングレートを推定し、それをメトリクスデータによって報告された実際のスループットで割ります。 推定サンプリング レートにより、トランザクションのセグメント内訳を推定できます。
このプロセスは完璧ではなく、さまざまな要因、特にサンプリング戦略によって影響を受ける可能性があります。これは、スパン データのパーセンテージを厳密にサンプリングする場合に最適に機能します。ただし、たとえば、エラーを表すスパンのみをサンプリングすると、セグメントの内訳が歪む可能性があります。
データベース
データベース ページには、サービスのデータベース クライアント操作に関する問題を特定し、分析するためのツールが用意されています。
OpenTelemetry計装は、データベースの意味規則を使用してデータベースへの呼び出しを表します。
データベース ページを駆動するNew Relicメトリクスは、 apm.service.datastore.operation.duration
メトリクスです。 OpenTelemetry データからどのように導出されるかの詳細については、こちらを参照してください。
呼び出し元ごとの消費時間
特定のデータベース呼び出しをクリックすると、「呼び出し元別の時間消費」グラフが表示されます。このグラフは、 apm.service.transaction.overview
メトリクスによって駆動されます。 これは、トランザクション ページのセグメント内訳ビューを駆動するメトリックと同じであり、スパン データから派生されます。
重要
OpenTelemetry のデータベース セマンティック規則は最近安定していると判断されました。安定した計装はまだ多く存在しておらず、存在する計装は多くの場合、スパン データのみを出力し、メトリクス データは出力しません。
そのため、安定したセマンティック規約がまだ採用されていない計装を使用する場合、データベース ページを駆動して生成されるAPMメトリクスはスパン データから派生します。
安定した計装が利用可能になり、それを採用すると、データベース ページでOpenTelemetryメトリクス データが活用され始めます。 あなたの言語で安定したデータベース計装が利用できるかどうかについては、 OpenTelemetryコミュニティにお問い合わせください。
外部サービス
外部サービス ページには、呼び出し元エンティティ (上流サービス) や呼び出し先エンティティ (下流サービス) などのサービスの外部呼び出しに関する問題を特定し、分析するためのツールが用意されています。
OpenTelemetryは、 HTTPおよびRPCセマンティック規則を使用して外部サービスへの呼び出しを表します。
データベース ページを駆動するNew Relicメトリクスは、 apm.service.external.host.duration
メトリクスです。 OpenTelemetry データからどのように導出されるかの詳細については、こちらを参照してください。
呼び出し元ごとの消費時間
特定の外部通話をクリックすると、「発信者別の時間消費」グラフが表示されます。このグラフは、 apm.service.transaction.overview
メトリクスによって駆動されます。 これは、トランザクション ページのセグメント内訳ビューを駆動するメトリックと同じであり、スパン データから派生されます。
JVMランタイム
JVM ランタイム ページには、Java サービスの JVM の問題を特定し、分析するためのツールが提供されています。このページは、 OpenTelemetry Javaを使用するサービスに対してのみ表示されます。個別のサービス インスタンスを区別するために、ページでservice.instance.id
リソース属性を設定する必要があります (詳細については、 「サービス」を参照してください)。
JVMゴールデン ランタイム ページには、ランタイムの問題とサービスの使用状況を関連付けるために、 JVMランタイム メトリクスの横に、ストップが表示されます。
この記事では、データがJVMメトリクスのセマンティック規則に準拠していることを前提としています。 これらの規則は、OpenTelemetry Java エージェントに自動的に組み込まれるOpenTelemetry OpenTelemetry Java計装ライブラリに具体化されていることに注意してください。
Goランタイム
Go ランタイム ページには、Go サービスのランタイムの問題を特定し、分析するためのツールが提供されています。 このページは、 OpenTelemetry Go を使用するサービスに対してのみ表示されます。 個別のサービス インスタンスを区別するために、ページではservice.instance.id
リソース属性を設定する必要があります (詳細については、 「サービス」を参照してください)。
Go ランタイムのゴールデン ページには、ランタイムの問題とサービスの使用状況を関連付けるために、Go ランタイム メトリクスの横に「マイナス」が表示されます。
この記事では、データがOpenTelemetry Go ランタイム計装ライブラリによって生成されることを前提としています。 現在、Go ランタイム メトリクスにはセマンティック規則が存在しないことに注意してください。
ログ
ログ ページには、問題を特定し、サービスのログを分析するためのツールが提供されます。 詳細については、 「ログ UI の使用」を参照してください。
エラーの受信トレイ
エラー受信トレイ ページには、サービスのエラーを検出してトリアージするためのツールが提供されます。 詳細については、 「エラー受信トレイの使用開始」を参照してください。
エラー受信箱ページはトレース データによって駆動されます。 ゴールデンの場合と同様、スパンのステータスがERROR
に設定されている場合 (たとえば、 otel.status_code = ERROR
)、スパンはエラーとして分類されます。
エラー スパンは、UUID、16 進数値、電子メール アドレスなどの識別値を正規化して計算されたエラー フィンガープリントごとにグループ化されます。 それぞれの個別のエラー スパンは、エラー グループ内の個別のインスタンスです。 エラー グループ メッセージは次のように決定されます。
- スパンステータスの説明(例:
otel.status_description
) rpc.grpc.status_code
RPCスパンセマンティック規約からhttp.status_code
HTTPスパンセマンティック規約からhttp.response.status_code
HTTPスパンセマンティック規約からundefined
上記のいずれも存在しない場合
スパンビュー(レガシー)
過去には、 OpenTelemetryインストゥルメント化されたサービスは、 New Relicの言語エージェントとはまったく異なるユーザー エクスペリエンスをもたらしました。 この古いエクスペリエンスでは、スパン データに基づいてキュレーションされたチャートが提供されていました。スパンのデータは通常はサンプリングされるため、特にスループットなどを表す場合には誤解を招く可能性があります。
現時点では、古いユーザー エクスペリエンスは、Span View (レガシー) ページから引き続き利用できます。上部には、「概要」、「トランザクション」、「データベース」、「外部サービス」の 4 つのタブがあります。これらのタブ上のすべてのチャートはスパン データから生成されます。
ヒント
従来のスパンベースのビュー
以前のOpenTelemetry APMエクスペリエンスでは、メトリクスとスパンの両方の観点からデータを表示できました。 通常、スパンデータはサンプリングされるため、メトリクスはより正確なスループットと応答時間の測定を提供します。 スパンベースのビューは引き続き利用可能ですが、段階的に廃止される予定です。詳細については、 「Span View (レガシー)」を参照してください。
スパンデータから派生したNew Relic APMメトリクス
APMエクスペリエンスを推進するNew Relic APMメトリクスは、通常、メトリクス データから派生します。 ただし、 APMメトリクスがスパン データから導出されるシナリオがいくつかあります。 次のシナリオでは、使用しているサンプリング戦略が生成されるメトリックに影響することに注意してください。
セグメント内訳
トランザクション セグメントの内訳ビューは、スパン データから生成されます。詳細については、セグメントの内訳を参照してください。
データベース呼び出し
OpenTelemetry データベースのセマンティック規則は最近安定していると宣言されました。ただし、ほとんどのデータベース計装は安定した規則をまだ採用しておらず、メトリクス データをまだ出力していません。 したがって、古い計装を使用する場合、データベース ページを駆動するメトリクスはスパン データから生成されます。 お使いの言語で利用可能になり次第、最新の安定したデータベース計装にアップグレードすることをお勧めします。
メッセージングシステム
OpenTelemetry メッセージングのセマンティック規則はまだ開発中です。ほとんどのメッセージング計装はまだメトリクス データを出力しません。 New Relic 、メッセージング システムとのやり取りを非ウェブサイトとして表します。 詳細については、「OpenTelemetry データからトランザクションがどのように派生されるか」を参照してください。
OpenTelemetry Ruby
OpenTelemetry現在、ほとんどの言語でメトリクスをサポートしていますが、 Ruby注目に値する例外です。 Rubyの場合、私たちはスパンデータからNew Relic APMメトリクスを生成するために最善を尽くしています。
APM サービスメトリクス
apm.service.*
メトリクスはNew RelicのAPMエクスペリエンスを推進します。 次のセクションでは、 apm.service.*
メトリクスを導出するために使用されるソースOpenTelemetryデータについて説明します。
メトリクスリソースのプロパティ
次のリソースプロパティがソースデータからAPMにコピーされます。
container.id
entity.guid
host.name
instrumentation.provider
k8s.cluster.name
k8s.container.name
k8s.namespace.name
k8s.pod.name
service.instance.id
service.name
メトリクス: apm.service.transaction.duration
属性 | タイプ | 説明 | 例 |
---|---|---|---|
|
| トランザクションの名前。 |
|
|
| トランザクションの種類。 |
|
|
| トランザクションが終了したエラーのクラスを説明します。 |
|
[1] : ソース メトリクスのユニットがコピーされます。
[2] : error.type
null以外に解決された場合、 apm.service.error.count
ソースデータのそれぞれのカウントで増分されます。
メトリクスのソース
意味の慣習 | メトリクス名 | 条件 |
|
|
|
---|---|---|---|---|---|
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
|
メトリクス: apm.service.transaction.overview
属性 | タイプ | 説明 | 例 |
---|---|---|---|
|
| トランザクションの名前。 |
|
|
| トランザクションの種類。 |
|
ドメイン属性 | 様々な | ソース規則に依存するドメイン固有の属性: |
|
スパンソース
意味の慣習 | スパンの種類 | 条件 |
|
| ドメイン属性 |
---|---|---|---|---|---|
|
|
|
| ||
|
|
|
| ||
|
|
|
| ||
|
|
|
| ||
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
|
メトリクス: apm.service.external.host.duration
属性 | タイプ | 説明 | 例 |
---|---|---|---|
|
| 逆引き DNS ルックアップなしでサーバー ドメインが利用可能な場合。それ以外の場合は、IP アドレスまたは Unix ドメイン ソケット名 |
|
[1] : ソース メトリクスのユニットがコピーされます。
メトリクスのソース
意味の慣習 | メトリクス名 | 条件 |
|
---|---|---|---|
|
|
| |
|
|
| |
|
|
|
メトリクス: apm.service.datastore.operation.duration
名前 | ユニット( UCUM ) | 説明 | |
---|---|---|---|
| ディストリビューション |
| データストア呼び出しの継続時間。 |
[1] : ソース メトリクスのユニットがコピーされます。
属性 | タイプ | 説明 | 例 |
---|---|---|---|
|
| クライアント計装によって識別されるデータベース管理システム (DBMS) 製品。 |
|
|
| データベース内のコレクション (テーブル、コンテナ) の名前。 |
|
|
| 実行される操作またはコマンドの名前。 |
|
|
| データベース書き込みのカーディナリティの低い概要。 |
|
メトリクスのソース
意味の慣習 | メトリクス名 | 条件 |
|
|
|
|
---|---|---|---|---|---|---|
|
|
|
|
|
|
ヘルパー機能
ヘルパー関数は、単純な属性参照よりも複雑な属性マッピング ロジックの一部への参照です。
働き | 説明 |
---|---|
| 文字列値を返す |
| rpc.grpc.status_codeの文字列値を返しますセット内であれば: |
| セット内の |
| セットに含まれない |
| プレースホルダー |
黄金の信号
最長、レスポンスタイム、エラー率のゴールデン シグナルは、 OpenTelemetry APM UI全体の複数の場所に表示されます。 使用する場合、次のように計算されます。
メトリクスの場合、この書き込みでは、データがHTTP メトリクスまたはRPC メトリクスの意味規則に準拠していると想定されます。
スパンの場合には、クエリは汎用的であり、最上位レベルのスパンのデータ モデルのみを利用します。 スパンは、サービスへのルート エントリ スパンの場合には、長さと応答時間にカウントされ、ヒューリスティックWHERE span.kind = server OR span.kind = consumer
を使用して計算されます。 スパンのステータス コードがERROR
(たとえば、 otel.status_code = ERROR
) の場合、そのスパンはエラーになります。
フィルターでデータを絞り込む
いくつかのページには、Narrow data to... [データを絞り込む]などのオプションを含むフィルター バーが含まれています。 これにより、ページ上のクエリを基準に合わせてフィルタリングできます。 たとえば、 service.version='1.2.3-canary'
をフィルタリングすることで、特定のカナリアデプロイメントに絞り込むことができます。 ページ間を移動するときにフィルターは保持されます。
ゴールデンメトリクス
ゴールデン メトリクスは、HTTP/RPC メトリクスなどの逆ゴールデン データの低カーディナリティ バージョンです。 これらは、エンティティ エクスプローラー、ワークロード アクティビティ ページ、変更追跡 (変更追跡機能) 詳細ページなど、さまざまなプラットフォーム エクスペリエンスに組み込まれます。 これらのメトリクスは、 newrelic.goldenmetrics.ext.service.*
のような名前を使用します。
重要
歴史的に、 OpenTelemetryゴールデンメトリクスはスパンから計算されていました。 スパンは、通常、サンプリングされるため、部分的な画像しか提供されません。 ゴールデン メトリクスが広く利用できるようになった現在、ゴールデン メトリクスはスパン データではなくメトリクス データを使用して計算されます。