dd-audit-cost-spike-investigation

監査証跡：コスト／使用量急増の調査

課金データと設定変更履歴を関連付けて、Datadog の使用量が急増した原因を特定します。

因果関係は次のとおりです。誰かが何かを変更した → その変更によってデータ量が増加した → 使用量が急増した → コストが上昇した。使用量メータリングでは、いつ何が起きたかを把握でき、監査証跡では誰が変更したかを把握できます。

前提条件

pup auth login   # OAuth2 (recommended) — covers audit queries
# Usage Metering queries also need 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 スパンを送信したサービス）は特定しません。送信単位での帰属を確認するには、LLM Observability のトレースまたは APM のインストルメンテーションを使用してください。

調査ワークフロー

ステップ 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 時間に発生した設定変更を監査証跡で検索する

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

因果関係のある変更が見つからない場合

1. 変更が 24 時間の対象期間より前に行われた可能性があります。72 時間に拡大してください
2. アプリケーション側のインストルメンテーション変更によって増加した可能性があります。デプロイを確認してください
3. 自然なトラフィック増加による可能性があります。製品のリリースやトラフィックイベントと関連付けてください

参考資料

• 使用量メータリング API
• 監査証跡 API
• LLM Observability