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. Charger les skills requis :

   skill: axiom-sre
   skill: axiom-build-dashboard

   axiom-build-dashboard fournit : dashboard-list, dashboard-get, dashboard-create, dashboard-update, dashboard-delete

2. Trouver le dataset d'audit. Essayer d'abord axiom-audit :

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

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

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

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

   S'il n'est pas trouvé, l'optimisation Phase 4 ne fonctionnera pas.

4. Confirmer avec l'utilisateur :

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

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

Astuces :

• Exécuter n'importe quel script avec -h pour la syntaxe complète
• Ne PAS rediriger la sortie du script vers head ou tail — provoque des erreurs SIGPIPE
• Nécessite jq pour l'analyse JSON
• Utiliser axiom-query du skill axiom-sre pour les APL ad-hoc, pas le CLI directe

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és, les récupérer avec dashboard-get et comparer à templates/dashboard.json pour détecter des dérives.

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 brûlure, 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 de l'étape de vérification préalable 4.

Étape 1 : Lister les notificateurs disponibles

scripts/list-notifiers -d <deployment>

Présenter la liste à l'utilisateur et demander quel notificateur il souhaite pour les alertes de coûts. S'il ne souhaite pas de notifications, procéder 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 quand l'ingestion quotidienne >1,2x le contrat OU la moyenne 7 jours augmente >15% vs baseline
2. Per-Dataset Spike — détection robuste par z-score, alerte par dataset avec attribution
3. Query Cost Spike — z-score renforcé avec baseline 30j, exclusion 5j, gating basé sur la persistance (median_z > 3, p25_z > 2,5)

Les moniteurs de spike utilisent notifyByGroup: true afin 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écuter scripts/baseline-stats si pas déjà fait. Il produit une liste priorisée :

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

Analyser les datasets dans l'ordre

Travailler 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ête → recommander DROP, passer au suivant.

Étape 2 : Analyse des valeurs de champs

Choisir un champ parmi 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>

Noter les valeurs avec grand volume mais jamais interrogées (marqueurs ⚠️).

Étape 3 : Gérer les valeurs vides

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

Étape 4 : Enregistrer la recommandation

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

Terminé quand

Tous les datasets P0⛔ et P1 analysés. Ensuite compiler le rapport avec 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. Supprimer les moniteurs existants d'abord en cas de re-déploiement.

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