Datadog integrations Deep Dive - AWS 編

はじめに

こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。

本記事は『【完全解説】4大クラウドの Datadog integrations アーキテクチャ【2024年版】』で解説仕切れなかった、Datadog AWS integration の細かな仕様と注意点を解説します。

主にメトリクス・ログ収集に関する AWS integration の様々なオプションについて解説しているので、参考にしていただけると幸いです🐶

AWS integration の全体像

デフォルトのデータ送信

Datadog AWS integration は主に Amazon CloudWatch からのメトリクス・ログ情報の収集と、各リソースのメタデータの参照と監視情報への紐付けを行います。

AWS integration のネットワーク接続

AWS integration はメトリクス・ログを Datadog Organization 毎に用意された API Key による認証でデータを適切な Datadog Org に収集します。この時、Datadog Site として US1, AP1 を選択することで、暗黙的に AWS グローバルネットワークを介した通信が行われ、安全性と効率性が高い状態での監視データ連携ができます。

加えて、ログ収集は Datadog Lambda Forwareder を利用しますが、AWS PrivateLink を介して Datadog に接続することで、明示的にプライベートネットワークを介した通信を強制できます。

• Datadog Lambda Forwareder ドキュメント「AWS PrivateLink サポート」

ストリーミングデータ送信

メトリクス・ログ収集は上記の方法以外に、Amazon Data Firehose を用いたストリーミングでの連携ができます。これらはデフォルトのデータ送信のデメリットを許容できない場合に選択するオプションの方式です。

メトリクス・ログのストリーミング転送用の CloudFormation テンプレートは Datadog から提供されています。

メトリクス収集

• デフォルト方式
  
• ストリーミング方式
  

複数メトリクス収集方式の併用

前述の通り、CloudWatch メトリクスの収集は Datadog クローラーが CloudWatch Metrics API を利用するデフォルト方式と、CloudWatch Metrics Stream と Data Firehose を利用するストリーミング方式があります。

これらの2つの方式は併用可能です。デフォルト方式が設定された上で、ストリーミング方式を特定のメトリクスで有効化すると、Datadog クローラーは自動的にそのメトリクスへの API リクエストを除外します。さらに、デフォルト方式によりカスタムタグや他のメタデータを収集するため、併用することが推奨されます。

メトリクス収集方式の選択

特定の方式でしか Datadog に連携できない CloudWatch メトリクスが存在します。

• デフォルト方式: aws.s3.bucket_size_bytes や aws.billing.estimated_charges などの2時間以上遅れて報告されるメトリクス
• ストリーミング方式: CloudWatch cross-account observability による他アカウントのメトリクス¹

両方式のメリット・デメリットを見比べると、互いにトレードオフであることがわかります。メトリクスの特性と利用用途に合わせて連携方式を決定しましょう。

方式	メリット	デメリット
デフォルト方式	柔軟な除外設定 メタデータの付与	15~20分の遅延
ストリーミング方式	2~3分の遅延	メタデータの欠如 課金の増加

詳細はそれぞれの設定ガイドを併せてご参照ください。

• Amazon Data Firehose を使用した AWS CloudWatch メトリクスストリーム
• Datadog Amazon Data Firehose Destination を使用して AWS サービスログを送信する

収集メトリクスの除外・制限

メトリクスの連携が不要な場合は名前空間や AWS リソースタグに基づく除外ができます。

Datadog の AWS integration タイルから、AWS のサービス名毎に用意される CloudWatch のメトリクス名前空間(AWS/<サービス名>/) ごとに収集を無効化できます。[Metric Collection] タブを選択し各サービス名のトグルをオフにすることで、Datadog クローラーは対象のメトリクス名前空間への API リクエストを行わなくなります。

さらに、EC2, Lambda, ELB(ALB, NLB), RDS, SQS, カスタムメトリクス の場合は、ホワイト/ブラックリストの両形式でリソースタグに応じたメトリクス収集の限定ができます。これにより、EC2, Lambda, カスタムメトリクス数に応じた Datadog 上の課金を制限できます。(ELB, RDS, SQS メトリクスの取り込みは Datadog の課金には影響しません)

詳細は「AWS インテグレーションの請求」ガイドを併せてご参照ください。

ログ収集

• デフォルト方式
  

• ストリーミング方式
  

デフォルトのログ収集

デフォルトではログ転送には Datadog Lambda Forwarder を利用することが推奨されます。

