Monitoring des coûts Snowflake avec Warehouse History

Snowflake facture à la consommation de crédits, pas aux octets traités. Cela rend le monitoring des coûts conceptuellement différent de BigQuery : vous suivez la durée de fonctionnement des warehouses et le nombre de crédits qu’ils consomment, pas la quantité de données que chaque requête a scannée. L’avantage est la prévisibilité — les crédits par warehouse sont cohérents. Le défi est la traduction : la plupart des parties prenantes ne savent pas ce que coûte un crédit Snowflake, donc le monitoring doit faire le calcul.

Deux vues système couvrent la plupart des besoins de monitoring des coûts : SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY pour les ventilations par requête et SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY pour les totaux par warehouse.

Ventilation des requêtes par warehouse

Commencez avec QUERY_HISTORY pour une vue détaillée de ce que font les warehouses :

SELECT
  warehouse_name,
  COUNT(*) AS query_count,
  ROUND(SUM(credits_used_cloud_services), 2) AS cloud_credits,
  ROUND(SUM(total_elapsed_time) / 1000 / 60, 1) AS total_minutes
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time >= DATEADD('day', -1, CURRENT_TIMESTAMP())
  AND warehouse_name IS NOT NULL
GROUP BY warehouse_name
ORDER BY cloud_credits DESC

credits_used_cloud_services capture la surcharge des services cloud — opérations de métadonnées, consultations du cache de résultats et activités similaires qui consomment des crédits sans s’exécuter sur le warehouse lui-même. C’est généralement une petite fraction du coût total mais vaut la peine d’être suivie séparément.

total_elapsed_time est en millisecondes ; diviser par 1 000 puis par 60 convertit en minutes. La figure des minutes totales aide à corréler la consommation de crédits avec le temps d’exécution réel — un warehouse qui consomme 10 crédits en 5 minutes travaille plus dur qu’un qui consomme 10 crédits en 2 heures.

Notez que QUERY_HISTORY a une latence allant jusqu’à 45 minutes. Les jobs de monitoring vérifiant les dernières 24 heures seront légèrement en retard sur le temps réel.

Historique de métering par warehouse

Pour une vue du coût total plus propre sans granularité par requête, WAREHOUSE_METERING_HISTORY est plus simple :

SELECT
  warehouse_name,
  ROUND(SUM(credits_used), 2) AS credits_used,
  ROUND(SUM(credits_used) * 3.00, 2) AS estimated_cost_usd
FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
WHERE start_time >= DATEADD('day', -1, CURRENT_TIMESTAMP())
GROUP BY warehouse_name
ORDER BY credits_used DESC

Le multiplicateur * 3.00 convertit les crédits en dollars estimés en utilisant le tarif standard des crédits Snowflake. Les clients enterprise avec des tarifs négociés doivent ajuster ce multiplicateur — le coût réel par crédit apparaît dans votre contrat ou console de facturation. Utiliser le mauvais multiplicateur n’affectera pas le classement relatif des warehouses (lequel coûte le plus) mais donnera des chiffres absolus en dollars incorrects dans les alertes.

Cette requête donne un résumé des coûts quotidiens propre : « Le TRANSFORM_WH a consommé 18,2 crédits (54,60 $) hier. Le REPORTING_WH a consommé 4,1 crédits (12,30 $). » C’est le format sur lequel une partie prenante peut agir sans comprendre ce qu’est un crédit.

Traduire les crédits pour les audiences non techniques

Pour les alertes de monitoring atteignant des audiences non techniques, exprimez les coûts en dollars plutôt qu’en crédits. « La dépense Snowflake d’hier était de 247 $, soit 2,3 fois la moyenne quotidienne de 107 $. Le TRANSFORM_WH représentait 68 % du coût » est plus actionnable que l’équivalent en nombre de crédits pour les parties prenantes financières, opérationnelles ou exécutives.

Lors de la configuration d’un agent IA pour livrer ces résumés, ajoutez cela explicitement dans la compétence :

## Reporting pour les parties prenantes non techniques

Lors du reporting des coûts aux audiences non techniques :
- Convertir les crédits en dollars au tarif contractuel (3,00 $ par crédit si inconnu)
- Commencer par le chiffre en dollars, pas le nombre de crédits
- Exprimer les anomalies comme un ratio : « 2,3 fois la moyenne quotidienne » plutôt que des chiffres bruts
- Nommer le warehouse responsable de la plus grande part du coût
- Éviter la terminologie technique (crédits, taille de warehouse, types de compute)

Pattern de détection d’anomalies

La même approche de comparaison glissante qui fonctionne pour les anomalies de coût BigQuery s’applique à Snowflake. Comparez la consommation de crédits d’aujourd’hui par rapport à la moyenne sur 7 jours et signalez quand le ratio dépasse un seuil :

WITH daily_usage AS (
  SELECT
    DATE(start_time) AS usage_date,
    warehouse_name,
    SUM(credits_used) AS daily_credits
  FROM SNOWFLAKE.ACCOUNT_USAGE.WAREHOUSE_METERING_HISTORY
  WHERE start_time >= DATEADD('day', -8, CURRENT_TIMESTAMP())
  GROUP BY 1, 2
),
averages AS (
  SELECT
    warehouse_name,
    AVG(daily_credits) AS avg_daily_credits
  FROM daily_usage
  WHERE usage_date < CURRENT_DATE()
  GROUP BY 1
)

