dd-audit-cost-spike-investigation

用途

该技能用于调查 Datadog 产品用量或成本突增的成因，核心方法是将计费数据与配置变更历史进行关联。其因果链为：有人修改了某项配置 → 该变更增加了数据量 → 用量突增 → 成本上升。Usage Metering 数据回答“何时、什么突增”，Audit Trail 回答“谁做了变更”。

前置条件

需先完成认证与密钥配置：

pup auth login   # OAuth2（推荐）— 覆盖审计查询
# Usage Metering 查询还需要 DD_API_KEY + DD_APP_KEY
export DD_API_KEY=<your-api-key>
export DD_APP_KEY=<your-app-key>
export DD_SITE=datadoghq.com

范围边界

该技能识别可能引发突增的配置变更，但不识别具体提交数据的用户或进程（例如哪个服务发送了 LLM spans）。如需按提交归因，应使用 LLM Observability traces 或 APM instrumentation。

调查工作流

步骤 1 — 识别突增窗口与产品族

START=$(date -u -v-7d +"%Y-%m-%dT%H:%M:%SZ" 2>/dev/null || date -u -d "7 days ago" +"%Y-%m-%dT%H:%M:%SZ")
END=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

curl -s -G "https://api.${DD_SITE}/api/v2/usage/hourly_usage" \
  -H "DD-API-KEY: ${DD_API_KEY}" \
  -H "DD-APPLICATION-KEY: ${DD_APP_KEY}" \
  --data-urlencode "filter[timestamp][start]=${START}" \
  --data-urlencode "filter[timestamp][end]=${END}" \
  --data-urlencode "filter[product_families]=all" \
  | jq '[.data[] | {
      timestamp: .attributes.timestamp,
      product: .attributes.product_family,
      measurements: [.attributes.measurements[] | {type: .usage_type, value: .value}]
    }]'

覆盖 LLM/AI 的产品族包括：llm_observability、bits_ai、logs、apm。

步骤 2 — 定位突增点

从步骤 1 的结果中找出用量跳升的小时/日期，将该时间戳记为 SPIKE_TIME。

步骤 3 — 检索突增前 24 小时的 Audit Trail 配置变更

pup audit-logs search \
  --query "@action:(created OR modified OR deleted)" \
  --from "SPIKE_TIME_MINUS_24H" \
  --to "SPIKE_TIME" \
  --limit 200 \
  -o json \
  | jq '[.data[] | {
      timestamp: .attributes.timestamp,
      user: .attributes.attributes.usr.email,
      actor_type: .attributes.attributes.evt.actor.type,
      action: .attributes.attributes.action,
      event_category: .attributes.attributes.evt.name,
      resource_type: .attributes.attributes.asset.type,
      resource_id: .attributes.attributes.asset.id
    }]'

注意：--from 和 --to 接受 ISO 时间戳（如 2026-05-01T14:00:00Z）或相对值（1h、24h、7d）。

步骤 4 — 缩小到与产品相关的配置变更

按最可能影响突增产品的审计类别进行过滤：

若该产品突增	在查询中加入
llm_observability	@evt.name:(Integration OR APM OR "Log Management")
logs / indexed_logs	@evt.name:"Log Management" @asset.type:(pipeline OR index OR exclusion_filter)
apm / indexed_spans	@evt.name:APM @asset.type:(retention_filter OR sampling_rate)
rum	@evt.name:RUM
metrics	@evt.name:Metrics

LLM Observability 突增示例：

pup audit-logs search \
  --query "@evt.name:(Integration OR APM OR \"Log Management\") @action:(created OR modified)" \
  --from "SPIKE_TIME_MINUS_24H" \
  --to "SPIKE_TIME" \
  --limit 100 \
  -o json \
  | jq '[.data[] | {
      timestamp: .attributes.timestamp,
      user: .attributes.attributes.usr.email,
      action: .attributes.attributes.action,
      category: .attributes.attributes.evt.name,
      resource_type: .attributes.attributes.asset.type,
      resource_id: .attributes.attributes.asset.id
    }]'

输出格式

Usage spike detected:
  Product: <product_family>
  Spike time: <SPIKE_TIME>
  Volume: <baseline> → <spike_value> (<magnitude>×)

Configuration changes in 24h preceding spike:
  <timestamp> | <user_email> | <action> <resource_type> <resource_id> | <category>

Likely causal change: <most-proximate change matching the product family>

Confidence: HIGH (single clear change) / MEDIUM (multiple candidates) / LOW (no matching changes)

Next steps:
  - Confirm with <user_email> whether the change was intentional
  - If unintentional: revert <resource_id> and monitor volume
  - If intentional: update cost forecasts and alert thresholds

未找到因果变更时

变更可能早于 24 小时窗口 — 扩大到 72 小时；
增长可能来自应用侧埋点变更 — 检查部署记录；
增长可能是自然流量增长 — 与产品发布或流量事件关联分析。

适用场景

适用于 Datadog 用量或成本出现异常突增，需要快速定位是否由配置变更引起，并给出确认、回滚或更新成本预测与告警阈值的后续建议。

限制

该技能不识别具体提交数据的用户或进程；如需按提交归因，需使用 LLM Observability traces 或 APM instrumentation。