Monitoreo del Rendimiento de MongoDB: Comandos y Métricas Clave Explicados

La gestión eficaz de bases de datos depende de un monitoreo robusto. Para MongoDB, una base de datos NoSQL líder, comprender las métricas de rendimiento es fundamental para mantener una alta disponibilidad y capacidad de respuesta. Las consultas lentas, el consumo excesivo de recursos o los picos inesperados de conexiones pueden afectar gravemente el rendimiento de la aplicación.

Cuando MongoDB se ralentiza, la primera pregunta útil no es "¿la base de datos es mala?". Es "¿qué está haciendo el servidor ahora mismo, y es diferente de lo normal?". Los comandos a continuación son los que uso para una primera pasada antes de cambiar índices, redimensionar hardware o culpar a la aplicación.

Comandos Esenciales de Monitoreo en el Shell de MongoDB (mongosh)

La interfaz principal para ejecutar estos comandos es el Shell de MongoDB (mongosh), o el shell heredado mongo. Todos los comandos mostrados aquí se ejecutan dentro de este entorno de shell.

1. Comprensión de las Conexiones Actuales: db.currentOp() y db.serverStatus()

Monitorear las conexiones activas es vital para prevenir el agotamiento de conexiones e identificar operaciones de larga duración que podrían estar bloqueando recursos.

db.currentOp()

Este comando devuelve información sobre las operaciones que se están ejecutando actualmente en la base de datos. Es indispensable para identificar consultas lentas o bloqueantes en tiempo real.

Ejemplo de Uso:

Para ver todas las operaciones que se están ejecutando actualmente:

db.currentOp()

Para buscar específicamente operaciones que se ejecutan durante más tiempo del umbral (por ejemplo, operaciones que se ejecutan durante más de 5 segundos):

db.currentOp({"secs_running": {$gt: 5}})

La salida incluye detalles como op, ns (espacio de nombres), query y secs_running.

db.serverStatus()

Si bien este comando proporciona información completa de estado, su sección connections es crucial para monitorear la agrupación de conexiones y los límites.

Métricas Clave dentro de serverStatus (Sección de Conexiones):

• current: El número de conexiones activas al servidor.
• available: El número de conexiones disponibles que se pueden establecer (según el máximo configurado).

db.serverStatus().connections

2. Análisis del Rendimiento de Consultas: db.getProfilingStatus() y db.setProfilingLevel()

MongoDB proporciona herramientas de perfilado integradas que registran los detalles de ejecución de las operaciones de la base de datos, lo que permite identificar consultas que consumen muchos recursos.

Niveles de Perfilado

Los niveles de perfilado determinan qué operaciones se registran:

• 0 (Desactivado): No se perfilan operaciones.
• 1 (Operaciones Lentas): Solo se perfilan las operaciones más lentas que el umbral configurado (slowms).
• 2 (Todas las Operaciones): Se perfilan todas las operaciones, lo que genera una carga de escritura significativa y solo debe usarse brevemente para la resolución de problemas específicos.

Verificación del Estado

Para ver el nivel de perfilado actual:

db.getProfilingStatus()

Configuración del Nivel (Ejemplo)

Para habilitar el perfilado solo para operaciones lentas (operaciones que superan los 100 milisegundos):

// Establecer slowms a 100 milisegundos (el valor predeterminado suele ser 100)
db.setProfilingLevel(1, { slowms: 100 })

Consejo: Siempre regrese el perfilado al nivel 0 después de haber recopilado la información necesaria para evitar la degradación del rendimiento causada por un registro excesivo.

Visualización de Consultas Lentas Perfiladas

Las operaciones perfiladas se almacenan en la colección system.profile dentro de la base de datos específica que se está monitoreando. Para ver las 10 consultas más lentas en la última hora:

db.system.profile.find().sort({millis: -1}).limit(10).pretty()

3. Métricas de Utilización de Recursos

Comprender cómo MongoDB utiliza los recursos de CPU, memoria y E/S es esencial para las decisiones de escalado.

Uso de Memoria y Almacenamiento: db.serverStatus()

Las secciones globalLock y storageEngine dentro de serverStatus proporcionan información detallada sobre la gestión de recursos.

Indicadores de Memoria:

• resident: Cantidad de memoria física que utiliza el proceso.
• virtual: Memoria virtual total asignada por el proceso.

db.serverStatus().globalLock

Monitoreo de Contención de Bloqueos

MongoDB utiliza mecanismos de bloqueo internos. Monitorear la adquisición de bloqueos y las esperas ayuda a identificar cuellos de botella de concurrencia.

Métricas Clave en globalLock:

• currentQueue.readers: Número de lectores esperando un bloqueo.
• currentQueue.writers: Número de escritores esperando un bloqueo.
• totalTime: Tiempo total dedicado a esperar bloqueos en todas las operaciones.

Los valores altos en currentQueue a menudo indican que faltan índices o que las operaciones de escritura son excesivamente largas, lo que provoca que los lectores/escritores se pongan en cola.

4. Uso y Salud de los Índices: db.collection.stats()

