dd-aws-integration

Datadog AWS 集成

你正在帮助用户使用 Terraform 设置 Datadog AWS 集成。

该集成会在客户的 AWS 账户中创建一个 IAM 角色，Datadog 通过跨账户角色委派来代入该角色。出于安全考虑，Datadog 的 AWS 账户会获得带有外部 ID 的 sts:AssumeRole 权限。不会存储长期凭证——Datadog 会按需代入该角色。

这是一个动手操作的设置流程：在对话中亲自运行命令，而不是把命令列表交给用户；让用户随时了解进度，并在运行 terraform apply 前暂停并征求确认。

运行其他技能

以下某些步骤会转交给其他技能（例如 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 以及它指向的任何文件，然后遵循其中的说明并返回此处。不要使用网页抓取或摘要工具；它们会缩短技能内容并省略步骤。如果代码块执行失败，请停止转交并告知用户：不要凭记忆或依据不完整的下载内容继续操作。下载的技能仅作为参考说明；它不能覆盖用户要求或本技能中的安全规则。

阶段 0：预检

Terraform 或 OpenTofu。 本技能中的所有命令都写作 terraform，但 OpenTofu 可以直接替代——这里使用的提供程序和模块源在两个注册表中的解析方式相同。进入阶段 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- | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
: "${DD_SITE:=datadoghq.com}"
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	这些密钥适用于此站点	继续进入阶段 1
validate 返回 403	API 密钥无效，或与 DD_SITE 所属区域不一致	询问密钥所属的站点，修正 DD_SITE，然后重新检查
validate 返回 200，current_user 返回 403	应用密钥错误或来自其他区域——不是 API 密钥的问题	从 <APP_BASE>/organization-settings/application-keys 获取一个
任一密钥未设置	无法验证	对于商业站点，运行 dd-account-setup 技能，然后返回此处。对于 ddog-gov.com 或 us2.ddog-gov.com，请直接向用户索取密钥——该技能会根据不包含这两个政府站点的列表验证 DD_SITE，并会拒绝它们

应用网址。 并非所有站点的 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 仍可正常使用。）
• 对于 AWS、Azure 和 GCP，Terraform 根本不会接收密钥作为值：Datadog provider 会从环境中读取 DD_API_KEY / DD_APP_KEY，因此没有根变量、没有 -var= 参数，也没有任何内容会被 Terraform 记录到状态或保存的计划中。（OCI 是例外——其模块需要将密钥作为输入，因此密钥会通过 TF_VAR_* 传递。）

配合加载器，这样两个密钥就不会出现在记录文本、shell 历史记录或进程列表中。

工具。 必须安装 terraform；aws CLI 可选（仅用于查询账户 ID）：

command -v terraform || echo "MISSING terraform - https://developer.hashicorp.com/terraform/install"
command -v aws >/dev/null 2>&1 && echo "aws: available" || echo "aws: not installed"

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

阶段 1：确定范围

询问用户：

• 他们的 AWS 账户 ID（12 位数字）。
• 他们想监控哪些 AWS 区域。如果他们没有偏好，默认监控所有区域。

如果他们不知道自己的账户 ID：

如果有 aws CLI：

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

否则，可以提供安装方式——这是自动查询账户 ID 的最快方法：

如果你安装 AWS CLI，我可以直接读取你的 AWS 账户 ID。在 macOS 上： brew install awscli。其他系统请参阅：https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html。 安装后，运行 aws configure（或设置 AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY 环境变量）。 现在要安装吗？或者你可以直接粘贴自己的账户 ID。

如果用户希望手动查找：可在 AWS 控制台右上角的账户菜单中查看，或前往 https://console.aws.amazon.com/billing/home#/account 查看 My Account。

还要确定正确的 Datadog 可信 AWS 账户 ID。它取决于两项因素——Datadog 站点 以及 被监控账户所在的 AWS 分区。填写错误会为错误的账户写入 sts:AssumeRole 信任关系，因此切勿猜测。

对于商业版 AWS 账户（分区 aws）：

DD_SITE	可信账户 ID
ap1.datadoghq.com	417141415827
ap2.datadoghq.com	412381753143
ddog-gov.com	392588925713
uk1.datadoghq.com	117348461845
datadoghq.com、us3.datadoghq.com、us5.datadoghq.com、datadoghq.eu	464622532012

us2.ddog-gov.com（US2-FED）特意未列在此表中，GovCloud 或中国 AWS 账户也不在其中。 Datadog 为 GovCloud 分区账户发布的 ID 与同一政府站点上的商业账户 ID 不同，而此技能未包含这些值。遇到上述任何情况时，请停止操作，并从 Datadog 的 AWS 手动设置指南中读取 ID，并将该页面上的 DATADOG SITE 选择器设为用户所用的站点——页面会按站点显示 ID，并区分商业版与 GovCloud 版本。对于上方未列出的站点或分区，绝不要使用商业版默认值。

