Datadog Forwarder

概要

Datadog Forwarder は、AWS から Datadog にログを送信する AWS Lambda 関数で、具体的には次のようなものです。

CloudWatch、ELB、S3、CloudTrail、VPC、SNS、CloudFront ログを Datadog に転送します。
S3 イベントを Datadog に転送します。
Kinesis データストリームイベントを Datadog に転送します (CloudWatch ログのみがサポートされています)。
AWS Lambda 関数から Datadog にメトリクス、トレース、ログを転送します。Datadog は、Lambda 関数を監視するために Datadog Lambda 拡張機能を使用することを推奨しています。

Forwarder を使用して AWS Lambda のログから Datadog にメトリクス、トレース、ログを転送しているサーバーレスのお客様は、Lambda の実行環境から直接テレメトリーを収集する Datadog Lambda 拡張機能へ移行するべきです。Forwarder は引き続きサーバーレスモニタリングで使用可能ですが、最新機能のサポートに伴うアップデートは行われません。

Datadog Forwarder による AWS サービスのログ送信については、Datadog Lambda 関数で AWS Services のログを送信するガイドをお読みください。

インストール

Datadog では、CloudFormation を使用して Forwarder を自動インストールすることを推奨しています。また、Terraform を使用するか手動で設定プロセスを完了することもできます。インストールが完了したら、トリガーの設定により、S3 バケットや CloudWatch ロググループなどのログソースに Forwarder をサブスクライブすることができます。

CloudFormation

管理者 AWS アカウントまたはロールにログインし、上のボタンで CloudFormation Stack をデプロイします。
DdApiKey を入力し、適切な DdSite を選択します。他のすべてのパラメーターはオプションです。
Create stack をクリックし、作成が完了するまで待ちます。
スタックの “Resources” タブで、論理 ID が Forwarder のインストール済みの Forwarder Lambda 関数を見つけます。
インストールした Forwarder にトリガーを設定します。
複数の AWS リージョンで運用している場合は、別のリージョンで上記の手順を繰り返します。

以前に Datadog の AWS インテグレーションページから以下の CloudFormation テンプレートを使用して AWS インテグレーションを有効にした場合、それを含めることにした場合、アカウントにはすでに Datadog Lambda Forwarder 関数がプロビジョニングされている場合があります。その場合、ログをエクスポートしたいアカウント内の追加の AWS リージョンに Datadog Lambda をインストールするだけで済みます。

注: Datadog Lambda Forwarder 関数コードブロックは、Lambda レイヤーを通してロジックが実装されているため、空であることが期待されます。

Terraform

Terraform リソース aws_cloudformation_stack を、指定されている CloudFormation テンプレートのラッパーとして使用して、Forwarder をインストールします。

Datadog は、個別の Terraform コンフィギュレーションを作成することをお勧めします。

最初のものを使用して Datadog API キーを AWS Secrets Manager に保存し、出力から適用するシークレット ARN を書き留めます。
次に、Forwarder のコンフィギュレーションを作成し、DdApiKeySecretArn パラメーターを介してシークレット ARN を指定します。
最後に、Forwarder にトリガーを設定するための構成を作成します。

API キーと Forwarder の構成を分離することで、Forwarder のアップデート時に Datadog API キーを提供する必要がありません。将来的に Forwarder を更新またはアップグレードするには、Forwarder の構成を再度適用します。

コンフィギュレーション例

# AWS Secrets Manager に Datadog API キーを保存します
variable "dd_api_key" {
  type        = string
  description = "Datadog API key"
}

resource "aws_secretsmanager_secret" "dd_api_key" {
  name        = "datadog_api_key"
  description = "Encrypted Datadog API Key"
}

resource "aws_secretsmanager_secret_version" "dd_api_key" {
  secret_id     = aws_secretsmanager_secret.dd_api_key.id
  secret_string = var.dd_api_key
}

output "dd_api_key" {
  value = aws_secretsmanager_secret.dd_api_key.arn
}

