verify-ssi

在 Kubernetes 上验证 APM SSI

**在进行任何操作之前：**完全解析 ## Context to resolve before acting 中的所有变量。所有变量都有具体值后，才能开始步骤 1。

触发条件

当用户表达以下意图时，调用此技能：

• 启用 APM 后，确认 SSI 是否正常工作
• 检查 Pod 是否已植入
• 验证追踪器是否正在运行并上报遥测数据
• 确认追踪器配置是否正确应用

以下情况不要调用此技能：

• 尚未启用 SSI——请先运行 enable-ssi
• Pod 完全没有植入——请使用 troubleshoot-ssi

---

前提条件

• 已完成 enable-ssi
• 启用 SSI 后，已重启应用 Pod

pup-cli：检查、安装并进行身份验证

Claude 运行

pup --version

如果未找到：

Claude 运行

brew tap datadog-labs/pack
brew install pup

检查身份验证状态：

pup auth status --site <DD_SITE>

如果尚未通过身份验证：

Claude 运行

pup auth login --site <DD_SITE>

这会打开一个浏览器标签页以进行 OAuth。请在那里完成登录——命令退出后，Claude 将继续操作。

如果令牌有效——继续。 错误：没有可用的浏览器——请使用 API 密钥作为备用方案：export DD_APP_KEY=<your-app-key>

---

操作前需要解析的上下文

变量	解析方法
CLUSTER_NAME	检查 datadog-agent.yaml 中的 spec.global.clusterName，或运行 kubectl config current-context
ENV	检查应用 Deployment 上的 tags.datadoghq.com/env 标签
SERVICE_NAME	检查应用 Deployment 上的 tags.datadoghq.com/service 标签

---

步骤 1：确认 Pod 已植入

Claude 运行

kubectl get pod -l app=<APP_LABEL> -n <APP_NAMESPACE> \
  -o jsonpath='{.items[0].spec.initContainers[*].name}'

如果输出中包含 datadog-lib-<language>-init 和 datadog-init-apm-inject，则表示已注入 SSI 初始化容器。

错误：缺少初始化容器——SSI 启用后未重启 Pod，或命名空间目标未匹配。请重启 Pod 并重新检查。

---

步骤 2：确认追踪器正在上报遥测数据

Claude 运行

DD_SITE=<DD_SITE> pup apm services list --env <ENV> --from 1h

如果服务列表中出现 <SERVICE_NAME>，且其 isTraced: true，则继续执行步骤 3。

错误：未找到服务——先向应用发送一些流量，然后重试：

Claude 运行

# Port-forward and send test traffic
kubectl port-forward deployment/<DEPLOYMENT_NAME> 8099:8000 -n <APP_NAMESPACE> &
sleep 2 && for i in $(seq 1 10); do curl -s -o /dev/null http://localhost:8099/; done
sleep 30 && kill %1 2>/dev/null
DD_SITE=<DD_SITE> pup apm services list --env <ENV> --from 10m

错误：发送流量后仍未找到——检查 Agent 的追踪接收器：kubectl exec -n <AGENT_NAMESPACE> <AGENT_POD> -c agent -- agent status | grep -A 10 "Receiver (previous minute)"。如果接收器显示 0 条追踪，请转到 troubleshoot-ssi。

---

步骤 3：确认追踪器配置

仅当在 enable-ssi 中显式配置了 ddTraceConfigs 时才执行此步骤（例如 profiling、AppSec、Data Streams）。如果配置的是基础 SSI，且未设置 ddTraceConfigs，请跳过此步骤。没有 ddTraceConfigs 就没有需要检查的内容。

Pod 规格是判断 ddTraceConfigs 是否已应用到工作负载的事实依据。SSI 会将每个条目作为环境变量添加到 Pod 的容器中。

对于每个配置了 ddTraceConfigs 的目标，各选取一个 Pod 执行此操作。对于 Data Streams，请在 DSM_SERVICES 中的每个 Deployment 上各执行一次，并在该 Deployment 所在的命名空间中运行；将 <LABEL_KEY> 设为 DSM_LABEL_KEY，将 <APP_LABEL> 设为该 Deployment 的值（二者均来自 enable-dsm）。其他情况下，<LABEL_KEY> 为 app。如果某个 Pod 仅匹配了未配置 ddTraceConfigs 的目标（例如兜底的 default 目标），则不应包含这些变量。这是预期行为，并不表示失败。

Claude 运行记录

kubectl get pod -l <LABEL_KEY>=<APP_LABEL> -n <APP_NAMESPACE> --sort-by=.metadata.creationTimestamp \
  -o jsonpath='{range .items[-1:].spec.containers[*]}{.name}{":"}{"\n"}{range .env[*]}{"  "}{.name}={.value}{.valueFrom}{"\n"}{end}{end}' | grep -E '^[^ ].*:$|^  DD_'

要查看 Pod 匹配了哪个目标：

kubectl get pod -l <LABEL_KEY>=<APP_LABEL> -n <APP_NAMESPACE> --sort-by=.metadata.creationTimestamp \
  -o jsonpath='{.items[-1:].metadata.annotations.internal\.apm\.datadoghq\.com/applied-target}'

如果该目标的每个 ddTraceConfigs 变量都以配置的值出现在应用容器中，则说明配置已传送到 Pod。这只能确认配置已传送，并不能确认 SDK 已应用这些配置；onboarding-summary 会检查产品数据。继续。

错误：缺少某个变量，或变量的值不一致。

• 值不一致：Deployment 自行设置了该变量，而 SSI 不会覆盖已有变量。请从 Deployment 中移除该变量或使其值保持一致。
• 缺少变量：检查 DatadogAgent 清单中是否在与该 Pod 匹配的目标下设置了该变量，并确认 Cluster Agent 完成滚动更新后重启了该 Pod。

然后检查跟踪器在运行时报告的内容。此输出仅供参考；不要因此判定步骤 3 失败。

Claude 运行记录

pup apm service-library-config get \
  --service-name <SERVICE_NAME> \
  --env <ENV>

此视图不会列出每个 SDK 的所有设置。例如，即使已启用 DSM，Java、Python、Ruby 或 Go 服务也不会显示 DD_DATA_STREAMS_ENABLED。如果某项设置已存在于 Pod 环境变量中，那么此处未显示该设置并不代表失败。对于 Data Streams，onboarding-summary 会通过 data_streams.latency 确认数据（如果单独运行了 enable-dsm，则通过步骤 3 确认）。

---

完成

只有在满足以下所有条件时才退出：

• 步骤 1：目标 Pod 已注入 SSI init 容器（datadog-lib-<language>-init 和 datadog-init-apm-inject）
• 步骤 2：服务显示在 pup apm services list 中，且 isTraced: true
• 步骤 3（仅当设置了 ddTraceConfigs 时）：每个 ddTraceConfigs 变量都以配置的值出现在其目标 Pod 的环境变量中。如果 pup apm service-library-config get 中未显示某项设置，并不代表失败

如果任何检查失败，请转到 troubleshoot-ssi。

所有步骤通过后，立即自动继续执行 onboarding-summary——无需征求用户许可。

---

安全约束

• 切勿将原始 API 密钥写入任何文件或聊天消息
• 未经用户确认，切勿运行 kubectl delete