累積メトリック (OTel および Prometheus)

輸出条件年 = 2023; export const gaDate = '4 月 4 日'; const gaDateAndYear = gaDate + ', ' + 年をエクスポートします。

OpenTelemetry 統合またはPrometheus リモート書き込み統合から累積メトリクスを報告すると、New Relic がそのデータをどのように処理するか (たとえば、デルタ測定値に変換する方法) を理解するのに役立ちます。これは、New Relic UI ビューを理解し、データをクエリし、データ レポートの問題を理解するのに役立ちます。

累積指標と差分指標の説明

アプリケーションからメトリック データを収集するときは、クエリ時にデータを使用および解釈する方法を決定する際に、そのデータがどのように測定されたかを考慮することが重要です。メトリクス タイプは重要な要素の 1 つです。特定の New Relic 集計関数は、一部のタイプでは機能し、他のタイプでは機能しません。しかし、もう 1 つの重要な要素は、メトリックの一時性です。

2 つの一時性は、 deltaとcumulativeです。Deltaは、レポート間隔の間に測定値がリセットされることを示します。Cumulativeは、リセットがなく、測定値が累積されていることを示します。Prometheus は累積メトリック コレクターの一般的な例であり (データ型に関する Prometheus ドキュメント)、OpenTelemetry は累積メトリックを収集する方法も定義しています (一時性に関する OpenTelemetry ドキュメント)。

New Relic は Prometheus と OpenTelemetry の両方の累積データをサポートし、取り込み時にデルタ変換を実行して、プラットフォーム上の他のメトリクスとの整合性を高め、 NRQLを介してそのデータとやり取りしやすくします。累積カウンターは New Relic cumulativeCountとして保存され、累積ヒストグラムは New Relic distributionとして保存されます。

Prometheus リモート書き込みサポート

詳しくは、 Prometheus リモート書き込み統合を参照してください。

OpenTelemetry のサポート

OpenTelemetry サポートの詳細については、 OpenTelemetry メトリック: ベスト プラクティスを参照してください。

累積からデルタへの変換の詳細

大まかに言えば、デルタ変換は、イベント時間に連続する 2 つのデータ ポイントを取得し、差を計算することによって実行されます。ただし、実際にはこれほど単純なことはありません。ここでは、予想されるいくつかの一般的なシナリオと、その対処方法を示します。

リセット

時系列のデータの値が突然減少した場合、これをリセットとして扱い、その新しい測定値を独自のデルタ値として出力します (つまり、 0測定値が前にあったかのように)。

OpenTelemetry は、値の減少が予想外である状況も定義します。これらのケースを検出し、New Relic 統合エラーを介して通知するために最善を尽くします (以下のトラブルシューティングを参照)。

データの並べ替え

New Relic にデータポイントが順不同で到着する原因は、多くの場合にあることを理解しています。そのため、レポートの時系列に予期しないギャップが検出された場合は、データ ポイントをバッファリングして並べ替えます。ギャップは、特定の時系列のデータを受信するレートによって決定される予想レポート間隔によって推測されます。バッファリングは制限されており、最終的にはデータポイントを「再シーケンスするには遅すぎる」と見なします。この場合、検出されたギャップ全体でデルタが計算され、時系列の処理が続行されます。

古いデータ

デルタ変換はステートフルな操作であるため、レポートを停止し、最終的にその状態を落とす可能性がある時系列を認識する必要があります。timeseries が5 分間新しいデータ ポイントを報告しなかった場合、バッファされたギャップ全体のデルタの計算を含め、現在の状態をフラッシュします。これは、データ ポイントが後の時点で到着した場合、それがその時系列の始まりであるかのように扱われ、事実上、フラッシュ前の最後のデータ ポイントとフラッシュ後の最初のデータ ポイントの間のデルタが失われることを意味します。これは、デルタ変換の利点を得るには、メトリック レポート間隔を5 分未満にする必要があることを意味します。

累積額に関する特記事項

データがアプリケーションによって記録され、単調に増加する値のシーケンスとして送信されたとしても、そのデータに対してsum()を呼び出すと、データがデルタ値のシーケンスであるかのように扱われます。 derivative()を計算する必要はありません!

合計をデルタに変換する場合、New Relic はデルタと一緒に累積値も出力し、最新の累積値をクエリできる機能を維持します。累積値にアクセスするには、 getField()を使用できます (例については、 「メトリクスをクエリする方法」を参照してください)。

データ ポイントは、間隔の開始点である関連するtimestampsにプロットされることに注意してください。ただし、累積値はデータ ポイントのendTimestampに関連付けられているため、累積クエリを解釈するときにデータ ポイントの幅を考慮する必要がある場合があります。

トラブルシューティング

場合によっては、累積からデルタへの変換プロセスの結果として、 New Relic 統合エラーが報告されます。ここにいくつかの一般的な理由があります。

翻訳エラー

デルタ変換には、イベント時間に連続する 2 つのデータ ポイントが単調に増加する累積値を持つという仮定が含まれます。この想定が破られると予想されるのは、監視対象のプロセスが再起動されたときだけです。他の理由で単調性が失われた場合でも、これをリセットとして扱いますが、アカウントにNew Relic 統合エラーイベントを生成して通知を試みます。これは、 OpenTelemetry データに対しては可能ですが、 Prometheus に対しては可能ではありません。OpenTelemetry には、そのような状況を検出するために使用できるより多くの情報が含まれているためです。単調性の予想外の中断の最も一般的な原因は、クライアント側アプリケーションがカーディナリティの制限に達し、データを削除してメモリの負荷を軽減した場合です。場合によっては、これが予期しないリセットとして機能し、New Relic に送信される値が予期せず減少する可能性があります。OTLP ログでこれのインスタンスを探すことをお勧めします。

Instrument % has exceeded the maximum allowed accumulations (2000)

OpenTelemetry SDK を使用すると、カーディナリティ制限を構成できます。OpenTelemetry は、Views [ビューを]使用してクライアント側でカーディナリティを減らす方法も提供しており、これらの問題を解決するための推奨されるパスです。もう 1 つのオプションは、メモリの節約に役立つデルタ時間性を使用して OTLP メトリクスをエクスポートすることを検討することです。

カーディナリティ制限

変換中、システム保護として、メトリック資格に基づくメトリック カーディナリティ制限も緩やかに適用されます。ロールアップの場合のように 1 日あたりの制限を適用するのではなく、この制限は追跡される同時時系列の数として適用されます。同時の一意の メトリクス timeseriesが多すぎると、古い timeseries が期限切れになるまで、新しい受信 timeseries が削除されます ( 「古いデータ」を参照)。

累積指標のリセット

通常、累積メトリックのリセットは、それを報告しているサービスまたはアプリケーションが再起動したときに発生します。リセットされたメトリクスをクエリすると、メトリクスの値が減少したように見える場合がありますが、これは OpenTelemetry メトリクス仕様で説明されているように予期される動作です。通常のメトリクスのリセットと、予想外に減少して いる 問題のあるメトリクスを区別するには、 New Relic 統合エラーがないかアカウントを確認してください。値が減少しているメトリクスに関して統合エラーが報告されていない場合は、累積メトリクスを報告しているアプリケーションが再起動され、メトリクス値がリセットされている可能性があります。