Los índices mal utilizados o faltantes son la causa más común de degradación del rendimiento. El comando stats() ayuda a analizar la eficiencia de los índices.

Cuando se ejecuta en una colección específica (por ejemplo, users):

db.users.stats()

Métricas Clave a Verificar:

• totalIndexSize: El espacio total en disco consumido por todos los índices en esa colección.
• indexSizes: Un desglose del uso de espacio por índice.
• Si un índice está presente pero nunca se usa para lecturas, es una sobrecarga que se debe considerar eliminar.

5. E/S de Disco y Rendimiento: db.serverStatus() (Red y Operaciones)

Monitorear la actividad de la red y la tasa de operaciones proporciona una visión del rendimiento de la base de datos.

Tasa de Operaciones (de opcounters):

opcounters rastrea el número total de operaciones ejecutadas desde el último reinicio del servidor, categorizadas por tipo:

• insert, query, update, delete, getmore, command.

Al rastrear los cambios en estos contadores a lo largo del tiempo (por ejemplo, comparando dos llamadas consecutivas a serverStatus), puede calcular el rendimiento operativo (operaciones por segundo).

Ejemplo de Comparación:

1. Ejecute db.serverStatus().opcounters en el momento T1.
2. Ejecute db.serverStatus().opcounters en el momento T2.
3. Reste los valores de T1 de los valores de T2 para obtener el total de operaciones ejecutadas en ese intervalo.

Mejores Prácticas para el Monitoreo Proactivo

• La Automatización es Clave: Depender únicamente de comandos manuales del shell es ineficiente. Integre el monitoreo utilizando herramientas como MongoDB Cloud Manager/Ops Manager o soluciones de monitoreo de terceros que consulten estos endpoints automáticamente.
• Establezca Líneas de Base: Ejecute comandos cuando el sistema esté saludable para establecer una línea de base de rendimiento. Cualquier desviación de esta línea de base justifica una investigación inmediata.
• Concéntrese en la Latencia: Si bien los recuentos de operaciones son útiles, priorice las métricas de latencia (como el tiempo informado por los registros de perfilado) sobre el rendimiento bruto al diagnosticar problemas de experiencia del usuario final.
• Verifique las Conexiones con Frecuencia: En aplicaciones de alto tráfico, los límites de conexión a menudo se alcanzan primero. Monitoree db.serverStatus().connections.current en relación con el máximo configurado.

Una Lista de Verificación Práctica para una Primera Pasada

Cuando alguien dice "MongoDB está lento", evite saltar directamente a los cambios de índice. Comience con una lista de verificación corta y anote lo que ve.

Verifique si el servidor está sobrecargado con operaciones activas:

db.currentOp({
  active: true,
  secs_running: { $gt: 2 }
});

Algunas operaciones de larga duración pueden ser normales para trabajos de análisis. Un gran conjunto de escrituras, escaneos de colecciones u operaciones bloqueadas es diferente. Busque el espacio de nombres en ns, el tipo de operación en op y la forma de la consulta. Si muchas operaciones están esperando detrás de una actualización o construcción de índice, la solución no es la misma que un índice faltante en una consulta de lectura.

Luego verifique las conexiones:

db.serverStatus().connections;

current aumentando rápidamente puede significar que un grupo de conexiones de la aplicación se configuró incorrectamente, un despliegue creó demasiados trabajadores, o los clientes están agotando el tiempo de espera y reconectándose. available cerca de cero es una señal urgente porque los nuevos clientes pueden no conectarse. La respuesta correcta podría ser el ajuste del grupo en la aplicación, no aumentar el límite del servidor.

A continuación, verifique los contadores de operaciones dos veces, con un intervalo corto:

const a = db.serverStatus().opcounters;
sleep(5000);
const b = db.serverStatus().opcounters;
printjson({
  insertPer5s: b.insert - a.insert,
  queryPer5s: b.query - a.query,
  updatePer5s: b.update - a.update,
  deletePer5s: b.delete - a.delete,
  commandPer5s: b.command - a.command
});

Los contadores desde el inicio son útiles para el contexto a largo plazo, pero las diferencias durante un intervalo conocido le indican lo que está sucediendo ahora. Si el tráfico de comandos es alto pero las consultas son bajas, es posible que esté viendo verificaciones de metadatos, ruido de monitoreo o comportamiento del controlador en lugar de lecturas normales.

Usando explain() Antes de Culpar al Hardware

La colección de perfiles puede indicarle qué operaciones son lentas. explain() le ayuda a comprender por qué una consulta es lenta antes de agregar CPU o memoria.

db.users.find({ email: "[email protected]" }).explain("executionStats");

En la salida, compare totalDocsExamined con nReturned. Si MongoDB examina una gran cantidad de documentos para devolver un usuario, es probable que la consulta necesite un mejor índice o un filtro diferente. Si totalKeysExamined es alto, existe un índice pero puede no ser lo suficientemente selectivo para el patrón de consulta.

Para una consulta compuesta, el orden del índice es importante:

db.orders.find({
  accountId: "acct_123",
  status: "open",
  createdAt: { $gte: ISODate("2025-11-01T00:00:00Z") }
}).sort({ createdAt: -1 });

