Contrôle des coûts Axiom

Tableaux de bord, moniteurs et identification du gaspillage pour l'optimisation de l'usage Axiom.

Avant de commencer

1. Chargez les skills requis :

   skill: axiom-sre
   skill: axiom-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 de contrat en TB/jour ? (requis pour les moniteurs Phase 3)

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

Conseils :

• Exécutez tout script avec -h pour l'usage complet
• NE PAS rediriger la sortie du script vers head ou tail — cause des erreurs SIGPIPE
• Requiert jq pour l'analyse JSON
• Utilisez axiom-query du skill axiom-sre pour les APL ad-hoc, pas le 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és, récupérez avec dashboard-get et comparez avec 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 burn, projections, candidats au gaspillage, utilisateurs principaux. Consultez reference/dashboard-panels.md pour les détails.

Phase 3 : Moniteurs

Un contrat est requis. Vous devez avoir la limite de contrat de l'étape de pré-vol 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ût. S'il ne souhaite pas de notifications, procédez 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 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 spike utilisent notifyByGroup: true pour que chaque dataset déclenche une alerte distincte.

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

Phase 4 : Optimisation

Obtenir la File d'analyse

Exécutez scripts/baseline-stats si cela n'a pas déjà été fait. Il génère une liste priorisée :

Work/GB = coût des requêtes (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 haut volume mais jamais interrogées (marqueurs ⚠️).

Étape 3 : Gérer les valeurs vides

Si (empty) a >5% du volume, vous DEVEZ approfondir 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 sont analysés. Compilez ensuite 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. Supprimez les moniteurs existants d'abord avant de redéployer.

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