AWS監視の「霧」を晴らす：Datadog × CloudWatch連携の真髄
こんにちは。システムが複雑になればなるほど、「どこで何が起きているか」を把握するのは至難の業になりますよね。
AWS上のリソースを監視する際、多くのエンジニアが最初に突き当たる壁が「DatadogとCloudWatchの連携」です。「とりあえず連携しておけばいいんでしょ？」と設定して、数ヶ月後に届く驚愕のAWS請求書と、ノイズだらけのダッシュボードに頭を抱える……そんな現場を私は何度も見てきました。
今日は、そんな悲劇を未然に防ぎ、「監視のプロが現場で実際に採用している」CloudWatchメトリクスの取り込み術を伝授します。これをマスターすれば、あなたの運用は劇的にシンプルになりますよ。
—
1. なぜ「CloudWatch単体」では足りないのか？
AWSを使っているなら、CloudWatchという強力なツールが既に手元にあります。しかし、CloudWatchは「AWSのパーツを見る」のには優れていますが、「アプリケーションの体験（UX）とAWSリソースを横断して可視化する」ことには不向きです。
Datadogを連携させる最大のメリットは、「AWSのインフラメトリクス」と「アプリのログ・トレース」を同じタイムラインで重ね合わせられる点にあります。これにより、「DBのCPU使用率が上がった」瞬間に「どのAPIリクエストが詰まっていたか」を、迷うことなく特定できるのです。
—
2. CloudWatchメトリクスを取り込む「2つの流儀」
DatadogでCloudWatchのデータを見るには、大きく分けて2つのアプローチがあります。
A. APIポーリング方式（標準的な統合）
Datadogのサーバーが、AWSのCloudWatch APIを定期的に叩きに行ってデータを取得する方法です。
- メリット: 設定が圧倒的に楽。DatadogのAWS Integration画面でRoleを作成するだけで完了。
- デメリット: CloudWatch APIのコール数に応じた課金（API利用料）が発生する。データの粒度に限界がある（通常1分間隔）。
B. Lambda転送方式（CloudWatch Metric Streams）
CloudWatch Metric Streamsを使い、Firehose経由でDatadogにデータを「プッシュ」する方法です。
- メリット: ほぼリアルタイム（数秒の遅延）で受信可能。APIコール数による従量課金を抑えられる。
- デメリット: アーキテクチャが少し複雑になる（FirehoseやS3バケットが必要）。
【結論】
小〜中規模なら「APIポーリング」で十分ですが、大規模環境や監視コストを極限まで最適化したいなら「Metric Streams（Lambda転送）」一択です。
—
3. 実践：最短で「最高品質」のセットアップ
まずは「APIポーリング」で基本を抑えましょう。ここでのポイントは「必要なメトリクスだけを取り込む」ことです。デフォルト設定ですべてを取り込むのは、お金をドブに捨てるようなものです。
ステップ1：Datadog専用IAMロールの作成
AWSのセキュリティ設定で、Datadogに「読み取り専用」の権限を与えます。
// 必要な最小限の権限（これを踏み台にするのがプロの定石）
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“cloudwatch:GetMetricData”,
“cloudwatch:ListMetrics”,
“cloudwatch:GetMetricStatistics”
],
“Resource”: “”
}
]
}
ステップ2：不要なメトリクスの「フィルタリング」
DatadogのAWS統合画面で、「Namespace」ごとのフィルタリングを設定します。例えば、使っていないEBSのメトリクスや、不要なLambdaのメトリクスを排除するだけで、月額コストが数万円単位で変わることもあります。
—
4. 精度高い「HelloWorld」的動作確認
設定が終わったら、本当にデータが届いているか確認しましょう。
1. Datadogダッシュボードへ移動: 「Dashboards」→「New Dashboard」を選択。
2. クエリの入力: `aws.ec2.cpuutilization` と入力してみてください。
3. フィルタの適用: `{host:あなたのインスタンスID}` を指定します。
【ここで差がつくポイント】
グラフが表示されたら、そのグラフを「Metric Monitor」として保存してください。
- `avg(last_5m):avg:aws.ec2.cpuutilization{host:your-host} > 80`
- この設定で、「CPUが5分間平均で80%を超えたらSlackに通知する」という監視の基本形が完成します。
—
5. 伝説のエンジニアからのアドバイス：コスト最適化の秘訣
最後に、現場で泣きを見ないための「コスト最適化」のコツを共有します。
- Metric Streamsの活用: 大規模環境ならCloudWatch Metric Streamsへ移行しましょう。APIコール数が減るため、AWS側のコストが劇的に下がります。
- 不要なタグの削除: 監視対象が増えるとタグの管理が複雑になります。必要なメタデータだけを残し、それ以外は取り込まない。
- 「高解像度」を使い分ける: 全てのメトリクスを秒単位で取得する必要はありません。Webサーバーのレスポンス時間は秒単位、ディスク容量は1時間単位といったメリハリが重要です。
—
最後に
監視ツールは「入れれば終わり」ではありません。「何が正常か」を定義し、ノイズを削ぎ落としていく作業こそが、オブザーバビリティの真髄です。
今日設定したこのダッシュボードが、将来のあなたが深夜に叩き起こされる回数を1回でも減らしてくれることを願っています。それでは、快適な運用ライフを！