Manual do DBA — Cosmos Optimizer passo a passo

§2 Walkthroughs por pane

Uma seção por pane. Cada uma tem: screenshot (quando disponível), o que mostra, teste passo a passo, resultado esperado em um cluster de produção movimentado, e notas de troubleshooting para problemas comuns.

Vista ao vivo de RU/s consumido pela sua conta Cosmos vs o budget que você definiu. Forecast Holt-Winters de 24h. Card de Recommendation comparando manual / autoscale / serverless / reserved.

Passos do teste

1. Defina RU/s budget para o throughput provisionado da sua conta (ex.: 5000 para um provisioning de 5k RU/s a nível de database).
2. Clique em Refresh.
3. Observe Consumed (avg): deve ser diferente de zero em um cluster ativo. Compare com o valor que você vê no Azure Portal em Metrics → NormalizedRUConsumption.
4. Verifique a cor do badge Utilisation: verde = abaixo de 65%, amarelo = 65-85%, vermelho = acima de 85%. Vermelho significa consideração urgente de scale-up.
5. Leia o card de Recommendation. Saídas comuns: RESERVED-3Y para workloads steady, AUTOSCALE para os spiky, SERVERLESS para bursts de baixo volume.
6. Role até Per collection (preview). Com apenas Azure Monitor, você vê uma única linha de instância agregando tudo — per namespace requer Log Analytics (PAID tier).

Captura o response header x-ms-request-charge de cada query que você roda pelo NoSqlStudio. Zero chamadas à Azure API — instrumentação puramente client-side, sempre disponível.

Passos do teste

1. Abra uma tab Shell ou Query contra a collection Cosmos.
2. Rode uma query pesada, ex.: db.Deals.find({ status: 'closed' }).limit(100) ou db.Deals.aggregate([{$match:{}}, {$group:{_id:'$status', n:{$sum:1}}}]).
3. Volte ao tab Query Cost. Top query shapes deve popular com o shape, RU total, RU médio, p95, max, e count.
4. Rode o mesmo shape 5+ vezes para popular o count e p95 corretamente.
5. Use o input de filter no topo-direito para restringir a ns ou substring de shape.

Probe ativo que agrupa documentos pela sua partition key e ranqueia as partitions resultantes por doc count. Pega skew (uma partition tendo 40%+ dos docs) antes que vire tempestade de throttle 429.

Passos do teste

1. Preencha Namespace: formato db.coll, ex.: catalog.products.
2. Preencha Partition key path: o nome do campo que você usou como shardKey ao criar a collection, ex.: tenantId.
3. Clique em Scan. Isso roda uma aggregation $group no Cosmos — custa RU proporcional ao tamanho da collection. Em uma collection de 200 GB espere 100-500 RU.
4. Leia o badge spread no top-right: verde = distribuição uniforme, amarelo = moderate skew, vermelho = severe skew (top partition > 40% dos docs).
5. Use o heatmap para spotar partitions hot específicas. Hover em qualquer célula para o key value exato + doc count.

Cosmos indexa todas as propriedades por default — cada write custa 1 RU por propriedade indexada. Excluir paths nunca queryados pode cortar consumo de write RU em 30-70% em collections document-heavy.

Passos do teste

1. Preencha Namespace, ex.: catalog.products.
2. Clique em Sample schema. NoSqlStudio lê 100 docs e constrói uma árvore de todos os field paths.
3. Desmarque qualquer field que NUNCA aparece em uma cláusula WHERE / filter — pense em imageBase64, fullText, metadata.audit.*, etc.
4. Clique em Save draft. JSON preview atualiza com a indexingPolicy proposta.
5. Copie o JSON, aplique via shell: db.runCommand({collMod: 'products', indexingPolicy: <paste>}).

Classifica seu workload (STEADY / SPIKY / CYCLIC / RAMP) dos últimos 15 min de métricas, depois simula bill mensal nos 5 modes de cobrança Cosmos lado-a-lado. Quote de Reserved Capacity na base.

Passos do teste

1. Clique em Refresh no topo-direito.
2. Leia o card Workload classification. Saídas comuns: STEADY (low variance, CV < 0.4), SPIKY (CV > 0.8, recomenda autoscale), CYCLIC (peaks diários previsíveis, recomenda reserved com scheduled scale).
3. Compare os 5 cards Monthly bill. O mais barato com badge RECOMMENDED é a escolha do algoritmo.
4. Procure o banner vermelho THROTTLED no card manual: indica que seu p95 atual excede o tier simulado e causaria 429s.
5. Role até Reserved capacity quote: número concreto de RU/s para se comprometer + economia mensal vs manual.