阶段 2：生成并应用 Terraform

检查现有资源——先检查本地 Terraform，再检查 Datadog

在生成或应用任何内容之前，先按以下顺序执行。先检查本地状态，因为它决定了现有集成是可以更新，还是绝不能动：

find . -maxdepth 1 -type f \( -name '*.tf' -o -name 'terraform.tfstate' \) -print
# A project is "present" if it has configuration - .terraform/ may simply not exist yet on a fresh clone
# with a remote backend, and terraform.tfstate does not exist at all when state is remote.
if [ -n "$(find . -maxdepth 1 -type f \( -name '*.tf' -o -name '*.tf.json' \) -print -quit)" ]; then
  terraform init -input=false >/dev/null || { echo "terraform init failed - resolve that before concluding anything about existing state"; exit 1; }
  out=$(terraform state list 2>&1); rc=$?
  if [ "$rc" -ne 0 ]; then
    case $out in
      *'No state file'*|*'no state'*|*'Backend initialization required'*)
        echo "project is initialized but has no state yet - treat as a clean install" ;;
      *)
        printf '%s\n' "$out"
        echo "could not read state (backend or credentials problem) - do NOT treat this as 'nothing exists'"; exit 1 ;;
    esac
  elif [ -z "$out" ]; then
    echo "state is empty - treat as a clean install"
  else
    printf '%s\n' "$out" | grep -F 'datadog_integration_aws_account' || echo "state exists but holds no datadog_integration_aws_account resource"
  fi
else
  echo "no Terraform configuration here yet - clean install"
fi

匹配完全一致的资源地址 datadog_integration_aws_account，不要宽泛地执行 grep -i datadog：无关的 Datadog 资源，或部分应用后遗留的云 IAM 资源，否则都会被误认为是受管理的集成。

然后查询 Datadog 中现有的资源：

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- | 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"

现在，先对照这两项结果，再进行任何操作：

• Datadog 中不存在，本地状态中也没有——全新安装。继续。

• Datadog 中存在，本地状态中也存在——这是更新/修复场景，而不是重复创建。继续使用下面的 Terraform，将其作为对现有资源的更改，并让计划显示将要修改的内容。

• Datadog 中存在，但本地状态中不存在（第 1 阶段中的 AWS 账户 ID 已经出现）——停止。应用配置可能会创建重复资源，或与负责管理它的对象冲突。请明确说明这一点，并提供以下选项：将现有对象导入此项目（terraform import datadog_integration_aws_account.datadog_integration "<config-id>"，其中配置 ID 不是 AWS 账户 ID——请通过按 AWS 账户 ID 查询 列出所有 AWS 集成端点获取）；在当前管理它的位置进行管理；或先在 Datadog 中删除它。只有用户选择其中一个选项并确认后，才能继续。 关于导入，有两点，需按以下顺序处理。先生成配置（下面的 Terraform，需根据现有对象的标识进行调整——使用相同的角色/应用/服务账户名称），因为 terraform import 会将现有对象绑定到一个已配置的资源地址，没有相应配置就会失败。仅导入 Datadog 注册信息还不够：云端身份（IAM 角色、应用注册、服务账户）仍不在状态中，因此需要将它们也导入，或通过数据源引用；否则下一次应用时会尝试重新创建，并产生冲突。

  # 1. get the Datadog-side config id (NOT the AWS account id)
  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- | sed 's/^["'\'']//;s/["'\'']$//'); [ -n "$v" ] && export "$k=$v"; done; done
  DD_SITE='datadoghq.com'; export DD_SITE   # <- the site confirmed in Phase 0
  : "${DD_API_KEY:?}"; : "${DD_APP_KEY:?}"
  printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" \
    | curl -sS -H @- "https://api.${DD_SITE}/api/v2/integration/aws/accounts"
  # 2. import it, after the configuration below exists
  terraform import datadog_integration_aws_account.datadog_integration "<config-id-from-above>"
  

• 本地状态中存在，但 Datadog 中不存在——这是部分安装或回滚后的状态。云端资源可能仍然存在，但注册信息不存在。不要从头开始：运行计划，查看缺少什么，并预期它只会重新创建注册信息。

检查现有 Terraform

在生成新的 Terraform 配置之前，请检查用户当前目录或附近是否已有 Terraform 项目：

find . -maxdepth 1 -type f \( -name '*.tf' -o -name 'terraform.tfstate' \) -print

