Ir al contenido
Documentación

Manual de prueba — NoSqlStudio Sizing Advisor

Una guía paso a paso para abrir, ejecutar y leer un assessment de solo lectura de capacidad y sizing de tu deployment.

Tiempo estimado: ~15 minutos
En este manual

Introducción

Una guía paso a paso para ayudarte a abrir, ejecutar y leer el Sizing Advisor — el assessment de solo lectura de capacidad y sizing integrado en NoSqlStudio. Sigue del Paso 1 hasta el final, en orden. Cada paso te dice qué hacer y qué vas a ver.

Cómo leer este manual

Cada paso tiene:

  • Haz — la acción exacta (abrir un menú, hacer clic en un botón, leer un panel).
  • Mira — qué debe ocurrir en pantalla. Este es tu “pasa / falla”.
  • Por qué — contexto adicional, solo cuando ayuda (sáltalo si vas con prisa).

Antes de empezar

Concepto

Qué es el Sizing Advisor

El Sizing Advisor es un assessment de solo lectura (read-only) de capacidad y sizing. Un único barrido lee comandos administrativos (como serverStatus, dbStats, $collStats y replSetGetStatus) para armar un Snapshot, y luego lo convierte en un Health Score, hallazgos (findings) priorizados, un desglose por base de datos y una recomendación de sizing de cloud con una previsión de costo. Nunca escribe nada en tu base de datos.

Atención

Seguro para ejecutar en producción

Como solo lee, el assessment es seguro para ejecutar contra un clúster de producción en vivo. Lee de un secondary cuando puede, así que ni siquiera calienta la caché del primary. Necesita una conexión activa.

Vas a necesitar:

  1. 1Una conexión activa a una base de datos — MongoDB, Atlas, Cosmos DB for MongoDB (vCore o RU) o Amazon DocumentDB.
  2. 2Idealmente un usuario con el rol clusterMonitor, para que comandos administrativos como serverStatus/replSetGetStatus funcionen; con un usuario más restringido el assessment igual se ejecuta y solo se marca como parcial.
  3. 3Nada que preparar en la base — el Sizing Advisor no crea colecciones ni ejecuta datos de prueba.

Tiempo estimado para el recorrido completo: ~15 minutos.

Etapa 1

Abre y ejecuta un assessment

Abre el Sizing Advisor, ejecuta un único barrido de solo lectura y llega al resultado.

Paso 1

Conéctate a un deployment

Haz

Conecta NoSqlStudio al deployment que quieres evaluar — un servidor o replica set MongoDB, un clúster Atlas, una instancia Cosmos DB for MongoDB o un clúster Amazon DocumentDB.

Mira

La conexión se abre y aparece en la barra lateral. El Sizing Advisor necesita esta conexión activa para leer de ella.

Paso 2

Abre el Sizing Advisor

Haz

Ábrelo desde el menú AI & Advisors → Sizing Advisor, o usa el atajo de teclado Ctrl+Alt+Shift+I. También puedes abrirlo desde la tarjeta de la pantalla Home.

Mira

Se abre una nueva pestaña con la pantalla del Sizing Advisor: un riel a la izquierda (con Objetivo, Recolección, Secciones y una tarjeta de Health Score) y un área de contenido vacía esperando un barrido.

Por qué

El Advisor es un advisor, así que vive en AI & Advisors, junto al Performance Advisor — no en las herramientas de monitoreo en vivo.

Paso 3

Revisa el objetivo y las opciones de recolección

Haz

En el riel izquierdo, confirma que el selector de Conexión muestra el deployment correcto y mira la engchip (chip de engine) justo debajo (por ejemplo ◆ MongoDB 8.0 · 3-node RS). En Recolección, deja los tres checkboxes activos: Todas las bases de datos, Stats por colección y Workload (opcounters).

Mira

El chip de engine refleja el engine y la topología que el Advisor detectó. Las tres opciones de recolección vienen marcadas por defecto.

Concepto

Desactivar Stats por colección hace el barrido más rápido en deployments enormes — pasa a depender solo de los totales por base de datos y se salta el bucle de $collStats por colección.

Paso 4

Ejecuta el assessment

Haz

Haz clic en el botón ▶ Ejecutar assessment en la parte superior del riel.

Mira

Una barra de progreso avanza mientras el único barrido de solo lectura recolecta un Snapshot — el bloque de admin/servidor, replicación, y luego un bucle por tus bases de datos y colecciones. Al terminar, el resultado se renderiza: los gauges, las tarjetas de recomendación, la tabla por base de datos y la tarjeta de cloud.

Por qué

Este es el núcleo de la herramienta — un barrido deliberado y de solo lectura produce un Snapshot inmutable y con fingerprint, del cual se deriva todo lo demás. ✅

Etapa 2

Lee el Health Score

El Health Score es el veredicto de un vistazo; entiende su número y su banda (band).

Paso 5

Encuentra el Health Score

Haz

Mira la tarjeta de Health Score en la parte inferior del riel izquierdo.

Mira