# Datadog Forwarder を使用して S3 と CloudWatch からのログ、および Lambda 関数からの可観測性データを Datadog へ送信します。詳しくは https://github.com/DataDog/datadog-serverless-functions/tree/master/aws/logs_monitoring を参照してください
resource "aws_cloudformation_stack" "datadog_forwarder" {
  name         = "datadog-forwarder"
  capabilities = ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM", "CAPABILITY_AUTO_EXPAND"]
  parameters   = {
    DdApiKeySecretArn  = "REPLACE ME WITH THE SECRETS ARN",
    DdSite             = "<SITE>",
    FunctionName       = "datadog-forwarder"
  }
  template_url = "https://datadog-cloudformation-template.s3.amazonaws.com/aws/forwarder/latest.yaml"
}

注: Datadog サイトと DdSite パラメーターが一致していることを確認してください。このページの右側でサイトを選択してください。上記のサンプル構成の <SITE> をに置き換えてください。

class SampleRegistry { public function put($key, $value) { \App\some_utility_function(‘some argument’); // 挿入されたアイテムの ID を返す return 456; }

手動

指定されている CloudFormation テンプレートを使用して Forwarder をインストールできない場合は、以下の手順に従って Forwarder を手動でインストールできます。テンプレートの機能について改善できる点がございましたら、お気軽に問題やプルリクエストを開いてお知らせください。

最新のリリースから、 aws-dd-forwarder-<VERSION>.zip を使用して Python 3.10 Lambda 関数を作成します。
Datadog API キーを AWS Secrets Manager に保存し、環境変数 DD_API_KEY_SECRET_ARN に Lambda 関数のシークレット ARN を設定し、Lambda 実行ロールに secretsmanager:GetSecretValue アクセス許可を追加します。
S3 バケットからログを転送する必要がある場合は、s3:GetObject アクセス許可を Lambda 実行ロールに追加します。
Forwarder で環境変数 DD_ENHANCED_METRICS を false に設定します。これにより、Forwarder は拡張メトリクス自体を生成しなくなりますが、他の Lambda からカスタムメトリクスを転送します。
一部の AWS アカウントは、トリガーが Cloudwatch ロググループが Forwarder を呼び出すことを許可するリソースベースのポリシーを自動的に作成しないように構成されています。Cloudwatch Log Events によって Forwarder が呼び出されるために必要な権限を確認するには、CloudWatchLogPermissions を参照してください。
トリガーを構成します。
S3 バケットを作成し、環境変数 DD_S3_BUCKET_NAME をバケット名に設定します。また、このバケットに s3:GetObject、s3:PutObject、s3:ListBucket、s3:DeleteObject 権限を Lambda 実行ロールに提供します。このバケットは、異なるタグキャッシュ (Lambda、S3、Step Function、Log Group) の保存に使用されます。さらに、このバケットは、転送の例外が発生した場合に、未転送のイベントを保存するために使用されます。
環境変数 DD_STORE_FAILED_EVENTS を true に設定して、フォワーダーがイベントデータも S3 バケットに保存するようにします。ログ、メトリクス、トレースをインテークに送信する際に例外が発生した場合、フォワーダーは関連データを S3 バケットに保存します。カスタム呼び出し、つまり retry キーワードが空でない文字列に設定されたイベントを受信した場合 (手動でトリガー可能 - 下記参照)、フォワーダーは保存されたイベントの送信を再試行します。成功した場合、バケット内のストレージをクリアします。

aws lambda invoke --function-name <function-name> --payload '{"retry":"true"}' out

新しいバージョンにアップグレードする

datadog-forwarder (名前を変更しなかった場合) CloudFormation スタックを見つけます。Datadog AWS インテグレーションスタックの一部として Forwarder をインストールした場合は、ルートスタックではなく、ネストされた Forwarder スタックを更新してください。
CloudFormation スタックの “Resources” タブから実際の Forwarder Lambda 関数を見つけ、その構成ページに移動します。新しいバージョンで問題が発生しロールバックする必要がある場合に備えて、dd_forwarder_version タグの値 (例: 3.73.0) をメモしておきます。
テンプレート https://datadog-cloudformation-template.s3.amazonaws.com/aws/forwarder/latest.yaml を使用してスタックを更新します。必要に応じて、latest を 3.73.0.yaml などの特定のバージョンに置き換えることもできます。アップデートを適用する前に、必ず変更セットを確認してください。

最新バージョンへのアップグレードで問題が発生した場合は、トラブルシューティングのセクションを確認してください。

古いバージョンを 3.107.0 以降にアップグレードする

バージョン 3.107.0 から、インテークポイントで例外が発生した場合に未転送のイベントを Lambda 関数が保存できる新機能が追加されました。DD_STORE_FAILED_EVENTS 環境変数を使用してこの機能を有効にすると、失敗したイベントはタグキャッシュを保存するために使用されるのと同じ S3 バケット内の定義済みディレクトリに保存されます。同じバケットを使用して、複数の Lambda 関数のログをユニークなサブディレクトリに保存できます。

古いバージョンを 3.106.0 以降にアップグレードする

バージョン 3.106.0 から、Lambda 関数は DD_S3_BUCKET_NAME で構成された S3 バケットに保存されるキャッシュファイル名にプレフィックスを追加するよう更新されました。これにより、複数の関数のキャッシュファイルを同じバケットに保存できるようになります。

古いバージョンを 3.99.0 以降にアップグレードする

バージョン 3.99.0 以降、Lambda 関数は Python 3.11 を必要とするように更新されました。古いフォワーダーのインストールを 3.99.0 以上にアップグレードする場合は、AWS Lambda 関数が Python 3.11 を使用するように構成されていることを確認してください。

古いバージョンを 3.98.0 以降にアップグレードする

バージョン 3.98.0 以降、Lambda 関数は Python 3.10 を必要とするように更新されました。古いフォワーダーのインストールを 3.98.0 以上にアップグレードする場合は、AWS Lambda 関数が Python 3.10 を使用するように構成されていることを確認してください。

古いバージョンを 3.74.0 以降にアップグレードする

バージョン 3.74.0 以降、Lambda 関数は Python 3.9 を必要とするように更新されました。古いフォワーダーのインストールを 3.74.0 以上にアップグレードする場合は、AWS Lambda 関数が Python 3.9 を使用するように構成されていることを確認してください。

古いバージョンを 3.49.0 以降にアップグレードする

バージョン 3.49.0 以降、Lambda 関数は Python 3.8 を必要とするように更新されました。古い Forwarder を 3.49.0 以上にアップグレードする場合、AWS Lambda 関数が Python 3.8 を使用するように構成されていることを確認してください。

古いバージョンを 3.0.0 以降にアップグレードする

バージョン 3.0.0 以降、Forwarder Lambda 関数は CloudFormation によって管理されます。古い Forwarder のインストールを 3.0.0 以降にアップグレードするには、以下の手順に従います。

インストールの手順に従って、新しい Forwarder をインストールします。
スタックの “Resources” タブで、論理 ID が Forwarder のインストール済みの Forwarder Lambda 関数を見つけます。
古い Forwarder のいくつかのトリガー (CloudWatch ロググループサブスクリプションフィルターと S3 バケットイベント通知) を新しいものに手動で移行します。
新しい Forwarder が期待どおりに機能していること、たとえばエラーなしで定期的に呼び出されることを確認します。
移行されたトリガー (ソース) からのログが Datadog ログエクスプローラーに表示されていることと、正しく表示されていることを確認します。
すべてのトリガーを新しい Forwarder に移行します。
- Datadog にトリガー管理を自動で任せている場合は、AWS インテグレーションページ Log Collection タブで Forwarder の Lambda ARN を更新します。
- トリガーを手動で管理していた場合は、手動で (またはスクリプトで) 移行する必要があります。
古い Forwarder Lambda 関数の呼び出しカウントがゼロになっていることを確認します。
安心したら、古い Forwarder Lambda 関数を削除します。
古い Forwarder Lambda 関数が複数の AWS アカウントとリージョンにインストールされている場合は、アカウントとリージョンのすべての組み合わせで上記の手順を繰り返します。

削除

Forwarder および、Forwarder CloudFormation スタックによって作成された他の AWS リソースを安全に削除するには、以下の手順に従います。

datadog-forwarder (名前を変更しなかった場合) CloudFormation スタックを見つけます。または、“This function belongs to an application. Click here to manage it.” (この関数はアプリケーションに属しています。ここをクリックして管理します。) というメッセージからリンクをクリックし、アプリケーションページの “Deployments” タブをクリックして、Forwarder Lambda 関数の管理コンソールからスタックを見つけることができます。
CloudFormation スタックを「削除」します。

Forwarder 設定の調整

datadog-forwarder (名前を変更しなかった場合) CloudFormation スタックを見つけます。
現在のテンプレートを使用してスタックを更新します。
パラメーター値を調整します。

Datadog は、Lambda 関数を直接編集するのではなく、CloudFormation を介して Forwarder 設定を調整することをお勧めします。スタックを起動するときに、template.yaml ファイルと CloudFormation スタック作成ユーザーインターフェイスで設定の説明を確認してください。追加の設定をテンプレートで調整できるように、お気軽にプルリクエストを送信してください。

ヘルプ

最近のリリースで問題がすでに修正されているかどうかも、忘れずに確認してください。

ロギング

Forwarder Lambda 関数で環境変数 DD_LOG_LEVEL を debug に設定して、詳細なログ記録を一時的に有効にします (削除することを忘れないでください)。デバッグログには、Lambda 関数が受信する正確なイベントペイロードと、Datadog に送信されるデータ (ログ、メトリクス、またはトレース) ペイロードを表示できる必要があります。

さらに詳細な調査のために、ログやコードを追加することもできます。寄稿セクションから、ローカルの変更を使用して Forwarder コードを構築する手順を見つけてください。

フォワーダーの更新に関する問題

フォワーダーの .zip コードを手動で更新すると、コードが Lambda レイヤーにパッケージされているフォワーダーインストールの CloudFormation アップデートと競合し、呼び出しエラーを引き起こす可能性があります (バージョン 3.33.0 からのデフォルトのインストール選択)。この場合、CloudFormation を介してスタックを最新のものに 2 回連続で更新する (最初に InstallAsLayer を false に設定し、次に true に設定する) ことで、問題が解決するはずです。これにより、.zip の残りが削除され、利用可能な最新のレイヤーがインストールされます。

それでもわからない場合は、デバッグログのコピーを使用して Datadog サポートのチケットを作成してください。

JSON 形式のログが Datadog に表示されていない

ログに Datadog がタイムスタンプとしてパースする属性が含まれている場合、タイムスタンプが現在で正しい形式であることを確認する必要があります。どの属性がタイムスタンプとしてパースされ、タイムスタンプが有効であることを確認する方法については、ログ日付リマッパーを参照してください。

S3 トリガーの作成に関する問題

S3 トリガーを作成する際に次のようなエラーが発生した場合、この記事で AWS が提案するファンアウトアーキテクチャに従うことを検討してください。

An error occurred when creating the trigger: Configuration is ambiguously defined. Cannot have overlapping suffixes in two rules if the prefixes are overlapping for the same event type.

寄稿

プルリクエストは大歓迎です。こちらがクイックガイドです。

実装する前に機能やバグ修正について話し合いたい場合は、Datadog Slack コミュニティの #serverless チャンネルで私たちを見つけてください。

ブランチをフォーク、複製、作成します。

git clone git@github.com:<your-username>/datadog-serverless-functions.git
git checkout -b <my-branch>

コードを変更します。

ローカルの変更で構築します。

cd aws/logs_monitoring
./tools/build_bundle.sh <SEMANTIC_VERSION> # any unique version is fine

変更したコードでテスト Forwarder を更新し、テストします。

# Upload in the AWS Lambda console if you don't have AWS CLI
aws lambda update-function-code \
    --region <AWS_REGION>
    --function-name <FORWARDER_NAME> \
    --zip-file fileb://.forwarder/aws-dd-forwarder-<SEMANTIC_VERSION>.zip

単体テストを実行します。

python -m unittest discover . # for code in Python
./trace_forwarder/scripts/run_tests.sh # for code in Go

インテグレーションテストを実行します。

./tools/integration_tests/integration_tests.sh

# to update the snapshots if changes are expected
./tools/integration_tests/integration_tests.sh --update

変更が CloudFormation テンプレートに影響する場合は、自身の AWS アカウントに対してインストールテストを実行してください。
```
./tools/installation_test.sh
```
フォークにプッシュして、プルリクエストを送信します。

高度な検索

複数の宛先へのログ送信

複数の Datadog オーガニゼーションまたはその他の送信先にログを送信する必要がある場合は、AdditionalTargetLambdaArns Cloudformation パラメーターを構成し、Datadog Forwarder で受信ログを指定の Lambda 関数にコピーします。これらの追加された Lambda 関数は、Datadog Forwarder が受信するものとまったく同じ event で非同期的に呼び出されます。

AWS PrivateLink サポート

VPC プライベートサブネットで Forwarder を実行し、AWS PrivateLink で Datadog にデータを送信できます。AWS PrivateLink は、AWS でホストされている Datadog サイトでのみ (たとえば datadoghq.eu ではなく datadoghq.com)、構成が可能です。

こちらの手順に従って、Datadog の api、http-logs.intake、trace.agent エンドポイントを VPC に追加します。
説明に従って、AWS Secrets Manager と S3 エンドポイントを VPC に追加します。
Forwarder を CloudFormation テンプレートでインストールする場合
1. UseVPC を true に設定します。
2. VPC 設定に基づき VPCSecurityGroupIds および VPCSubnetIds を設定します。
3. AWS Resource Groups Tagging API では PrivateLink がサポートされないため、DdFetchLambdaTags を false に設定します。

DdUsePrivateLink は非推奨です

DdUsePrivateLink オプションは v3.41.0 から非推奨になりました。このオプションは以前、データのインテークに PrivateLink エンドポイントの特別なセットを使用するよう Forwarder に指示するために使用されていました: pvtlink.api.、api-pvtlink.logs.、trace-pvtlink.agent.。v3.41.0 以降、Forwarder はインテークエンドポイントの通常の DNS 名を使用して PrivateLink 経由で Datadog にデータを送信することができます: api.、http-intake.logs.、trace.agent.。したがって、DdUsePrivateLink オプションは不要になりました。

DdUsePrivateLink が true に設定された、Forwarder の旧デプロイメントをご使用の場合は、構成済みの PrivateLink エンドポイントと Datadog の文書に記載されたものが異なることがありますが、これは想定内です。古い PrivateLink エンドポイントは、文書から削除されていますが、依然として機能します。Forwarder をアップグレードする際は、変更の必要はなく、DdUsePrivateLink を有効にしたまま、旧エンドポイントを引き続き使用できます。

ただし、新しいエンドポイントへの切り替えをご希望の場合は、上記の新しい手順に従い、以下を実行する必要があります。

新しいエンドポイントを api.、http-intake.logs.、trace.agent. に設定します。
DdUseVPC を true に設定します。
DdUsePrivateLink を false に設定します。

AWS VPC およびプロキシのサポート

公共のインターネットに直接アクセスできない VPC に Forwarder をデプロイする必要があり、AWS PrivateLink を使用して Datadog に接続できない場合 (例えば、組織が Datadog EU サイト: datadoghq.eu にホストされている場合)、プロキシ経由でデータを送信することができます。

Forwarder がパブリックサブネットにデプロイされている場合以外は、こちらの手順に従い Secrets Manager および S3 のエンドポイントを VPC に追加し、Forwarder がこれらのサービスにアクセスできるようにします。
プロキシを以下の構成 (HAProxy または NGINX) で更新します。他のプロキシや Web プロキシを使用している場合は、Datadog のドメインを許可リストとして指定します (例: .)。
CloudFormation テンプレートで Forwarder をインストールする際は、DdUseVPC、VPCSecurityGroupIds、VPCSubnetIds を設定します。
AWS VPC はまだ Resource Group Tagging API にエンドポイントを提供しないため、DdFetchLambdaTags オプションが無効になっていることを確認してください。
HAProxy または NGINX を使用している場合

DdApiUrl を http://<proxy_host>:3834 または https://<proxy_host>:3834 に設定します。
DdTraceIntakeUrl を http://<proxy_host>:3835 または https://<proxy_host>:3835 に設定します。
DdUrl を <proxy_host> に、DdPort を 3837 に設定します。

それ以外、Web プロキシを使用している場合

DdHttpProxyURL をプロキシエンドポイントに設定します。例: http://<proxy_host>:<port> またはプロキシにユーザー名とパスワードがある場合は、http://<username>:<password>@<proxy_host>:<port>

http を使用したプロキシに接続する場合は、DdNoSsl を true に設定します。
自己署名証明書のある https を使用したプロキシに接続する場合は DdSkipSslValidation を true に設定します。

コード署名

Datadog Forwarder は Datadog によって署名されています。Forwarder の整合性を確認するには、手動インストール方法を使用します。Forwarder ZIP ファイルをアップロードする前に、Datadog の署名プロファイル ARN (arn:aws:signer:us-east-1:464622532012:/signing-profiles/DatadogLambdaSigningProfile/9vMI9ZAGLc) を含むコード署名コンフィギュレーションを作成し、それを Forwarder Lambda 関数に関連付けます。

CloudFormation パラメーター

必須

DdApiKey: Datadog API キー。Organization Settings > API Keys で確認することができます。API キーは AWS Secrets Manager に保存されます。すでに Secrets Manager に Datadog API Keyが保存されている場合は、代わりに DdApiKeySecretArn を使用します。
DdApiKeySecretArn: Datadog API キーを格納しているシークレットの ARN (すでに Secrets Manager に格納されている場合)。シークレットは、キーと値のペアではなく、プレーンテキストとして保存する必要があります。
DdSite: メトリクスやログが送信される Datadog サイト。Datadog サイトはです。

Lambda 関数 (オプション)

FunctionName: Datadog Forwarder Lambda 関数の名前。既存の CloudFormation スタックを更新するときはこれを変更しないでください。変更すると、現在の Forwarder 関数が置き換えられすべてのトリガーが失われることになります。
MemorySize: Datadog Forwarder Lambda 関数のメモリサイズ
Timeout: Datadog Forwarder Lambda 関数のタイムアウト
ReservedConcurrency: Datadog Forwarder Lambda 関数の予約済み同時実行数。空の場合、予約されていないアカウントの同時実行を使用します。 Datadog は、最低でも 10 個の予約済み同時実行を使用することをお勧めしますが、制限を増やす必要があるかもしれないので、デフォルトは 0 です。予約されていないアカウントの同時実行を使用する場合、環境内の他の Lambda 関数を制限することができます。
LogRetentionInDays: Datadog Forwarder Lambda 関数により生成されたログの CloudWatch ログ保存期間

ログ転送 (オプション)

DdTags: 転送されたログにカスタムタグを追加します。カンマ区切りの文字列で、末尾にカンマはありません。例:env:prod,stack:classic
DdMultilineLogRegexPattern: 指定された正規表現を使用して、S3 からの複数行ログの新しいログ行を検出します。たとえば、パターン “11/10/2014” で始まる複数行ログの場合は \d{2}\/\d{2}\/\d{4} です。
DdUseTcp: デフォルトでは、Forwarder はポート 443 を介して HTTPS を使用してログを送信します。SSL 暗号化 TCP 接続を介してログを送信するには、このパラメーターを true に設定します。
DdNoSsl: ログの転送時に SSL を無効にし、プロキシを介してログを転送する場合は true に設定します。
DdUrl: ログを転送するエンドポイント URL。プロキシを介してログを転送するのに役立ちます。
DdPort: ログを転送するエンドポイントポート。プロキシを介してログを転送するのに役立ちます。
DdSkipSslValidation: エンドポイントから指定された証明書を検証せずに、HTTPS 経由でログを送信します。これにより、Forwarder とログインテークエンドポイント間のトラフィックは暗号化されますが、宛先 SSL 証明書が有効かどうかは検証されません。
DdUseCompression: ログ圧縮を無効にするには、false に設定します。HTTP 経由でログを送信する場合にのみ有効です。
DdCompressionLevel: 圧縮レベルを 0 (圧縮なし) から 9 (最高の圧縮) に設定します。デフォルトの圧縮レベルは 6 です。圧縮レベルを上げると、Forwarder の実行時間が長くなる代わりに、送信ネットワークトラフィックが減少するという利点を得られる場合があります。
DdForwardLog: ログ転送を無効にするには、false に設定しますが、Lambda 関数からのメトリクスやトレースなど、他の可観測性データの転送は続行します。
DdFetchLambdaTags: Forwarder が GetResources API 呼び出しを使用して Lambda タグをフェッチし、それらをログ、メトリクス、トレースに適用できるようにします。true に設定すると、アクセス許可 tag:GetResources が Lambda 実行 IAM ロールに自動的に追加されます。
DdFetchLogGroupTags: Forwarder が ListTagsLogGroup を使用して Log Group タグをフェッチし、それらをログ、メトリクス、トレースに適用できるようにします。true に設定すると、アクセス許可 logs:ListTagsLogGroup が Lambda 実行 IAM ロールに自動的に追加されます。

ログスクラビング (オプション)

RedactIp: \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} に一致するテキストを xxx.xxx.xxx.xxx に置き換えます。
RedactEmail: [a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+ に一致するテキストを xxxxx@xxxxx.com に置き換えます。
DdScrubbingRule: 指定された正規表現に一致するテキストを xxxxx (デフォルト) または DdScrubbingRuleReplacement (指定されている場合) に置き換えます。ログスクラビング規則は、完全な JSON 形式のログに適用されます。これには、Lambda 関数によって自動的に追加されたメタデータも含まれます。各ログで、パターンマッチが見つからなくなるまですべての一致が置換されます。.* など、非効率な正規表現を使用すると、Lambda 関数の遅延につながります。

DdScrubbingRuleReplacementに一致するテキストを、指定されたテキストで置き換えます。

ログのフィルタリング (オプション)

ExcludeAtMatch: 指定された正規表現に一致するログを送信しません。ログが ExcludeAtMatch と IncludeAtMatch の両方に一致する場合、そのログは除外されます。
IncludeAtMatch: 指定された正規表現に一致するログのみを送信し、ExcludeAtMatch によって除外されません。

フィルタリング規則は、完全な JSON 形式のログに適用されます。これには、Forwarder によって自動的に追加されたメタデータも含まれます。ただし、ログパイプラインによる変換はログが Datadog に送信された後に行われるため、Forwarder でログをフィルタリングする際には使用できません。.* など、非効率な正規表現を使用すると、Forwarder の遅延につながります。

ログのフィルタリングに使用できる正規表現の例：

Lambda プラットフォームログ: "(START|END) RequestId:\s の包含 (または除外)。先行する " は、ログメッセージの開始 (JSON blob 内の ({"message": "START RequestId...."})) と一致する必要があります。Datadog では、REPORT ログを残すことを推奨しています。これは、サーバーレス関数のビューで呼び出しリストを生成するために使用されるからです。
CloudTrail エラーメッセージのみ含める: errorMessage
HTTP 4XX または 5XX のエラーコードを含むログのみを含める: \b[4|5][0-9][0-9]\b
message フィールドに特定の JSON キー/値ペアを含む CloudWatch ログのみを含める: \"awsRegion\":\"us-east-1\"
- CloudWatch のログイベントのメッセージフィールドは、文字列としてエンコードされています。例えば、{"awsRegion": "us-east-1"} は {\"awsRegion\":\"us-east-1\"} としてエンコードされます。したがって、提供するパターンには、\"awsRegion\":\"us-east-1\" のように \ エスケープ文字を含める必要があります。

ログに対してさまざまなパターンをテストするには、デバッグログをオンにします。

高度 (オプション)

SourceZipUrl: 実行内容を理解できない場合は、変更しないでください。関数のソースコードのデフォルトの場所を上書きします。
PermissionBoundaryArn: Permissions Boundary Policy の ARN。
DdUsePrivateLink (非推奨): AWS PrivateLink を介したログとメトリクスの送信を有効にするには、true に設定します。AWS PrivateLink で Datadog に接続するを参照してください。
DdHttpProxyURL: 標準の Web プロキシ環境変数 HTTP_PROXY および HTTPS_PROXY を設定します。これらは、プロキシサーバーが公開する URL エンドポイントです。これを AWS Private Link と組み合わせて使用しないでください。DdSkipSslValidation も true に設定してください。
DdNoProxy: 標準の Web プロキシ環境変数 NO_PROXY を設定します。これは、Web プロキシから除外する必要があるドメイン名のコンマ区切りのリストです。
VPCSecurityGroupIds: VPC セキュリティグループ ID のカンマ区切りリスト。AWS PrivateLink が有効な場合に使用されます。
VPCSubnetIds: VPC サブネット ID のカンマ区切りリスト。AWS PrivateLink が有効な場合に使用されます。
AdditionalTargetLambdaArns: Datadog Forwarder が受信するのと同一の event と非同期で呼び出される Lambda ARN のコンマ区切りリスト。
InstallAsLayer: レイヤーベースのインストールフローを使用するかどうか。フォワーダーコードを GitHub から S3 バケットにコピーする 2 番目の関数をインストールするレガシーインストールフローを使用するには、false に設定します。デフォルトは true です。
LayerARN: フォワーダーコードを含むレイヤーの ARN。空の場合、スクリプトはフォワーダーが公開されたレイヤーのバージョンを使用します。デフォルトは空です。

ヘルプ

CloudFormation Stack をデフォルトのオプションでデプロイするには、Datadog API キーをシークレットとして保存し、Forwarder のコード (ZIP ファイル) を格納する S3 バケットを作成し、Lambda 関数 (実行ロールとロググループを含む) を作成します。

IAM ステートメント:

{
  "Effect": "Allow",
  "Action": [
    "cloudformation:*",
    "secretsmanager:CreateSecret",
    "secretsmanager:TagResource",
    "s3:CreateBucket",
    "s3:GetObject",
    "s3:PutEncryptionConfiguration",
    "s3:PutBucketPublicAccessBlock",
    "iam:CreateRole",
    "iam:GetRole",
    "iam:PassRole",
    "iam:PutRolePolicy",
    "iam:AttachRolePolicy",
    "lambda:CreateFunction",
    "lambda:GetFunction",
    "lambda:GetFunctionConfiguration",
    "lambda:GetLayerVersion",
    "lambda:InvokeFunction",
    "lambda:PutFunctionConcurrency",
    "lambda:AddPermission",
    "lambda:TagResource",
    "logs:CreateLogGroup",
    "logs:DescribeLogGroups",
    "logs:PutRetentionPolicy"
  ],
  "Resource": "*"
}

CloudFormation スタックを作成するには、次の機能が必要です。

CAPABILITY_AUTO_EXPAND、Forwarder テンプレートが AWS SAM マクロなどのマクロを使用するためです。
CAPABILTY_IAM/NAMED_IAM、Forwarder は IAM ロールを作成するためです。

CloudFormation Stack は、次の IAM ロールを作成します。

ForwarderRole: Forwarder Lambda 関数が S3 からログを読み取り、Secrets Manager から Datadog API キーをフェッチし、独自のログを書き込むための実行ロール。

IAM ステートメント

[
  {
    "Effect": "Allow",
    "Action": [
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:PutLogEvents"
    ],
    "Resource": "*"
  },
  {
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::*",
    "Effect": "Allow"
  },
  {
    "Action": ["secretsmanager:GetSecretValue"],
    "Resource": "<ARN of DdApiKeySecret>",
    "Effect": "Allow"
  }
]

ForwarderZipCopierRole: ForwarderZipCopier Lambda 関数が S3 バケットに Forwarder デプロイの ZIP ファイルをダウンロードするための実行ロール。

IAM ステートメント:

[
  {
    "Effect": "Allow",
    "Action": [
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:PutLogEvents"
    ],
    "Resource": "*"
  },
  {
    "Action": ["s3:PutObject", "s3:DeleteObject"],
    "Resource": "<S3Bucket to Store the Forwarder Zip>",
    "Effect": "Allow"
  },
  {
    "Action": ["s3:ListBucket"],
    "Resource": "<S3Bucket to Store the Forwarder Zip>",
    "Effect": "Allow"
  }
]

その他の参考資料

お役に立つドキュメント、リンクや記事:

Datadog の Lambda 関数で AWS サービスのログを送信する