累積合計メトリクスがCumulative Countタイプとして扱えるようになりました

はじめに

OTLPメトリクスパイプラインは、累積合計メトリクスの処理方法をより適切にサポートするために日々Updateされています。この一環として、累積合計の基礎となるメトリクスデータタイプをgaugeタイプからcumulativeCountタイプに移行しています。このタイプを使用すると、登録されたデータの累積値とデルタ値の両方を簡単に照会できるようになります。New Relicもこれに追随し、累積合計メトリクスの扱いをguageからcumulativeCountへ移行していくことになりました。これに伴い、既存のNRQLクエリの実行結果が変わる可能性があります。

本Postでは、影響範囲や移行スケジュール、具体的な対応方法について解説していきます。

影響を受ける可能性があるお客様

2023/04/04以前から、Opentelemetryを利用して累積タイプのメトリクスをNew Relicに送信している場合に影響を受ける可能性があります。

Prometheusを使用して累積合計メトリクスを登録している場合は影響ありません

影響の内容

累積合計メトリクスに対するチャートやアラートを利用している場合、EoL後にクエリ結果が変わる可能性があります。

移行スケジュール

2023年4月4日以降、次のサポート終了 (EoL) タイムラインに従って累積合計メトリクスを取り込みます。

2023年4月4日

メトリクスタイプとして累積合計メトリクスであるcumulativeCountタイプが有効化されます。このメトリクスタイプをguageとして取り込む経験は非推奨になりました

この日付より前に累積合計メトリクスを送信していたアカウントは、gaugeタイプとしての取り込みを引き続き使用できます
その他のアカウントには、累積合計メトリクスがある場合はcumulativeCountメトリクスタイプとして取り込まれるようになりました

4月4日～10月21日

非推奨のguageタイプへの取り込みを使用するアカウントは、cumulativeCountタイプの取り込み方式に変更することができます。早期の変更は、使用しているクエリやアラートが EoL によって影響を受けないようにするための最良の方法です

2023年10月22日以降

すべてのアカウントは、累積合計メトリクスはcumulativeCountタイプに順次移行されます（従来のguageタイプへの取り込みは廃止されます）

具体的な対応方法

4月4日より前に累積合計タイプのメトリクスを取り込んでいた場合、この期間で、影響を受けるメトリクスを利用するクエリとアラートを任意のタイミングで更新することができます。

本Postではこの変更に対して具体的に何をすれば良いのか、以下ような具体的な対応方法についてご案内します。

ご利用のアカウントが影響を受けるかどうかを確認する手順
具体的なクエリの変更方法
EoL前に手動でcumulativeCountタイプに切り替える手順

影響があるメトリクスがあるか確認する

ご利用のNew Relicアカウントが2023年4月4日以前に累積合計メトリクスをNew Relicに送信していた場合、2023年10月22日にEoLの影響を受けることになります。

お客様のアカウントが影響を受けているかどうかを確認するには、以下のNRQLクエリを実行してください。このクエリは、過去24時間以内にこのEoLの影響を受けたメトリクスが登録されている場合に結果を返します。

FROM NrIntegrationError SELECT count(*)
WHERE newRelicFeature = 'cumulativeSumAsGaugeEoL'
SINCE 24 hours ago

さらに詳しく調べるには、以下のクエリを実行してどのメトリクスが影響を受けているかを確認することができます。これらのメトリクスに関連するモニタリングやアラートは、EoLの日付が変わる前に見直し、更新する必要がある場合があります。

FROM NrIntegrationError SELECT uniques(metricName)
WHERE newRelicFeature = 'cumulativeSumAsGaugeEoL'
LIMIT MAX SINCE 24 hours ago

既存のクエリを変更する

クエリの変更方法について、累積合計メトリクス(metricName)のシンプルな以下のクエリを例にとって説明します。

FROM Metric SELECT latest(<metricName>)

このクエリは、EoLまではgaugeタイプのlatest値(=累積合計)を評価することになりますが、EoLが発生するとmetricNameに関連付けられた基礎となるメトリクスタイプはcumulativeCountに変更され、デルタ値が返されるようになります（詳細は"Applendex: 結果が変わる仕組み"を参照してください）。
よって、明確にguageによる累積合計値を求めたい場合は以下のようなクエリに変更する必要があります。

FROM Metric SELECT latest(<metricName>)
WHERE <metricName>[type] = 'gauge'

なお、同じように明確にcumulativeCountによる累積値を求めることもできます。

FROM Metric SELECT latest(<metricName>[cumulative])
WHERE <metricName>[type] = 'cumulativeCount'

OpenTelemetryのベストプラクティスでは、gauge と cumulativeCountの各メトリクスタイプについて、累積合計を求める場合とデルタ値を求める場合のクエリの詳細を解説していますので、こちらも参照してください。

