はじめに
Datadog Syntheticsで外形監視を行うと、テスト実行結果から得られるメトリクスが収集されることはご存知でしょうか？
このメトリクスをさらに監視することで、2段構えの監視ができます。
今回の記事では自分たちが実際に使っている監視テクニックを紹介します。
Synthetics実行結果から得られるメトリクス
Syntheticsではテストを作成すると、テスト結果がDatadog内でメトリクスとして保存されます。
たとえばHTTPテストなら、以下のようなメトリクスが自動で収集されます。
-
synthetics.http.response.time（レスポンスタイム） -
synthetics.http.response.size（レスポンスサイズ） -
synthetics.test.run.count（実行回数）
これらは他のメトリクスと同じように扱えるため、これらを監視するMonitorを作成することも可能です。
ここに目をつけ、以下のような2段構えの監視設定を作成することにしました。
以降、Syntheticsそのものの設定を「Synthetics本体」、Synthetics実行によって収集されるメトリクスを「Syntheticsメトリクス」と呼びます。
- Synthetics本体がエラー → 緊急度の高いアラートとしてメンション付きで通知
- Syntheticsメトリクスでレスポンスタイムが遅くなっている → 緊急度の低いアラートとしてメンションなしで通知
Synthetics本体は緊急度の高いアラートとして設定
Synthetics本体の設計方針は「緊急度の高い問題を検知し、即座にアラート」とします。
アラート発報にかかる時間を短縮
設定画面の「An alert is triggered if your test fails for X minutes」にて、FAILEDになってからアラート発報までの時間を最短1分まで短くできます。
1 minute from any 1 location とすると最速でアラートとなる
ただし、1回のFAILEDでもアラートになるため、誤報を防ぐよう次の対策をあわせて行います。
FAILED条件を厳格に
Syntheticsでは「ステータスコードが200以外」や「レスポンスタイムが遅い」といった条件で判定することが多いと思います。
ここでは、「明らかにつながらない」といえる値を閾値にするのがポイントです。
例えば、FAILEDとみなすレスポンスタイムを「ちょっと遅いかな？」程度の値にすると、「重いけど使えてはいる」という場合にもアラート扱いになります。
即座に通知が届くようにする分、本当に緊急対応が必要な場合にのみアラート扱いとすべきです。
なので、レスポンスタイムは「これだけ遅かったらダウンしていると言っていい」程度の値まで伸ばします。
参考まで、私がウェブサイトの監視に利用しているSyntheticsでは、レスポンスタイムの閾値を15秒としています。
リトライを丁寧に
一時的なネットワーク不調など、システム側の問題ではないのにアラート扱いとなるのは避けたいです。
そこで、1回のFAILEDとみなすまでのリトライ設定を調整します。
例えば「3秒おきに3回」というように広めのリトライ間隔にしておくと、合計10秒近くかかるため、一時的な異常であれば回避しやすくなります。
なお、リトライ回数も増やせるとよかったのですが、最大3回が上限です。
アラート発生時は鬼電！！！
ここまでしたら「本当にやばいアラート」として深夜に叩き起こされても本望です。（？）
アラートが発生した場合は、Slackでメンションが来るのに加え、DatadogのOn-Call機能でチームメンバーに順番に電話がかかってくるよう設定しています。
Syntheticsメトリクスは緊急度の低いアラートとして設定
Synthetics本体を「明らかにつながらない」場合のみ通知するようにすると、「ちょっと遅いかな？」程度の軽微な異変は取りこぼしてしまいます。
そこで、Syntheticsメトリクスを使って、軽微な異変を見逃さないようにします。
ちょっと遅いかな？が引っかかる閾値
今回はSyntheticsメトリクスの synthetics.http.response.time を使ってMonitorを作ります。
ここでの閾値は、さきほどのSynthetics本体とは逆に「ちょっと遅いかな？」程度の値にします。
今回はSynthetics本体の閾値を15秒に設定したため、こちらはそれより小さい値を設定します。
- Warning: 3秒を超えたら
- Error: 10秒を超えたら
ちょっと遅いかな？が引っかかるように
翌営業日に気付ける程度の通知
「ちょっと遅いかな？」程度の軽微な異変であれば、メンションや電話で即時通知する必要はなく、翌営業日に気付けば十分です。
そのため通知方法としては「メンションなしのSlack投稿」とします。
実際に役に立った例
ある日、出勤するとSlackの通知チャンネルにWarnとRecoveredの通知が交互に来ていました。
通知チャンネルに大量の通知
しかも最後に発生したのがWarn、つまりまだ復旧していない！
この日の状況としては、深夜からレスポンスタイムが遅くなり、ギリギリ閲覧はできるものの体感かなり重い状況でした。
深夜から重い状態が続いていた
出勤してすぐ調査を始め、午前中に復旧できました。
負荷が高まり続けている状態で、このまま放置すればサイトが落ちていたかもしれないため、気付けるようにしておいてよかったです。
逆に言うと、それぐらい急がなくてもいい異変だったので、メンションや電話で呼ばれなかった点もちょうどいい塩梅だと感じました。
まとめ
Syntheticsは使いたいが、緊急度ごとに挙動を変えたい、しかしSyntheticsを2つ用意すると料金が2倍かかる……と悩んでいたところにSyntheticsメトリクスを見つけて、これだ！となりました。
Syntheticsで監視するなら、ぜひ「1粒で2度おいしい」Syntheticsメトリクスも使ってみてください！
Discussion