Datadogで実現するモニタリングとオペレーションのオートメーション化

当社では、AWS運用管理サービスでモニタリングツールとしてDatadogを提供しています。本サービスをご利用のお客様より、モニタリングをするだけでなく、そこで検知したアラートに対してのオペレーションをオートメーション化できないかとご要望を頂きました。実際のお客様の課題に対して、サービス・プロセス（IIS、apache、tomcat、DBMSなど）の状態をDatadogでモニターし、異常を検知した場合のオペレーション（サービス・プロセスの再起動）をオートメーション化する実装を行いました。本記事ではその詳細についてご紹介します。

現状の運用と課題

ご要望を頂いたお客様のシステムは、現状24時間365日で稼働しており、システムの障害が発生すると業務への影響があるため、運用者は24時間365日の体制で対応する必要があり、運用コストが大きくなるという課題がありました。また、異常が検知されると、アラート内容の把握、暫定復旧作業、原因追及、恒久対応などシステムの復旧を図りますが、人手に頼るため、システムの停止時間が長くなることも課題となっていました。

DatadogとAWSサービスを組み合わせてモニタリング+オペレーションの自動化で課題を改善

これらの課題に対して、障害検知から対応までを自動化できるか、当社で検討を行いました。下記のように、Datadogでサービス・プロセスの監視を行い、サービス・プロセスの停止等の異常アラートを検知した場合に、サービス・プロセスの再起動をAWSサービスと連携して自動化することで、お客様の課題を改善できました。

1．課題解決にあたり利用しているAWSサービス

EC2（監視対象のサーバー）
EventBridge（Datadogからのデータ受け取り）
Lambda（サービス再起動命令処理実行）
SSM（サービス再起動命令処理実行）
SNS（運用担当者への通知連絡）

EC2，Lambdaにつきましてはそれぞれ個別記事を公開しております。
サービスの詳細をご覧になりたい場合は、下記ページをご覧ください。

AWS活用法｜おさえておきたい基本サービス Amazon EC2とは？

AWS活用法｜サーバーレスの時代？ AWS Lambdaを活用した、サーバーレスアーキテクチャのシステム開発のすすめ

2．今回の構成概要と注意点

DatadogとEventBridgeは連携可能ですが、Datadogが東京リージョンのEventBridgeと連携できないため、バージニアリージョンのEventBridgeと連携させます。また、EventBridgeは連携先としてSSMを指定可能ですが、別リージョンのSSMは指定できないため、バージニアリージョンのLambdaを間に挟んで、東京リージョンのSSMを起動させます。

3．設定・構築方法

3.1 監視対象サーバー（EC2内）の設定

①Windowsの場合

Datadogエージェントをインストールして、監視対象のWindowsサービスを設定します。インストール後、Datadog Agent Managerを起動（http://127.0.0.1:5002/へアクセス）し、監視対象にするサービスを記載し、[Save]＞[Restart Agent]をクリックします。下記例だと、【W3SVC】を監視対象サービスとしています。

②Linuxの場合

Datadogエージェントをインストールして、監視対象のサービスを設定します。httpdサービスを監視例として設定例を記載します。Linuxについては、設定ファイルに監視するサービスを定義します。「/etc/datadog-agent/conf.d/process.d/conf.yaml」のファイルを開き、下記内容を追記します。

conf.yamlを編集後、datadog-agentサービスを再起動します。

datadog-agentにて、設定したサービスがモニタリングできているか確認します。下記コマンドを実行し、httpdプロセスがモニタリングできていることを確認します。

3.2 Datadogコンソール上での設定

①Windowsの場合

Datadogのコンソールにて、IntegrationsでWindows Serviceをインストールし、監視サービスの停止/起動を検知後にバージニアリージョンのEvent Bridgeへの連携設定です。

EventBridgeへ連携させるため、[Integrations]＞[Integrations]＞[Amazon EventBridge]を選択し、バージニアリージョン通知先を追加します。

[Monitors]＞[New Monitor]＞[Integration]＞[Windows Service]＞[Integration Status]の順に選択し、新しい監視設定を行います。通知先として先ほど作成したEventBridgeの通知先を指定します。

②Linuxの場合

Datadogのコンソールにて、サービス監視の設定を行います。EventBrige側の設定はWindowsと同様になります。（バージニアリージョンのEvent Busを作成する）

[Monitors]＞[New Monitor]＞[Process Check]の順に選択し、新しい監視設定を行います。

[Pick a Process]の設定箇所にて、conf.yamlファイル内で設定した[moniter_httpd]がドロップダウンにて選択できます。

[Say what's happening]に作成したEventBridge連携用のイベントバスを指定します。

3.3 Event Bridgeの設定

バージニアリージョンのEventBridge画面にてルールを作成します。この設定により、Datadog側でサービスの停止／起動を検知した場合、EventBridgeに連携されるようになります。

3.4 Lambda設定

呼び出されるLambdaのプログラムは以下のようになります。簡単に説明しますと、

if alert_type == 'error':

上記の部分が、サービスの停止を検知した場合の挙動になります。サービス再起動コマンドの実行と、その旨を管理者へ通知します。

if alert_type == 'success':

上記の部分でサービスの起動を検知した旨を運用管理者へ通知します。

①Windowsの設定例
②Linuxの設定例

4. 実行結果

IIS（サービス名：W3SVC）を監視します。サーバー内でIISサービスを停止して、しばらくすると以下のようなメールを受信します。再起動実施の旨を受信してから1分後に起動完了のメールを受信しています。これは、Datadogの監視間隔が60秒に設定されているためです。

Datadog画面を見ると、確かに12:22と12:23付近でサービスの状態が変化していることがわかります。

実際にWindowsのイベントログにて起動時刻を確認すると、停止時間は約55秒でした。

今回の結果からDatadogにてサービス停止を検知してから実際に起動するまで数秒程度でした。時系列を整理すると、以下のようになります。

(a)Datadogの監視間隔は60秒

(b)DatadogでWindowsサービス停止を検知してから、起動完了まで、約3秒程度

(a)(b)から、[Windowsサービス停止]～[停止検知]～[起動完了]～[起動検知]まで自動化でき、約2分で完了させることができました。実質的なサービス停止時間は約1分となります。

まとめ

Datadogにて、Windows及びLinux環境のサービス・プロセスの監視を行い、その復旧についてもEventBrigeと連携し、LambdaでSSM Run Commandを実行することで、サービス・プロセス再起動を自動化しました。それにより、サービス停止時間を最小化し、一連の動作をオートメーション化することで運用担当者の大きな負荷軽減につながりました。

現状Datadogが東京リージョンのEventBrigeを指定できないため、Lambdaで東京リージョン（ap-northeast-1）のssmコマンドを実行させる形となりましたが、今後のDatadogのアップデートで東京リージョンのEventBrigeを指定できるようになることを期待しています。

今回の記事を読んでご興味がある方は、是非お問合せをお待ちしております。