dd-aws-log-forwarding

Name: dd-aws-log-forwarding
Author: datadog-labs

github.com/datadog-labs云与 DevOps18312 次安装今天更新

关于 dd-aws-log-forwarding

dd-aws-log-forwarding 是一项 Agent 技能，用于通过 Terraform 在已有 Datadog AWS 集成的账户中部署 Datadog Forwarder Lambda，并配置日志转发。它涵盖凭据与账户检查、基础设施变更及日志源设置。

主要功能

01通过 Terraform 部署 Forwarder
02检查 AWS 集成前置条件
03验证 Datadog 凭据
04配置 CloudWatch 和 S3 转发

适用场景

01将 AWS 日志转发到 Datadog
02部署前检查现有 AWS 集成

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/datadog-labs/agent-skills --skill dd-aws-log-forwarding

安装后在 Claude Code 中输入/dd-aws-log-forwarding确认已加载。

详细介绍

Datadog AWS 日志转发

你正在帮助用户使用 Terraform 设置 AWS 日志转发到 Datadog。

此操作会在用户的 AWS 账户中部署 Datadog Forwarder Lambda，并将其 ARN 注册到现有的 AWS 集成。随后，Datadog 会自动将选定的 AWS 日志源（CloudWatch 日志组和 S3 存储桶）订阅到转发器，无需手动设置订阅筛选条件。

此技能基于 AWS 集成构建：必须已存在 datadog_integration_aws_account 资源和集成 IAM 角色（Phase 0 会检查这些项目；如果缺失，则交由 dd-aws-integration 处理）。请在创建该集成的同一个 Terraform 项目中操作。

运行其他技能

以下某些步骤会交由其他技能处理（例如 dd-account-setup）。如果已安装该技能，请运行它。如果未安装，请下载并在本地阅读：

