輸出条件年 = 2023; export const gaDate = '4 月 4 日'; const gaDateAndYear = gaDate + ', ' + 年をエクスポートします。
OpenTelemetry 統合またはPrometheus リモート書き込み統合から累積メトリクスを報告すると、New Relic がそのデータをどのように処理するか (たとえば、デルタ測定値に変換する方法) を理解するのに役立ちます。これは、New Relic UI ビューを理解し、データをクエリし、データ レポートの問題を理解するのに役立ちます。
累積指標と差分指標の説明
アプリケーションからメトリクス データを収集する場合、クエリ時にそのデータをどのように使用し、解釈するかを決定する際に、そのデータがどのように測定されたかを考慮することが重要です。 メトリクス タイプは重要な要素の 1 つであり、特定のNew Relic集計関数は一部のタイプでは機能しますが、他のタイプでは機能しません。 しかし、もうひとつの重要な要素はメトリクスのtemporalityです。
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 に順序どおりに到着しない原因は数多くあることは承知しています。 そのため、レポートの時系列に予期しないギャップが検出された場合は、データ ポイントをバッファリングして並べ替えます。 ギャップは、特定の時系列のデータを受信する速度によって決定される予想されるレポート間隔によって推測されます。 バッファリングには制限があり、最終的にはデータ ポイントが「再シーケンスするには遅すぎる」とみなされます。 この場合、検出されたギャップ全体のデルタが計算され、時系列の処理が続行されます。
古いデータ
デルタ変換はステートフルな操作であるため、レポートが停止し、最終的に状態が失われる可能性がある時系列に注意する必要があります。 時系列が5 minutesの新しいデータ ポイントを報告していない場合は、バッファリングされたギャップ全体のデルタを計算するなど、現在の状態をフラッシュします。 つまり、データ ポイントが後の時点で到着した場合、そのデータ ポイントはその時系列の先頭であるかのように扱われ、フラッシュ前の最後のデータ ポイントとフラッシュ後の最初のデータ ポイント間の差分が実質的に失われます。 つまり、デルタ変換の利点を得るには、メトリクスのレポート間隔を5 minutes未満にする必要があります。
累積額に関する特記事項
データがアプリケーションによって記録され、単調に増加する値のシーケンスとして送信されたとしても、そのデータに対してsum()を呼び出すと、データがデルタ値のシーケンスであるかのように扱われます。 derivative()を計算する必要はありません!
合計をデルタに変換する場合、New Relic はデルタと一緒に累積値も出力し、最新の累積値をクエリできる機能を維持します。累積値にアクセスするには、 getField()を使用できます (例については、 「メトリクスをクエリする方法」を参照してください)。
データ ポイントは、間隔の開始点である関連するtimestampsにプロットされることに注意してください。ただし、累積値はデータ ポイントのendTimestampに関連付けられているため、累積クエリを解釈するときにデータ ポイントの幅を考慮する必要がある場合があります。
トラブルシューティング
場合によっては、累積からデルタへの変換プロセスの結果として、 New Relic 統合エラーが報告されます。ここにいくつかの一般的な理由があります。
翻訳エラー
デルタ変換では、イベント時間で連続する 2 つのデータ ポイントの累積値が単調に増加するという仮定が行われます。 この仮定が破られると予想される唯一の状況は、モニターされているプロセスが再起動されるときです。 その他の理由で単調性が破られた場合も、これをリセットとして扱いますが、アカウントにNew Relicインテグレーション エラー イベントを生成して通知を試みます。 OpenTelemetry データbut not Prometheusではこれが可能です。OpenTelemetry には、このような状況を検出するために使用できるより多くの情報が含まれているためです。 単調性が予期せず中断される最も一般的な原因は、クライアント側アプリケーションがカーディナリティ制限に達し、メモリ負荷を軽減するためにデータを削除する場合です。 場合によっては、これは予期しないリセットとして機能し、New Relic に送信される値が予期せず減少する可能性があります。 OTLP ログでこのインスタンスを探すことをお勧めします。
Instrument % has exceeded the maximum allowed accumulations (2000)OpenTelemetry SDK を使用すると、カーディナリティ制限を設定できます。 OpenTelemetry は、 Viewsを使用してクライアント側のカーディナリティを減らす方法も提供しており、これらの問題を解決するための推奨パスです。 もう 1 つのオプションは、メモリを節約できるDelta temporality を使用して OTLP メトリックをエクスポートすることです。
カーディナリティ制限
翻訳中、システム保護として、Metriks の権限に基づいた Metriks カーディナリティ制限も緩く適用されます。 ロールアップの場合のように 1 日あたりの制限を適用するのではなく、この制限は追跡される同時時系列の数として適用されます。 同時実行されている一意の メトリクス 時系列が多すぎる場合は、古いものが古くなるまで新しい時系列が削除されます ( 「古いデータ」を参照)。
累積指標のリセット
累積メトリックのリセットは通常、それを報告するサービスまたはアプリケーションが再起動したときに発生します。 リセットされたメトリックをクエリすると、メトリックの値が減ったように見える場合がありますが、これはOpenTelemetryメトリック仕様で説明されている想定される動作です。 通常のメトリックのリセットと、予期せず減少する問題のあるメトリックを区別するには、アカウントにis New Relicインテグレーション エラーが ないか確認してください。値が減少しているメトリックに関してインテグレーション エラーが報告されていない場合は、累積メトリックを報告するアプリケーションが再起動し、メトリック値をリセットしている可能性があります。