🆕

New Relic Alert 閾値チューニング入門

Tocyuki

2023/12/06に公開

この記事は、AEON Advent Calendar 2023とNew Relic Advent Calendar 2023の6日目です🎉

New Relic Alert 閾値設定難しすぎﾜﾛﾀｧ

以下の図にあるような設定項目を全部理解して設定できているという方はさっさと帰っていただいて結構ですが（うそですごめんなさい）、それぞれのパラメーターの意味がよく理解できずStatic Threshold Typeのみでなんとなく閾値設定頑張っている、という方も多いのではないでしょうか？（知らんけど）

特にWindow durationやStreaming method、Gap filling Strategyあたりは仕組みが少々複雑でなかなか理解するのが難しくNewRelic初心者の方々には取っ付き難い部分かと思います（ワイもよくわかってない説ある）

ここをすべて理解して設定していると言えるのかい？

New RelicではAlertの閾値を以下のさまざまなパラメーターにより、きめ細かく柔軟に設定できます。
本記事ではそれぞれのパラメーターで最低限抑えておくと良い部分を中心に説明していこうと思います！

Threshold Type
- Static
- Anomaly
Data Aggregation
- Window duration
- Sliding window aggregation
Streaming method
- Event flow
- Event timer
Gap filling Strategy

Threshold Type

New Relic Alert 閾値設定の基本のキであるThreshold Typeは間違いなく抑えておきましょう！
これは閾値をどのように検知するかを決める設定で、Static(静的検知)かAnomaly(異常検知)を選択できます。

Static/Anomalyがそれぞれどのようなパラメーター、ユースケースで選択するかについては以下の通りです。

パラメーター	説明	ユースケース
`Static`	あらかじめ設定した静的な閾値の超過有無で判定	良し悪しを判断できる明確な基準が設けられる場合
`Anomaly`	過去のデータに基づいて予測された正常範囲からの逸脱有無で判定	周期性の異常を判定したい場合や良し悪しを判断できる明確な基準や材料がない場合

もう少し深掘りしていきます。

Static

前述の通りあらかじめ設定した静的な閾値の超過有無で判定する設定ですが、グラフで見るとわかりやすいかと思います。

赤い線が閾値で赤色の範囲が検知した箇所

こんな感じで設定項目もシンプル

閾値超過の評価方法

Threshold Type Staticの評価方法は以下の2通りです。

評価方法	説明
`for at least XX minutes`	XX分間閾値を超過する状態が続いたらインシデントがオープンされる
`at least once in XX minutes`	XX分間の間に1回でも閾値を超過したらインシデントがオープンされる

画像の例だとWhen a query returns a value above 1 for at least 5 minutesとなっているのでクエリ結果の値が1以下でその状態が5分間継続した場合にインシデントをオープンする設定になっています。

前述の通り、良し悪しを判断できる明確な基準が設けられる場合のユースケース、たとえば「CPU使用率が90％を超えた場合」などのアラートを設定したい場合などに有用です。

Anomaly

前述の通り過去のデータに基づいて予測された正常範囲からの逸脱有無で判定する設定ですが、こちらもグラフで見るとわかりやすいかと思います。
画像の灰色の範囲を逸脱すると異常と見做されインシデントがオープンされます。

Anomalyの場合、Staticに比べThreshold directionという設定項目が増えています。

Threshold direction

Upper and lower, Upper only, Lower onlyが選択でき、値に対してどの方向へのびた場合に検知するかを設定できます。

例えばUpper onlyだとこんな感じで値がいくら低くなっても検知しません。

Standard Deviation

Staticでは静的な値を閾値で設定しましたがAnomalyの場合、標準偏差を指定します。
標準偏差の値の増減で正常といえる範囲を設定します。

標準偏差を3にした場合と6にした場合のグラフを見比べてみてみましょう。

標準偏差を3にした場合

標準偏差を6にした場合

こんな感じでSeverity levelのWarning/Criticalで標準偏差の値を変えて設定し、運用の中で必要に応じて値をチューニングしていくと良いでしょう。

Window duration

Window durtionについての説明に関しては以下の記事を見ていただくのをオススメします。

記事から引用しますがWindow durationとは

評価対象のデータを集約する期間を定義するものです。
1minであれば1min範囲内のデータが集約対象、2minであれば2min範囲内のデータを集約します。

とのことなのですが、もしかしたらちょっとわかりづらいかもしれないので図も引用します。

どんな時に使うと良いのか

基本的にはデータの山谷が激しいく、短期間の集約では適切に評価できないようなデータでのアラート設定時に利用するのが良いと思います。

