O app não é um dashboard para ficar olhando. É um instrumento de investigação, e ele só funciona se você seguir a ordem: sintoma → timepoint → operação → decisão.
O Microsoft Fabric Capacity Metrics App responde muito bem a três perguntas: a capacidade passou de 100% em algum momento?, qual operação consumiu mais CU naquele instante? e estou pagando dívida de consumo passado?. Ele responde mal a duas outras: como estava mês passado? e quero ser avisado antes de acontecer — porque o histórico é curto e não existe alerta nativo.
Quatro passos, sempre nesta sequência. Pular etapa é como pular a anamnese: você trata o sintoma errado.
O gráfico de utilização mostra consumo suavizado, em timepoints de 30 segundos. A barra das 9h não é o que aconteceu às 9h — é o que aconteceu às 9h mais a parcela distribuída de tudo que rodou nas 24 horas anteriores. É por isso que a linha sobe sem ninguém ter feito nada.
Essas três métricas contam a história da dívida. Add é o excedente que entrou naquele timepoint. Burndown é o quanto foi amortizado. Cumulative é o saldo. A leitura é simples e implacável:
| Cumulative ao longo das horas | Interpretação | Ação |
|---|---|---|
| Sobe e volta a zero no mesmo dia | Pico isolado — o bursting fez o trabalho | Nenhuma; anote o evento |
| Sobe de manhã, cai de tarde, repete | Rotina apertada demais para a SKU | Redistribuir janelas de refresh |
| Nunca volta a zero | Dívida estrutural — throttling é questão de dias | Cortar consumo ou escalar, com número na mão |
Clique no timepoint e você recebe duas tabelas: operações interativas e operações background que contribuem para aquele instante. Ordene por CU(s) e olhe as cinco primeiras linhas. Na prática, uma delas responde por 40% a 70% do problema — e quase sempre é um refresh, um Dataflow Gen2 ou um notebook.
Porque os gráficos de throttling olham consumo futuro projetado, e a utilização do timepoint olha o presente suavizado. São janelas diferentes da mesma conta.
Para ver todas as capacidades, sim. Sem esse papel, você depende de alguém exportar a visão para você — um dos motivos pelos quais times maiores acabam construindo o próprio painel.
Dá: os dados de consumo podem ser lidos e persistidos fora do app, e a partir daí você monta tendência, rateio e alerta. É exatamente o que o FabricBoard faz.
A mesma leitura deste artigo, feita sozinha todo dia: timepoint crítico identificado, item responsável nomeado, alerta enviado antes do usuário abrir o relatório.
Smoothing, bursting e os três estágios de rejeição, com a tabela de limites.
Capacidade & CU Comparativo F2 x F4 x F8Quanto cada SKU entrega por dia e onde cada uma quebra na prática.
Por que o staging dobra a escrita e como decidir quando ele é necessário.
Conteúdo técnico sobre Microsoft Fabric e Power BI para quem opera essas plataformas todo dia. Artigos novos toda semana.
Criado e mantido pela PRS Tecnologia para contribuir com a comunidade técnica de dados. Site independente, sem vínculo com a Microsoft e não oficial: não representa posições da empresa. Microsoft, Microsoft Fabric e Power BI são marcas de seus respectivos proprietários. · © 2026 · fabricmetrics.com.br
powerbiembed.com.brfabricboard.com.br