Un número grande de 0 a 100 con un subtítulo como 2 críticos · 3 avisos. El número está coloreado: verde cuando está sano, ámbar cuando es razonable, rojo cuando está en riesgo o crítico.

Paso 6

Lee la banda (band)

Haz

Mapea el score a su banda.

  • 85–100 — sano: ninguna acción urgente.
  • 70–84 — razonable: algunos avisos que vale agendar.
  • 50–69 — en riesgo: los críticos se están acumulando.
  • por debajo de 50 — crítico: actúa ahora.

Concepto

El score es explicable

El score es determinista — empieza en 100 y cada punto perdido mapea a un hallazgo con nombre. El mismo estado del deployment siempre produce el mismo score, así que puedes comparar ejecuciones a lo largo del tiempo. Los conteos de críticos y avisos del subtítulo vienen directo de esos hallazgos.

Etapa 3

Recorre los hallazgos

Las tarjetas de recomendación son el corazón del informe — ordenadas por impacto, cada una con una severidad, la evidencia y una corrección.

Paso 7

Lee los gauges de la cabecera

Haz

Encima de las recomendaciones, recorre la franja de gauges.

Mira

Una fila de gauges con números grandes en mono: Datos (lógico), En disco (con el ratio de compresión), Índices, RAM, vCPU, WT cache (usado / configurado), Ventana del oplog y Conexiones. El subtítulo de cada gauge está coloreado — verde para ok, ámbar para aviso, rojo para señal crítica (por ejemplo datos ≫ RAM).

Por qué

Los gauges son los hechos crudos a partir de los cuales se construyen los hallazgos — tamaño lógico vs. en disco, cuánto del working set cabe en la caché, el historial del oplog, el churn de conexiones.

Paso 8

Lee una tarjeta de recomendación

Haz

Mira la sección Recomendaciones. Lee la primera tarjeta, de arriba abajo.

Mira

Cada tarjeta tiene una barra coloreada a la izquierda y un chip de severidad (crítico / aviso / ok), un ícono, un título, una frase de evidencia con los números reales, y una línea → corrección con la remediación concreta. Las tarjetas se ordenan por impacto, así que la más importante va primero.

Paso 9

Almacenamiento y disk-fill

Haz

Encuentra los hallazgos de almacenamiento — por ejemplo un ratio de compresión bajo, o un aviso de previsión de llenado del disco.

Mira

Los hallazgos de almacenamiento comparan los datos lógicos con el tamaño en disco y, cuando hay suficiente historial, proyectan cuándo se llena el disco. Un ratio de compresión sano (en torno a 2.3×) aparece como ok.

Paso 10

Working set vs. RAM

Haz

Encuentra el hallazgo de working set — compara tus datos calientes con la RAM y la caché de WiredTiger.

Mira

Cuando los datos son mucho mayores que la RAM (por ejemplo 881 GB de datos contra 31 GB de RAM), dispara como crítico: las queries fuera del conjunto caliente van a disco. La corrección sugiere agregar RAM para que el working set quepa, archivar colecciones frías o hacer sharding.

Concepto

Qué significa “working set”

El working set es la porción de tus datos que se lee y escribe activamente — la parte caliente. Para buen rendimiento debe caber en la RAM (específicamente en la caché de WiredTiger, que es alrededor de la mitad de la RAM). No necesitas RAM igual a todos tus datos, solo al conjunto caliente.

Paso 11

Salud de los índices

Haz

Encuentra los hallazgos de indexación — índice inflado, colecciones con demasiados índices, índices sin uso o duplicados.

Mira

Los hallazgos de índice señalan una base de datos cuyo tamaño de índice es grande en relación a sus datos (por ejemplo 41.5 GB de índice para 87.9 GB de datos), o una colección que carga demasiados índices. La corrección te apunta al Performance Advisor para eliminar los que no se usan.

Paso 12

Postura de seguridad y ventana del oplog

Haz

Encuentra el hallazgo de seguridad (postura de TLS / auth) y el hallazgo de la ventana del oplog.

Mira

El hallazgo de seguridad señala TLS débil, auth de clúster por key-file, o autorización deshabilitada. El hallazgo de oplog reporta la ventana de replicación en horas/días — una ventana cómoda (por ejemplo 7.8 días) aparece como ok; una ventana que se encoge acercándose a un día dispara un aviso.

Atención

Algunas métricas se degradan en engines gestionados

En Cosmos DB for MongoDB o DocumentDB, comandos como replSetGetStatus, hostInfo o las stats de la caché de WiredTiger pueden no estar disponibles. Esos gauges muestran en vez de un 0 falso, y las reglas que los necesitan se saltan con una nota info en lugar de disparar un crítico falso.

Etapa 4

Por base de datos y sizing de cloud

Dos paneles quedan debajo de las tarjetas: dónde está tu espacio, y qué aprovisionar en la cloud.

Paso 13

Lee la tabla por base de datos

Haz

Mira el panel Datos por base de datos.

Mira