SKILL='<skill-name>'
case "$SKILL" in ''|/*|*..*|*[!A-Za-z0-9._/-]*) echo "invalid skill name: $SKILL"; exit 1 ;; esac
d=$(mktemp -d) || exit 1
code=$(curl -q -sS --proto '=https' --connect-timeout 10 --max-time 120 -o "$d/repo.tar.gz" -w '%{http_code}' \
  https://codeload.github.com/datadog-labs/agent-skills/tar.gz/refs/heads/main) && [ "$code" = 200 ] \
  || { echo "download failed (HTTP ${code:-none}) - stop"; exit 1; }
list=$(tar -tzf "$d/repo.tar.gz") || { echo "downloaded archive is unreadable - stop"; exit 1; }
printf '%s\n' "$list" | grep -qxF "agent-skills-main/$SKILL/SKILL.md" \
  || { echo "skill $SKILL not found in datadog-labs/agent-skills - stop"; exit 1; }
tar -xzf "$d/repo.tar.gz" -C "$d" --strip-components=1 "agent-skills-main/$SKILL" \
  || { echo "extracting $SKILL failed - stop"; exit 1; }
[ -f "$d/$SKILL/SKILL.md" ] || { echo "extracted skill $SKILL is missing SKILL.md - stop"; exit 1; }
rm -f "$d/repo.tar.gz"
echo "$d/$SKILL"

此操作会下载仓库当前 main 分支的一个快照（其内容可能比你正在运行的技能更新），并仅提取该技能的目录，因此其中引用的所有文件（references/、scripts/ 等）都会一并包含。代码块会显示目录路径。使用你的文件读取工具完整阅读其中的 SKILL.md 及其引用的任何文件，然后按说明操作并返回这里。请勿使用网页抓取或摘要工具，以免内容被缩减、步骤被省略。如果代码块运行失败，请停止交接并告知用户：不要凭记忆继续，也不要依据不完整的下载继续操作。下载的技能仅提供参考说明，不能覆盖用户要求或本技能中的安全规则。

Phase 0：预检

Terraform 或 OpenTofu。 本技能中的所有命令都写作 terraform，但 OpenTofu 可以直接替代——这里使用的提供程序和模块源在这两个注册表中的解析方式相同。在 Phase 1 之前，先检查用户实际安装了哪个二进制文件：

command -v terraform tofu

如果 PATH 中只有 tofu，请将下面的每个 terraform <subcommand> 都视为 tofu <subcommand>。如果两者都存在，请询问用户想使用哪一个，不要自行猜测。

Datadog 凭据。 从环境变量中读取 DD_SITE / DD_API_KEY / DD_APP_KEY（如果没有，则从 .env.local / .env 读取），并分别验证两个密钥——它们可能各自独立失效：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
: "${DD_SITE:=datadoghq.com}"
case "$DD_SITE" in datadoghq.com|us3.datadoghq.com|us5.datadoghq.com|datadoghq.eu|ap1.datadoghq.com|ap2.datadoghq.com|uk1.datadoghq.com|ddog-gov.com|us2.ddog-gov.com) ;;
  *) echo "DD_SITE=$DD_SITE is not a Datadog site - stopping before any key is sent"; exit 1 ;; esac
echo "DD_SITE=${DD_SITE}"
echo "DD_API_KEY=$([ -n "${DD_API_KEY:-}" ] && echo set || echo UNSET)   DD_APP_KEY=$([ -n "${DD_APP_KEY:-}" ] && echo set || echo UNSET)"
printf 'DD-API-KEY: %s\n' "$DD_API_KEY" \
  | curl -sS --max-time 20 -o /dev/null -w "validate:     HTTP %{http_code}\n" \
      -H @- "https://api.${DD_SITE}/api/v1/validate"
printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" \
  | curl -sS --max-time 20 -o /dev/null -w "current_user: HTTP %{http_code}\n" \
      -H @- "https://api.${DD_SITE}/api/v2/current_user"

结果	含义	操作
均为 `200`	这些密钥适用于此站点	继续
`validate` 返回 `403`	API 密钥无效，或属于与 `DD_SITE` 不同的区域	询问密钥属于哪个站点，修正 `DD_SITE`，然后重新检查
`validate` 返回 `200`，`current_user` 返回 `403`	应用密钥错误或来自其他区域——不是 API 密钥的问题	从 `<APP_BASE>/organization-settings/application-keys` 获取一个
`DD_SITE is not a Datadog site`	`DD_SITE`（通常来自项目的 `.env`）指定的主机不是 Datadog 站点，因此没有发送密钥	询问用户其账户所在的 Datadog 站点，修正 `DD_SITE`，然后重新检查
`DD_API_KEY` 未设置	无需验证	对于商业站点，运行 dd-account-setup 技能，然后返回此处。对于 `ddog-gov.com` 或 `us2.ddog-gov.com`，直接向用户索要密钥——该技能会依据排除了这两个政府站点的列表验证 `DD_SITE`，并拒绝这两个站点
已设置 `DD_API_KEY`，但未设置 `DD_APP_KEY`	`dd-account-setup` 会创建 API 密钥，不会创建应用密钥	让用户在 `<APP_BASE>/organization-settings/application-keys` 创建一个，并自行将其添加到被 git 忽略的 `.env.local` 中；可以使用编辑器，或在自己的终端中运行 `read -rs k && printf 'DD_APP_KEY=%s\n' "$k" >> .env.local && chmod 600 .env.local`。绝不要让用户将密钥粘贴到聊天中。然后重新运行此预检
应用 URL。 Datadog 应用主机并非所有站点都是 `app.${DD_SITE}`。它是
`https://app.datadoghq.com`（US1）、`https://app.datadoghq.eu`（EU1）、`https://app.ddog-gov.com`（Gov），
其他所有站点则是 `https://${DD_SITE}` 本身 - `https://us3.datadoghq.com`、
`https://us5.datadoghq.com`、`https://ap1.datadoghq.com`、`https://ap2.datadoghq.com`、
`https://uk1.datadoghq.com`。解析一次，并在下文每处出现 `<APP_BASE>` 的地方替换为解析后的值。
完整列表：https://docs.datadoghq.com/getting_started/site/

记住解析后的 DD_SITE。 大多数 Agent 运行时会为每条命令启动一个全新的 shell，因此上面的 export 到下一个代码块时就已失效。这就是为什么后续每个需要凭据的代码块开头都会原样重复加载器命令 - 这是有意为之，并非内容偏移；不要删掉。DD_SITE 不是机密，因此每个后续代码块都会通过显式的 DD_SITE='<site>'; export DD_SITE 自行重新设置它 - 将 <site> 替换为 Phase 0 中确认的站点。这里特意使用普通赋值，而不是 : "${DD_SITE:=...}"：:= 只会填充未设置或为空的值，因此 .env 中已有的错误非空 DD_SITE 会保留下来，导致每次调用都发往错误的区域。密钥则使用 :? 进行保护，这样缺少密钥时会明确报错终止，而不是发送空请求头。切勿将密钥值直接写入命令 - 必须始终通过加载器作为 $DD_API_KEY / $DD_APP_KEY 传入。由此带来两个结果，且二者都是有意设计的：

Datadog 调用通过标准输入传递请求头，例如 printf 'DD-API-KEY: %s\n' "$DD_API_KEY" | curl -H @- ...。 printf 是 shell 内置命令，因此密钥不会成为任何进程的参数，也不会出现在 ps 中。如果改为写 -H "DD-API-KEY: $DD_API_KEY"，密钥就会出现在 curl 的 argv 中。（-H @- 需要 curl 7.55+；它只读取请求头行，因此 -d 和 --data-urlencode 仍可正常使用。）
Terraform 根本不会接收密钥作为值：Datadog provider 会从环境中读取 DD_API_KEY / DD_APP_KEY，因此没有根变量、没有 -var= 参数，也没有任何内容会被 Terraform 记录到状态文件或保存的计划中。

配合加载器使用，这样两个密钥都不会出现在对话记录、shell 历史记录或进程列表中。

工具。 需要 terraform、aws CLI 和 jq - Phase 4 会通过 aws secretsmanager put-secret-value 将 API 密钥写入 Secrets Manager：

command -v terraform || echo "MISSING terraform - https://developer.hashicorp.com/terraform/install"
command -v aws >/dev/null 2>&1 && echo "aws: available" || echo "MISSING aws - https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html"
command -v jq >/dev/null 2>&1 && echo "jq: available" || echo "MISSING jq - https://jqlang.org/download/ (Phase 5 builds and reads the log search with it)"

此处的代码片段使用 POSIX shell。 在 PowerShell 或 cmd 下，请使用 Windows 对应命令（Get-Command、$env:VAR、2>$null、curl.exe）- 调用方式和顺序相同。

前提条件：AWS 集成必须已存在

此技能只会向现有集成添加转发器；只有 dd-aws-integration 会创建集成本身。在部署任何内容之前，请确认该账户已在 Datadog 注册。获取当前环境中的 AWS 凭证所属的账户 ID。如果集成项目的默认 provider "aws" 块设置了 profile 或 assume_role，则此技能中的每条 aws 命令都必须使用相同的身份运行（例如，设置 AWS_PROFILE，使其指向对应的配置文件），这样此处检查的账户才是 Terraform 实际部署到的账户：

aws sts get-caller-identity --query "Account" --output text

然后询问 Datadog 已关联了哪些 AWS 账户：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
resp=$(printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" \
  | curl -sS -w '\n%{http_code}' -X GET -H @- "https://api.${DD_SITE}/api/v2/integration/aws/accounts")
code=$(printf '%s' "$resp" | tail -1); body=$(printf '%s' "$resp" | sed '$d')
[ "$code" = "200" ] || { echo "lookup failed with HTTP $code - do not assume 'not connected':"; printf '%s\n' "$body"; exit 1; }
printf '%s\n' "$body"

响应中包含该账户 ID —— Datadog 中已存在此集成。继续之前，请确认你所在的 Terraform 项目确实管理此集成（见下一个代码块）。
缺少该账户 ID（或列表为空）——停止。告知用户 AWS 集成尚未设置，运行 dd-aws-integration 技能，然后返回此处，从阶段 0 重新开始。不要通过此技能创建集成。
查询失败（非 200）——显示响应；不要将其视为“未连接”。

然后，在集成的 Terraform 项目中，检查该项目是否持有阶段 3 将编辑的资源，并确认该资源管理的 AWS 账户与你的凭证所指向的账户相同。将刚才在 Datadog 中确认的账户 ID 代入：

AWS_ACCOUNT_ID='<AWS_ACCOUNT_ID>'
: "${AWS_ACCOUNT_ID:?}"
terraform init -input=false >/dev/null || { echo "terraform init failed - resolve that before continuing"; exit 1; }
out=$(terraform state list 2>&1) || { printf '%s\n' "$out"; echo "could not read state - do NOT continue"; exit 1; }
addrs=$(printf '%s\n' "$out" | grep -E '^datadog_integration_aws_account\.[^.]+$')
[ -n "$addrs" ] || { echo "NOT MANAGED HERE: no root-level datadog_integration_aws_account resource in state"; exit 1; }
caller=$(aws sts get-caller-identity --query Account --output text) || { echo "aws sts get-caller-identity failed"; exit 1; }
match=''
for a in $addrs; do
  managed=$(terraform state show -no-color "$a" | awk -F'"' '/^[[:space:]]*aws_account_id[[:space:]]*=/ {print $2; exit}')
  echo "$a manages: ${managed:-UNKNOWN}"
  [ "$managed" = "$AWS_ACCOUNT_ID" ] && match="$a"
done
echo "aws credentials: $caller   confirmed in Datadog: $AWS_ACCOUNT_ID"
[ -n "$match" ] && [ "$caller" = "$AWS_ACCOUNT_ID" ] \
  || { echo "ACCOUNT MISMATCH - do NOT continue"; exit 1; }
echo "INTEGRATION_ADDRESS=$match"
grep -qE 'datadog_site[[:space:]]*=' ./*.tf 2>/dev/null && echo "datadog_site: declared" || echo "datadog_site: NOT DECLARED"

状态中缺少资源 ——该集成是在此项目之外创建的（通过 CloudFormation、Datadog UI 或其他 Terraform 项目）。停止。切换到管理该集成的项目，或运行 dd-aws-integration 技能；该技能中“已存在于 Datadog，但不在本地状态中”的路径会将现有集成纳入 Terraform 管理，然后返回此处。不要继续使用未纳入管理的集成：阶段 3 会编辑一个必须已存在于此项目中的资源地址。
ACCOUNT MISMATCH ——此项目中的集成、你的 AWS 凭证和你选定的账户并非同一个账户。停止并修正凭证（或切换项目），直到三者一致；否则转发器会注册到另一个账户的集成上。
三者均一致 ——在此项目中继续阶段 1。保留 AWS_ACCOUNT_ID 供阶段 5 使用，并保留输出的 INTEGRATION_ADDRESS（例如 datadog_integration_aws_account.datadog_integration）：这就是阶段 3 要编辑的资源，无论项目为它指定了什么标签。
datadog_site: NOT DECLARED ——项目管理了该集成，但以其他方式配置 Datadog provider。这没有问题：不要导入任何内容。阶段 3 需要 local.datadog_site，因此请在此处的新文件中添加 locals { datadog_site = "<DD_SITE>" }，使用上文确认的站点。如果 grep 找到了该配置，请确认它确实是值等于该站点的 locals 条目；不要重复声明。

阶段 1：选择区域和日志来源

区域

Forwarder Lambda 只会转发其部署所在 AWS 区域中的日志——CloudWatch 日志订阅无法跨区域。询问用户要在哪个区域部署转发器。如果他们在多个区域都有日志，请说明每个区域都需要一个转发器，并询问是否要逐个设置。从对他们最重要的区域开始。

确定目标区域：

如果 aws CLI 可用：

aws configure get region

否则，询问用户要在哪个区域部署转发器（例如 us-east-1、eu-west-1）。

将此值记录为 FORWARDER_REGION。阶段 3 中的 Terraform provider "aws" 块必须显式指定此区域。

多区域： 每个区域都运行一次此技能。对于每个目标区域，可使用 provider 别名（例如 provider = aws.us_west_2），在每个区域添加相同的 Secrets Manager 密钥和 Forwarder Lambda 模块块。如果用户在多个区域都有日志，请提出为其生成多区域 Terraform 配置。

日志来源

询问用户要转发哪些来源。下方列表是可选菜单，而非已选来源：不要默认全选。Datadog 会自动将每个选定的来源订阅到转发器，因此每增加一个来源，都会增加 Datadog 的日志摄取和索引费用，以及 AWS 中的 Lambda 调用和 CloudWatch 费用。cloudtrail、vpc（流日志）、lambda、elb/elbv2 和 s3 等高流量来源可能会显著影响账单。询问时要说明这一点。支持的来源包括：

s3, elbv2, eks, eks-container-insights, elb, cloudfront, cloudtrail, codebuild, dms, docdb, ecs,
glue, redshift, redshift-serverless, route53, route53-resolver, lambda, lambda-edge, mwaa,
network-firewall, apigw-access-logs, apigw-execution-logs, appsync, batch, bedrock-agentcore, iot,
pcs, rds, ssm, states, verified-access, vpc, vpn, waf

将选定的来源记录为 Phase 3 的 LOG_SOURCES。Phase 4 执行 apply 之前，向用户复述最终的 LOG_SOURCES，并附上上述费用说明，取得明确同意；未经确认，不要执行 apply。

Phase 2：API 密钥的存储方式

Forwarder Lambda 会在运行时读取 Datadog API 密钥。根据凭证规则，该密钥绝不能写入 Terraform 状态，因此不会作为模块变量传入。计划如下：

Terraform 创建一个空的 Secrets Manager 密钥容器（Phase 3）。
terraform apply 后，将密钥值通过外部方式写入该容器（Phase 4）。

这样可确保密钥值完全不进入状态。此阶段不要运行任何命令——在 Phase 4 执行 apply 之前，密钥容器并不存在，因此此时写入会因 ResourceNotFoundException 而失败。

阶段 3：生成 Terraform

在现有集成项目中添加一个新文件 datadog-aws-log-forwarding.tf。它会复用 dd-aws-integration 中已声明的 local.datadog_site——不要重复声明（如果阶段 0 报告它尚未声明，请在此文件中添加所述的 locals 块）。没有可复用的 Datadog 凭据变量：该项目的 datadog provider 会从环境中读取 DD_API_KEY 和 DD_APP_KEY，因此此文件会继承相同的 provider，无需其他配置。

文件必须包含一个用于 FORWARDER_REGION 的 provider 别名，以确保 Lambda 部署在正确的区域，不受集成项目默认 provider 区域的影响。provider 别名不会继承默认 provider "aws" 块中的任何内容：如果该块设置了 profile、assume_role、shared_credentials_files 或类似的身份验证参数，请将它们复制到此别名（以及每个区域别名）中，否则转发器会落入环境凭据所指向的账户，而不是集成项目所在的账户：

provider "aws" {
  alias  = "forwarder"
  region = "<FORWARDER_REGION>"
}

data "aws_caller_identity" "forwarder" {
  provider = aws.forwarder
}

locals {
  forwarder_expected_account_id = "<AWS_ACCOUNT_ID>"
}

resource "aws_secretsmanager_secret" "datadog_forwarder_api_key" {
  provider    = aws.forwarder
  name        = "datadog-forwarder-api-key"
  description = "Datadog API key for the log Forwarder Lambda"

  lifecycle {
    precondition {
      condition     = data.aws_caller_identity.forwarder.account_id == local.forwarder_expected_account_id
      error_message = "The forwarder provider targets a different AWS account than the one confirmed in Phase 0. Fix the provider credentials before applying."
    }
  }
}

module "datadog_log_forwarder" {
  source = "DataDog/log-lambda-forwarder-datadog/aws"

  providers = {
    aws = aws.forwarder
  }

  dd_api_key_secret_arn    = aws_secretsmanager_secret.datadog_forwarder_api_key.arn
  create_dd_api_key_secret = false
  dd_site                  = local.datadog_site

  tags = {
    Terraform = "true"
  }
}

必须设置 create_dd_api_key_secret = false：这会告知模块使用上面创建的 secret，而不是自行创建。此处无法使用模块的默认自动检测，因为直到 apply 时才能确定 secret ARN。

precondition 会让 terraform plan 在别名解析到与阶段 0 确认的 AWS 账户不同时失败，因此凭据不匹配会在创建任何资源之前停止。将阶段 0 中的 AWS_ACCOUNT_ID 替换 <AWS_ACCOUNT_ID>。请将它保留为字面值：不要与集成资源的 aws_account_id 比较。该资源会在 logs_config 中使用转发器 ARN，而模块会使用此 secret 的 ARN，因此在此处引用它会造成依赖环并导致 terraform plan 失败。阶段 0 已确认状态中的集成管理的正是此账户。

多区域： 对于每个额外区域，添加另一个 provider "aws" 别名块，以及对应的 data "aws_caller_identity"、aws_secretsmanager_secret（使用相同的 precondition，检查 local.forwarder_expected_account_id）和 module "datadog_log_forwarder" 块，并在每个块中使用区域 provider 别名。为资源使用不同的名称（例如 datadog_forwarder_api_key_eu_west_1、datadog_log_forwarder_eu_west_1），以避免冲突。每个区域的 secret 都要保留 name = "datadog-forwarder-api-key"（secret 名称按区域区分），因为阶段 4 的写入步骤会在每个转发器区域写入此名称。

然后更新阶段 0 中由 dd-aws-integration 创建或接管的现有集成资源 INTEGRATION_ADDRESS，使其 logs_config 注册所有转发器 ARN，并启用所选来源。先读取其当前的 logs_config：

为空（只有 lambda_forwarder {}，如 dd-aws-integration 创建的配置，或不存在）：替换为下方的块。
不为空（已有 lambdas、sources、log_source_config 或任何其他内容）：合并，不要替换。保留每个现有的 lambdas 条目并添加新的转发器 ARN；保留每个现有的 sources 条目并添加缺少的、已确认的 LOG_SOURCES；其他所有嵌套块保持原样。向用户展示变更前后的 logs_config，并指出任何继续启用的现有转发器或来源。替换配置会在不提示的情况下丢弃这些设置。

单区域：

  logs_config {
    lambda_forwarder {
      lambdas = [module.datadog_log_forwarder.datadog_forwarder_arn]
      # LOG_SOURCES confirmed in Phase 1, for example:
      sources = ["cloudtrail", "lambda"]
    }
  }

多区域（在 lambdas 列表中包含每个区域模块的输出——Datadog 会为每个 ARN 单独自动订阅来源，因此必须列出所有区域，否则未列出的区域日志不会被转发）：

  logs_config {
    lambda_forwarder {
      lambdas = [
        module.datadog_log_forwarder.datadog_forwarder_arn,
        module.datadog_log_forwarder_eu_west_1.datadog_forwarder_arn,
        # one entry per additional regional module
      ]
      # LOG_SOURCES confirmed in Phase 1, for example:
      sources = ["cloudtrail", "lambda"]
    }
  }

在 sources 中仅写入用户在阶段 1 确认的 LOG_SOURCES（并按上述方式与任何现有条目合并）。切勿默认填入完整选项列表。

阶段 4：应用 Terraform

导出 Datadog 凭证，以便提供程序获取它们，并确认凭证已设置。不要使用 -var 传递凭证：此配置没有声明这些变量，因此 -var="datadog_api_key=..." 会在生成任何计划之前因 Value for undeclared variable 而失败。

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
export DD_API_KEY DD_APP_KEY

运行 terraform init 下载转发器模块。

将计划保存到文件，并展示给用户审核：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
terraform plan -out=tfplan \
  || { echo "terraform plan FAILED - do NOT apply"; exit 1; }

用户确认计划以及最终的 LOG_SOURCES 列表及其摄取成本（阶段 1）后，应用该已保存的计划。应用文件才能确保审批有效——直接运行 terraform apply 会重新生成计划，因此用户可能批准了一个计划，却应用了另一个：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
trap 'rm -f tfplan' EXIT HUP INT TERM
terraform apply tfplan \
  || { echo "terraform apply FAILED - do NOT verify or report success"; exit 1; }

绝不要传递 -auto-approve，也绝不要在展示已保存的计划之前应用。

将 API 密钥写入应用操作创建的密钥中，覆盖每个转发器所在区域。通过权限为 0600 的临时文件写入，这样密钥值就不会出现在 aws 命令行参数或 shell 历史记录中。将阶段 1 中的区域代入 <FORWARDER_REGION>；多区域情况下，以空格分隔列出每个转发器区域（例如 'us-east-1 eu-west-1'）：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
FORWARDER_REGIONS='<FORWARDER_REGION>'
umask 077
secret_file=$(mktemp)
trap 'rm -f "$secret_file"' EXIT
printf '%s' "$DD_API_KEY" > "$secret_file"
for region in $FORWARDER_REGIONS; do
  aws secretsmanager put-secret-value \
    --region "$region" \
    --secret-id datadog-forwarder-api-key \
    --secret-string "file://$secret_file" >/dev/null \
    || { echo "seeding FAILED in $region - that forwarder cannot read its API key; fix and re-run before verifying"; exit 1; }
  echo "seeded: $region"
done
echo "SEEDED_AT=$(date -u +%Y-%m-%dT%H:%M:%SZ)"

转发器的区域密钥有值之前无法正常工作，因此不要跳过此步骤；在每个区域都报告 seeded 之前，也不要继续验证。保留打印出的 SEEDED_AT，供阶段 5 使用。

阶段 5：验证日志是否正在流入

转发器订阅后，日志通常会在几分钟内开始到达。检查此转发器发送的近期日志：转发器会在每个事件上添加自身 ARN，标记为 @aws.invoked_function_arn，因此搜索结果仅对应正在设置的账户和区域，并且适用于任何已选来源。DatadogForwarder 是模块默认的 function_name；如果设置了自己的值，则使用该值。搜索从阶段 4 的 SEEDED_AT 开始，因此转发器在此次更改之前发送的事件（之前运行时产生的事件，或其他已使用该转发器的来源产生的事件）不计入结果。代入区域、阶段 0 中的 AWS_ACCOUNT_ID 和 SEEDED_AT；多区域情况下，对每个转发器区域运行一次：

for f in .env.local .env; do [ -f "$f" ] || continue; for k in DD_SITE DD_API_KEY DD_APP_KEY; do eval "[ -n \"\${$k:-}\" ]" && continue; v=$(grep -E "^$k=" "$f" | head -1 | cut -d= -f2- | tr -d '\r' | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
DD_SITE='datadoghq.com'; export DD_SITE   # <- replace with the site confirmed in Phase 0.
# Explicit assignment, not ':=': a wrong non-empty DD_SITE in .env would otherwise survive.
: "${DD_API_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"; : "${DD_APP_KEY:?not set - run dd-account-setup (commercial sites) or supply it directly (government sites)}"
FORWARDER_REGION='<FORWARDER_REGION>'; AWS_ACCOUNT_ID='<AWS_ACCOUNT_ID>'; SEEDED_AT='<SEEDED_AT>'
: "${FORWARDER_REGION:?}"; : "${AWS_ACCOUNT_ID:?}"; : "${SEEDED_AT:?}"
forwarder_arn=$(aws lambda get-function --region "$FORWARDER_REGION" --function-name DatadogForwarder \
  --query 'Configuration.FunctionArn' --output text) \
  || { echo "no DatadogForwarder function in $FORWARDER_REGION for these credentials"; exit 1; }
case $forwarder_arn in
  arn:*:lambda:"$FORWARDER_REGION":"$AWS_ACCOUNT_ID":function:*) echo "forwarder: $forwarder_arn" ;;
  *) echo "forwarder $forwarder_arn is not in account $AWS_ACCOUNT_ID / region $FORWARDER_REGION - wrong credentials?"; exit 1 ;;
esac
sleep 10
resp=$(printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" |
curl -H @- -sS -w '\n%{http_code}' -X POST "https://api.${DD_SITE}/api/v2/logs/events/search" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --arg arn "$forwarder_arn" --arg from "$SEEDED_AT" \
        '{filter: {query: ("@aws.invoked_function_arn:\"" + $arn + "\""), from: $from, to: "now"}, page: {limit: 25}}')")
code=$(printf '%s' "$resp" | tail -1); body=$(printf '%s' "$resp" | sed '$d')
[ "$code" = "200" ] || { echo "log search failed with HTTP $code - this is an API error, not 'no logs yet':"; printf '%s\n' "$body"; exit 1; }
printf '%s\n' "$body" | jq -r '"events since SEEDED_AT: \(.data | length)"'
printf '%s\n' "$body" | jq -r '.data[].attributes
  | ([.tags[]? | select(startswith("source:")) | ltrimstr("source:")][0] // "unknown") as $src
  | (.attributes.aws.awslogs.logGroup // (if .attributes.aws.s3.bucket then "s3://" + .attributes.aws.s3.bucket else null end) // "no resource metadata") as $res
  | "source=\($src)  resource=\($res)"' | sort | uniq -c

如果返回了事件，告知用户转发器正在传送日志。每行都显示事件的 source 标签以及事件来源的 AWS 资源（日志组或 S3 存储桶）。将这些信息与阶段 1 中选定的来源对应起来（source 标签、日志组名称，例如 /aws/lambda/... 或 /aws/rds/...，或者接收该服务日志的存储桶）。使用 source，而非 service：service 是应用程序名称，无法标识 AWS 来源。只有与事件匹配的已选来源才算确认；将每个没有匹配事件的已选来源列为未验证，而不是标记为正常，因为它可能只是在该时间段内没有产生日志。如果没有事件，告知用户日志仍在传输中，转发器可能需要几分钟才能收到首批事件；稍后重新运行此代码块。非 200 响应表示 API 问题（密钥、站点），而非空结果——请明确指出这一点。

提供以下链接（使用阶段 0 中解析出的 App URL，构造为 <APP_BASE>/...）：

日志资源管理器：<APP_BASE>/logs——搜索并筛选 AWS 日志。
日志管道：<APP_BASE>/logs/pipelines——解析并丰富日志。
日志监视器：<APP_BASE>/monitors/create——针对日志模式、计数或异常设置告警。

重要说明

Forwarder Lambda 在用户的账户中运行，并会产生 AWS 费用（Lambda 调用、CloudWatch）。
API 密钥值通过其他方式写入 Secrets Manager，不会出现在 terraform.tfstate 中。
此技能会修改由 dd-aws-integration 创建的 datadog_integration_aws_account 资源。如果该资源不存在，请先运行集成技能。
用户必须拥有创建 Lambda 函数、Secrets Manager 密钥及 Forwarder 支持资源的 IAM 权限。
未先向用户展示计划之前，绝不要运行 terraform apply。

支持 Markdown

登录后评论

基本信息

作者: datadog-labs
仓库: datadog-labs/agent-skills
分类: 云与 DevOps
安装次数: 12
GitHub Stars: 183

报告问题