← Tots els posts

Cinc minuts al dia per deixar de reaccionar a cegues a Microsoft Fabric

Guia pràctica de la Microsoft Fabric Capacity Metrics App per diagnosticar rendiment, throttling i consum de CUs

CapacitatFabric Traduït de l’original en castellà

A Microsoft Fabric, el consum de recursos se suavitza, s’acumula i, de vegades, es converteix en throttling abans que ningú no ho hagi vist venir. Els informes triguen més, els refrescos comencen a fallar i apareixen missatges de throttling sense avís previ. I la pregunta inevitable sempre és la mateixa:

Què està consumint realment la meva capacitat?

GIF: un hombre con gafas de sol lanzando billetes

La resposta no és a la intuïció, ni a assenyalar Spark «perquè sí», ni a mirar malament l’informe més utilitzat. És a les dades de consum de la teva pròpia capacitat. I aquí és on entra la Capacity Metrics App.

Què és la Microsoft Fabric Capacity Metrics App?

La Capacity Metrics App és una aplicació oficial de Microsoft que recopila i visualitza totes les operacions que consumeixen CUs dins d’una capacitat de Fabric. T’ajuda a respondre tres preguntes clau: qui està consumint, quan ho està fent i com aquest consum impacta en el rendiment global.

Ajustem expectatives:

  • Et dirà quin informe, quin pipeline o quin notebook consumeix.
  • No et dirà quina mesura DAX o quina línia de codi Spark és la culpable.

Això és la llanterna, no el bisturí.

Com instal·lar la Capacity Metrics App

Necessites el rol d’Administrador de capacitat a Fabric. Sense ell, no veuràs les dades que necessites.

  1. Ves a AppSource i busca «Microsoft Fabric Capacity Metrics».
  2. Fes clic a Get it now i instal·la l’app al teu tenant.
  3. En obrir-la per primera vegada, connecta-la introduint el Capacity ID (el trobaràs al portal d’administració de Fabric).

L’app té una retenció màxima de 14 dies i no és monitoratge en temps real, però és més que suficient per a l’anàlisi de patrons que necessites.

La meva rutina dels 5 minuts amb el cafè

Abans que entri el primer tiquet de «això va lent», ja sé com està la capacitat. No perquè tingui superpoders, sinó perquè tinc una ruta fixa que dura el que dura el primer cafè.

GIF: una mujer sonriendo con una taza de café

Un consell abans de començar: no comencis pel detall. Analitza sempre 7–14 dies complets. Entrar directament a un timepoint de 30 segons sense context és com intentar diagnosticar una malaltia mirant només una analítica solta.

Parada 1 — Health page de la Capacity Metrics App: el semàfor general

El primer que obro és la Health page. Dues vistes: Last 24 hours per veure què va passar ahir a la nit, Last 1 hour si ja hi ha algú reportant problemes.

Les cards de capçalera em diuen l’estat real sense que hagi d’interpretar res. El més important: si hi ha alguna capacitat a # Throttled capacities, # Interactive rejected o # Background rejected. Si aquests comptadors estan a zero, respiro. Si no, aquest cafè el necessitaré.

Al Capacity breakdown, la columna Health no deixa marge a l’ambigüitat:

  • Healthy → tot bé, continuo amb el cafè
  • At Risk of Throttling → el 10 min interactive ja supera el 90%, cal vigilar
  • Throttling → el fre ja està posat, algú ho notarà
  • Interactive / Background Rejection → això ja no és cafè, això és reunió

També faig un cop d’ull a Usage variance. Una variància alta amb deute acumulat és la signatura d’una capacitat que fa dies que va al límit encara que no hi hagi cap pic espectacular.

Si tot és verd, tanco la Health page i acabo el cafè tranquil·la. Si no, continuo baixant.

Tot bé, aquell dia em vaig prendre el cafè tranquil·la. Total, tenia una Trial nova. Tot bé, aquell dia em vaig prendre el cafè tranquil·la. Total, tenia una Trial nova.

Parada 2 — Compute page: l’electrocardiograma de la teva capacitat Fabric

Des de la Health page: clic dret sobre la capacitat → Drill through → Compute.

Capacity Metrics: drill through a Compute des de la pàgina de salut

Pestanya de Compute Pestanya de Compute

Tres pestanyes per ordre:

Utilization. Barres apilades vermelles (interactive) i blaves (background). La línia grisa al 100% és el límit real de l’SKU. Si hi ha columnes que el superen de manera recurrent, tinc un problema estructural, no un incident aïllat.

Clarament aquella setmana vaig muntar poques demos… Clarament aquella setmana vaig muntar poques demos…

Throttling. Em diu quant marge em queda abans que Fabric comenci a frenar:

  • Interactive delay → quan el 10 min interactive supera el 100%
  • Interactive rejection → quan el 60 min interactive supera el 100%
  • Background rejection → quan el 24h background supera el 100%

Si veig barres a interactive delay a la mateixa hora cada matí, hi ha alguna cosa que se solapa i no hauria de fer-ho. Algú va planificar refrescos en el pitjor moment possible.