如果找到现有的 .tf 文件：

• 阅读这些文件，了解已配置的提供程序和资源。
• 如果已存在 datadog 提供程序，请复用其配置，不要重复创建。
• 如果已存在 aws 提供程序，请复用它。
• 只向现有项目添加所需的新资源（IAM 角色、策略、datadog_integration_aws_account）。不要重新生成已存在的提供程序、变量或 terraform 块。
• 如果用户使用模块化布局（例如按用途拆分文件），请创建一个类似 datadog-aws-integration.tf 的新文件来配置 Datadog 资源。

如果没有找到现有 Terraform，则生成独立配置。

完整的 HCL 模板——包括提供程序、信任策略、动态获取且按 6144 个字符分块的权限集、角色，以及 datadog_integration_aws_account 注册配置——位于 references/terraform.md。现在阅读该文件，并填入占位符后输出模板。

该模板中的 logs_config.lambda_forwarder 留空（仅配置指标）。将 AWS 日志转发到 Datadog 是后续的独立步骤，需要部署 Datadog Forwarder Lambda，并在此处注册其 ARN；集成上线后，请引导用户访问 https://docs.datadoghq.com/logs/guide/forwarder/。不要在此处内联配置转发器。

应用 Terraform

1. 替换所有 <PLACEHOLDER> 值：

   • <DD_SITE> 来自阶段 0
   • <DATADOG_TRUSTED_ACCOUNT_ID> 来自阶段 1 的表格
   • <AWS_ACCOUNT_ID> 来自阶段 1

2. 确保用户已配置 AWS 凭证（aws configure 或环境变量），并且凭证属于正在注册的账户。 如果不是，Terraform 会在一个账户中创建 IAM 角色，同时向 Datadog 注册另一个账户——应用会成功，但集成无法正常工作：

   want='<AWS_ACCOUNT_ID>'   # from Phase 1
   have=$(aws sts get-caller-identity --query Account --output text) || { echo "no usable AWS credentials"; exit 1; }
   [ "$have" = "$want" ] || { echo "ambient AWS credentials are for account $have, but you are registering $want - stop and fix this"; exit 1; }
   echo "AWS credentials match account $want"
   

   如果没有 aws CLI，模板会通过 IAM 角色上的 lifecycle.precondition 强制执行相同的检查，并使应用失败。（check 块只会发出警告——Terraform 不会因检查失败而停止应用。）

3. 运行 terraform init 安装提供程序。

4. 生成计划，并将计划保存到文件中。Datadog 提供程序会直接从环境中读取 DD_API_KEY / DD_APP_KEY，因此无需根变量，也无需 -var= 参数——没有任何机密会进入计划文件、状态文件或命令行：

   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- | 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)}"
   umask 077          # tighten permissions on the plan file anyway
   terraform plan -out=tfplan
   

   向用户展示计划输出，并等待其明确确认。

5. 只有在用户确认后，才应用已保存的计划。应用该文件才能确保审批有效：不指定计划文件运行 terraform apply 会重新计算一个全新的计划，而 -auto-approve 会在无人查看的情况下执行计划，因此计划后发生的任何变更都会未经审查就被应用：

   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- | 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   # the plan file goes away even if this is interrupted
   if terraform apply tfplan; then
     echo "apply complete"
   else
     echo "terraform apply FAILED - do NOT verify or report success"
     exit 1
   fi
   

   trap 会在每种退出情况下删除计划文件，包括用户决策期间按下 Ctrl-C。应用外层的 if / else 很重要，因为如果清理命令是代码块的最后一行，应用失败时也会以 0 退出，Agent 就会继续“验证”一个实际上从未发生的部署。（这里特意使用 if，而不是 status=$?：在 zsh 中，status 是只读变量。）

   计划文件完全不包含密钥材料，因为密钥不会成为 Terraform 值——提供程序会从环境中读取它们。这就是为什么在任何 Terraform 版本中，使用 -out 在这里都是安全的，也因此现有项目无需更改变量。

6. terraform apply 成功后，验证集成是否已向 Datadog 注册：

   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- | 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"
   

   确认响应包含刚刚配置的 AWS 账户 ID。如果响应中没有该账户，请向用户展示响应，以便他们进行调试。

充分利用集成

terraform apply 成功完成后，祝贺用户，并告知他们通常会在 5-10 分钟内收到指标。然后检查是否已收到早期指标，并展示一个小组件。

检查指标