以下はスループットのアラート設定時にWindow durationを1分に設定した時のグラフですが、データの山谷が激しいことを確認できます(激しいか?)

NRQL

SELECT rate(count(apm.service.transaction.duration), 1 minute) AS 'Throughput' FROM Metric WHERE entity.guid IN ('XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX') FACET appName TIMESERIES 1 minute SINCE 6 hours ago

Window durationを1分に設定した時のグラフ

もっと平滑化したデータで評価をしたい、となった場合にWindow durationを例えば5分などにしてみると以下のようなグラフになります。

NRQL

SELECT rate(count(apm.service.transaction.duration), 1 minute) AS 'Throughput' FROM Metric WHERE entity.guid IN ('XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX') FACET appName TIMESERIES 5 minute SINCE 6 hours ago

Window durationを5分に設定した時のグラフ

Window durationを大きくした場合の注意点もあるので以下に引用します。

なお、Window durationを大きくした場合、集約する期間が広がるため、アラート通知のタイミングもそれに従います。つまり、Window
durationが2minであれば、最短2min間隔となります。Window durationを広げつつ、アラート通知タイミングを細かくしたい場合は、Sliding
windowを利用して評価範囲をオーバーラップさせます。

というわけでWindow durationを広げるが、アラート通知タイミングを細かくしたい場合にはSliding window aggregationを利用してあげる必要があります。

Sliding window aggregation

Sliding window aggregationについての説明に関しても以下の記事を見ていただくのをオススメします。

そしてこちらも図の方が理解しやすいので、図を引用します。
図の通り、評価範囲をオーバーラップすることでfor at least XX minutesやat least once in XX minutesなどで設定する評価期間を短く設定できるようになります。

Streaming method

Streaming methodは特定の集計ウィンドウのデータが揃ったことを判定するロジックとなり、現在、Event flow, Event timer, Cadenceの3種類のロジックが用意されています。

こちら中々説明が難しいので簡単にまとめると以下のような使い分けをすると良いのかなと思います。

Streaming method	ユースケース	具体例
Event flow	コンスタント且つ高確率で届くデータ	APM/Infrastructure/Browserエージェントなど
Event timer	発生や到着にムラのあるデータ	API PolingによるCloud IntegrationやMobileエージェントなど

より詳細については以下も参照してみてください。

Gap filling Strategy

Gap filling Strategyは欠損データの取り扱い定義に関するパラメーターです。
よくわからずnoneを選択する場面も多いと思いますが、データの欠損がクリティカルな影響を与える場面ではCustom static vlaueでアラートを上げるような値を入れたり、妥当な値を入れるなどの調整をすると良いでしょう。
また、値が予測可能で短時間で大きく変化しない場合などはLast known valueを設定すると良いでしょう。

パラメーター	説明
`none`	欠損のまま扱う
`Custom static value`	固定値で埋める
`Last known value`	前出の値で埋める

詳細については以下を参照してみてください。

まとめ

Threshold Typeは基本なのでしっかり理解して設定する
データを平滑化して評価したい場合Window durationを大きくし、Window durationの値よりも通知のタイミングを細かく設定したい場合にはSliding windowを利用する
Streaming methodは特定の集計ウィンドウのデータが揃ったことを判定するロジックのこと
- Cadenceは非推奨のため利用しない
- 継続的に送られるようなデータ（APM/Infrastructure/Browserエージェントなど）を取り扱う場合Event flowを利用する
- 発生や到着にムラがあるようなデータ（API PolingによるCloud IntegrationやMobileエージェントなど）を取り扱う場合はEvent timerを利用する
Gap filling Strategyは欠損データの取り扱い定義に関するパラメーターのこと
- noneは欠損のまま扱う
- データの欠損がクリティカルな影響を与える場面ではCustom static vlaueでアラートを上げるような値を入れたり、妥当な値を設定する
- 値が予測可能で短時間で大きく変化しない場合などはLast known valueを設定する

参考

以下、New Relic Alert設定関連で参考になるリンクなので興味があれば是非見てみてください！

追伸

感謝賞いただきました🎉

絶賛採用中です！

イオンスマートテクノロジーではエンジニアをはじめとした様々な職種を積極的に採用中です！
これからとてもおもしろいフェーズへ突入していくと思いますので興味のある方は是非カジュアル面談などで話を聞いてください！

https://hrmos.co/pages/ast

GitHubで編集を提案

AEON TECH HUBPublication

AEONグループのテックブログです！今後様々なグループ会社を巻き込みながらAEONのテクニカルな側面をお届けしていきます！（いきたい！）