Ni m’acosto a l’interactive delay; a la resta hi pot passar una bola de matolls Ni m’acosto a l’interactive delay; a la resta hi pot passar una bola de matolls

Overages → Carryforward. Si la línia vermella de Cumulative % no baixa a les hores vall, la capacitat no descansa mai. És l’indicador més silenciós i alhora més perillós.

A la part de baix, el Matrix by item and operation: ordeno per CU (s) de més gran a més petit i veig quin workspace i quin ítem se n’emporta la major part. Taronja és degradació moderada; vermell vol dir que alguna cosa ha empitjorat més d’un 25% respecte a la setmana anterior.

Matrix by item and operation ordenada per CU

💡 Truc: passa el ratolí per sobre de qualsevol fila del matrix per veure’n el desglossament per tipus d’operació. És un dels pocs llocs on pots veure aquesta granularitat sense fer drill-through.

Detall de les operacions i el seu cost Detall de les operacions i el seu cost

Parada 3 — Timepoint Detail: la sala d’interrogatoris

Clic dret sobre el pic → Drill through → Timepoint detail. Clic dret sobre el pic → Drill through → Timepoint detail.

El primer: el Heartbeat chart, una finestra de 60 minuts centrada en el timepoint. Em diu si aquell pic va ser un tret aïllat o un altiplà sostingut. Aquesta diferència canvia completament el diagnòstic.

Heartbeat chart amb el CU % respecte al límit

Després, les taules:

Si el problema és interactiu: la columna User em diu exactament qui va llançar la query, en quin workspace i sobre quin ítem. Ordeno per Timepoint CU (s) i en cinc segons sé si hi ha un usuari executant un informe pesat a primera hora, una consulta SQL sense filtre o un notebook que algú es va oblidar d’aturar abans d’anar a dinar. Si hi ha valor a Throttling (s), aquell usuari ja ho ha notat a la seva pantalla, encara que no hagi dit res encara.

I aquí surto jo revisant FUAM I aquí surto jo revisant FUAM

Si el problema és background: un pipeline solapat amb l’inici de la jornada, un refresc semàntic mal planificat, un Spark job nocturn que continua consumint en el smoothing de l’endemà. Quan l’identifico, la decisió és senzilla: el replanifiquem? L’optimitzem? L’aturem?

He anat a fer captures justament del FUAM perquè us comenci a sonar aquesta altra MERAVELLA d’eina He anat a fer captures justament del FUAM perquè us comenci a sonar aquesta altra MERAVELLA d’eina

I la columna que més m’agrada de tota l’app: Minutes to burndown. Em diu quant temps queda abans que el carryforward acumulat es dissipi. Si són més de 60 minuts amb càrrega interactiva a sobre, el throttling és gairebé segur. No com a sospita: com a dada.

Aquesta columna és molt clau Aquesta columna és molt clau

El passeig final: buscar el que ningú no et reportarà

Quan no hi ha incidents, aprofito els últims minuts del cafè per passejar-me pel matrix amb la vista de 14 dies:

  • Ítems amb Performance delta taronja o vermell de manera recurrent → fa temps que el rendiment es degrada i ningú no se n’ha adonat perquè «més o menys va»
  • Workspaces amb Overloaded minutes alts → estan pagant el preu del bursting dels altres
  • Pics que es repeteixen exactament a la mateixa hora cada dia → planificació mal dissenyada, gairebé sempre evitable

Cafè acabat. Ja saps què passa, qui ho causa i si tens marge perquè el dia continuï bé.

Dos casos que veuràs més d’una vegada

Refrescos solapats en hora punta. El símptoma: barres vermelles i blaves alhora, just a les 8:00 o a les 9:00. La causa: algú va programar els refrescos semàntics sense tenir en compte que és l’hora de més càrrega interactiva. La solució passa per esglaonar els refrescos a finestres de poc trànsit, o convertir els refrescos full en incrementals on sigui possible.

Informes amb visuals o DAX «amb esteroides». El símptoma: un únic ítem interactiu que monopolitza el consum del timepoint i apareix en vermell al Performance delta. La causa: un informe amb massa visualitzacions complexes, mesures DAX sense optimitzar o un model que força un full scan a cada interacció. La Capacity Metrics App t’assenyala el culpable; DAX Studio o l’Analitzador de rendiment et diran el perquè.

Menys throttling, més control

La Capacity Metrics App no arregla els problemes per si sola. Però fa una cosa molt més important: et diu exactament on has de mirar.

Quan la domines, deixes de reaccionar a cegues i comences a gestionar la teva capacitat amb dades, criteri i tranquil·litat. Cinc minuts al dia, una ruta clara i el cafè encara calent.

Menys microinfarts. Més control. I una capacitat Fabric que, per fi, juga al teu equip.

Enllaços d’interès

T’ha servit? Aplaudeix, sense compte. Pots fer-ho diverses vegades.

Comentaris