DatadogのSysntetics監視のベストプラクティスを検討した時のメモ。 入門監視におけるデザインパターン「ユーザ視点での監視」を実装する際に、様々なLocationから外形監視を行うことが出来るDatadogのSynteticsは非常に有用であるが、とりあえずどう監視設定をいれておけばいいのかよくわからなかったので、整理してみた。
※DatadogのSynteticsは、通常の外形監視に加えて、ブラウザ操作の自動化テスト（ログインチェックなど）も出来るが、今回は通常の外形監視（API Test）のみ調べている。
Make a request
- リクエストを送るURLを指定する。以下の2点の考え方があると思っていて、適切な方を選択する。
- ユーザ視点での監視を考えて、サービスのトップページ（ログインページ）を指定する。（アプリケーションにヘルスチェックパスが実装されていない場合なども含む）
- アプリケーション視点での監視を考えて、アプリケーションにヘルスチェックパスを実装し、そのパスを指定する。
- HTTPリクエストメソッドを指定する項目があるが、ここもユーザ視点で考えると、一般的にはGETを選択しておけばよい。
- Name,TagはチームのDatadog運用ルールに基づいて適切な名前・タグを付与する。
- Locationsについては、監視対象サービスの提供する場所によって決めるべきだと考えている。
- 日本にのみ提供するサービスであれば、
Tokyo(AWS)のみでも構わないと思う。 - 当然国外のRegionリクエストを送ることも出来るが、物理的に距離が離れているため、Response Timeはどうしても遅くなる。
- 日本にのみ提供するサービスであれば、
How often should we run the test?は、外形監視の監視間隔を設定する項目。- 監視対象のサービスに求められるSLOにもよるが、メトリクス収集の意味でも1分間隔で実行しておくのが良い。
Alert Condition
alert condition
「どのような条件でエラーを検知しアラートをあげるか？」を定義する設定項目であるが、ここの設定項目の意味を理解するのに苦労した。。
An alert is triggered if any assertion fails for X minutes from any Y of N location
XとYが本設定項目で指定する値である。ちなみに、ここでのNは、前述の、外形監視リクエスト送るLocationの数である。
簡単に言うと、以下の設定項目にチェックを入れた数となり、下のケースではN=1になる。
公式ドキュメントを読み、挙動を整理してみたところ、どうやら、以下の条件を両方満たした場合に、アラートが発生することになるらしい。
- 最後のX分間、（少なくとも）指定した一箇所のLocationからの外形監視でエラーが発生し続けていた
- 最後のX分間のある瞬間に、少なくとも指定したLocationのY箇所で、同時にエラーが発生した
外形監視の間隔と、アラートとして評価するかというモニタ評価の間隔が異なるので混乱するのだが、モニタ評価は外形監視の間隔とは関係なく、1分毎に行われる。 モニタ評価のタイミングで、そのタイミングからX分間遡り、ずっと外形監視がエラーとなっている場合に、アラートを発生させる、という挙動になる。
X < 外形監視の間隔にすると、おそらく意味がないし、わかりづらい。。（外形監視間隔が5分なのに、モニタ評価が1分しか遡らないと、4分間くらいは同じ外形監視のエラーを拾い続ける）
また、外形監視の間隔=1にするのは、前述したとおり、メトリクス収集の意味でも妥当な選択である。
故に、以下の方針で設定するのがよいだろう。
監視間隔=1にする- 監視の要件に応じてXの値を増減させる
- 厳密に監視したい（リクエストが一回でも失敗したら即検知）なら0と指定
- 2回連続で失敗したら検知するようにしたいなら2と指定
N（Region数）=1にする- 国外に提供するようなサービスは別
Y=N=1にする- シンプルに1つ目の条件だけでアラートを上げるようにするため
statuscode/response time
status codeは、指定したパスが正しく動作した時に返すレスポンスコードを指定する（通常は200）- And条件で
response timeを指定しておくとよい。（秒数はサービスによる）
Notify your team
- 会社やチームによりけりだが、Slack通知、あるいはPagerdutyなどのSaaSと連携した電話通知を設定するのがよいだろう。
以上が、僕の考えるSyntetics監視のベストプラクティスである。 無論、ここの内容がそのまま全てのチーム・サービスに適用出来るわけではなく、チームの構成やサービスの特性によって、適宜設定項目を変更しながら利用する必要がある。