あしざわです。
Datadogは、SaaSベースでサーバーやサービスの監視および分析機能を提供するサービスです。
同様のSaaSのサーバー監視分析サービスがたくさんあることは知っていましたが、個人の経験としていずれのサービスも使ったことがありませんでした。
とあるお問い合わせがきっかけでDatadogに触れる機会がありましたので、その様子をブログに残しておこうと思います。
想定読者
本記事はTerraformを利用したAWS環境の構築経験はあるが、Datadogは触ったことがない方を想定して執筆しています。AWS、Terraformの経験がない方にとってわかりづらい箇所が多いと思いますがご容赦ください。
アーキテクチャ全体とゴール
以下の構成のVPCにデプロイしたLB配下のWebサーバー(EC2/Amazon Linux 2023)に対し、Datadogを利用した監視環境を実装・アラートのテストをするところまでを本検証のゴールとしました。
フロントはALB、ALB配下のEC2はプライベートサブネットに配置し、Datadogにメトリクスを送信するためにNAT Gatewayを配置しています。また検証用途なのでALB配下のEC2はシングル構成にしています。
後ほど登場しますが、環境構築で利用できるTerraformテンプレートをGitHubリポジトリのリンクを掲載しています。本番用途で構築する場合はマルチAZ構成にするなど状況に応じてカスタマイズしてください。
やってみた
以下の流れで検証を進めていきます。
- Datadogの初期セットアップ
- 監視対象環境の作成
- 監視アラートの設定とテスト
Datadogの初期セットアップ
私はDatadogのアカウントを持っていないため、アカウントのサインアップから始めます。既にアカウントを持っている方はこの手順は飛ばしてください。
トライアルアカウントのサインアップの前提となるAgentの有効化は、以下ブログの「Datadogアカウントのサインアップ」見出しを参考に新規作成したCloud9環境で実施しました。詳しい手順については割愛します。
Your Datadog Agent is running and functioning properly.
赤枠箇所に含まれる、上記から始まるメッセージが表示されたら成功していそうです。
画面の表示通りに進めていくと、Welcome〜の画面まで辿り着けました。
AWS環境のセットアップ
Terraformを利用してDatadog Agentのインストールを含めたAWS環境の構築を行います。
以下のGitHubリポジトリにテンプレートをアップロードしましたので、クローンするなどしてご利用ください。
注意点が1点あり、Datadog AgentのアクティベートをUserDataで実施していますが、初期状態ではコマンドをコメントアウトしている(かつAPIキーが正しくない)のでそのまま実行しても監視が開始できません。
私のテンプレートではUserDataはuserdata.shの中で定義しています（以下）
#!/bin/bash
## ホスト名設定
HOSTNAME="datadog-dev-instance"
hostnamectl set-hostname ${HOSTNAME}
## HTTP設定
yum install -y httpd
systemctl start httpd
systemctl enable httpd
usermod -a -G apache ec2-user
chown -R ec2-user:apache /var/www
chmod 2775 /var/www
find /var/www -type d -exec chmod 2775 {} \;
find /var/www -type f -exec chmod 0664 {} \;
echo `hostname` > /var/www/html/index.html
## Datadog Agent設定
dnf install -y libxcrypt-compat
#DD_API_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX DD_SITE="ap1.datadoghq.com" DD_APM_INSTRUMENTATION_ENABLED=host bash -c "$(curl -L https://s3.amazonaws.com/dd-agent/scripts/install_script_agent7.sh)"20行目のハイライト箇所の後に自身のDatadogアカウントで発行した、ご自身のAPIキーが含まれたDatadog Agentのインストールコマンドを入れてください。
Datadog Web UIのIntegrations > Agentから対象OSのディストリビューションを指定すると、ワンライナーのインストールコマンドを発行できる画面に遷移します。デフォルトではDD_API_KEY=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXと先頭のAPIキーがXの連続文字列で埋められている状態なのでSelect API Keyから利用するAPIキーを選択してからコマンド取得するようにしましょう。紫でマスキングされるようになればOKです。
テンプレート実行後、Webブラウザやcurlコマンド等でALBのパブリックDNSアドレスにHTTPアクセスして、以下のように出力されたらAWS環境は正しくデプロイできています。
(例)
> curl http://datadog-dev-alb-123456789.ap-northeast-1.elb.amazonaws.com
datadog-dev-instance環境構築後しばらく経った後に、DatadogのWeb UIのInfrastructures > Infrastructure Listを確認すると、構築したEC2インスタンスが表示されます。List画面からでもOS、ステータス、CPU使用率など最低限の情報が確認できますね。
表示されているインスタンス名をクリックすると詳細についてドリルダウンできます。Host Infoタブ、MetricsタブからDatadog Agentが収集したであろうさまざまな情報が確認できます。
監視アラートの設定とテスト
Datadogでは監視メトリクスが閾値を超えた際にアラート・通知を設定するために、メトリクスモニターという機能を利用します。
メトリクスモニターを使って以下のような監視アラートを設定します。メトリクスモニターのテスト目的の設定なので閾値に対する根拠はないです。
- アラートの種類: 閾値(
Threshold Alert) - メトリクスの定義:
- 作成したEC2ののCPU利用率(
system.cpu.user, host=datadog-dev-instance) - 過去５分間の平均(
average, last 5 minutes)
- 作成したEC2ののCPU利用率(
- 監視条件:
- アラート閾値: 100%以上(
above or equal to, 100%) - Warning閾値: 90%以上(
above or equal to, 90%)
- アラート閾値: 100%以上(
- 通知先
- 通知メッセージ: デフォルト
- 通知先: 自分のメールアドレス
- 優先度: Critical
- その他: 10分おきに再通知する
Monitor > New Monitorをクリックして、New MonitorでMetricを選択します。
次の画面で監視設定を進めていきます。UIの言語は英語ですが、視覚的にわかりやすいので何を設定すべきなのか理解しやすかったです。
画面上部に直近で発生したメトリクスが表示されるので、実際に発生したメトリクスの傾向をみながら監視設定できるところも良いですね。
メトリクスモニターの設定ができました。
ここから実際にEC2に負荷をかけて監視アラートのテストを実施していきます。
対象のEC2にSSM Session Managerを利用してリモート接続し、yes > /dev/null &コマンドを複数回実行用してCPUに負荷をかけます。
h-5.2$ yes > /dev/null &
h-5.2$ yes > /dev/null &
(中略)
h-5.2$ yes > /dev/null &
sh-5.2$ jobs
[1] Running yes > /dev/null &
[2] Running yes > /dev/null &
[3] Running yes > /dev/null &
[4] Running yes > /dev/null &
[5] Running yes > /dev/null &
[6] Running yes > /dev/null &
[7] Running yes > /dev/null &
[8] Running yes > /dev/null &
[9] Running yes > /dev/null &
[10] Running yes > /dev/null &MonitorのStatusに大体1、2分くらいのラグでメトリクスがリアルタイムで表示されました。
しかし、コマンドを増やしたりしばらく待ってみても私の環境では60%くらいまでしかCPU使用率が上昇しませんでした。
※T系のインスタンスタイプを利用したため、検証ではCPU使用率を100%全て使い切ることができなかったと考えています。
一旦、killコマンドで負荷がけを停止します。
sh-5.2$ kill %1 %2 %3 %4 %5 %6 %7 %8 %9 %10閾値を調整して再チャレンジします。
前回の傾向から、20%でWarning、50%でAlertとしてみました。
グラフ上でもわかる通り、これなら確実にアラートを発砲させられそうです。
設定変更を確定させ、再度SSMでリモート接続しyesコマンドで負荷をかけたところ、登録しているメールアドレスに[P1] Warn: CPU Utilizations is very high on datadog-dev-instanceという件名のWarning通知のメールが届きました。
その後少し遅れて[P1] Triggered: CPU Utilizations is very high on datadog-dev-instanceという件名のAlert通知のメールが届きます。
このタイミングでWeb UIを確認すると、ステータスが赤くなっておりグラフ上からアラートに至るまでのCPU使用率の遷移が見て取れます。
killコマンドで負荷がけを停止すると、[P1] Recovered: CPU Utilizations is very high on datadog-dev-instanceという件名のメールが届きました。これでアラートが解消されたことがわかります。
検証は以上とします。
さいごに
今回の検証はDatadog Agentを利用した単純なメトリクス監視までにとどまっているので、AWSサービスであるCloudWatchを利用した監視とほぼ同じものになっています。
当然ながら、たくさんあるDatadogの機能をまだまだ使いきれていないので、次回以降の検証で他の機能も試してみたいです。
以上です。
15