EoL前に手動でcumulativeCountタイプに切り替える手順

累積合計メトリクスは、EoLまではgaugeタイプとして保存され続けますが、EoL前にcumuativeCountタイプを試して、クエリやアラートが期待通りに動作していることを検証することができます。cumuativeCountタイプを早期に試すには、New Relicに送信するOTLPデータに以下の属性を追加します。

newrelic_metric_type=cumulativeCount

コードベースで直接送信する場合

コードベース内でOTLP計測ライブラリを使用している場合、アプリケーションに適した言語のSDKを参照する必要があります。newrelic_metric_type=cumulativeCountという属性を個々のメトリックデータポイントやリソース属性レベルに追加する方法であれば、十分でしょう。

ここでは、Java SDKでレポートメトリックに直接属性を追加する例を紹介します。

final var meter = openTelemetry.meterBuilder("manual-instrumentation-scope")
                .setInstrumentationVersion("1.0.0")
                .build();
final LongCounter counter = meter.counterBuilder("myCumulativeCounter")
                .build();
counter.add(1, Attributes.of(stringKey("newrelic_metric_type"), "cumulativeCount"));

コレクター経由で送信する場合

OTLPモニタリングのソースがOTLPコレクターから来る場合、OpenTelemetryattributes processorを使って、エクスポーターに送信する前に属性を追加することができます。

例えば次のスニペットは、newrelic_metric_type=cumulativeCount属性を挿入します。

…
attributes:
  actions:
    - key: newrelic_metric_type
      action: insert
      value: cumulativeCount
…
service:
  pipelines:
    metrics:
      …
      processors: [...,attributes,...]
      …

重要
newrelic_metric_type=cumulativeCountの送信を開始すると、受信した累積合計メトリクスがcumulativeCountタイプに変換されて登録されるようになります。つまり、gaugeタイプをターゲットとして設定された既存のクエリーやアラートは、予期しない結果を受け取ることになります。cumulativeCountの体験をテストする際にはこの点に留意してください。gaugeタイプに戻すにはnewrelic_metric_type属性の設定を止めるだけです。必要に応じてテストとして既存のメトリクスは残しつつ、newrelic_metric_type=cumulativeCountを設定したメトリクスを追加で送信し、その違いを確認してみてください。

結果を確認する

newrelic_metric_type=cumulativeCountを設定した後、以下クエリで正しく受信できているかどうか確認できます。無事にcumulativeCountタイプのデータが送られてきていることを確認できたら、前述した方法でクエリを確認し、期待結果が得られているかを確認し、問題があれば必要に応じてクエリを変更しましょう。

FROM Metric SELECT count(*) WHERE %[type] = 'cumulativeCount' TIMESERIES

さいごに

この変更はOTLPのパイプラインの仕組みのupdateに伴い、累積合計メトリクスの扱いが変更されたことに合わせたupdateになります。常に最新の状態を保つことで、より効率の良いデータ保管および分析が可能になります。ぜひこの期間で最新のデータの取り扱いについて理解し、活用できるようにしていきましょう。

Applendex: 結果が変わる仕組み

OTelで累積合計メトリクスを送信している場合、New Relicではguageタイプでは以下のように登録されます。

{"type": "gauge", "count": 1, "sum": 300, "latest": 300} 
{"type": "gauge", "count": 1, "sum": 200, "latest": 200} 
{"type": "gauge", "count": 1, "sum": 100, "latest": 100}

これがcumuativeCountに移行されると以下のように登録されるようになります。

{"type": "CumulativeCount", "count": 100, "cumulative": 300} 
{"type": "CumulativeCount", "count": 100, "cumulative": 200} 
{"type": "CumulativeCount", "count": 100, "cumulative": 100}

この状態で以下のクエリを実行すると、結果が変わります。

FROM Metric SELECT latest(<metricName>)

gaugeタイプのlatest値(=累積合計)を評価することになり、300が返ります。
cumulativeCountでは、デフォルトではcountに登録されている100（=デルタ値）が返るようになります。

よってこのようなクエリでアラートや可視化を行っている場合は明確に以下のようなクエリに書き換える必要があります（metricNameの後ろに[cumulative]を追加する）。

FROM Metric SELECT latest(<metricName>[cumulative])

By 会澤康二, 技術統括コンサルティング部担当部長

SIerにてシステム開発プロジェクトのPMやインフラ設計・構築などを歴任。その後、クラウドインテグレーション組織の立ち上げを行い、多くのお客様システムのクラウド移行を支援。近年はDevOpsやクラウドネイティブ化へ向けたコンテナやKubernetes、CI/CDなどの技術要素の導入支援を行い、現職。

The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.

780+ integrations to start monitoring your stack for free.

See All Integrations

In this article