Datadog 06–08

Datadog と ECS — AWSの外側と、コンテナの内側を集める

AWS IntegrationとDatadog Agentは競合ではありません。CloudWatch経由で見える管理サービスの世界と、コンテナ内からしか取れないアプリの世界を補い合います。

TL;DR

  1. AWS IntegrationはCloudWatch API等を通じ、AWSマネージドサービスの情報を取得する。
  2. Datadog AgentはECSタスクに同居し、コンテナ・ホスト・APMなどの詳細を収集する。
  3. ログ配送はFireLens、メトリクス/トレース収集はAgentという経路を分けて考える。

01クラウドの管理面と、アプリの実行面を一緒に観測する。

AWSの管理面と、コンテナの実行面を補完関係として捉える。

クラウドの管理面と、アプリの実行面を一緒に観測する。
左はCloudWatch経由の外側、右はAgent経由の内側で、中央のDatadogへ合流する。

RDS CPUやSQS滞留はAWS Integration、アプリコンテナのCPUやAPM traceはAgentというように、観測対象で入口が変わる。

「Agentを入れたからRDSも見える」とは限らない。データ源と必要なIAM権限・設定を信号ごとに確認する。

02アプリの隣に収集役を置き、コンテナ単位の状態を出す。

アプリと同じECS Task内に、テレメトリ収集用コンテナを置く。

アプリの隣に収集役を置き、コンテナ単位の状態を出す。
タスクの枠内でAppとAgentが並び、AgentだけがDatadogへ送信する構造を見る。

cost-providerとAgentを同じタスク定義に置き、service・env・versionタグを共通化してコンテナメトリクスとAPMを送る。

APIキーや環境名を平文で混在させず、安全な注入経路とタグの一貫性を確認する。

03どの信号がどこを通るかを、タスク定義で明確にする。

ログ、メトリクス、トレースの入口を別々に追跡できるようにする。

どの信号がどこを通るかを、タスク定義で明確にする。
stdout→FireLensの上経路と、tracer/metrics→Agentの下経路がDatadog側で合流する。

ログが欠ける場合はlog driverとFireLensを、traceが欠ける場合はTracerからAgentへの接続を先に確認する。

すべてをAgent障害と決めつけない。信号ごとの配送経路を切り分けると、調査対象を早く絞れる。

結論

  1. AWS Integrationは管理サービス、Agentは実行中コンテナに近い情報を補う。
  2. ECSではAgentをサイドカーとして置き、実行面の観測を行う。
  3. ログはFireLens、メトリクスとトレースはAgentという収集経路を分けて理解する。