Conta respostas 429 (rate-limited) na janela recente via Azure Monitor, depois correlaciona cada burst com queries capturadas no ring buffer do Query Cost. Surface a query shape com maior RU cumulativo durante a janela de 429 — o provável culpado.

Passos do teste

1. Clique em Refresh. Leia Total 429s, 429 events, e Peak / interval.
2. Defina o input Window ± minutos (default 5). Diminua para correlation mais apertada, aumente se nenhuma query caiu na janela.
3. Role até Suspect queries. Cada linha = um burst de 429 com a query shape mais cara que rodou ± window minutos do burst, com um confidence score (0-1).
4. Se vazio: abra o tab Query Cost Inspector e rode tráfego. Sem captures de query, o RCA não tem nada para correlacionar.

10 queries Kusto prontas contra os Cosmos Diagnostic Logs no seu workspace Log Analytics. Requer o tier PAID (Diagnostic Settings ativado, workspace ID do Log Analytics configurado).

Passos do teste

1. Verifique se o banner AZURE MONITOR mostra upgrade available: Log Analytics. Se você não plugou o workspace ID, este pane mostra NO SOURCE e o botão Run in app fica disabled.
2. Clique em qualquer card de template (ex.: Slow queries — last 1 hour) para carregar seu KQL no editor.
3. Clique em Edit para ajustar o KQL inline (ex.: mude ago(1h) para ago(24h)).
4. Clique em Run in app. Tabela de resultados renderiza embaixo em 2-5 segundos.
5. Para análise long-form, clique em Open in portal para deep-link da query no editor KQL do Azure Portal.

Observa o ring buffer do Query Cost, identifica query shapes que tocam 2+ campos sem um composite index correspondente, projeta ~60% de economia de RU, emite o JSON snippet para colar na indexingPolicy do Cosmos.

Passos do teste

1. Defina Min queries to consider = 5 (default). Threshold para considerar uma shape valer a recomendação.
2. Rode queries representativas pelo NoSqlStudio por ~5 minutos. Exemplos de filter multi-campo: {tenantId: X, status: Y}, {userId: A, createdAt: {$gte: ...}}.
3. Volte aqui. A lista Recommendations enche com shape + RU saving projetado + JSON snippet.
4. Clique Copy JSON em qualquer recomendação, cole na indexingPolicy da sua collection Cosmos via collMod.

Wizard de disaster-recovery. Escolhe um ponto na janela continuous-backup do Cosmos (7 ou 30 dias dependendo da política configurada), gera o comando CLI az cosmosdb restore, opcionalmente o executa via host shell.

Passos do teste

1. Preencha Account (o nome da conta Cosmos).
2. Defina o Restore timestamp via slider ou input ISO-8601. Default: agora menos 1 hora.
3. Preencha Target account name (deve ser novo — não pode sobrescrever o source) e Region.
4. Clique em Validate plan. NoSqlStudio roda az cosmosdb show-backup-information para confirmar que um backup existe naquele timestamp. Retorna check verde ou erro vermelho.
5. Clique em Run via host shell (az-cli) quando estiver pronto. Restore demora 30-90 minutos para collections típicas.

Assistente de migração bidirecional. Escolhe source + target (Atlas → Cosmos ou Cosmos → Atlas), mostra translation matrix (features que se tornam unsupported), projeta bill mensal no destino, gera o script mongosh.

Passos do teste

1. Escolha Source e Target: Atlas → Cosmos ou vice-versa.
2. Leia o Translation matrix: features que não sobrevivem à mudança (ex.: Atlas Search → Cosmos: funciona via engines multi-DB locais do NoSqlStudio, não nativamente; Cosmos PITR → Atlas: substituído por snapshots de cluster Atlas).
3. Verifique Bill projection: custo mensal estimado no target baseado no seu workload atual.
4. Clique em Generate script. Saída é um script mongosh com batches insertMany e reporting de progress.
5. Para migração real, faça dry-run em uma collection de teste primeiro (Cosmos cobra write RU por inserts durante a migração!).

O painel de controle de quais fontes de dados alimentam cada outro pane. Três tiers: TIER C local (sempre on), TIER B Azure Monitor (FREE), TIER A Log Analytics (PAID).

Passos do teste

1. Confirme que o card TIER B mostra badge CONFIGURED se você salvou as credenciais.
2. Fields sensíveis (Resource ID, Tenant ID, Client ID, Client Secret, Workspace ID) aparecem mascarados como •••••••XXXX com um botão Edit. Clique em Edit para revelar + alterar, depois Mask para esconder novamente.
3. Após Save: banner de source-mode em cada pane de métricas vira AZURE MONITOR em < 100 ms (via evento interno), ou até 15 s (via poll fallback).
4. Botão Clear (vermelho) limpa credenciais para esta conexão do disco + remove a bridge — tudo reverte para NO SOURCE / Local samples.