Datadogで手軽にいい感じに外形URL監視を実現する方法 #監視

これはDatadog Advent Calendar 2016 2日目の記事です。

Webサービスを運営している場合、実際のエンドユーザに対して、正常にサービスが提供出来ているかを知る手段として外形URL監視をそれぞれの方法でやっていると思います。

今回は、Datadogを使って外形URL監視を組んだ事例について紹介しようと思います。

外形URL監視とは

定期的に、外部公開しているURLに対してリクエストを送り、レスポンスのステータスコードや応答時間をチェックし、異常時には、何らかの通知を送ることで、そのサービスの死活監視をすること。

なぜDatadog

Saas系のモニタリングツールだとmackralやpingdomあたりは、Saas側の機能として外形URL監視サービスを持っています。
これらを使うことも検討したのですが、ちょうど監視ツールをDatadogに入れ替えようとしているタイミングだったこともあり、何とかDatadogで実現出来ないかと調べながら作りました。

※Datadogは、エージェントが必要な点が少し難点なのですが、そのうちSaas側から実行出来るようになるといいなと！！

こんな感じに出来る

Datadogを使った外形監視をするとどんな感じになるかというアウトプットを先にお見せしようと思います。

外形URL監視でエラーが起きると

下記のようにslackに通知され、気付いた人が即確認するみたいなフローで運用されてます！
※基本、全員がそのchannelへのモバイル通知を全イベント有効にすることで、すぐに気づけるように。。

URL毎の稼働率のモニタリング

各サイト毎の稼働率だったり、過去に起きたイベントの履歴が一覧で見れます。(この画面はとてもわかりやすい)

外部から見たサービス毎のレスポンスタイムもグラフ化出来る

副次的なものなのですが、URL単位のレスポンスタイムをメトリクスとして送っているので、それをグラフ化することで、外部から見た時のサイトのレスポンスタイムを可視化しています。

Datadogの設定

ここからは、実際のDatadogでの設定をサンプル交え解説します。

全体の構成は、下記のようなフローとなってます。

【フロー】
1.専用のホストを一台準備し、datadog-agentから各URLに対して監視を行います。
2.メトリクスデータは、Datadog本体側に送られ、実際の通知設定(Monitor)やグラフの描画(Dashboards)はSaas側で行います。
3.アラート条件に係るイベントが発生した場合は、DatadogからSlackに対してエラーをpostします。

使用するメトリクス

Datadogのエージェントは、デフォルトで様々なメトリクスを取得できるプラグインが内包されています。

今回は、[http_check]プラグインを使います。

【監視可能な項目】

ステータスコード
レスポンスタイム
コンテンツの文字列チェック

datadog-agentの設定のサンプル(エージェントのいるホストで実施)

エージェントをインストールして、下記yamlに設定を書きエージェントを再起動するだけです。

【例】
監視対象のURLに関して、5秒以内にstatus_code:200を返さない場合にエラーと判定

/etc/dd-agent/conf.d/http_check.yaml

init_config:
  # Change default path of trusted certificates
  # ca_certs: /etc/ssl/certs/ca-certificates.crt

instances:
  - name: stay_main
    url: http://www.ikyu.com
    timeout: 5
    http_response_status_code: 200
    skip_event: true
    tags:
      - env:xxx
      - cat:xxweb

  - name: restaurant
    url: http://restaurant.ikyu.com
    timeout: 5
    http_response_status_code: 200
    skip_event: true
    tags:
      - env:xxx
      - cat:xxcweb
・・・

monitor設定のサンプル(DatadogのWeb画面で設定)

エージェントでメトリクス送信が始まったら、今度はDatadogのweb画面で通知の設定を行います。Datadogでは、監視(閾値超えるイベント発生したら何かアクションする)の設定はmonitor画面で行います。

【サマリ】

事前に、slackインテグレーションで通知先channelを登録しておく。(integrations→slackでチャンネルを登録)
通知メッセージに関しては、下記に書いたテンプレートを使いながらURL・イベント単位で出し分けしている。※下記の記事に書いてます。

エージェントからの通知が来ない場合もアラートを投げられる。(5分間データ来なかったら通知するようにしてる)※エージェント止まっていて、監視止まるとかシャレにならないので。。

↓実際の設定画面のサンプル

設定のポイント

一度のエラーで通知してしまうと、NW的な中継経路等の問題で誤検知が多発するので、数回連続でアラートが出たら通知するという設定にした方が良い
Datadogで送るメトリクスは、タグづけがかなり重要なポイント
- タグ毎にDatadog側で、うまくグルーピングしないとポチポチが辛くなる
- 外形監視だと、サービス単位でやるのがうまいやり方だと思う。(xxxserviceというタグつける事でこのタグついているメトリクスに対して同じmonitorで一括設定が出来る)

まとめ

設定が簡単(Datadogあまり触ってなかったけど、ほぼ一日で)
Datadogに他のホストのメトリクスも送っている場合だと、同じ時間軸で障害の切るわけが出来るのは素敵
Saas全般に言えるけど、グラフ描画が遅いとか集約する側の負荷とかの運用面を考えなくていいのは相当なメリットだなと思った！

※エージェント運用する手間(今回は、AWS上にインスタンスを立てたので一台分の料金と若干のメンテコスト)はかかるので、Saas側からこの機能使えるとさらにうれしいとは思う！！

今回は、Datadogを使った外形URL監視の事例について、書きました。メトリクス取得やグラフ描画の部分にはパワーを割かず、そのデータを使って何がしたいかという事に絞って作業出来るのは、相当なメリットだなと思います。
サービス監視は、生命線的な側面があるので、もしまだやっていない方がいたら、Datadogでのこんな方法も選択肢の一つに入れてみてはいかがでしょうか。

Datadogで手軽にいい感じに外形URL監視を実現する方法

目次