OpenTelemetry 、次元メトリックスデータ モデル、メトリックス テレメトリーを記録するためのAPI 、メトリックス データを集約およびエクスポートするためのSDK を提供します。
このページでは、New Relic OpenTelemetryNew RelicOTLP エンドポイント 経由で受信した メトリクスをどのように処理するかについて説明します。次のページを参照してください。
- エンドポイント設定の要件については、 New Relic OTLP エンドポイントを参照してください。
- OpenTelemetryを使用してサービスを構成する手順については、 OpenTelemetry APM監視」を参照してください。
計装の種類からメトリクスの種類まで マッピング
OpenTelemetryメトリクスAPIいくつかの計装の種類を定義します。 インストゥルメントされたレコード測定値は集約され、特定のメトリック タイプとして OTLP 経由でエクスポートされます。 以下の表は、各OpenTelemetryメーターが集計およびエクスポートする方法のデフォルトの動作を示しています。 で各メトリック タイプがどのように処理されるかの詳細については 、「OTLP メトリック マッピング」をNew Relic 参照してください。
計装の種類 | 使用例 | デフォルトの集計 | エクスポートされたメトリックスタイプ |
|---|---|---|---|
処理されたバイト数 |
| ||
プロセス全体のCPU時間を観察する |
| ||
キュー内のアイテム |
| ||
現在のメモリ使用量を観察する |
| ||
httpリクエストの持続時間 | |||
CPUファン速度のイベントを変更する | |||
現在の室温を観察する |
正しい計装タイプの選択の詳細については、 OpenTelemetryの補足ガイドラインを参照してください。
[1]ヒストグラム インストゥルメントされたは、指数ヒストグラムメトリックスに集約することもできます。 詳細については、OTLP ヒストグラム メトリックを参照してください。
OTLP メトリック マッピング
New Relic OTLP メトリクスをMetric データ型にマッピングします。 以下の表は、 メトリクス プロト メッセージのフィールドがどのように解釈されるかを示しています。 および SDK によってさまざまなメトリクス タイプがどのように生成されるかについて詳しくは、 「メトリクス タイプへの計装」 を参照してください。OpenTelemetryAPI
OTLPメトリクス原始体 | New Relic |
|---|---|
| 各キー値は |
|
|
|
|
| 各キー値は |
|
|
|
|
|
|
|
|
|
|
| 各キー値は |
| New Relic へのマップ |
| New Relic OTLP合計メトリクスを参照 |
| New Relic へのマップ |
| New Relic へのマップ |
| New Relic へのマップ OTLPの概要を見る |
[1] : リソース属性、スコープ属性、メトリクスポイント属性、および最上位のメトリクスフィールドで競合が発生した場合、優先順位（最高から最低）は次のようになります：最上位のMetric.*フィールド > Metric.*.data_points.attributes > ScopeMetrics.InstrumentationScope.attributes > ResourceMetrics.Resource.attributes 。
New Relic OTLP エンドポイントでサポートされている属性タイプの詳細については、 OTLP 属性タイプを参照してください。
OTLP 合計メトリック
OTLP 合計メトリクスは、時間の経過に伴う測定値の合計を表します。 合計には、値が単調に増加するか (つまり、上昇のみ可能)、そうでないか (つまり、上昇と下降が可能) を示すaggregation_temporalityフィールドとis_monotonicフィールドが含まれます。 次の表は、New Relic がさまざまな合計の種類をどのように処理するかを示しています。
|
| 行動 |
|---|---|---|
|
| New Relic へのマップ |
|
| New Relic へのマップ |
|
| New Relic へのマップ |
|
| データが意味をなさないためサポートされていません。 詳細についてはこのディスカッションを参照してください。 |
OTLP ヒストグラム メトリック
OTLP ヒストグラム メトリクスと指数ヒストグラム メトリクスは、測定値の分布を表す合計、カウント、最小、最大、バケットなどの情報を使用して測定値の集団を要約します。 ヒストグラムの種類 (明示的なバケット ヒストグラムとも呼ばれます) には、明示的な境界を持つバケットがあります。 指数関数型には、指数式で記述される境界を持つバケットがあります。 どちらの種類にも、集約時間フィールドが含まれています。
ヒストグラムの両方の種類は、内部の基数 2 の指数ヒストグラム表現によってサポートされるNew Relic distributionに変換されます。 この表現は、OpenTelemetry 指数ヒストグラム形式にほぼ一致しています。 このため、 New Relic指数ヒストグラムが優先されます (指数ヒストグラムを優先するように OTLP を構成する方法の詳細については、「メトリクス ミストグラム集計」を参照してください)。 OpenTelemetry の明示的なバケット ヒストグラムの種類は、線形補間を使用して指数表現に変換されます。 詳しい説明についてはNrSketchを参照してください。
負の無限大と正の無限大に境界を持つバケットは、New Relic ではゼロ幅のバケットとして表されます。 たとえば、境界が[-∞, 10)の OpenTelemetry バケットは、New Relic では[10, 10)として表されます。 その結果、ディストリビューションの最後に誇張されたバケット数が表示される場合があります。
OTLPサマリーメトリクス
OTLP サマリー メトリクスは、合計とカウントを含む測定値の母集団を要約するという点でヒストグラムに似ています。 ただし、ヒストグラムには測定値の分布を表すバケットが含まれますが、サマリーには分位数が含まれます。 これらの分位数は、空間的または時間的な再集約ができないため、用途が限られています。 レガシー サポート用の OpenTelemetry に含まれるサマリーと、OpenTelemetry API および SDK ではサマリーは生成されません。
要約は New Relic summaryに翻訳されます。 New Relic サマリー タイプは分位数をサポートしていないことに注意してください。
重要
要約は取り込まれ、New Relic summaryに変換されますが、適切にサポートされていません。 New Relic実際には累積メトリクスである場合でも、サマリーが最後の測定以降のデルタを表すと想定します ( 「集計時間性」を参照)。 サマリーは、累積的なメトリクス システムである Prometheus によって最も一般的に出力されます。 したがって、New Relic は現在、最も一般的なユースケースをサポートしていません。 そのため、取り込みの失敗など、サマリー メトリックスで予期しない動作が発生します。
集約の時間性
OpenTelemetryの集計時間の概念は、特定の Metrics データ ポイントが累積的な測定値セット (通常はアプリケーションの開始以降) を集計するか、最後のエクスポート以降の測定値のデルタ セットを集計するかを定義します。 OTLP合計メトリクスとヒストグラムメトリクスには、ポイントのセマンティクスを記述するaggregation_temporalityフィールドがあります。
累積的時間メトリックとデルタ時間メトリックの両方を受け入れますが、 New Relic一般的にデルタ時間メトリック システムであるため、ユーザーには OTLP エクスポーターを設定してデルタ時間メトリックを優先するように推奨します。
時間性が累積的である場合、メトリックはデルタ表現に変換されます（累積値はcumulativeCountに対して保持されます）。ステートフル変換を使用すると、同じシリーズの 2 つの連続する累積ポイントからデルタを計算するステートフル プロセスが実行されます。 Metric.*.data_points.start_time_unix_nanoはシリーズのリセットを検出するために使用されます。
模範となるサポート
OpenTelemetryメトリクスサンプルは現在New Relicではサポートされていません。