Datadogを使ったECS on Fargateコンテナの監視設計

Datadog

Last updated at 2025-06-02Posted at 2025-06-01

はじめに

先日参加した「ハッカソン春の陣」にて構築したインフラにおいて、Datadogを初めて導入し、ECS on Fargateでの監視設計に取り組みました。本記事では、Datadogとは何か？何ができるのか？そして、ECS on Fargate上に構築したFastAPIアプリケーションの監視にどのように導入・活用したかをまとめました。

Datadogとは？

Datadogは、クラウドネイティブなインフラやアプリケーションの状態をリアルタイムで可視化・分析できるSaaS型の統合監視ツールです。

クラウド、オンプレミス、コンテナ、サーバーレスなど、あらゆる環境を対象に、以下のような多角的な監視が可能です。

機能	説明
メトリクス監視	CPU・メモリ・ディスクIO・ネットワークなどをリアルタイムに可視化
ログ分析	アプリやコンテナログのフィルタ・検索・統計処理
APM (Application Performance Monitoring)	アプリケーション内部の処理遅延・エラー・トレースを可視化
インフラ監視	EC2やRDS、ECS、FargateなどAWSサービスと統合し、メトリクスを一元管理
アラート通知	複雑な条件設定に対応。Gmail, Slack, Opsgenie等と連携
ダッシュボード	グラフや表でメトリクス・ログをまとめて表示

Datadogでできること

今回の開発では以下の点を目的にDatadogを導入しました：

Fargate上のコンテナの死活監視と状態可視化（agent-up / status check）
ログの収集・フィルタ・エラー検知（CloudWatchと連携）
Datadog Agentの稼働確認 (agent-up チェック)
異常検知時のメール通知（Gmail）
タスクの起動順制御による監視漏れを防止

また、ECSタスクにおける起動順を制御することで、監視エージェントがアプリより先に起動するよう構成しました。

なぜDatadogを選定したのか？

今回の監視ツール選定において、Datadogを使ってみたいという個人的な興味が出発点でした。ただ、実際にFargate環境に導入を検討する中で、技術的にも合理的な選択であることが分かりました。Fargateはホストアクセスができず、CloudWatchだけでは細かなリソース状態を把握しづらい一方、DatadogはAgentをSidecarとして動かすことで、CPUやメモリ使用率、ログ、死活状態などを多層的に監視できます。加えて、Terraformとの統合やUIの直感性により、短期間での構築と検証が可能でした。モニターでは通知メッセージに変数を埋め込めるため、異常発生時に状況や対応手順を自動で案内できる点が実用的でした。また、APMやログ監視を無料トライアル中に検証できたことも、実環境での導入を見据えた判断材料になりました。

無料プランでできることと制約

Datadogには14日間の無料トライアルが用意されています。

この期間中は以下の有償機能が試用可能です：

APM（アプリケーションパフォーマンス監視）
コンテナの詳細メトリクス（FargateのCPUやメモリなど）
ログ収集・インデックス・検索・フィルタリング
Process Monitoring や Host Map 機能など

これにより、Fargateのモニタリングやトレース分析を実運用レベルで検証できます。

トライアル時に注意すべき設定（Terraform）

Datadogでは、有償機能（APM、ログ、プロセス監視など）を明示的に無効化しない限り有効化される場合があり、意図せず課金対象になることがあります。特に、ログの保持期間延長や同時に監視するホスト数の上限を超えると、従量課金が発生する可能性があるため注意が必要です。

そのため、環境変数によって機能を明示的にON/OFF制御する構成が推奨されます。

以下は、Datadog AgentをFargateで使用する際の主な環境変数設定の例です：

environment = [
  { name  = "DD_SITE", value = "ap1.datadoghq.com" },
  { name  = "ECS_FARGATE", value = "true" },
  { name  = "DD_CONTAINER_METRICS_ENABLED", value = "true" },
  { name  = "DD_LOGS_ENABLED", value = "true"},
  { name  = "DD_PROCESS_AGENT_ENABLED", value = "true"},
  { name  = "DD_PROCESS_CONFIG_ENABLED", value = "true"},
  { name  = "DD_LOGS_CONFIG_CONTAINER_COLLECT_ALL", value = "true"},
  { name  = "DD_APM_ENABLED", value = "true"},
  { name  = "DD_TRACE_ENABLED", value = "true"}
]

ECS on Fargate構成と監視アーキテクチャ

アーキテクチャは以下のような構成です：

