Fabric Capacity Metrics: como monitorar o consumo

A fatura do Fabric só assusta quem não olha o consumo#

O roteiro se repete em quase todo cliente que assumimos com o Fabric já rodando. A capacidade foi contratada no olho, alguém publicou relatórios, ligou pipelines, agendou atualizações, e depois de alguns meses aparece uma reclamação de lentidão ou um susto no custo. A pergunta que ninguém consegue responder é simples: para onde está indo a capacidade que pagamos? A boa notícia é que existe uma resposta objetiva, e ela mora no Fabric Capacity Metrics, o aplicativo oficial da Microsoft que mostra, operação por operação e item por item, quanto da sua capacidade está sendo consumido em Capacity Units.

Neste artigo eu vou direto ao que importa em campo: como instalar e ler o app, como funciona o smoothing que distribui o consumo no tempo, o que é o throttling que aparece quando você estoura de forma sustentada, como caçar as operações que mais pesam e, com tudo isso na mesa, como dimensionar o SKU F correto sem pagar por capacidade ociosa nem sofrer com fila. Sem promessa de economia mágica. Monitorar consumo é disciplina, não sorte.

O Fabric Capacity Metrics é o painel oficial de consumo em Capacity Units#

O Fabric Capacity Metrics é um app gratuito publicado pela Microsoft, instalado a partir do AppSource dentro do serviço do Power BI, e conectado à sua capacidade por um administrador de capacidade. Depois de instalado, ele lê a telemetria da própria plataforma e monta um relatório que você abre como qualquer outro conteúdo do Fabric. Não é um script caseiro nem uma planilha, é a fonte de verdade que a Microsoft usa para explicar cobrança e throttling.

O que ele entrega, na prática, é a leitura do consumo em Capacity Units, a unidade de capacidade que o Fabric gasta ao executar qualquer trabalho: atualizar um modelo semântico, rodar um pipeline, processar um notebook Spark, responder uma consulta de relatório. Toda capacidade contratada tem um teto de CUs por segundo, definido pelo SKU. O app mostra o quanto desse teto você está usando ao longo do tempo, quais itens consomem mais e quando a capacidade passou a operar sob restrição.

Duas telas concentram o uso diário. A primeira é uma linha do tempo do consumo da capacidade, onde você vê picos, vales e os momentos em que a utilização passou de 100 por cento. A segunda é a tabela de detalhamento por item e por operação, o famoso ripple ou matriz de operações, que lista cada execução, o item que a originou e quantas CUs ela custou. É clicando dessa visão macro para o detalhe que se descobre o verdadeiro dono do consumo, e quase nunca é quem o time imagina.

Smoothing distribui o consumo no tempo, e isso muda a leitura#

Aqui está o conceito que mais confunde quem abre o app pela primeira vez. O Fabric não cobra o pico bruto de cada operação no instante em que ela roda. Ele aplica smoothing, ou suavização, distribuindo o consumo de uma operação ao longo de uma janela de tempo. Uma atualização pesada que na vida real durou poucos minutos aparece amortecida, espalhada em uma janela posterior, para evitar que um único pico derrube a capacidade inteira.

O efeito prático é duplo. Por um lado, o smoothing protege o ambiente: um pico isolado não causa throttling imediato, porque a plataforma dilui aquele consumo. Por outro lado, ele engana a intuição. Você olha o gráfico, vê a capacidade alta em um horário no qual ninguém está trabalhando, e estranha. Não há fantasma. É o smoothing empurrando para frente o custo de operações que aconteceram antes. Ler o Capacity Metrics sem entender isso leva a conclusões erradas, como culpar o horário em vez da operação.

A regra mental que ensino ao time do cliente é esta: o smoothing decide quando o consumo pesa no seu teto, não quanto ele custa no total. O trabalho executado é o mesmo, o que muda é a diagramação dele no tempo. Operações interativas, como abrir um relatório, são suavizadas em uma janela curta. Operações em segundo plano, como atualizações agendadas e pipelines, são suavizadas em uma janela bem mais longa. É por isso que background jobs raramente derrubam a capacidade sozinhos, mas somados criam um platô constante de consumo que ninguém percebe.

Throttling é o que acontece quando o estouro vira dívida#

Enquanto o consumo suavizado couber no teto do SKU, você não sente nada. O problema começa quando o uso passa a exceder a capacidade de forma sustentada. Nesse ponto o Fabric acumula uma espécie de dívida de capacidade, e para cobrá-la aplica throttling, que é o atraso ou a recusa de novas operações até o consumo voltar ao normal. O Capacity Metrics tem uma aba dedicada a isso, mostrando quando a capacidade entrou em cada estágio de restrição.

