さぁ、ICMPポーリングをSynthetic Monitroingで実施して可視化もできたぞと威張っていたら、『アラートのことを忘れてはいませんか？(紳士的)』と聞かれたので、どのようなアラートを設定すればいいかを考えてみました。アラート道に絶対の正解はないので、是非、こんなケースだとどんなアラートを設定すればいいのだろうという議論の出発点に慣れれば本望です。
New Relic株式会社のQiita Organizationでは、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
はじめに
前回はICMPポーリングをSynthetic Monitoringで行った結果を可視化した内容を共有してみたので、今回はアラートを設定してみようかと思います。
色々なアラート設定はあるかと思うのですが、以下の良くリクエストされる3つのケースを考えてみたいと思います。
- 一定期間連続でICMPポーリングの結果が失敗したケース
- 応答速度がいつもよりも大きく劣化したケース
- Synthetic Monitoringで1回のサイクルが適切に完了しなかったケース
色々な要件があるかと思うので、上記以外に有用なアラート設定アイデアがあれば教えてもらえると嬉しいです。
早速アラートを設定してみる
以前、取りまとめのためのQiita記事も書いておりますので、参考にして頂けると幸いです。
上記のQiita記事内でも触れていますが、アラートの設定方法はオンデマンドのトレーニングを受講して頂くのが最短最速の方法だと感じています。アラートの設定方法を理解したいと思われている方は是非、下記の画像のリンクから受講を検討してください。
一定期間連続でICMPポーリングの結果が失敗したケース
早速、アラートの設定を考えてみましょう。ここで大事なのは各ポーリング対象のレスポンスを得ることができなかった時(Resultカラムの値が、successからfailedとなった)に、気づけることです。
また、failedの状態が継続している場合、ポーリングする度にアラートが発報してしまうと、恨みつらみしか生まれませんね。
こんな感じで設定してみました。
SELECT average( if(Result = 'success', numeric(1), numeric(0)) ) AS 'Status'
FROM CustomSyntheticICMPPolling
FACET `Host Name` AS '対象名称'
その他の主要設定として、
- Window duration: 1 minutes (Synthetic Monitoringのポーリング周期に合わせてみました)
- Streaming method: Even flow (定期的にポーリングされており、その都度データが送信されることを想定)
- Delay: 30 seconds (これはあまり強い根拠はありません。。数秒でも良いかもしれません。)
- Set condition thresholds: Static (評価するデータ値は、0または1のため)
- When a query return a value: below 1 for at least 1 minutes
Alert conditionでNRQLを設定する際は、TIMESERIES句やSINCE句は不要となります。
複数のポーリング対象が同時にfailedと検出されたので、まとまった形となっていますね。別々にしたい場合は、Alert policyの集約条件や、Workflow上で付加情報を追加するなどの設定を行うことでより詳細な情報を通知することが可能です。
SLACKに通知したら、以下のような結果を得ることができました。
アラートの詳細を確認したい時は、Alerts → Issues & Activityに進んで、IssuesやAlert eventsの詳細をご確認下さい。
応答速度がいつもよりも大きく劣化したケース
SELECT average(ResponseTime)
FROM CustomSyntheticICMPPolling
FACET `Host Name` AS '対象名称'
WHERE Result ='success'
その他の主要設定として、
- Window duration: 1 minutes (Synthetic Monitoringのポーリング周期に合わせてみました)
- Streaming method: Even flow (定期的にポーリングされており、その都度データが送信されることを想定)
- Delay: 30 seconds (これはあまり強い根拠はありません。。数秒でも良いかもしれません。)
- Set condition thresholds: Anomaly (いつもと違うことを検知したいため)
- Threshold direction: Upper only (応答時間が大きくなった場合のみを捉えたいため)
- When a query return a value outside the threshold: by 3 standard deviation(s) for at least 2 minutes (2回連続で標準偏差3以上の外れ値を示したら。ここは環境によりチューニングの余地は多分にあると思います!!)
アラートの閾値設定に絶対の正解はないので、必ず環境に合わせて調整を行なって下さい。
もし、応答時間が具体的な値以内で応答するという要件があるようであれば、Anomalyの代わりにStaticを用いるなども現実的な設定になります。
アラートは一定期間(デフォルトでは3日)が経過すると自動クローズする設定となっています。この期間はアラート設定全体とAlert condition毎の設定ができ、短い設定の方が適用されます。
Synthetic Monitoringで1回のサイクルが適切に完了しなかったケース
FROM SyntheticCheck
SELECT average( if(result = 'SUCCESS', numeric(1), numeric(0)) ) AS 'result'
WHERE monitorName IN ('Synthetic ICMP Pinger')
FACET monitorName
WHERE句内でIN ('xxx')を持ちいているのは、複数のモニタ設定を作成するケースを想定しているためです。例えば、IN ( 'xxx', 'yyy', 'zzz')と記載することで複数のモニタ設定を対象とすることができます。
その他の主要設定として、
- Window duration: 1 minutes (Synthetic Monitoringのポーリング周期に合わせてみました)
- Streaming method: Even flow (定期的にポーリングされており、その都度データが送信されることを想定)
- Delay: 30 seconds (これはあまり強い根拠はありません。。数秒でも良いかもしれません。)
- Set condition thresholds: Static (評価するデータ値は、0または1のため)
- When a query return a value: below 1 for at least 1 minutes
- Consider the signal lost after: 3 minutes
- On signal loss: Open new "lost signal" alert event. Notification sent based on issue creation preference: 有効化(チェックを入れる) (それ以外はチェックを外す)
signal lossの設定は、一定期間データが到着しなかった際に異常を通知するアラートを発報する仕組みです。
設定しすぎると、アラートが大量に発生する要因になり得ますが、効果的に使うことで障害状況や異常を素早く把握することが可能です。
さいごに
如何でしょうか？アラートを適切に設定することで、異常状態の発生や予兆を素早く把握することが可能です。アラートの設定に正解はない(アンチパターンはある(涙))ので、そういった情報も今後は積極的のご報告できれば幸いです。
無料のアカウントで試してみよう！
New Relic フリープランで始めるオブザーバビリティ！
