Snowflake ne tombe presque jamais en panne. Les requêtes aboutissent, les tableaux de bord se chargent et l'exécution dbt de la nuit passe au vert, et c'est précisément pour cela que personne ne remarque quand le compte devient discrètement deux fois plus cher. Les filets de sécurité habituels, resource monitors, auto-suspend et l'éventuel tableau de bord des coûts, sont conçus pour les pannes et les quotas, pas pour les changements de comportement lents et silencieux.

digna est une plateforme de Data Quality & Observability, et l'une des choses que vous pouvez surveiller avec elle est la plateforme sur laquelle tournent vos données. Cette vidéo reprend six idées reçues que beaucoup d'équipes Snowflake ont sur leur facture et confronte chacune aux vues account usage d'un laboratoire pharmaceutique fictif dans le projet de démonstration de digna.

Tout est dans account usage

Snowflake enregistre déjà tout ce dont vous avez besoin dans SNOWFLAKE.ACCOUNT_USAGE : la consommation des warehouses, l'historique des requêtes, la charge des warehouses, les crédits serverless, le stockage, les exécutions de tasks et les connexions. digna lit ces vues là où elles se trouvent et apprend à quoi ressemble la normale pour chaque warehouse, chaque modèle dbt et chaque rapport, y compris le rythme hebdomadaire et la clôture mensuelle.

Six idées reçues, et ce que disent les données

« Un resource monitor nous préviendra. » Oui, une fois le quota épuisé. Un warehouse de transformation qui grossit un peu chaque semaine ne déclenche jamais rien : dans la démo, il est passé d'environ 17 crédits par jour en février à plus de 30 en juillet sans un seul jour rouge, et les analyses de digna l'ont placé en tête du classement des tendances bien avant qu'un quota ne soit atteint.

« Un warehouse plus grand va simplement plus vite. » Il facture aussi selon sa taille. Quand le warehouse des analystes a été passé de small à extra large pour une démo et que personne ne l'a réduit ensuite, ses crédits par heure active ont été multipliés par plus de sept du jour au lendemain, et digna l'a signalé le jour même.

« L'auto-suspend gère le temps d'inactivité. » Jusqu'à ce que quelqu'un le modifie. Quand l'auto-suspend des analystes a été porté à soixante minutes, une règle simple sur l'instantané quotidien des warehouses, aucun warehouse au-delà de dix minutes, l'a repéré le jour même.

« Si une requête a abouti, tout va bien. » Une jointure cartésienne a tourné six heures et scanné environ dix téraoctets sur un warehouse qui lit normalement un demi-téraoctet par jour, et trois semaines plus tard un rapport a perdu son partition pruning et scanné près de trois fois son volume habituel. Les deux ont abouti, et les deux ont été signalées.

« Le serverless se gère tout seul. » C'est vrai, et il le facture. Quand la search optimization a été activée sur de grandes tables de ventes, ses crédits ont été multipliés par plus de huit en une journée, et quand un nouveau modèle sémantique s'est mis à générer un SQL énorme, les cloud services du warehouse de reporting sont passés d'environ 10 à 60 % de son calcul.

« Si quelque chose casse, nous le saurons. » Parfois. Douze des trente-sept tasks dbt ont échoué une nuit sur la même erreur de compilation, une modification d'une vue de ventes a cassé 176 requêtes de tableaux de bord, et une journée a apporté 238 échecs de connexion de plus que la veille. digna a repéré les trois avec des règles simples sur les vues account usage.

Pour les métriques derrière ces contrôles, lisez comment suivre l'utilisation, les coûts et les performances de Snowflake.

Ce que digna laisse tranquille

Ce qui n'est pas signalé compte tout autant. En fin de mois, le warehouse finance consomme presque moitié plus qu'un jour normal, et comme digna a appris le calendrier de clôture, il reste vert, là où une alerte fixe se déclencherait chaque mois sans exception.

Une page le matin, ou une question à votre assistant

Tout cela arrive chaque matin sur une seule page, verte presque partout et rouge uniquement là où quelque chose a bougé pendant la nuit. Et si vous préférez demander plutôt que regarder, demandez à votre assistant IA quels warehouses Snowflake sont devenus plus chers cette année : grâce au skill digna, il interroge le serveur MCP de digna et répond à partir des résultats de digna, warehouse par warehouse, sans jamais lire les données elles-mêmes.

Tout s'exécute dans votre propre environnement, juste à côté des vues account usage qu'il lit, de sorte que rien ne quitte jamais votre organisation.

Réservez une démo et voyez-le sur votre propre compte Snowflake.

Questions fréquentes

Quelles vues Snowflake digna utilise-t-il ?

Dans la démo : WAREHOUSE_METERING_HISTORY pour les crédits par warehouse et par heure active, QUERY_HISTORY pour la durée, les octets scannés et les échecs, WAREHOUSE_LOAD_HISTORY pour les files d'attente, METERING_DAILY_HISTORY pour les crédits serverless, le stockage, TASK_HISTORY pour les tasks dbt et LOGIN_HISTORY pour les échecs de connexion, plus un instantané quotidien de SHOW WAREHOUSES.

Un resource monitor ne suffit-il pas ?

Un resource monitor agit quand un quota de crédits est épuisé. Il ne vous dit pas qu'un warehouse a grossi de 80 % en cinq mois alors que chaque jour paraissait normal ; le classement des tendances de digna, si, bien avant que le quota soit atteint.

Comment digna remarque-t-il un resize de warehouse oublié ?

Il suit les crédits par heure active de chaque warehouse. Chaque palier de taille double ce chiffre, si bien qu'un resize apparaît le jour même comme un saut par rapport à la baseline apprise du warehouse, quelle que soit sa charge.

Les pics de fin de mois et de fin de trimestre déclenchent-ils des alertes ?

Non. La saisonnalité fait partie de la baseline apprise : un warehouse finance qui consomme moitié plus en fin de mois reste vert, alors que le même saut un jour ordinaire serait signalé.

Snowflake est-il la seule plateforme que digna peut observer ?

Non. Observer la plateforme de données est un cas d'usage de digna, la plateforme de Data Quality & Observability ; la même approche fonctionne pour Databricks, Teradata et d'autres warehouses, en plus de la surveillance des données elles-mêmes.