O throttling não é um liga-desliga. Ele funciona em estágios progressivos, que ficam mais severos conforme a dívida cresce. A tabela abaixo resume a lógica que a Microsoft aplica, do mais brando ao mais duro:

Estágio	O que acontece	Quem sente primeiro
Overage protegido pelo smoothing	Consumo passou do teto, mas ainda é diluído sem punir o usuário	Ninguém percebe
Interactive delay	Operações interativas passam a responder com atraso	Quem abre e navega em relatórios
Interactive rejection	Novas operações interativas são recusadas na hora	Usuários de relatório e consulta
Background rejection	Operações em segundo plano são recusadas	Atualizações agendadas e pipelines

A leitura correta dessa aba muda a conversa. Se o que estoura são operações interativas, o problema é uso de relatório em horário de pico, e a resposta pode ser modelagem, cache ou escalonamento. Se o que estoura são background jobs, o problema é a janela de atualizações e pipelines competindo pela mesma capacidade, e a resposta costuma ser reorganizar horários antes de gastar mais dinheiro. Comprar SKU maior sem saber qual estágio dói é apagar incêndio com dinheiro.

Identificar as operações caras é onde o dinheiro aparece#

O maior valor do Fabric Capacity Metrics não é o gráfico bonito de utilização, é a tabela de operações. Ela ordena, do mais caro ao mais barato, cada execução por CUs consumidas, com o item de origem ao lado. Ordenar essa lista por consumo total quase sempre revela que uma minoria de itens responde pela maior parte da conta. É o velho princípio do poucos vitais, e ele vale aqui como em qualquer diagnóstico de custo.

Na sustentação de ambientes Fabric, os suspeitos que mais aparecem no topo da lista se repetem. Vale conhecê-los antes de abrir o app, porque assim você sabe o que caçar:

Operação cara	Por que consome tanto	Primeira alavanca
Atualização completa de modelo grande	Reprocessa tudo mesmo quando poucos dados mudaram	Atualização incremental
Consultas DirectQuery pesadas	Cada interação vai ao banco de origem	Modelagem, agregações, Import onde couber
Notebooks Spark superdimensionados	Cluster grande para volume pequeno	Ajustar pool e particionamento
Dataflows Gen2 redundantes	Mesma transformação repetida em vários fluxos	Consolidar e reusar camadas
Pipelines em horário de pico	Competem com uso interativo pela capacidade	Reagendar para janelas ociosas

O padrão que mais economiza é banal: encontrar duas ou três atualizações completas de modelos grandes que poderiam ser incrementais. Trocar full refresh por incremental em um punhado de tabelas volumosas costuma aliviar a capacidade mais do que qualquer aumento de SKU, e sem custo mensal adicional. Esse tipo de correção é, no fundo, trabalho de engenharia de dados aplicado sobre o que o monitoramento revelou. O app diz onde dói, a engenharia resolve.

Dimensionar o SKU certo é decisão de dados, não de medo#

Com o consumo real na mão, o dimensionamento deixa de ser chute. Os SKUs de capacidade Fabric vão de F2 a F2048, identificados pelo número de Capacity Units que entregam, e você pode escalar para cima ou para baixo conforme a pressão observada. O erro mais comum que vejo é o oposto do que se imagina: não é gente economizando demais, é gente que provisionou uma capacidade grande por garantia no primeiro dia e nunca revisitou, pagando mês cheio por CUs que não usa.

O caminho honesto tem uma ordem. Primeiro, otimize as operações caras que o Capacity Metrics apontou, porque muita gente descobre que nem precisava de mais SKU, precisava de menos desperdício. Segundo, olhe a utilização sustentada, não os picos isolados que o smoothing já absorve. Se a capacidade vive em platô alto e o throttling é frequente mesmo depois de otimizar, aí sim subir de SKU se justifica. Terceiro, lembre que dá para pausar ou reduzir capacidade em períodos de baixa, tratando o SKU como decisão dinâmica e não como número gravado em pedra.

Vale um alerta sobre um degrau específico. Alguns recursos, como o Copilot, exigem um piso de capacidade definido pela Microsoft, então o SKU nem sempre é escolhido só pelo consumo bruto, mas também pelos recursos que o negócio precisa liberar. Se a discussão de qual modelo de licenciamento e qual faixa de capacidade faz sentido para o seu caso ainda está aberta, ela merece uma análise própria, que aprofundamos em Microsoft Fabric: o que é e vale a pena em 2026. O ponto aqui é anterior: sem os números do Capacity Metrics, qualquer escolha de SKU é aposta.