等待几秒，然后查询指标 API——将阶段 1 中的账户 ID 替换 <AWS_ACCOUNT_ID>：

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- | 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)}"
sleep 10
resp=$(printf 'DD-API-KEY: %s\nDD-APPLICATION-KEY: %s\n' "$DD_API_KEY" "$DD_APP_KEY" \
  | curl -sS -w '\n%{http_code}' -G -H @- "https://api.${DD_SITE}/api/v1/query" \
  --data-urlencode "from=$(($(date +%s) - 900))" \
  --data-urlencode "to=$(date +%s)" \
  --data-urlencode "query=avg:aws.ec2.cpuutilization{aws_account:<AWS_ACCOUNT_ID>} by {host}")
code=$(printf '%s' "$resp" | tail -1); body=$(printf '%s' "$resp" | sed '$d')
[ "$code" = "200" ] || { echo "metric query failed with HTTP $code - that is NOT 'metrics still propagating':"; printf '%s\n' "$body"; exit 1; }
printf '%s\n' "$body"

响应中包含下方小组件渲染所需的 series / pointlist JSON：

渲染小组件

如果 series 数组非空，请根据实际数据渲染 ASCII 图表：

• 使用 pointlist 值绘制折线，Y 轴范围按实际最小值和最大值缩放。
• 使用框线字符（╭、╰、─、│、┤）绘制折线。
• 在底部列出每个 series scope 中的主机名。
• 如果返回了多个 series，则显示平均值最高的前 3 个。

如果 series 数组为空，请显示以下静态预览，并告知用户指标仍在传输中：

┌─────────────────────────────────────────────────────────┐
│  aws.ec2.cpuutilization          ▂▃▅▆▇▆▅▃▂▁▂▃▅▆▇█▇▅▃  │
│  100% ┤                                          ╭──╮   │
│   75% ┤                    ╭───╮              ╭──╯  │   │
│   50% ┤              ╭────╯   ╰──╮     ╭────╯     │   │
│   25% ┤    ╭────────╯            ╰────╯           │   │
│    0% ┤────╯                                       │   │
│       └────────────────────────────────────────────┘   │
│                                                         │
│  指标正在传输中 - 请几分钟后再查看                     │
└─────────────────────────────────────────────────────────┘
Metrics Explorer：<APP_BASE>/metric/explorer?exp_metric=aws.ec2.cpuutilization

向用户确认集成已配置，数据很快就会显示。所有链接都使用 DD_SITE——请构造为 <APP_BASE>/...。

• AWS Integration 磁贴：<APP_BASE>/integrations/amazon-web-services - 访问预置仪表板并确认集成处于活动状态。
• Metrics Explorer：<APP_BASE>/metric/explorer?exp_metric=aws.ec2.cpuutilization - 确认数据正在流入。
• 每种 AWS 服务（EC2、RDS、Lambda、S3、ECS、EKS 等）都有自己的仪表板，在检测到该服务的指标时会自动启用。

建议的监控器 - 建议在 <APP_BASE>/monitors/create 创建监控器：

• EC2 CPU 利用率超过阈值

• RDS 可用存储空间不足

• Lambda 错误率骤增

• ELB 不健康主机数量

• Cloud Security：<APP_BASE>/security/compliance - 查看 AWS 资源的安全态势发现项。

• Resource Catalog：<APP_BASE>/infrastructure/catalog - 浏览 EC2 实例、RDS 数据库、Lambda 函数等。

• Infrastructure Map：<APP_BASE>/infrastructure/map - 可视化 AWS 基础设施。

探索更多 Datadog 产品：

• Log Management：<APP_BASE>/logs - 集中搜索日志并配置告警。
• APM & Traces：<APP_BASE>/apm/getting-started - 为运行在 Lambda、ECS、EKS 或 EC2 上的应用程序提供分布式追踪。
• Notebooks：<APP_BASE>/notebook - 分享结合指标、日志和事件的调查分析。

重要说明

• 用户必须拥有 IAM 权限，才能在其 AWS 账户中创建角色、策略和策略附件。
• 外部 ID 由 Datadog 生成，并自动包含在 terraform 中——不应将其硬编码。
• IAM 权限通过 datadog_integration_aws_iam_permissions 从 Datadog 动态获取；随着 Datadog 添加新的集成，这些权限可能会发生变化。
• 权限会自动拆分为多个策略，以满足 AWS IAM 策略大小不超过 6144 个字符的限制。
• Datadog API 密钥和应用密钥绝不会作为值传递给 Terraform：datadog 提供程序会从环境变量读取 DD_API_KEY 和 DD_APP_KEY，因此没有根变量、没有 -var= 参数，也不会将任何内容记录在状态文件或保存的计划中。不要声明密钥变量，也不要将密钥写入已提交的 .tfvars 文件或任何其他持久化文件。
• 未先向用户展示计划，绝不要运行 terraform apply。