この記事は、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 分に設定した時のグラフですが、データの山谷が激しいことを確認できます(激しいか?)
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 分などにしてみると以下のようなグラフになります。
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 設定関連で参考になるリンクなので興味があれば是非見てみてください！
追伸
感謝賞いただきました🎉
絶賛採用中です！
イオンスマートテクノロジーではエンジニアをはじめとした様々な職種を積極的に採用中です！
これからとてもおもしろいフェーズへ突入していくと思いますので興味のある方は是非カジュアル面談などで話を聞いてください！
Discussion