Ferramenta aberta

Fabric Capacity Radar

Assessment de capacidade e throttling do Microsoft Fabric: houve throttle, por causa de qual item, e o que fazer a respeito.

O que o Fabric Capacity Radar responde

O app nativo Capacity Metrics do Microsoft Fabric responde "quanto" você consumiu. O Fabric Capacity Radar responde a pergunta que sobra: houve throttle, por causa de qual item, e o que fazer a respeito. Entre um pico isolado e um problema crônico há uma decisão de dinheiro — e é ela que a ferramenta ajuda a tomar.

Por que capacidade, e não "custo"

O Fabric cobra por capacidade de preço fixo (F-SKU), com smoothing e throttling. Multiplicar CU por preço dá um número que não existe na sua fatura — a fatura é a reserva fixa. Por isso este não é um "FinOps de consumo". A pergunta certa é de capacidade: você está sendo throttled? Tem folga? Qual item queima CU? Deve redimensionar o F-SKU?

O que o Radar entrega

Reproduzir os gráficos do Capacity Metrics App seria trabalho perdido — ele já faz isso, de graça e melhor. O valor está na leitura sênior que o app não conclui, sobre uma fundação estável e ancorada em eventos.

Atribuição causal do throttle — no momento de cada evento, qual item queimou CU, ranqueado pela parcela suavizada que de fato aterrissou ali, não pela hora de início (que confunde causa com vítima).

Utilização e overage do timepoint — estimados sobre todos os itens da janela de 30 segundos, com a fórmula validada contra a documentação. Um alerta honesto acompanha: utilização acima de 100% num timepoint não é o mesmo que throttle.

Diagnóstico por tipo de throttle — lido de System events, a verdade-fundamento: atraso interativo (leve) contra rejeição interativa ou de background (grave). E três estados, não dois: quando o modelo não pôde ser lido, o resultado é inconclusivo, nunca um falso "não há throttle".

Recomendação de F-SKU com gate de cronicidade — rejeição crônica (dois ou mais dias distintos) sugere considerar upsize, mas só depois da escada de remédios: rebalancear, load-balance, pause/resume, e só então subir o SKU. Rejeição isolada manda investigar, não "dobrar a fatura".

Limites declarados

O que torna a ferramenta crível para um público sênior é dizer onde ela para:

Medir "quanta folga tenho" e sugerir downsize exige a utilização média da janela, não só nos momentos de throttle. É a próxima frente, e sem esse dado o Radar não afirma folga nem sugere diminuir o SKU.

Não há promessa de paridade numérica com as medidas versionadas do app.

O modelo semântico do app é não suportado para consumo externo e muda entre versões — por isso o Radar descobre e valida os nomes em runtime, com fallback claro, em vez de assumir.

A interpretação é Python puro e testada, incluindo o caminho de dado ausente: ausência de leitura nunca vira uma recomendação confiante.

Como funciona

Roda num notebook do Microsoft Fabric via SemPy. A descoberta do modelo usa a REST pura; a leitura de schema e dados passa pelo endpoint XMLA, o que exige o XMLA read-only habilitado na capacidade (leitura basta). As requisições vão como baixa prioridade, para não agravar a capacidade que estão medindo.

Do diagnóstico à ação

O Radar aponta o problema e o caminho. Redimensionar, rebalancear refreshes e reprojetar a capacidade é o passo seguinte — o trabalho de engenharia que a mldata faz. O código é aberto, sob Apache 2.0, e está no repositório abaixo.

Ver no GitHub ↗

Código aberto sob Apache 2.0. Implementar e validar no seu ambiente é o trabalho da mldata.