Audit Trail : Investigation d'un pic de coûts / utilisation

Identifiez ce qui a causé un pic d'utilisation Datadog en corrélant les données de facturation avec l'historique des changements de configuration.

La chaîne causale est : quelqu'un a modifié quelque chose → ce changement a augmenté le volume de données → l'utilisation a grimpé → le coût a augmenté. Usage Metering vous dit quand et quoi ; Audit Trail vous dit qui a fait le changement.

Prérequis

pup auth login   # OAuth2 (recommandé) — couvre les requêtes d'audit
# Les requêtes Usage Metering nécessitent aussi 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

Limites du périmètre

Cette skill identifie les changements de configuration qui ont pu causer un pic. Elle n'identifie pas quel utilisateur ou processus spécifique a soumis les données (p. ex., quel service a envoyé les spans LLM). Pour une attribution par soumission, utilisez les traces LLM Observability ou l'instrumentation APM.

Workflow d'investigation

Étape 1 — Identifiez la fenêtre du pic et la famille de produits

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}]
    }]'

Familles de produits avec couverture LLM/AI : llm_observability, bits_ai, logs, apm

Étape 2 — Localisez précisément le pic

À partir de l'étape 1, identifiez l'heure/jour où le volume a augmenté. Notez le timestamp sous SPIKE_TIME.

Étape 3 — Recherchez dans l'Audit Trail les changements de configuration dans les 24h précédant le pic

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
    }]'

Note : --from et --to acceptent les timestamps ISO (p. ex., 2026-05-01T14:00:00Z) ou les valeurs relatives (1h, 24h, 7d).

Étape 4 — Affinez sur les changements de configuration pertinents pour le produit

Filtrez sur les catégories d'audit les plus susceptibles d'affecter le produit ayant connu un pic :

Exemple pour un pic 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
    }]'

Format de sortie

Pic d'utilisation détecté :
  Produit : <product_family>
  Heure du pic : <SPIKE_TIME>
  Volume : <baseline> → <spike_value> (<magnitude>×)

Changements de configuration dans les 24h précédant le pic :
  <timestamp> | <user_email> | <action> <resource_type> <resource_id> | <category>

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

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

Étapes suivantes :
  - Confirmer avec <user_email> si le changement était intentionnel
  - Si involontaire : rétablir <resource_id> et surveiller le volume
  - Si intentionnel : mettre à jour les prévisions de coûts et les seuils d'alerte

Quand aucun changement causal n'est trouvé

1. Le changement peut précéder la fenêtre de 24h — élargissez à 72h
2. L'augmentation peut provenir de changements d'instrumentation côté application — vérifiez les déploiements
3. L'augmentation peut être une croissance organique du trafic — corrélé avec un lancement de produit ou un événement de trafic

Références

• Usage Metering API
• Audit Trail API
• LLM Observability