本構成では、FastAPIアプリをFargateで動作させるタスク定義内に、以下の4コンテナを定義し、dependsOnにより起動順を制御しました：

init-datadog : Datadog Agent起動準備（Volumeマウント）
datadog-agent : 常駐型の監視プロセス（監視をバックグラウンドで実行）
db-migration : 初期マイグレーション実行（一時実行）
fastapi-app : FastAPIアプリ本体（dependsOnで順序制御）

これにより、アプリの起動前にDatadog Agentが準備され、ログ・メトリクスが確実に取得されるようになります。
アプリログがDatadog Agent起動前に失われることを防ぎます。

この設定により、Datadog Agentの挙動を環境変数ベースで柔軟に管理でき、コストリスクを抑えた状態で機能を評価できます。

Datadog APIキーを Secrets Manager で管理する

Datadog AgentのAPIキーはAWS Secrets Managerに格納し、ECSタスク起動時に環境変数として安全に注入します。これにより、コードやタスク定義にハードコーディングせずに機密情報を管理可能です。IAMロールに secretsmanager:GetSecretValue 権限を付与することも忘れずに設定します。

Datadog APIキーの確認方法
Datadogコンソール画面の左下「アカウント名」→「Organization Settings」→「API Keys」から確認することができます。取得したキーはSecrets Managerに登録し、ECSタスク定義の環境変数から参照する形をとります。

DatadogでFargateコンテナのモニターを作成する手順

Datadogでは「Monitor（モニター）」機能を使って、Fargate上のECSコンテナの状態を自動監視し、異常時に通知を受け取ることができます。ここでは、監視対象となるFargateコンテナに対してモニターを設定する手順を紹介します。

① 「Monitors」→「New Monitor」を選択
Datadogの左メニューから「Monitors」を開き、「New Monitor」をクリックして新しい監視条件の作成を開始します。

② モニタータイプに「Host」を選択
監視対象としてホスト単位の状態を選ぶため、モニタータイプで「Host」を選択します。

③ ターゲットホストを絞り込む
検索窓に name:と入力し、Datadog AgentがインストールされたECSクラスターのホスト名をフィルタリングします。
「ecs_cluster_name: "作成したクラスター名" 」を選択して対象を指定します。

④ アラート条件を設定
例えば、コンテナの agent-up が「Down」になった際に通知を送るよう設定します。必要に応じて再試行回数やリカバリ条件も調整可能です。

⑤ 通知内容を設定
モニター名・通知内容・通知先メールアドレスなどを入力し、「Create」ボタンを押して作成を完了します。
通知メッセージには異常検知時の対応手順などを含めておくと、トラブル対応がスムーズになります。

⑥ モニターが作成されたことを確認
一覧に新しく作成したMonitorが表示されていれば、設定は完了です。

⑦ Fargateコンテナが対象として監視されているか確認
作成したモニターが、Fargate上のDatadog Agentが稼働するホスト（コンテナ）に対して有効に動作していることを確認します。問題がある場合、CloudWatch Logs で Agent の状態を調べましょう。

アラート通知設計とGmail連携設定

前のセクション「⑤ 通知内容を設定」では、モニター発火時の通知先やメッセージの基本設定を行いました。
ここではその補足として、Fargate上のコンテナに異常が発生した場合に、実際にどのような通知がGmailに届くのか、および効果的な通知テンプレート設計のポイントを具体的に解説します。
Datadogではテンプレート変数を活用することで、通知メッセージに対象のコンテナ名やIPアドレス、関連ダッシュボードへのリンクなどを自動挿入することができます。
これにより、通知を受け取った運用者がすぐに状況を把握し、適切な対応に移ることが可能になります。

以下は一例です：

