こんにちは。ギフトモール Engineering Managerをやっている @nori0620 です。
はじめに
Giftmallではサーバ監視、アラート送信の仕組みに Datadog を導入しています。 Datadogの各種インテグレーションを利用することでEC2, ECS, RDS, ALBといった様々なインフラリソースの監視に利用しており、何か問題の予兆があった際にはSlackに通知を送ってチームが把握できる体制を作っています。
ただ、システムを運用していく上で、インフラ/サーバだけでなく、アプリケーションに近いレイヤーでも監視を行いたいようなニーズがでてきました。例えば「ユーザがログインに失敗した総回数」をモニタリングしておいて不正なログインの試行などが行われていないかを監視するなどです。
このようなアプリケーションレイヤーにおけるモニタリングも既存のDatadogで監視しているインフラと同様のフロー/体制と同様のものを導入したい、と思い調査したところ、DogStatsD経由での送信する場合は各言語でクライアントライブラリが用意されており、数行のコードで導入ができます。
この記事ではDatadog カスタムメトリクスの概要と、それをサービスのどのような部分の監視に利用しているかについて紹介します。
Datadog カスタムメトリクスとは？
Datadogの カスタムメトリクス を利用すると、既存のインテグレーション以外の任意のメトリクスを送信・追跡することができます。
メトリクスの送信方法は以下のような方法が用意されています。 - カスタム Agent チェック - DogStatsD - DatadogのHTTP API
アプリケーションに近いレイヤーの指標を扱う際は、後者のいずれかになる場合が多いと思います。
Giftmallではアプリケーションが動いているサーバにはDatadog Agentがインストール済みであったこと、同一マシン内での通信になるので通信コストもHTTP APIよりも低いことからDogStatsDを利用しています。
DogStatsD経由での送信する場合、各言語でクライアントライブラリが用意されており数行のコードで導入ができます。例えばPHPであれば以下のようなイメージです。
$statsd = new \DataDog\DogStatsd(['host' => '127.0.0.1','port' => 8125]); $statsd->increment('my_app.matrix', 1, ['environment'=>'dev']);
次に、実際にGiftmallで運用しているカスタムメトリクスの事例をいくつか紹介したいと思います。
ログイン試行回数の監視
ログインの失敗回数が極端に多い場合、不正なログイン試行などが行われている可能性があります。
不正ログインへの対策自体も行いつつ、状況把握のために「普段どれぐらいのログイン失敗が起きているか？」などを日常的にモニタリングしておくことも有意義です。
そこでGiftmallではユーザの「ログイン成功」と「ログイン失敗」を、それぞれ発生時にlogin.succss、login.failureというメトリクス名で送信しています。
メトリクスをもとに、以下のようなダッシュボードをDatadog上に作成しています。
これで、どれぐらいのログイン試行が日常的なのかを把握することができます。 またDatadogのモニターを利用して、通常と異なるようなログイン試行のトレンドがあった場合に、開発チームのSlackに通知するように設定しています。
通知を受けると、必要に応じて詳細なログを確認し「何がおきているか」の調査を行っています。
JobQueueの状態監視
こちらはアプリケーションというよりシステム寄りな話になっています。 Giftmallではサービスの非同期処理などのためにJobQueueを運用しており、そのJobQueueの状態もカスタムメトリクスで監視しています。
以下のように定期的に実行待ちのJob数をメトリクスとして送信しています。
$statsd->increment( 'job_queue.waiting_jobs', // メトリクス名 $numberOfWaitingJobs, // 実行待ちのJob数 [ // タグ情報 'queue_name'=>'admin' // 対象のQueue名, 'product' => 'giftmall' ] );
タグに入れているqueue_nameは、複数存在するQueueの識別子です。
Queueが複数存在しているのは「メール送信など遅延がシビアであるJobのためのQueue」、「管理画面のアップロード機能などある程度の時間がかかること前提のJobのためのQueue」のように特性の違いに応じて、それぞれにQueueを用意しているためです。
タグにqueue_nameを入れておくことで、 avg by queue_nameなどのように設定するとダッシュボードでのグラフ描画やモニタリング設定を一括で行うことができます。
以下は avg by queue_nameでQueueごとに待機中のJob数を表示したグラフです。
Slackへの通知に関しても、Queueの特性ごとに閾値を設定しています。 遅延することで利用者の方にユーザに影響がでるようなQueueに関しては、開発チームのチャンネルだけでなく、Customer Supportチームのチャンネルにも通知を送って対応を進められるようにしています。
おわりに
この記事では、DatadogのカスタムメトリクスについてGiftmallにおける事例を紹介しました。 Datadogを導入している環境であれば、インフラに限らない数値の監視をはじめることができ、かつ既存の監視と同様のフローをそのまま使えるのはメリットが大きいと思います。 アプリケーションの異常監視を検討してる方に少しでも参考になれば嬉しいです。
ギフトモールでは、一緒に働く仲間を募集しています！
まずは一度話してみるだけなどのカジュアル面談も歓迎ですので、少しでも興味を持った方はお気軽に連絡ください！