Lambda Forwarder は転送だけではなくログのマスキング・フィルタリング・圧縮・タグ付けなどを行えます。Datadog Lambda Forwarder は AWS CloudFormation(Cfn) で作成時に CloudFormation パラメーターでこれらのオプションを制御できます。作成後も、Lambda 環境変数に DD_SITE のようにアッパースネークケースで値を指定し、これらの機能を有効化できます。

これは、Lambda Forwarder には内部的に Datadog Agent と同様の機能を備えており、Datadog Agent のログ転送オプション同様の制御ができるためです。内部的な仕組みは GitHub にも公開されています。

そのため、Lambda Forwarder は Lambda 関数のトレースやメトリクスを転送する機能も備えていますが、現在この利用方法は非推奨となっています。Lambda Forwarder の代わりに、Lambda Extension(拡張機能) で Lambda 関数ごとに転送機能を用意することが推奨されます。

auto-subscription 機能

Lambda Forwarder を利用する大きな利点は、auto-subscription 機能です。これは、AWS integration で設定された IAM role を利用して、Datadog 上の AWS integration タイルからログ収集を制御できる機能です。特定の CloudWatch ログ名前空間のサブスクリプションフィルターの作成と、特定のログを保管する S3 のトリガーの作成ができます。

ストリーミングのログ収集

アカウント・リージョンごとの Lambda の同時実行制限に影響を与えたくない場合や、複数リージョンからのログを転送したい際には Data Firehose を利用したログのストリーミングが可能です。

ただし、ストリーミングでログ送信を制御したい場合にも Lambda Forwarder の作成は推奨されます。これはストリーミング転送に失敗した際、そのログを S3 に保管して再送するためです。

Data Firehose は CloudWatch ログから直接宛先として指定でき、他に Data Streams の宛先としても指定できます。そのため、CloudWatch ログ以外のデータソースからログを直接転送したい場合に有効な選択肢です。

ログ収集方式の選択

両方式のメリット・デメリットを見比べると、基本はデフォルト方式で問題ないことが分かります。デフォルト方式のデメリットが許容できない場合にストリーミング方式を検討しましょう。

方式	メリット	デメリット
デフォルト方式	マスキング・フィルタリング ・圧縮・タグ付け auto-subscription 機能	Lambda 同時実行制限への影響 リージョンの制限
ストリーミング方式	マルチリージョン対応 多様な転送元の選択	タグ付けの制限 再送構成の手間

詳細はそれぞれの設定ガイドも併せてご参照ください。

• Datadog の Lambda 関数で AWS サービスのログを送信する
• Datadog Amazon Data Firehose Destination を使用して AWS サービスログを送信する

AWS integration × CloudFormation

AWS integration を CloudFormation(Cfn) で作成すると、多数のリソースが作成されます。図中の「Lambda Forwarder Cfn Stack」ログ収集に利用される Lambda Forwarder と必要なリソースが含まれ、「AWS integration Cfn Stack」はメトリクス・コスト・メタデータ・X-ray トレース収集や auto-subscription 機能・ログアーカイブに利用される IAM role を作成します。

さらに利用者が意識しない範囲として、「Datadog API Call Cfn Stack」があります。これは Datadog API for AWS integrationを呼び出し、Datadog 内の AWS integration に必要な設定・リソースの作成・変更・削除を行うための DatadogAPICall Lambda 関数とその権限である IAM role を作成するものです。

この Lambda 関数は、Cfn のカスタムリソースとして機能し、Cfn の作成・変更・削除に伴って Datadog API を呼び出して Datadog 内の設定やリソースを作成・変更・削除を行います。そのため、AWS integration を停止したい場合は、Cfn スタックの削除を行うだけで Datadog 上の設定も自動的に削除されます。

おわりに

本記事では Datadog AWS integration を使いこなすための情報をオリジナルの図と共に説明しました。

Datadog の AWS integration には、X-ray トレースの連携やログアーカイブとしての S3 の利用、EventBridge と Datadog Event Management の統合など触れられていない機能もたくさんあります。

基本的な機能については『【完全解説】4大クラウドの Datadog integrations アーキテクチャ【2024年版】』でも説明しているため、こちらも是非ご参照ください。

1. 他アカウントのメトリクスのメタデータは、メトリクスのソースアカウント自体にデフォルト方式の設定を行うことで収集できます。 ↩