Tracer sa consommation de Capacity Units dans Microsoft Fabric : une preview à tester, pas à adopter trop vite

REX — Nous avons testé les événements de consommation de capacité exposés par Eventstream dans Microsoft Fabric. La granularité est intéressante, mais pour un besoin standard, Capacity Metrics fait déjà une grande partie du travail. Sur une petite capacité, le coût de la collecte est aussi à prendre en compte.

Le contexte : une nouvelle brique, mais pour quel besoin ?

Sur un projet client récent, une question est revenue plusieurs fois : qui consomme quoi sur une capacité Microsoft Fabric ?

L’application Capacity Metrics répond déjà à une grande partie de cette question. Elle présente toutefois quelques limites : la donnée est exposée dans Power BI, n’est pas directement requêtable en SQL, se croise difficilement avec les autres données du projet et sa rétention du détail reste limitée.

Microsoft propose désormais, en preview, une nouvelle source Eventstream qui expose les événements de consommation d’une capacité, opération par opération.

Nous avons donc voulu la tester avec une question simple :

Pour une analyse standard, notre réponse est plutôt non. Pour certains besoins plus spécifiques, elle peut en revanche avoir du sens.

1. Ce que propose cette nouvelle source Eventstream

Eventstream permet de capter un flux d’événements et de le router vers différentes destinations : Lakehouse, Eventhouse, Activator, etc. Pour ce test, nous avons utilisé la source « Événements d’une opération de capacité », disponible depuis août 2026 et encore en preview.

Microsoft envisage notamment deux usages :

• déclencher une alerte Activator sur une opération ;
• conserver les événements pour une analyse historique par workspace, item ou opération.

Nous avons retenu le second scénario, avec un Lakehouse comme destination.

2. Ce que l’on récupère

La partie data d’un événement contient notamment :

Quelques champs sont particulièrement utiles.

capacityUnitMs

C’est la consommation brute de l’opération : CU × millisecondes consommées.

utilizationType

Il distingue notamment les opérations interactives des opérations background. Ces dernières sont lissées sur 24 heures, ce qui peut reporter leur consommation sur les fenêtres suivantes.

operationStartTime et les fenêtres de consommation

operationStartTime correspond au démarrage réel de l’opération.

windowStartTime et windowEndTime correspondent à la fenêtre de lissage. Il faut donc éviter de les confondre.

itemId, itemName et itemKind

Ces champs permettent d’identifier l’objet Fabric à l’origine de la consommation.

3. Une chaîne Bronze / Silver assez simple

Pour le test, nous avons gardé une architecture minimale. L’Eventstream dépose les événements dans une table Delta Bronze : lh_bronze.dbo.activity. La colonne data contient en réalité un JSON à dépiler : un notebook la parse pour en extraire chaque champ dans une colonne dédiée.

On récupère par exemple :

• capacity_unit_ms
• cu_seconds
• item_id
• utilization_type

Un point d’attention : une même opération apparaît une fois par fenêtre de consommation où elle a été active. Une opération qui dure 20 minutes, sur des fenêtres de 10 minutes, apparaîtra donc 2 fois — avec, à chaque fois, le cu_seconds et le status correspondant à cette tranche précise. Ce n’est pas un doublon à dédupliquer, mais bien deux lignes légitimes à conserver.

Une fois la donnée en Silver, on peut l’agréger par jour, capacité, workspace, item ou opération. On peut aussi rechercher un objet à partir d’un identifiant d’activité :

Le prototype fonctionne. Mais une question se pose rapidement :

4. Face à Capacity Metrics

Capacity Metrics gère déjà nativement les mécanismes de lissage et de carry-forward, notamment avec overageAddCapacityUnitMs. Notre implémentation ne fait qu’approcher cette logique. La reconstruire dans le Lakehouse ajoute donc surtout une couche de traitement.