{{#is_alert}}  
🚨【Fargateアラート】コンテナ {{host.name}} が応答しません 🚨

🔎 **概要**
ECS on Fargate 上のコンテナ {{host.name}} からの応答が途絶えています。  
Datadog Agent またはアプリケーションレイヤーの問題の可能性があります。

⚠️ **想定される原因**
1. タスクが停止・強制終了された（スケジューリング or OOM）
2. Datadog Agent の初期化やバックグラウンド常駐に失敗
3. Secrets Manager 経由の API キー読み込み失敗
4. アプリケーションのクラッシュまたは ALB 経由のヘルスチェック失敗

🛠 **推奨される対応手順**
- ECS コンソールで該当タスクの状態を確認
- `datadog-agent` のログを CloudWatch で確認
- Secrets Manager の API キーの有効性を確認
- ALB ターゲットのヘルスチェックステータスを確認
- コンテナのログ確認（`DD_LOGS_ENABLED` = true の場合）

📊 **関連リンク**
- Infrastructure ダッシュボード: [{{host.name}} 詳細](https://app.datadoghq.com/infrastructure?filter=host:{{host.name}})
- CloudWatch Logs: `log-group:/ecs/{{host.name}}`
- Datadog Agent ステータス確認: `init-datadog` or `datadog-agent` タスクログ参照

🔔 **通知先**: @XXXXX@gmail.com  
{{/is_alert}}

---

{{#is_recovery}}  
✅【回復】Fargate コンテナ {{host.name}} が応答を再開しました ✅

📌 **タスク名**: {{host.name}}  
📌 **IP アドレス**: {{host.ip}}

📊 **関連リンク**
- Infrastructure ダッシュボード: [{{host.name}} 詳細](https://app.datadoghq.com/infrastructure?filter=host:{{host.name}})
- CloudWatch Logs: `/ecs/{{host.name}}`

🔔 **通知先**: @XXXXX@gmail.com  
{{/is_recovery}}

メトリクスを確認する方法（Metrics Explorer）

Datadogの "Metrics Explorer" を使用することで、Fargate上で動作するコンテナのCPUやメモリなどのリソース使用状況を、時系列グラフとして視覚的に把握できます。対象メトリクスを選択し、時間範囲を「Past 1 Day」などに変更することで、過去24時間の推移を確認可能です。

このグラフから何がわかるのか？

このメトリクス（ ecs.fargate.cpu.user ）は、Fargateコンテナがユーザーレベルの処理でどれだけCPUを使っているか（ミリコア単位）を示しています
折れ線の上下変動は、アプリケーションの処理負荷の変動や外部アクセスの増減を表しており、ピーク時間帯の特定やスケーリング判断に役立ちます
たとえば、15時台にスパイクが見られれば、その時間帯に一時的な高負荷処理が発生していたことを示唆します
このようなグラフを用いることで、特定時間帯にリソース使用率が異常に高くなっていないか、スケーリングが適切か、負荷分散が効いているかを定量的に判断できます。

複数メトリクスの重ね表示で全体傾向を把握

Datadogでは「Add Query」機能を使うことで、1つのグラフ上に複数のメトリクスを同時に表示できます。

たとえば、以下のように設定することで、負荷上昇時のリソース全体への影響を可視化できます：

ecs.fargate.cpu.user （CPU使用量）
ecs.fargate.mem.usage（メモリ使用量）
ecs.fargate.net.bytes_sent（ネットワーク送信量）

複数のメトリクスを組み合わせて可視化することで、リソース間の相関関係が把握しやすくなり、どのリソースがボトルネックになっているかを特定しやすくなります。これにより、システム全体の健全性をより正確に判断できます。

Datadogで取得できる主なFargateメトリクス

以下は、Datadogが収集可能な主な ecs.fargate メトリクスです：

メトリクス名	説明
`ecs.fargate.cpu.user`	ユーザーレベルのCPU使用量（ミリコア）
`ecs.fargate.cpu.system`	カーネルレベルのCPU使用量（ミリコア）
`ecs.fargate.mem.usage`	使用中のメモリ（バイト）
`ecs.fargate.mem.rss`	常駐セットサイズ（RSS）
`ecs.fargate.net.bytes_rcvd`	ネットワーク受信バイト数
`ecs.fargate.net.bytes_sent`	ネットワーク送信バイト数
`ecs.fargate.net.packet.in_dropped`	受信パケットのドロップ数
`ecs.fargate.net.packet.out_dropped`	送信パケットのドロップ数

Metrics Explorerで ecs.fargateと入力すれば、上記のようなメトリクス候補がドロップダウン形式で表示されるため、存在する項目だけを正確に選択できます。
DatadogのMetrics Explorerは、ただのグラフ描画ツールではなく、タグベースの柔軟なフィルタや複数メトリクスの重ね表示など、現場運用を見据えた高度な可視化と分析が可能な機能です。
これらを活用することで、Fargate環境のリソース使用状況を継続的かつ効果的にモニタリングできます。

まとめ

Datadogは、Fargate環境における非侵襲的かつ多層的な監視を可能にし、アプリやインフラの状態把握・障害対応を効率化します。今回のハッカソンでは、構築スピード・運用設計の観点からも適したツールであると実感しました。今後はAPMやSLO指標の活用を通じて、信頼性向上にもつなげていきたいと考えています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up