DatadogのURL監視でリダイレクトを検出できるようにしよう

はじめに

西藤です。

弊社ではAWSインフラ上で動くシステムの監視に"Datadog"を用いております。

このDatadogを使用することで「CPU使用率」「メモリ使用率」や「ストレージ空き容量」などクラウド上のインフラリソースの各種情報を監視できるほか、所定のURLに対して一定間隔でアクセス試行を行うことでサイトの死活監視を行うこともできます。

今回はそのURLに対する死活監視、Datadogの用語で「HTTPチェック」において、サイト上のリダイレクトの発生を監視できるための方法を紹介します。

HTTPチェックの基本設定と実現したいシナリオ

まず、DatadogのHTTPチェックの構成概念は以下のようになります。

例えば、EC2インスタンスなどの基盤にインストールされたDatadogエージェントから監視対象としたいURLに対して一定間隔でアクセス試行を行います。

そして、その際のレスポンス内容に基づいて、該当のURLが正常にウェブリクエストに対してレスポンスできているかを判断します。

この際の「正常か」の判断は、Datadogエージェントがインストールされている基盤内にある設定ファイルの設定値などから判断されます。

上記のような前提に基づき、次のようなシナリオを考えてみます。

https://example.com というURLを対象にページの死活監視を行いたい。
そして、このURLにおいてはページが表示されることを正常として、想定外に別のURLにリダイレクトされるような事態も捕捉できるようにしたい。

といったシナリオです。

このシナリオを実現するための方法を考えていきます。

※内容としては、すでにDatadogを運用されている方向けを想定しており、Datadogの契約やエージェント導入など監視を開始するまでの初期設定は割愛させていただきます。

HTTPチェックの設定ファイル（サンプル）

まず、URL監視をするためにはDatadogエージェントをインストールしている基盤上で設定ファイルを記述する必要があります。

https://docs.datadoghq.com/ja/integrations/http_check/

のサンプルを参考に

http_check.d/conf.yamlファイルを次のように記述します。

init_config:

instances:
  - name: Example website
    url: https://example.com/

これによりDatadogエージェントと連携しているDatadogの管理画面にて
https://example.com/のURLを対象としたHTTPチェックのためのモニターを作ることができます。

サンプルの問題点

これだけでも「対象のURLが稼働しているか」を監視することができます。
例えば、対象のウェブサイトのサーバーがダウンしたらその時点で異常系のレスポンスが返ってくるようになるので、通知を受け取ることができます。

しかし、「サイト上でリダイレクトが行われるようになっており、想定していたページ以外が表示されていた」という状況は検出することができません。

これは

https://docs.datadoghq.com/ja/integrations/http_check/#サービスのチェック

次のいずれかが発生したら DOWN を返します。

• uri へのリクエストがタイムアウトした
• 応答コードが 4xx/5xx またはhttp_response_status_code で指定されているパターンコードと一致しない
• 応答本文が content_match のパターンを含まない
• reverse_content_match が true で、応答本文が content_match のパターンを含む
• uri に https が含まれ、tls_verify が true であり、SSL 接続を検証できない

とあることからも、デフォルトの設定においては4xx系または5xx系のレスポンスでない場合が異常（DOWN）と判定されるためです。

リダイレクト発生時のレスポンスコードは3xx系のものが使われるので、
例え
「昨日までウェブサイトのトップページが見れていたのに、今日になったら別のURLにリダイレクトされるようになっていた」
という状況が生じていても、それだけでは条件に合致せず、異常と判定されてもらえないのです。

HTTPチェックの設定ファイル（改善版）

では、どうやればリダイレクトが発生するようになった時にそれを補足できるかの修正点を考えてみます。

変更版は次の通りです。

init_config:

instances:
  - name: Example website
    url: https://example.com/
    http_response_status_code: 200
    allow_redirects: false

内容としては

http_response_status_code: 200
と
allow_redirects: false

の追加です。

上記の異常判定する時の条件文を見ると
「http_response_status_codeに200だけを指定すればOKなのでは？」と思ってしまいがちですが、それだけでは足りません。

allow_redirects というオプションがありますが、これは未記載の場合trueが適用されており、「リダイレクトの発生を許容する」という働きをします。
そのためfalseの設定で
allow_redirects: false
を追加しないと、200以外である、3xx系のリダイレクトのレスポンスが返っていても、それが異常とは判定されなくなってしまいます。忘れずに追加しましょう。

動作確認

このような設定を入れた状態で、
例えば、監視対象のページ上にてリダイレクトのループを発生させてみると、Slackチャンネルに通知が届いた場合は...

のように「200のレスポンスコードが想定されていたところに301のレスポンスが発生した」旨を指摘して、アラートが発生します。

まとめ

以上で、URL監視において、リダイレクトの発生を検出できるようにするための方法をご紹介しました。
サイトの運用形態によって、必ずしもリダイレクトの発生イコール異常ではないことも多くあるので、一様に適用するべき設定ではないですが、
これによりサイト運営上のミスなどによりリダイレクトループを発生させてしまった場合（私もWordPressサイトなど動かしているときにやりがちです...）や、サイト改竄によりサイトの訪問者が想定外のウェブサイトに転送されるようになってしまった場合の検出にも役立てられることが期待されます。

最近はURLに対するレスポンスだけではなく、アクセス後の振る舞いも総合して、監視対象にできる"Synthetic"※と呼ばれる仕組みがDatadogやAWSからも登場しており、より細かい設定で監視をしたい場合はそちらがフィットするかもしれませんが、今回の記事がWebサービス監視を行う上で、ヒントの一つとなれば幸いです。

※:
https://docs.datadoghq.com/ja/synthetics/
https://aws.amazon.com/jp/about-aws/whats-new/2019/11/introducing-amazon-cloudwatch-synthetics-preview/

sho