Il tuo lavoro quotidiano da Fabric Data Engineer non finisce quando una pipeline gira: devi sapere se è girata, quanto ha consumato e cosa succede quando la capacity si satura. Fabric offre due strumenti distinti e complementari per questo — il Monitoring hub e l’app Microsoft Fabric Capacity Metrics — ed è fondamentale non confonderli.
Monitoring hub: cosa è successo
Il Monitoring hub è la vista centralizzata, trasversale a tutti i workspace, delle run delle attività Fabric. Qui tracci in un unico posto:
- Data pipeline run e le loro singole activity;
- Dataflow Gen2 refresh;
- Notebook e Spark job, con accesso ai dettagli Spark (log, stage, executor);
- Semantic model refresh, con storico e stato.
Per ogni voce vedi status (Succeeded, Failed, In progress, Cancelled), start time, durata e submitter. Puoi filtrare per tipo di item, stato o keyword e aprire il dettaglio per leggere il messaggio di errore, rilanciare (rerun) o ispezionare i log. Il Monitoring hub risponde alla domanda “la mia run è andata a buon fine e, se no, perché?” — non ti dice nulla sui costi di capacity.
Capacity Metrics: quanto è costato
L’app Microsoft Fabric Capacity Metrics (installabile da un capacity admin) monitora il consumo di Capacity Units (CU) dello SKU F. Distingue le operazioni in due famiglie:
- Interactive: query, rendering di report, operazioni utente a bassa latenza;
- Background: dataset refresh, pipeline, Spark job, dataflow.
L’app mostra la ripple/utilization matrix per item e operazione, i timepoint critici, gli overloaded minutes e i top item per CU. È lo strumento che usi per diagnosticare un overload e decidere se ottimizzare o scalare.
Smoothing e bursting
Fabric non fa pagare il consumo istante per istante. Applica lo smoothing: distribuisce il consumo nel tempo per assorbire i picchi. Le operazioni interactive vengono smussate su una finestra breve (circa 5 minuti), le background su 24 ore. Questo evita che un singolo refresh notturno mandi in throttling la capacity.
Il bursting è il meccanismo opposto ma complementare: per completare in fretta un job pesante (es. uno Spark job), Fabric usa più CU di quelle nominali dello SKU, “prendendo in prestito” capacity futura. Il debito viene poi riassorbito dallo smoothing. Bursting = velocità immediata; smoothing = spalmatura del costo.
Le fasi di throttling
Quando il consumo futuro smoothed accumulato supera le soglie, Fabric applica un throttling progressivo, che colpisce prima le operazioni meno critiche per la percezione utente… anzi, esattamente il contrario di quello che verrebbe da pensare: colpisce prima le interactive, perché le background sono già protette dallo smoothing su 24h.
| Consumo futuro accumulato | Fase | Effetto |
|---|---|---|
| ≤ 10 minuti | Overage protection | Nessun throttling |
| 10 – 60 minuti | Interactive Delay | Le richieste interactive subiscono un ritardo (circa 20s) |
| 60 min – 24 ore | Interactive Rejection | Le richieste interactive vengono rifiutate (429); le background continuano |
| > 24 ore | Background Rejection | Anche i job background (refresh, pipeline, Spark) vengono rifiutati |
L’ordine è quindi: Interactive Delay → Interactive Rejection → Background Rejection. Le operazioni background sono le ultime a essere bloccate, e solo in caso di overload grave e prolungato.
Come rientrare
- Ridurre il carico: ottimizzare query e refresh, scaglionare i job nel tempo, evitare refresh concomitanti.
- Scalare lo SKU (es. F4 → F8 → F64) per alzare la CU baseline; oppure spostare workload su un’altra capacity.
- Per Spark, valutare l’Autoscale Billing for Spark, che scorpora i job Spark a consumo serverless e non li fa pesare sulla capacity condivisa.
- Attendere il riassorbimento del carryforward (il debito accumulato cala nel tempo con lo smoothing).
Trappole tipiche d’esame
- Utenti lamentano report lenti, ma i refresh notturni completano → la capacity è in Interactive Delay: le richieste interactive sono penalizzate per prime, le background no.
- “Quale operazione viene rifiutata per prima?” → le interactive (soglia 60 min), non le background. Il Background Rejection scatta solo oltre le 24 ore ed è l’ultima fase.
- I refresh dei semantic model iniziano a fallire con rejection → sei in overload estremo (>24h): non basta ottimizzare, serve scalare lo SKU o ridurre drasticamente il carico.
- “Quale meccanismo fa completare velocemente uno Spark job pesante?” → il bursting (usa CU extra); lo smoothing invece distribuisce il consumo su 24h.
- Stato ed errore di una singola pipeline run → Monitoring hub. Consumo CU e throttling → Capacity Metrics app. Non invertirli.