Como montamos uma rotina de monitoramento que evita surpresa#

Instalar o app e olhar uma vez não muda nada. O que evita surpresa na fatura é transformar isso em rotina. Nos ambientes que sustentamos, a cadência é enxuta e funciona assim:

• Semanal: abrir a linha do tempo de utilização, identificar novos platôs de consumo e confirmar se algum item entrou no topo da lista de operações.
• A cada evento de throttling: investigar a aba de throttling no mesmo dia, classificar se o estouro foi interativo ou de background e agir na causa certa.
• Mensal: revisar se o SKU contratado ainda bate com o consumo sustentado, decidindo por manter, subir, reduzir ou pausar em janelas ociosas.
• A cada novo item publicado: verificar o custo em CUs da primeira execução, para pegar um modelo mal modelado ou um pipeline pesado antes que ele vire hábito caro.

Essa disciplina é barata e paga sozinha. Ela transforma o Fabric de caixa-preta em algo previsível, no qual o custo é consequência de decisões visíveis e não de um número que aparece no fim do mês. Quando o cliente não tem fôlego interno para manter esse ritmo, é exatamente esse tipo de acompanhamento contínuo que entra no escopo de sustentação de BI, junto com a correção das operações que o monitoramento vai apontando. Se o Fabric é parte de uma estratégia maior de dados na empresa, também vale ver como ele se conecta ao restante no guia completo de Power BI para empresas no Brasil em 2026.

Perguntas frequentes#

O Fabric Capacity Metrics é pago?

Não. O app é distribuído gratuitamente pela Microsoft no AppSource. O que você paga é a capacidade Fabric em si, contratada pelo SKU F. O monitoramento em cima dela não tem custo de licença adicional, apenas o pequeno consumo do próprio relatório do app, que é irrelevante frente ao que ele ajuda a economizar.

Qual a diferença entre smoothing e throttling?

São coisas complementares. Smoothing é a suavização preventiva, que distribui o consumo de uma operação ao longo de uma janela de tempo para evitar que picos isolados derrubem a capacidade. Throttling é a punição corretiva, que atrasa ou recusa operações quando o consumo excede o teto de forma sustentada, depois que o smoothing já não dá conta de absorver a diferença.

Consigo saber exatamente qual relatório ou usuário está consumindo mais?

Sim, no nível de item e operação. A tabela de detalhamento mostra cada execução com o item de origem, então você identifica qual modelo, relatório, pipeline ou notebook custou mais CUs. O app é orientado a operações e itens, e essa granularidade é suficiente para agir na causa, mesmo quando não expõe o usuário individual em toda operação.

Estourei a capacidade uma vez, já vou sofrer throttling?

Não necessariamente. Um pico isolado costuma ser absorvido pelo smoothing sem punir ninguém. O throttling entra quando o excesso é sustentado e a dívida de capacidade se acumula. Por isso a leitura correta olha a utilização ao longo do tempo, e não um único momento acima de 100 por cento no gráfico.

Devo aumentar o SKU assim que aparecer throttling?

Quase nunca essa é a primeira ação. Antes de gastar mais, use o app para achar as operações caras e otimizá-las, porque boa parte dos estouros some depois de trocar atualizações completas por incrementais e reorganizar horários de pipeline. Só suba de SKU quando a capacidade seguir sob pressão sustentada mesmo após a otimização.

Preciso ser administrador para usar o app?

Para instalar e conectar o Capacity Metrics à capacidade, sim, é necessário perfil de administrador de capacidade Fabric. Depois de configurado, o relatório pode ser compartilhado com quem precisa acompanhar o consumo, respeitando as permissões definidas. Na prática, quem toma decisão de custo e quem faz a sustentação técnica devem ter acesso à leitura.

Antes de mexer no SKU, olhe o consumo#

Dimensionar capacidade sem dados é o jeito mais caro de operar o Fabric. O Capacity Metrics existe justamente para tirar a decisão do campo do achismo: ele mostra o consumo em CUs, explica o smoothing, sinaliza o throttling e aponta as operações que pesam. O resto é disciplina de monitorar e a engenharia de corrigir o que aparece. Se você quer instalar, ler o app com método e transformar isso numa rotina que evita surpresa na fatura, fale com a gente e a gente estrutura esse acompanhamento com você.