Un índice útil podría ser:

db.orders.createIndex({ accountId: 1, status: 1, createdAt: -1 });

Esa no es una regla universal. El mejor índice depende de la cardinalidad, el orden de clasificación y el conjunto completo de consultas que afectan a la colección. El punto es hacer que la base de datos le muestre el plan de ejecución en lugar de adivinar.

Leyendo Datos de Perfilado Sin Reaccionar de Forma Exagerada

El nivel de perfilado 2 registra cada operación y puede agregar sobrecarga en sistemas ocupados. Úselo solo para una ventana corta y específica. El nivel 1 con un umbral slowms razonable es más seguro para encontrar operaciones lentas.

db.setProfilingLevel(1, { slowms: 200 });

Después de recopilar datos, inspeccione las entradas más lentas:

db.system.profile.find(
  {},
  {
    ns: 1,
    op: 1,
    millis: 1,
    command: 1,
    keysExamined: 1,
    docsExamined: 1,
    nreturned: 1
  }
).sort({ millis: -1 }).limit(20).pretty();

Una consulta lenta no siempre significa un incidente de producción. Un informe programado, un caché frío después de un reinicio o una tarea de mantenimiento poco frecuente pueden aparecer cerca de la parte superior. Los patrones importan más que una sola muestra. Si la misma forma de consulta aparece repetidamente y examina muchos más documentos de los que devuelve, tiene un candidato real para ajuste.

Monitoreo de Conjuntos de Réplicas y Presión de Almacenamiento

Para los conjuntos de réplicas, el rendimiento no se trata solo del primario. Un secundario que se queda atrás puede afectar la confianza en la conmutación por error y las cargas de trabajo de lectura si los clientes usan lecturas secundarias.

rs.status();

Busque miembros que no estén saludables, cambios de estado inesperados o retraso de replicación que no se recupere. El retraso aceptable exacto depende de la aplicación. Una carga de trabajo similar a una cola puede tolerar un pequeño retraso. Un panel que promete lecturas casi en tiempo real puede que no.

La presión de almacenamiento necesita el mismo contexto. db.serverStatus() puede mostrar métricas del motor de almacenamiento y WiredTiger, pero las herramientas a nivel de disco siguen siendo importantes. Si MongoDB está esperando discos lentos, los comandos del shell dentro de la base de datos mostrarán síntomas en lugar de la causa raíz. Correlacione con métricas del host como latencia de disco, uso del sistema de archivos, robo de CPU y presión de memoria.

Convirtiendo Verificaciones Manuales en Alertas

Los comandos manuales son mejores durante la investigación. Para operaciones normales, convierta las señales útiles en verificaciones automatizadas: uso de conexiones, salud de la replicación, tasa de consultas lentas, uso de disco, fallos de página o presión de caché cuando estén disponibles, y latencia de operación. Alerte sobre el mal comportamiento sostenido, no cada pico de un minuto.

Las buenas alertas incluyen contexto. "Consultas lentas de MongoDB altas" es menos útil que una alerta que incluya la base de datos, la colección, la forma de la consulta, la tasa actual y un enlace a muestras de perfil recientes o paneles de control. El objetivo es acortar los primeros diez minutos del incidente.

Qué No Hacer Durante una Ralentización

Evite hacer varios cambios a la vez. Agregar un índice, aumentar los límites de conexión, reiniciar la aplicación y cambiar los tamaños de los grupos en el mismo incidente puede eliminar el síntoma, pero no tendrá idea de qué acción ayudó. Haga un cambio, observe la métrica que debería mejorar y tome notas.

Tenga cuidado con killOp. Puede ser útil cuando una operación es claramente dañina, pero matar operaciones aleatorias de larga duración puede empeorar el comportamiento de la aplicación. Si la operación pertenece a una migración, copia de seguridad, construcción de índice o trabajo de informes, identifique al propietario antes de detenerla a menos que la base de datos ya esté en serios problemas.

No trate serverStatus() como una única puntuación de salud mágica. Es una colección de contadores y instantáneas. Un valor alto puede ser normal en un sistema grande y ocupado, y un valor bajo puede ser malo en un sistema pequeño y sensible a la latencia. La pregunta útil es si el valor cambió de una manera que coincida con el problema que enfrenta el usuario.

También separe los síntomas de la base de datos de los síntomas del despliegue. Un nuevo lanzamiento que cambia la forma de la consulta, abre grupos de conexiones más grandes o inicia una migración en segundo plano puede hacer que MongoDB parezca la causa raíz. Compare el momento de las operaciones lentas con los despliegues, programaciones de trabajos, copias de seguridad y cambios de tráfico antes de hacer una solución solo para la base de datos.

El monitoreo de MongoDB funciona mejor cuando compara el comportamiento actual con una línea de base conocida. db.currentOp(), db.serverStatus(), el perfilado, explain() y las verificaciones del conjunto de réplicas le brindan suficiente evidencia para decidir si el problema es una consulta, un índice, el comportamiento de la conexión del cliente, la replicación o el host debajo de la base de datos.