Una fila por base de datos, ordenadas por tamaño: Datos, Disco, una sizebar data · idx (cian = datos, ámbar = índice), los conteos de Coll e Idx, y una Flag (por ejemplo grande, pocas coll, archivable, idx NN GB, vacía u ok). La sizebar hace que las bases pesadas en índice salten a la vista.

Paso 14

Lee la tarjeta de Sizing de Cloud

Haz

Mira la tarjeta Sizing de Cloud junto a la tabla.

Mira

Un tier recomendado (por ejemplo M60), su spec (RAM · vCPU · disco), un costo mensual estimado, y un desglose: datos en disco, + headroom, RAM (working set), crecimiento y alcanza el 80% del disco en ~N meses. Debajo, alternativas (un tier más barato o una opción con sharding) con sus trade-offs.

Por qué

El Advisor mapea tus requisitos a tiers de Atlas, Cosmos vCore y VM genérica, eligiendo el más barato que cabe en tu RAM, vCPU, disco e IOPS — para que no aprovisiones ni de menos ni de más.

Paso 15

Sobre los precios

Atención

Precios de referencia, no una cotización

Las cifras de costo vienen de una tabla de precios de referencia fechada y versionada (on-demand, de lista, single-region). Sirven como guía para right-sizing — confirma siempre en la calculadora del propio proveedor antes de comprometerte, ya que los precios varían por región y contrato.

Etapa 5

Exportación y auditoría

Convierte el assessment en un artefacto compartible y ánclalo a tu rastro de auditoría.

Paso 16

Exporta el informe

Haz

En la parte inferior, usa la barra de exportación. Haz clic en Informe PDF, HTML imprimible o JSON (snapshot bruto).

Mira

PDF y HTML producen el informe blueprint completo — stats de portada, hallazgos, host y memoria, por base de datos, carga y replicación, config y seguridad, y sizing de cloud. JSON guarda el snapshot bruto y determinista, que puedes reimportar más tarde para comparar a lo largo del tiempo.

Paso 17

Adjunta a la auditoría

Haz

Haz clic en Adjuntar a la auditoría.

Mira

El hash sha256 del informe se registra en la línea de tiempo de auditoría local (y, cuando hay licencia, se ancla a la cadena inmutable del backend). Un toast lo confirma con el hash corto.

Concepto

El fingerprint sha256 estable del snapshot es la clave de anclaje, así que re-adjuntar el mismo snapshot es idempotente y las entradas de auditoría del mismo deployment se alinean a lo largo del tiempo.

Etapa 6

Snapshots y crecimiento a lo largo del tiempo

Cada ejecución se guarda; vuelve a escanear más tarde para ver cómo creció el deployment.

Paso 18

Encuentra tus snapshots guardados

Haz

Abre la lista de Snapshots guardados (cada assessment que ejecutas se guarda aquí, cifrado en reposo con su fingerprint sha256).

Mira

Una lista de snapshots pasados, cada uno con su timestamp, etiqueta y Health Score. Puedes abrir cualquiera del pasado para revisarlo exactamente como fue capturado.

Paso 19

Vuelve a escanear y compara a lo largo del tiempo

Haz

Ejecuta el assessment de nuevo más tarde (un día o más después del primero), y luego compara el nuevo snapshot con uno anterior.

Mira

Un diff temporal muestra los deltas por base de datos y por métrica — por ejemplo creció X% en 30 días — y la tarjeta de cloud ahora proyecta un ETA fechado de llenado del disco a partir de la tendencia.

Atención

El crecimiento necesita al menos 2 snapshots

Con un único snapshot no hay tendencia que trazar, así que la tarjeta de cloud muestra “recolecta ≥ 2 snapshots para una proyección de crecimiento.” La previsión obtiene un ETA fechado en cuanto tienes dos snapshots con al menos un día de diferencia, y gana confianza con cuatro o más.

Limpieza (cuando termines)

Concepto

No hay nada que deshacer en la base de datos

El Sizing Advisor es de solo lectura — no escribió nada en tu base de datos, así que no hay nada que eliminar ni revertir. Lo único que gestionar son los snapshots guardados localmente.

Haz

Si quieres, abre la lista de Snapshots guardados y borra cualquier snapshot antiguo que ya no necesites.

Mira

Los snapshots seleccionados se eliminan del almacenamiento local. El deployment en sí queda intacto.

Resumen de lo que validaste

EtapaFuncionalidad
1Abrir el Sizing Advisor y ejecutar un assessment de solo lectura
2Leer el Health Score (0–100) y su banda
3Recorrer los hallazgos: almacenamiento, working set vs. RAM, índices, seguridad, oplog
4Leer la tabla por base de datos y la recomendación de sizing de cloud
5Exportar el informe (PDF / HTML / JSON) y adjuntarlo a la auditoría
6Guardar snapshots y comparar el crecimiento a lo largo del tiempo
Si cada paso dio el “Mira” esperado, el Sizing Advisor está 100% validado. Anota el número del paso de cualquier discrepancia para que podamos corregirlo.