New Relicのアラート作成で時間を指定する設定5つについて解説してみる
はじめに
mediba Advent Calendar 2022 と、
New Relic Advent Calendar 2022の8日目の記事となります。
みなさんNew Relicでアラート設定していますか?
おはこんハロチャオ!medibaでSREをしている北浦（@kitta0108）です。
今回はNew Relicでオンコール対応を初めとした通知機能を運用に実装しようとした際に、
お世話になるであろうAlert機能の中で、時間にまつわる設定値の話をつらつらと書いていきます。
弊社の中でも、この設定値は1つずつ紐解いていくのが困難でわからないという声が多くあがっていたので、筆をとってみました。
というわけで、この”時間”を指定する設定について、
- なぜ必要なのか
- どんな時にチューニングするのか
- 一旦は何も考えずに設定したいときはどうしたらいいのか
を紹介していきます。
読者想定
こんな方々へ何かしらの貢献ができる記事になるよう意識しています。
- New Relicでアラート設定をしたいモチベーションがある
- メトリクスの扱いに自信がない
- 今までなんとなくアラート設定していたので理解を深めたい
問題の設定値
時間を設定する値って5つもあるんですよねー。 今回は以下を解説していきます。
- Condition thresholds
- Signal loss expiration time
- Window Duration
- Slide by Interval
- Event flowのDelayまたは、Event TimerのTimer
お題
解説の便宜上、以下、2つの例を使っていきます。
- 例A(ALBのHealthy Host Countが0になったらアラートする)
SELECT max(aws.applicationelb.HealthyHostCount) FROM Metric FACET aws.applicationelb.LoadBalancer
- 例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする)
SELECT sum(aws.applicationelb.HTTPCode_Target_5XX_Count) FROM Metric FACET aws.applicationelb.LoadBalancer
1.Condition thresholds
アラートの閾値としての時間指定です。
例えば、above or equals 2 at least once in 1 minutesと指定した場合は、
少なくとも1分間に指定のメトリクスが2以上に上がった時、
アラート判定とする設定です。
アラートとして、メトリクスを見にいく頻度（回数）という見方もできます。
この時間は、短くすればするほど、
こまめにメトリクスが上がってないか見てくれるので、
解像度を高めることができます。
- 例A(ALBのHealthy Host Countが0になったらアラートする)
equals 0 at least once in 1 minutes
0になったらアラートなので、equals 0と指定します。
頻度に関しては、0となった時にすぐ連絡が欲しいので、1分間毎にします。
- 例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする)
above or equals 10 at least once in 5 minutes
10以上になったらアラートなので、above or equals 10と指定します。
頻度に関しては、5分間の総量を判定させたいので、5分毎にします。
2.Signal loss expiration time
メトリクスがNew Relicで受信できなかったときに、
Signal lossと判定させるまでの時間です。
- 例A(ALBのHealthy Host Countが0になったらアラートする)
ALBのHealtyHostCountメトリクスは
1分間に1回の頻度で集計されるメトリクスなので、
AWSからNew Relicに対しては、以下のように1分間に1回のペースでメトリクスデータが送られます。
しかし、このメトリクスデータがネットワークの揺らぎなどの原因により、
New Relicに3分間届かなかったとします。
このようなケースにおいて、アラートとしてどのような振る舞いをするべきか、
厳密な設定が可能です。
HealtyHostCountのケースでは生存確認の意を含んだアラートになる為、
3分間データが届かなかった場合は、
メトリクスデータが届いていないというアラートを起票するようにしたいです。
そのためsignal lost after 3 minutesでOpen New “lost signal” violationにチェックを入れます。
- 例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする)
HealtyHostCountは定期的に集計されて送られてくる継続データでしたが、
一方で以下のように、とあるイベントが発生したときだけ、
送るといった不定期なデータも存在します。
※画面例は4XXエラーです。5XXエラーはなかなか画面ショットを撮りたい時に発生してくれないものでしてあしからず。
このような不定期データをアラートとして扱う場合、
以下で説明するEvent Timer設定により詳細なコントロールが可能であるため、
無効化しておくことが個人的なおすすめです。
3.Window Duration
いつのメトリクスデータを評価するのかという枠の指定です。
1分間の合計を評価するのか、あるいは5分間の合計を評価するのか。
評価するための時間枠はここで設定します。
- 例A(ALBのHealthy Host Countが0になったらアラートする)
HealtyHostCountの場合、一度でも0だった場合、
不健全とみなし、アラート発報させたいので
可能な限り頻度の高い設定値にします。
このメトリクスデータは1分間集計なので、
Window Durationは1分間という枠にします。
- 例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする)
HTTPCode_Target_5XX_Countは5分間の合計値を1分間の頻度で確認したいため、
Window Durationは5分間に設定します。
4.Slide by Interval
Window Durationで指定した枠を、どのくらいスライドして評価させるかという指定です。
弊社でも多くの人の理解を挫折に導いた設定値ですが、
適切なアラートをさせるために重要な設定でもあります。
- 例A(ALBのHealthy Host Countが0になったらアラートする)
このケースでは使いません。
- 例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする)
Window Durationを5分間に設定した場合、このSlide by Intervalの設定をしないと、 5分間に1回の評価しかできません。
5分間の集計を1分間の頻度で評価をするためには、 5分間集計を1分間毎にスライドさせて評価する必要があります。
これを実現させるために、このケースではSlide by Intervalの設定を1分間に設定します。
5.Event flowのDelay または、Event TimerのTimer
Streaming Methodによって、より確実に集計するための設定です。
メトリクスデータが継続的なものか、不定期なものかによって、
Event Flowを使うか、Event Timerを使うか変わってきます。
Cadenceという設定もあるのですが、
現在では非推奨設定なので、選択肢からは除外してよいでしょう。
- 例A(ALBのHealthy Host Countが0になったらアラートする)
HealtyHostCountは継続データなので、Event Flowを使います。
結論から伝えると2分間のDelayを設けます。
この設定を入れることにより、現在の時刻が12:02だった場合、11:59 ~ 12:00のメトリクスデータを評価するようになります。
Signal lossの箇所でも解説した通り、
メトリクスデータはリアルタイムで届かない可能性があり、
その考慮がないと適切な評価ができず、
閾値を超えているのにアラート判定がされない…という状況が起きかねません。
2分間のDelayを設けることにより、
メトリクスデータが到着している可能性を高めることができます。
ここは確実性と検知スピードのトレードオフになるので、
適切なチューニングが必要とされます。
まぁ、2分間も設けておけば、検知スピードとして問題となるケースも少ないでしょう。
- 例B (ALBのHTTPCode_Target_5XX_Countが10以上になったらアラートする)
HTTPCode_Target_5XX_Countは不定期データなので、
Event Timerを使います。
結論から伝えると5分間のTimerを設けます。
この設定をいれることにより、
12:00に初回のメトリクスデータが到着した場合、
その時点から5分間のタイマーがセットされます。
その後、12:03に2回目のメトリクスデータが到着した場合、
その時点から追加で5分間のタイマーがセットされ、
12:08に12:00 ~ 12:05のメトリクスデータが評価されます。
このTimerは仕組み上、
Window Durationよりも少ない時間を指定することがは非推奨なので、
その点は注意しましょう。
おわりに
ざざっと該当項目に関して解説してみましたがいかがでしょうか。
例などを出してわかりやすくしたつもりではありますが、
改めて見返しても、
必要となる前提知識や背景などの情報量の多さ故に腰を据えてみていかないと理解が難しい側面はあるかもしれません。
何かしらアラート設定でつまづいた時にでも、
こんなこと書いてたやつがいたなーと思い出してもらえたら幸いです。
ちょっとだけ宣伝
NRUG(New Relic User Group)：通称ぬるぐ というユーザーグループがあります。
弊社でも板谷（@mary_tuba）がNRUGの運営、
僕がNRUG SRE支部の運営を勤めておりまして、直近の予定は以下になります。
12/14(水) NRUG Vol.5 Day1 1周年だよ!全員集合!! https://nrug.connpass.com/event/265357/
12/15(木) NRUG Vol.5 Day2 交流会 https://nrug.connpass.com/event/266747/
?/? NRUG SRE支部 Vol.3 来年春頃まで必ずやりたい…!!
気になる方は是非チェックしてみてください！
