Datadogを利用した外形監視について考えてみた。

一言に運用監視と言っても監視内容は多岐に渡ります。

• 死活監視
• トラフィック監視
• ネットワーク監視
• ログ監視
• などなど。

こうして挙げただけでも「やっぱり運用監視って大変だなぁ」という印象を抱いてしまいます。

では、そもそもなぜ監視が必要なのでしょうか？

それはITサービスの多くが、わずか数分のシステムダウンが起こっただけで甚大な影響を受けてしまうからです

システムがダウンすることにより、一時的な売上減少といった直接的な損失を被るだけでなく、顧客や取引先からの信用を失ってしまうと将来的な機会損失につながることもあります。

「たかがシステムのトラブル」と片付けられないのが現代のIT社会の怖さではないでしょうか。

こういった事態を発生させないように、システムの稼働を可視化し、異常が認められた際には迅速に対応してシステムを復旧させる、もしくはトラブルの予兆を早期に検知して先手を打つといったことが求められます。

これが監視が必要とされる理由です。

平常時（システムが安定稼働しているとき）にはあまり意識することがなくても、こうして改めて整理して書き連ねてみると運用監視がいかに重要かということを再認識させられます。

前置きが長くなってしまいましたが、ここからが本題の外形監視のお話です。

私の担当するシステムでも、少し前から遅ればせながらDatadogを利用した外形監視を始めました。

目的は前述したトラブルの予兆を早期に検知すること。

DatadogにはSyntheticsという外形監視機能があり、APIテストとブラウザテストの二種類が利用可能です。

今回はその中のAPIテストにフォーカスしてお話します。

APIテストでは、APIエンドポイントを監視して失敗や遅延が起きた場合にアラートを受け取ることができます。

このチェックによって、アプリケーションがリクエストに応答していることや、応答時間・HTTPステータスコード・ヘッダ・本文の内容など、定義された条件を全て満たしていること（Webサイトが正常に稼働していること）を検証できます。

では早速APIテストを作成していきます。

まずは、検証するAPIを選定します。

選定の基準は問題が発生すると影響の大きいもの、自ずとシステムにおいて最も重要なAPIが対象となってきます。

また、以前なんらかの異常が認められたAPIも対象に加えても良いでしょう。

対象が決まったらAPIコンフィギュレーションを定義します。

監視するエンドポイントのURLを追加して、カスタムリクエストヘッダー・認証資格情報などを必要に応じて設定します。

APIテストの作成自体はこれで完了。至って簡単です。

次にアラート条件を定義します。

ここでは主にHTTPステータスコードやresponse timeを定義します。

response timeの基準は、通常時のresponse timeを参考に決めていきます。

※通常時が1000ms未満であれば3000msといった感じ。

以下は設定のイメージ

    
    2 assertions have been configured:
    └Status Code should be 200
    └Response Time should be less than 3000ms
    
    

これでアラート条件の設定も完了です。

最後にアラート通知の設定です。

異常を検知した際に誰にどのように通知するかも重要な要素になります。

Datadogではメール通知だけではなく、slackやPagerDutyなどのインテグレーションを使用することもできます。

一般的にはslackに「xxxx_alert」といったchannelを用意しておいてそこに通知を投げ込む、緊急度の高いものについてはPagerDutyで電話連絡を受けられるようにしておくといった形が多いのではないでしょうか。