La limite de Capacity Metrics est plutôt du côté de l’accès à la donnée. Le modèle est exposé via Power BI, n’est pas directement requêtable en SQL, sa rétention du détail par opération est limitée à 14 jours et il est difficile à croiser avec les autres données du projet.

C’est là que l’extraction externe peut avoir un intérêt. Nous pensions notamment utiliser Eventstream pour retrouver l’objet associé à une opération à partir de son identifiant, mais Capacity Metrics sait déjà le faire. Sa table de détail expose une colonne OperationId qui permet de retrouver l’item, l’opération, la durée, le Timepoint CU (s) et le % of Base capacity.

Notre fonction find_activity() reproduit donc, avec une infrastructure supplémentaire, quelque chose que Capacity Metrics sait déjà faire sur sa fenêtre de rétention. La granularité supplémentaire est intéressante, mais elle n’apporte pas forcément une valeur supplémentaire.

5. Avant de construire, regarder ce qui existe déjà

La communauté Fabric propose notamment FUAM — Fabric Unified Admin Monitoring, qui extrait le modèle sémantique via XMLA et permet de le recharger dans un Lakehouse Delta. On obtient ainsi une donnée requêtable en SQL, avec une rétention que l’on maîtrise.

Si le besoin est simplement :

6. Et le coût ?

Sur une petite capacité, l’Eventstream consomme lui-même des CU lorsqu’il est actif. Nous avons fait le test sur une F2, soit 2 CU. Nous avons observé un pic net le jour de l’activation de l’Eventstream.

Sur une journée d’utilisation d’environ 09h à 06h le lendemain, en filtrant sur Item kind = EventStream, le traitement des événements a représenté 39,51 % de la capacité de base d’une F2.

Ce chiffre correspond à notre environnement de test et ne doit pas être généralisé. Mais il montre un point important : la collecte de la donnée consomme elle-même de la capacité. Sur une grosse capacité, le coût pourra être marginal. Sur une F2, il ne l’est pas forcément.

7. Les principales limites

Une preview

La fonctionnalité est encore en preview. Le schéma et certains champs, notamment releaseType, peuvent encore évoluer.

Une partie du besoin est déjà couverte

Pour rechercher une opération, identifier un item ou analyser la consommation, Capacity Metrics couvre déjà une bonne partie du besoin.

Ajouter Eventstream signifie aussi ajouter de l’infrastructure, de la maintenance et de la consommation de CU.

Le cas d’usage doit venir en premier

La granularité opérationnelle est intéressante, mais elle n’a de valeur que si elle répond à un besoin précis.

8. Quand utiliser Eventstream ?

Quelques cas peuvent justifier cette approche :

• croiser la consommation avec des données métier ;
• conserver un historique plus long ;
• construire un alerting spécifique ;
• exploiter les événements en quasi temps réel.

Dans ces situations, la donnée au niveau de l’opération peut justifier la chaîne supplémentaire. À l’inverse, nous ne partirions pas sur cette solution pour simplement :

• identifier les consommateurs d’une capacité ;
• retrouver une opération ;
• analyser la consommation par item ;
• reproduire les indicateurs Capacity Metrics.

Dans ces cas, l’existant suffit généralement. Pour le monitoring de capacité et de tenant, FUAM mérite notamment d’être regardé. Pour les problématiques FinOps et le rapprochement avec la facturation Azure, FCA — Fabric Cost Analysis est une autre piste.

Conclusion

Cette preview est intéressante, mais elle ne justifie pas à elle seule de revoir une architecture existante.

Avant de l’utiliser, regarder :

1. ce que Capacity Metrics sait déjà faire ;
2. ce que les solutions existantes comme FUAM permettent ;
3. le coût de la collecte sur sa propre capacité.

Pour un besoin standard, Capacity Metrics reste probablement suffisant. Eventstream devient intéressant lorsque le besoin est plus spécifique : croisement avec des données métier, historique long, alerting custom ou exploitation événementielle.

Partir du cas d’usage avant de partir de la fonctionnalité.