Introdução
Um guia passo a passo para te ajudar a abrir, rodar e ler o Sizing Advisor — o assessment read-only de capacidade e sizing embutido no NoSqlStudio. Siga do Passo 1 até o fim, em ordem. Cada passo diz o que fazer e o que você vai ver.
Como ler este manual
Cada passo tem:
- Faça — a ação exata (abrir um menu, clicar num botão, ler um painel).
- Veja — o que deve acontecer na tela. Esse é o seu “passou / falhou”.
- Por quê — contexto adicional, só quando ajuda (pule se estiver com pressa).
Antes de começar
Conceito
O que é o Sizing Advisor
O Sizing Advisor é um assessment read-only (somente leitura) de capacidade e sizing. Uma única varredura lê comandos administrativos (como serverStatus, dbStats, $collStats e replSetGetStatus) para montar um Snapshot, e então o transforma em um Health Score, achados (findings) priorizados, um detalhamento por database e uma recomendação de sizing de cloud com previsão de custo. Ele nunca escreve nada no seu banco.
Atenção
Seguro para rodar em produção
Como ele só lê, o assessment é seguro para rodar contra um cluster de produção ao vivo. Ele lê de um secondary quando possível, então nem aquece o cache do primary. Ele precisa de uma conexão ativa.
Você vai precisar de:
- 1Uma conexão ativa a um banco — MongoDB, Atlas, Cosmos DB for MongoDB (vCore ou RU) ou Amazon DocumentDB.
- 2Idealmente um usuário com a role clusterMonitor, para que comandos administrativos como
serverStatus/replSetGetStatusfuncionem; com um usuário mais restrito o assessment ainda roda e apenas se marca como parcial. - 3Nada para preparar no banco — o Sizing Advisor não cria coleções nem roda dados de teste.
Tempo estimado para o walkthrough completo: ~15 minutos.
Abra e rode um assessment
Abra o Sizing Advisor, rode uma única varredura read-only e chegue ao resultado.
Conecte-se a um deployment
Conecte o NoSqlStudio ao deployment que você quer avaliar — um servidor ou replica set MongoDB, um cluster Atlas, uma instância Cosmos DB for MongoDB ou um cluster Amazon DocumentDB.
A conexão abre e aparece na barra lateral. O Sizing Advisor precisa dessa conexão ativa para ler dela.
Abra o Sizing Advisor
Abra pelo menu AI & Advisors → Sizing Advisor, ou use o atalho de teclado Ctrl+Alt+Shift+I. Você também pode abrir pelo card da tela Home.
Uma nova aba abre com a tela do Sizing Advisor: um trilho à esquerda (com Alvo, Coleta, Seções e um card de Health Score) e uma área de conteúdo vazia esperando uma varredura.
O Advisor é um advisor, então ele fica em AI & Advisors, ao lado do Performance Advisor — não nas ferramentas de monitoramento ao vivo.
Confira o alvo e as opções de coleta
No trilho da esquerda, confirme que o seletor de Conexão mostra o deployment certo e olhe a engchip (chip de engine) logo abaixo (por exemplo ◆ MongoDB 8.0 · 3-node RS). Em Coleta, deixe os três checkboxes ligados: Todos os databases, Stats por coleção e Workload (opcounters).
O chip de engine reflete a engine e a topologia que o Advisor detectou. As três opções de coleta vêm marcadas por padrão.
Conceito
Desligar Stats por coleção deixa a varredura mais rápida em deployments enormes — ela passa a depender apenas dos totais por database e pula o loop de $collStats por coleção.
Rode o assessment
Clique no botão ▶ Rodar assessment no topo do trilho.
Uma barra de progresso avança enquanto a única varredura read-only coleta um Snapshot — o bloco de admin/servidor, replicação, e depois um loop pelos seus databases e coleções. Ao terminar, o resultado é renderizado: os gauges, os cards de recomendação, a tabela por database e o card de cloud.
Esse é o coração da ferramenta — uma varredura deliberada e somente-leitura produz um Snapshot imutável e com fingerprint, do qual tudo o mais é derivado. ✅
Leia o Health Score
O Health Score é o veredito de relance; entenda o número e a sua faixa (band).
Encontre o Health Score
Olhe o card de Health Score na parte de baixo do trilho da esquerda.
Um número grande de 0 a 100 com um subtítulo como 2 críticos · 3 avisos. O número é colorido: verde quando saudável, âmbar quando razoável, vermelho quando em risco ou crítico.
Leia a faixa (band)
Mapeie o score para a sua faixa.
- 85–100 — saudável: nenhuma ação urgente.
- 70–84 — razoável: alguns avisos que vale agendar.
- 50–69 — em risco: os críticos estão se acumulando.
- abaixo de 50 — crítico: aja agora.
Conceito
O score é explicável
O score é determinístico — começa em 100 e cada ponto perdido mapeia para um achado nomeado. O mesmo estado do deployment sempre produz o mesmo score, então você pode comparar execuções ao longo do tempo. As contagens de críticos e avisos no subtítulo vêm direto desses achados.
Percorra os achados
Os cards de recomendação são o coração do relatório — ordenados por impacto, cada um com uma severidade, a evidência e uma correção.
Leia os gauges do cabeçalho
Acima das recomendações, percorra a faixa de gauges.
Uma linha de gauges com números grandes em mono: Dados (lógico), Em disco (com o índice de compressão), Índices, RAM, vCPU, WT cache (usado / configurado), Janela do oplog e Conexões. O subtítulo de cada gauge é colorido — verde para ok, âmbar para aviso, vermelho para sinal crítico (por exemplo dados ≫ RAM).
Os gauges são os fatos brutos a partir dos quais os achados são construídos — tamanho lógico vs. em disco, quanto do working set cabe no cache, o histórico do oplog, o churn de conexões.
Leia um card de recomendação
Olhe a seção Recomendações. Leia o primeiro card, de cima a baixo.
Cada card tem uma barra colorida à esquerda e um chip de severidade (crítico / aviso / ok), um ícone, um título, uma frase de evidência com os números reais, e uma linha → correção com a remediação concreta. Os cards são ordenados por impacto, então o mais importante vem primeiro.
Armazenamento e disk-fill
Encontre os achados de armazenamento — por exemplo um índice de compressão baixo, ou um aviso de previsão de enchimento do disco.
Os achados de armazenamento comparam os dados lógicos ao tamanho em disco e, quando há histórico suficiente, projetam quando o disco enche. Um índice de compressão saudável (em torno de 2.3×) aparece como ok.
Working set vs. RAM
Encontre o achado de working set — ele compara os seus dados quentes com a RAM e o cache do WiredTiger.
Quando os dados são muito maiores que a RAM (por exemplo 881 GB de dados contra 31 GB de RAM), ele dispara como crítico: queries fora do conjunto quente vão a disco. A correção sugere adicionar RAM para o working set caber, arquivar coleções frias ou fazer sharding.
Conceito
O que significa “working set”
O working set é a fatia dos seus dados que é ativamente lida e escrita — a parte quente. Para boa performance ela deve caber na RAM (especificamente no cache do WiredTiger, que é cerca de metade da RAM). Você não precisa de RAM igual a todos os seus dados, só ao conjunto quente.
Saúde dos índices
Encontre os achados de indexação — índice inflado, coleções com índices demais, índices não usados ou duplicados.
Os achados de índice sinalizam um database cujo tamanho de índice é grande em relação aos dados (por exemplo 41.5 GB de índice para 87.9 GB de dados), ou uma coleção carregando índices demais. A correção te aponta para o Performance Advisor para dropar os não usados.
Postura de segurança e janela do oplog
Encontre o achado de segurança (postura de TLS / auth) e o achado da janela do oplog.
O achado de segurança sinaliza TLS fraco, auth de cluster por key-file, ou autorização desabilitada. O achado de oplog reporta a janela de replicação em horas/dias — uma janela confortável (por exemplo 7.8 dias) aparece como ok; uma janela encolhendo e se aproximando de um dia dispara um aviso.
Atenção
Algumas métricas degradam em engines gerenciados
Em Cosmos DB for MongoDB ou DocumentDB, comandos como replSetGetStatus, hostInfo ou as stats do cache do WiredTiger podem estar indisponíveis. Esses gauges mostram — em vez de um 0 falso, e as regras que precisam deles pulam com uma nota info em vez de disparar um crítico falso.
Por database e sizing de cloud
Dois painéis ficam abaixo dos cards: onde está o seu espaço, e o que provisionar na cloud.
Leia a tabela por database
Olhe o painel Dados por database.
Uma linha por database, ordenadas por tamanho: Dados, Disco, uma sizebar data · idx (ciano = dados, âmbar = índice), as contagens de Coll e Idx, e uma Flag (por exemplo grande, poucas coll, arquivável, idx NN GB, vazia ou ok). A sizebar faz os databases pesados em índice saltarem aos olhos.
Leia o card de Sizing de Cloud
Olhe o card Sizing de Cloud ao lado da tabela.
Um tier recomendado (por exemplo M60), seu spec (RAM · vCPU · disco), um custo mensal estimado, e um detalhamento: dados em disco, + headroom, RAM (working set), crescimento e atinge 80% do disco em ~N meses. Abaixo, alternativas (um tier mais barato ou uma opção com sharding) com seus trade-offs.
O Advisor mapeia os seus requisitos para tiers de Atlas, Cosmos vCore e VM genérica, escolhendo o mais barato que cabe na sua RAM, vCPU, disco e IOPS — para você nem sub nem super-provisionar.
Sobre os preços
Atenção
Preços de referência, não uma cotação
Os valores de custo vêm de uma tabela de preços de referência datada e versionada (on-demand, de lista, single-region). Eles servem de guia para right-sizing — sempre confirme na calculadora do próprio provedor antes de fechar, já que os preços variam por região e contrato.
Exportação e auditoria
Transforme o assessment em um artefato compartilhável e ancore-o à sua trilha de auditoria.
Exporte o relatório
Na parte de baixo, use a barra de exportação. Clique em Relatório PDF, HTML imprimível ou JSON (snapshot bruto).
PDF e HTML produzem o relatório blueprint completo — stats de capa, achados, host & memória, por database, carga & replicação, config & segurança, e sizing de cloud. JSON salva o snapshot bruto e determinístico, que você pode reimportar depois para comparar ao longo do tempo.
Anexe à auditoria
Clique em Anexar à auditoria.
O hash sha256 do relatório é registrado na timeline de auditoria local (e, quando licenciado, ancorado à cadeia imutável do backend). Um toast confirma com o hash curto.
Conceito
O fingerprint sha256 estável do snapshot é a chave de âncora, então reanexar o mesmo snapshot é idempotente e as entradas de auditoria do mesmo deployment se alinham ao longo do tempo.
Snapshots e crescimento ao longo do tempo
Cada execução é salva; re-rode depois para ver como o deployment cresceu.
Encontre os seus snapshots salvos
Abra a lista de Snapshots salvos (cada assessment que você roda fica guardado aqui, criptografado em repouso com o seu fingerprint sha256).
Uma lista de snapshots passados, cada um com o seu timestamp, label e Health Score. Você pode abrir qualquer um do passado para revisá-lo exatamente como foi capturado.
Re-rode e compare ao longo do tempo
Rode o assessment de novo mais tarde (um dia ou mais depois do primeiro), e então compare o novo snapshot com um anterior.
Um diff temporal mostra os deltas por database e por métrica — por exemplo cresceu X% em 30 dias — e o card de cloud agora projeta um ETA datado de enchimento do disco a partir da tendência.
Atenção
Crescimento precisa de pelo menos 2 snapshots
Com um único snapshot não há tendência para traçar, então o card de cloud mostra “colete ≥ 2 snapshots para uma projeção de crescimento.” A previsão ganha um ETA datado assim que você tem dois snapshots com pelo menos um dia de diferença, e fica mais confiante com quatro ou mais.
Limpeza (quando terminar)
Conceito
Não há nada para desfazer no banco
O Sizing Advisor é read-only — ele não escreveu nada no seu banco, então não há nada para dropar ou reverter. A única coisa para gerenciar são os snapshots salvos localmente.
Se quiser, abra a lista de Snapshots salvos e apague quaisquer snapshots antigos que você não precise mais.
Os snapshots selecionados são removidos do armazenamento local. O deployment em si fica intocado.
Resumo do que você validou
| Etapa | Recurso |
|---|---|
| 1 | Abrir o Sizing Advisor e rodar um assessment read-only |
| 2 | Ler o Health Score (0–100) e a sua faixa |
| 3 | Percorrer os achados: armazenamento, working set vs. RAM, índices, segurança, oplog |
| 4 | Ler a tabela por database e a recomendação de sizing de cloud |
| 5 | Exportar o relatório (PDF / HTML / JSON) e anexá-lo à auditoria |
| 6 | Salvar snapshots e comparar o crescimento ao longo do tempo |