SELECT
  d.warehouse_name,
  d.daily_credits AS today_credits,
  ROUND(d.daily_credits * 3.00, 2) AS today_cost_usd,
  a.avg_daily_credits AS avg_credits,
  ROUND(d.daily_credits / NULLIF(a.avg_daily_credits, 0), 2) AS ratio_to_avg
FROM daily_usage d
JOIN averages a USING (warehouse_name)
WHERE d.usage_date = CURRENT_DATE()
ORDER BY ratio_to_avg DESC

Cette requête retourne une ligne par warehouse avec la consommation d’aujourd’hui, la moyenne récente et le ratio. Tout ratio supérieur à 2,0 mérite d’être signalé. Tout ratio supérieur à 3,0 justifie une investigation immédiate.

La garde NULLIF(a.avg_daily_credits, 0) gère les nouveaux warehouses qui n’ont pas encore une semaine d’historique — sans elle, la division échoue sur des moyennes à zéro.

Ce qui entraîne des coûts Snowflake anormaux

Quand le ratio augmente, les causes les plus courantes :

Auto-suspend du warehouse mal configuré. Un warehouse de développement laissé en marche toute la nuit. Vérifiez WAREHOUSE_METERING_HISTORY pour la consommation de crédits nocturne — si le warehouse a fonctionné en continu sans requêtes, l’auto-suspend ne fonctionnait pas.

File d’attente de requêtes sur un warehouse sous-dimensionné. Un warehouse trop petit pour la charge de travail continue à s’activer et à évoluer. Les crédits consommés par requête augmentent. Vérifiez QUERY_HISTORY pour queued_overload_time et queued_provisioning_time.

Scan complet de table remplaçant l’incrémental. Un modèle dbt qui aurait dû s’exécuter de manière incrémentale a été lancé en full refresh. Si le ratio d’un warehouse augmente sans changement dans le nombre de requêtes, la taille des requêtes individuelles a changé. Vérifiez le champ bytes_scanned dans QUERY_HISTORY pour trouver la valeur aberrante.

Nouveau rapport ou requête planifiée ajouté. Quelqu’un a ajouté un rapport récurrent qui s’exécute toutes les heures. Le nombre de crédits a augmenté parce que la fréquence des jobs a augmenté. Vérifiez le nombre de requêtes par rapport à la moyenne — s’il est significativement plus élevé, la fréquence est le facteur déterminant.

Pour un agent IA qui investigue une anomalie, ces causes correspondent à des requêtes de suivi spécifiques. Un fichier de compétence bien rédigé peut instruire l’agent à exécuter des suivis diagnostiques quand la vérification d’anomalie initiale se déclenche, en approfondissant le warehouse spécifique qui a connu une augmentation.

Planification avec OpenClaw

Pour un résumé quotidien des coûts :

openclaw cron add --name "snowflake-daily-cost" \
  --cron "0 8 * * *" \
  --tz "Europe/Paris" \
  --session isolated \
  --message "Interroger Snowflake WAREHOUSE_METERING_HISTORY pour les coûts d'hier par warehouse. Convertir les crédits en dollars à 3,00 $ par crédit. Signaler tout warehouse où la dépense d'aujourd'hui dépasse 2 fois la moyenne sur 7 jours. Formater le résumé en langage simple sans jargon technique." \
  --announce \
  --channel slack \
  --to "channel:C1234567890"

La requête de monitoring elle-même devrait vivre dans un fichier de compétence pour que le message cron reste lisible. Le message cron gère l’instruction de haut niveau (« résumer et signaler les anomalies ») ; la compétence fournit le SQL et les directives de formatage.

Contrairement à BigQuery, Snowflake n’a pas de niveau gratuit pour les requêtes de métadonnées — exécuter des requêtes ACCOUNT_USAGE consomme des crédits de services cloud. La consommation est minimale (fractions de crédit par requête), mais vaut la peine d’être mentionnée si vous supervisez un environnement sensible aux coûts.

Relation avec le monitoring dbt

Si vous faites tourner dbt sur Snowflake, l’approche WAREHOUSE_METERING_HISTORY vous donne une visibilité des coûts au niveau warehouse. Pour l’attribution des coûts au niveau modèle — comprendre quel modèle dbt a entraîné le pic de coût — vous devrez croiser QUERY_HISTORY avec les tags de requête ou labels de job dbt.

dbt sur Snowflake peut être configuré pour taguer les requêtes avec des métadonnées de modèle en utilisant le paramètre query_comment dans dbt_project.yml :

query-comment:
  comment: "{{ {'app': 'dbt', 'dbt_model': model.name} | tojson }}"
  append: true

Avec cela en place, QUERY_HISTORY.query_text contiendra un commentaire JSON avec le nom du modèle, permettant des requêtes d’attribution qui mappent les crédits Snowflake vers des transformations dbt spécifiques.