Contrôle des coûts Axiom

Tableaux de bord, moniteurs et identification des gaspillages pour l'optimisation de l'utilisation d'Axiom.

Avant de commencer

1. Chargez les skills requis :

   skill: axiom-sre
   skill: building-dashboards

   Building-dashboards fournit : dashboard-list, dashboard-get, dashboard-create, dashboard-update, dashboard-delete

2. Trouvez le dataset d'audit. Essayez d'abord axiom-audit :

   ['axiom-audit']
   | where _time > ago(1h)
   | summarize count() by action
   | where action in ('usageCalculated', 'runAPLQueryCost')

   • Si non trouvé → demandez à l'utilisateur. Noms courants : axiom-audit-logs-view, audit-logs
   • Si trouvé mais pas d'événements usageCalculated → mauvais dataset, demandez à l'utilisateur

3. Vérifiez l'accès à axiom-history (requis pour Phase 4) :

   ['axiom-history'] | where _time > ago(1h) | take 1

   Si non trouvé, l'optimisation Phase 4 ne fonctionnera pas.

4. Confirmez avec l'utilisateur :

   • Nom du déploiement ?
   • Nom du dataset d'audit ?
   • Limite du contrat en TB/jour ? (requise pour les moniteurs Phase 3)

5. Remplacez <deployment> et <audit-dataset> dans toutes les commandes ci-dessous.

Astuces :

• Exécutez n'importe quel script avec -h pour l'usage complet
• Ne pipez PAS la sortie du script vers head ou tail — provoque des erreurs SIGPIPE
• Nécessite jq pour le parsing JSON
• Utilisez axiom-query du skill axiom-sre pour les requêtes APL ad-hoc, pas l'CLI direct

Quelles phases exécuter

Phase 0 : Vérifier la configuration existante

# Tableau de bord existant ?
dashboard-list <deployment> | grep -i cost

# Moniteurs existants ?
axiom-api <deployment> GET "/v2/monitors" | jq -r '.[] | select(.name | startswith("Cost Control:")) | "\(.id)\t\(.name)"'

Si trouvé, récupérez avec dashboard-get et comparez à templates/dashboard.json pour détecter la dérive.

Phase 1 : Découverte

scripts/baseline-stats -d <deployment> -a <audit-dataset>

Capture les statistiques d'ingestion quotidiennes et produit la File d'analyse (nécessaire pour Phase 4).

Phase 2 : Tableau de bord

scripts/deploy-dashboard -d <deployment> -a <audit-dataset>

Crée un tableau de bord avec : tendances d'ingestion, taux de consommation, projections, candidats au gaspillage, utilisateurs principaux. Voir reference/dashboard-panels.md pour les détails.

Phase 3 : Moniteurs

Le contrat est requis. Vous devez avoir la limite du contrat à l'étape de préflight 4.

Étape 1 : Lister les notificateurs disponibles

scripts/list-notifiers -d <deployment>

Présentez la liste à l'utilisateur et demandez quel notificateur il souhaite pour les alertes de coûts. S'il ne souhaite pas de notifications, continuez sans -n.

Étape 2 : Créer les moniteurs

scripts/create-monitors -d <deployment> -a <audit-dataset> -c <contract_tb> [-n <notifier_id>]

Crée 3 moniteurs :

1. Total Ingest Guard — alerte lorsque l'ingestion quotidienne >1,2x contrat OU la moyenne 7j croît >15% vs baseline
2. Per-Dataset Spike — détection z-score robuste, alerte par dataset avec attribution
3. Query Cost Spike — z-score renforcé avec baseline 30j, écart d'exclusion 5j, gating basé sur la persistance (median_z > 3, p25_z > 2,5)

Les moniteurs de pic utilisent notifyByGroup: true pour que chaque dataset déclenche une alerte séparée.

Voir reference/monitor-strategy.md pour la dérivation des seuils.

Phase 4 : Optimisation

Obtenir la file d'analyse

Exécutez scripts/baseline-stats si pas déjà fait. Il retourne une liste priorisée :

Work/GB = coût de requête (GB·ms) / ingestion (GB). Plus bas = moins de valeur des données.

Analyser les datasets dans l'ordre

Travaillez de haut en bas. Pour chaque dataset :

Étape 1 : Analyse des colonnes

scripts/analyze-query-coverage -d <deployment> -D <dataset> -a <audit-dataset>

Si 0 requêtes → recommandez DROP, passez au suivant.

Étape 2 : Analyse des valeurs de champs

Choisissez un champ de la liste suggérée (généralement app, service, ou kubernetes.labels.app) :

scripts/analyze-query-coverage -d <deployment> -D <dataset> -a <audit-dataset> -f <field>

Notez les valeurs avec volume élevé mais jamais interrogées (marqueurs ⚠️).

Étape 3 : Traiter les valeurs vides

Si (empty) a >5% de volume, vous DEVEZ explorer avec un champ alternatif (ex. kubernetes.namespace_name).

Étape 4 : Enregistrer la recommandation

Pour chaque dataset, notez : nom, volume d'ingestion, Work/GB, valeurs principales non interrogées, action (DROP/SAMPLE/KEEP), économies estimées.

Terminé quand

Tous les datasets P0⛔ et P1 analysés. Compilez ensuite le rapport en utilisant reference/analysis-report-template.md.

Nettoyage

# Supprimer les moniteurs
axiom-api <deployment> GET "/v2/monitors" | jq -r '.[] | select(.name | startswith("Cost Control:")) | "\(.id)\t\(.name)"'
axiom-api <deployment> DELETE "/v2/monitors/<id>"

# Supprimer le tableau de bord
dashboard-list <deployment> | grep -i cost
dashboard-delete <deployment> <id>

Note : Exécuter create-monitors deux fois crée des doublons. Supprimez d'abord les moniteurs existants si vous redéployez.

Référence

Champs du dataset d'audit

Champs courants pour l'analyse de valeur

Unités et conversions

• Les scripts utilisent TB/jour
• Le filtre du tableau de bord utilise GB/mois

Actions d'optimisation