MongoDB Monitoreo: SolarWinds vs New Relic vs Datadog
Instalamos SolarWinds, Datadog y New Relic en sistemas limpios que ejecutaban MongoDB 7.0 para probarlos. Revisamos todo el proceso de configuración de cada herramienta, documentando cada paso y obstáculo.
MongoDB resultados del benchmark de herramientas de monitoreo de rendimiento
Plataforma | Tiempo de configuración | Perfilado de consultas | Precisión de métricas | RAM Uso | Mejor para |
|---|---|---|---|---|---|
5 min | ✓ | 100 % preciso | Medio (500MB) | Optimización de producción | |
New Relic | 15 min | ✕ | Baja (23 a 800 % de tasas de error) | Bajo (90MB) | Comprobaciones básicas de estado |
Datadog | 20+ min | ✕ | Poco claro | Medio (330MB) | Monitoreo multitecnología |
MongoDB resumen de rendimiento del monitoreo
- SolarWinds completó la configuración en 5 minutos con detección automática y proporcionó perfilado a nivel de consulta que los demás no ofrecían.
- New Relic tardó 15 minutos con pasos de verificación manual y reportó métricas inexactas.
- Datadog requirió más de 20 minutos de edición de YAML y ofreció solo visibilidad básica.
También puede ver cómo estas plataformas monitorean MySQL y nuestro entorno de prueba y metodología
1. Experiencia de instalación e incorporación
1. SolarWinds
SolarWinds terminó la integración de MongoDB en menos de 5 minutos. SolarWinds abre con un modal simple: “¿Qué desea monitorear?” Cuando selecciona rendimiento de la base de datos, la plataforma muestra las bases de datos compatibles de inmediato.
Después de seleccionar MongoDB, SolarWinds busca agentes existentes.
La plataforma detectó de inmediato nuestro agente instalado previamente.
Una característica destacó: la interfaz muestra los detalles del agente (sistema operativo, ID de instancia en la nube, versión) directamente en la pantalla de selección. Sin buscar en menús desplegables.
Ahora SolarWinds solicita las credenciales de MongoDB. Ingresamos los detalles de conexión: localhost, método de autenticación (basado en contraseña), nombre de usuario y contraseña. El nombre visible se autocompletó con la información de nuestro servidor, aunque usó el nombre de host interno completo en lugar del nombre del agente que habíamos especificado antes.
Una rareza: el menú desplegable “Captura de consultas” apareció sin explicación. Seleccionamos “Registro” y avanzamos, sin saber qué hacían las otras opciones.
La siguiente pantalla presentó tres comandos de base de datos para ejecutar. Cada comando tenía un botón de copiar. Los ejecutamos en MongoDB e hicimos clic en “Observar base de datos”.
Aquí es donde SolarWinds nos impresionó. En lugar de pedirnos que averiguáramos los permisos, proporcionó comandos de copiar y pegar:
- Crear un usuario de monitoreo con credenciales específicas
- Otorgar los privilegios necesarios (roles clusterMonitor y readAnyDatabase)
- Establecer el nivel de perfilado
Apareció una pantalla de resumen que mostraba nuestra configuración. El estado del plugin mostraba “El plugin se está desplegando”.
Segundos después, el estado cambió a “La implementación del plugin fue exitosa” con un enlace para ver el panel. Configuración completa.
Descubra la observabilidad de SolarWinds con monitoreo profundo de MongoDB y perfilado de consultas. Explore SolarWinds.
Visita el sitio web2. New Relic
New Relic tardó aproximadamente 15 minutos en configurarse, pero el tiempo no era el problema real. La fricción vino de responder preguntas que la plataforma ya debería haber sabido.
New Relic comienza en la página Integraciones y agentes.
Buscamos “mongo” y encontramos varias integraciones relacionadas con MongoDB.
Después de seleccionar MongoDB, New Relic nos pidió que eligiéramos un método de instrumentación.
Elegimos “En un host” porque nuestro agente ya estaba instalado. La siguiente pantalla pidió el sistema operativo. Seleccionamos Linux. Esto parecía innecesario porque el agente ya se estaba ejecutando en el servidor, pero continuamos.
La siguiente pantalla pidió los detalles del host de MongoDB. El término “SCRAM” apareció sin explicación. La mayoría de la gente lo conoce como autenticación de nombre de usuario/contraseña, pero el término técnico añade confusión.
Después de hacer clic en “Continuar”, New Relic nos preguntó en qué servidor instalar. Esta pregunta debería haber aparecido primero, no después de que ya habíamos ingresado los detalles de configuración. El agente ya estaba instalado en “aimultiple-benchmark”, así que lo seleccionamos y continuamos.
La siguiente pantalla nos pidió verificar la compatibilidad de la versión de MongoDB. New Relic quería que ejecutáramos mongod --version y confirmáramos que la salida coincidía con sus requisitos. Tuvimos que copiar el comando, cambiar a nuestra terminal, ejecutarlo, verificar el número de versión y volver a hacer clic en continuar.
El agente ya está instalado en el servidor. Podría comprobarlo automáticamente.
Después de hacer clic en continuar, llegamos al paso de creación de usuario. New Relic proporcionó un script de MongoDB para crear el usuario de monitoreo. Los comandos eran claros, con asignaciones de roles adecuadas (clusterMonitor y readAnyDatabase). También tuvimos que ejecutar un comando de prueba de conexión para verificar que el usuario funcionara correctamente.
Este enfoque era mejor que pedir acceso root, pero asumía que averiguaríamos dónde ejecutar estos comandos.
La siguiente pantalla nos pidió instalar el paquete de integración. Ahora New Relic quería que lo instaláramos manualmente usando yum. Aunque el agente ya está instalado en Ubuntu, la interfaz usa Amazon Linux de forma predeterminada y proporciona comandos de instalación de yum en lugar de apt. Esperábamos que la plataforma detectara automáticamente el sistema operativo correcto a partir del agente instalado.
Ejecutamos el comando apt correcto para Ubuntu y pasamos a la siguiente pantalla. New Relic proporcionó un archivo de configuración YAML y nos dijo exactamente dónde colocarlo: /etc/newrelic-infra/integrations.d/. Al menos la ruta del archivo estaba clara.
Creamos el archivo, pegamos la configuración e hicimos clic en Continuar. La pantalla final mostró un botón “Probar conexión”. Hicimos clic y esperamos.
La prueba pasó. Configuración completa.
3. Datadog
Datadog tardó más de 20 minutos en completarse. La integración funcionó al final, pero llegar allí requirió un esfuerzo manual significativo.
Después de iniciar sesión, fuimos a Integraciones y buscamos “mongo”. Hicimos clic en MongoDB y apareció un modal.
La descripción general mostró qué incluye el monitoreo de MongoDB, pero hacer clic en “Instalar integración” solo abrió otra pantalla con instrucciones densas.
Aquí es donde Datadog nos abrumó. La pantalla mostró una guía de referencia completa que cubría todos los escenarios posibles de MongoDB: instancias independientes, conjuntos de réplica, clústeres fragmentados, métodos de autenticación, configuración SSL y más.
Para alguien que solo intenta monitorear una única instancia de MongoDB, el muro de texto resultó excesivo.
Nos desplazamos buscando los pasos básicos:
- Crear un usuario de monitoreo en MongoDB
- Editar el archivo de configuración YAML
- Reiniciar el agente de Datadog
Datadog proporcionó los comandos de MongoDB para crear el usuario, lo cual fue útil. Pero en cuanto al archivo YAML, la documentación decía editar conf.yaml sin indicar claramente dónde debía colocarse este archivo.
Sabíamos por experiencia que pertenece a /etc/datadog-agent/conf.d/mongo.d/, pero las instrucciones enterraban este detalle en lo profundo de la documentación.
Creamos el usuario de MongoDB, escribimos la configuración YAML, la colocamos en el directorio correcto y reiniciamos el agente.
Luego volvimos a la interfaz de Datadog e hicimos clic en “Instalar integración”.
El botón desapareció. Sin mensaje de confirmación, sin notificación de éxito, sin redirección a un panel. Nada.
Esperamos un momento, luego navegamos manualmente a la sección de paneles y encontramos que las métricas de MongoDB comenzaban a poblarse.
2. Consumo de recursos del agente
Monitoreamos cuántos recursos consumía cada agente mientras se ejecutaba. La prueba duró aproximadamente 10 minutos con los tres agentes recopilando datos simultáneamente de la misma instancia de MongoDB bajo carga.
Estresamos el sistema insertando 2 millones de registros en MongoDB mediante un script que generaba datos aleatorios. Esto simuló la actividad real de una base de datos mientras medíamos el uso de recursos del agente.
CPU consumo
Los tres agentes usaron recursos mínimos de CPU durante la prueba.
- New Relic mostró el consumo promedio de CPU más bajo, pero tuvo picos ocasionales que alcanzaron el 4 %. Estos picos fueron breves y no afectaron el rendimiento del sistema.
- SolarWinds mantuvo el uso de CPU más constante, permaneciendo alrededor del 3 % sin variaciones significativas.
- Datadog quedó en el medio, promediando poco más del 2 % con un rendimiento estable durante toda la prueba.
Uso de memoria
El uso de memoria mostró diferencias más significativas entre los agentes.
New Relic consumió aproximadamente 5-6x menos memoria que SolarWinds. En nuestro servidor de prueba de 16GB, esto se tradujo en:
- New Relic: ~90MB
- Datadog: ~330MB
- SolarWinds: ~500MB
Para la mayoría de los servidores de producción, estas cantidades no importarán. Pero si ejecuta agentes en sistemas con recursos limitados o monitorea cientos de bases de datos, la diferencia se acumula.
El uso de memoria se mantuvo estable en los tres agentes durante toda la prueba. No se produjeron fugas de memoria ni crecimientos inesperados.
E/S de disco
La actividad de disco varió considerablemente entre los agentes.
SolarWinds realizó significativamente más lecturas de disco que los otros dos agentes, aproximadamente 40x más que New Relic y 1.5x más que Datadog. Esto sugiere que SolarWinds accede con más frecuencia a los datos almacenados localmente, posiblemente por sus funciones de perfilado de consultas.
Datadog fue el que menos escribió en disco, lo que indica que almacena menos datos localmente antes de enviarlos a la nube.
New Relic mostró el patrón de E/S más equilibrado con lecturas y escrituras moderadas.
Uso de red
El tráfico de red mostró cuántos datos enviaba cada agente a su backend.
Los tres agentes enviaron cantidades similares de datos por la red. Datadog transmitió ligeramente menos, posiblemente debido a una compresión más agresiva o a diferentes tasas de muestreo.
El tráfico bidireccional tiene sentido, ya que los agentes envían métricas y reciben actualizaciones de configuración o comandos de la plataforma.
Resumen del impacto en los recursos
Ninguno de estos agentes sobrecargará su sistema. Incluso bajo carga de la base de datos con los tres ejecutándose simultáneamente, el consumo total de recursos se mantuvo muy por debajo del 10 % de CPU y memoria combinados.
New Relic gana en eficiencia de memoria. SolarWinds usa más recursos pero ofrece un análisis más detallado a nivel de consulta. Datadog se sitúa en el medio.
Para la mayoría de los casos de uso, estas diferencias de recursos no influirán en su decisión. Elija según las funciones y la usabilidad, no el consumo de recursos.
3. Panel y capacidades de monitoreo
Después de completar la configuración, necesitábamos ver qué muestra realmente cada plataforma. Ejecutamos la misma carga de trabajo en las tres: insertar 2 millones de registros en lotes de 5.000, seguidos de otros 5 millones de registros.
El script usó Node.js con Faker para generar datos aleatorios de usuario: nombres, correos electrónicos, direcciones y números de teléfono. Esto nos dio un dataset realista para monitorear.
Mientras se ejecutaban las inserciones, monitoreamos el consumo de recursos del agente en segundo plano.
La carga de trabajo puso a MongoDB bajo estrés real, lo que nos permitió ver cómo cada plataforma capturaba y mostraba la actividad.
Panel de SolarWinds
Hicimos clic en “Bases de datos” en el menú izquierdo e inmediatamente vimos nuestra instancia de MongoDB. Un clic y apareció un panel completo.
La parte superior de la pantalla mostró el estado de MongoDB, el tiempo de respuesta promedio, el rendimiento (consultas por segundo) y el recuento de errores. El gráfico de burbujas “Desglose de los 10 servicios principales” mostró los patrones de consulta más utilizados con sus recuentos y porcentajes.
Los números contaban una historia. El rendimiento mostró 3 consultas por segundo en promedio. El desglose mostró 1.400 operaciones de inserción. ¿Por qué 1.400 en lugar de 7 millones?
Insertamos 7 millones de registros en lotes de 5.000. Eso equivale a 1.400 operaciones por lotes. SolarWinds rastreó cada lote sin omitir ninguno.
La pestaña Perfilador mostró los patrones de consulta con los tiempos de ejecución promedio.
Nuestras consultas de inserción tardaron 4-5 segundos cada una, lo que parece alto hasta que recuerda que cada consulta escribía 5.000 filas.
La pestaña Estado mostró que todo funcionaba sin problemas.
Detuvimos el servicio de MongoDB para ver qué tan rápido lo notaría SolarWinds. En un lapso de 30 a 40 segundos, el estado de salud cambió a “Malo”.
La pestaña Consultas ofrecía filtrado avanzado. Podía enumerar las consultas que:
- Devolvieron errores
- Se ejecutaron sin índices adecuados
- Respondieron lentamente
- Generaron advertencias
Cada patrón de consulta mostró cuándo apareció por primera vez, cuándo se ejecutó por última vez, cuántas muestras se capturaron y estadísticas de ejecución. Para la resolución de problemas, este nivel de detalle importa.
La pestaña Alertas nos permitió crear alertas específicas de MongoDB. Antes habíamos creado una alerta de memoria para el host, pero ahora podíamos configurar notificaciones específicas de la base de datos.
La pestaña Recursos mostró métricas a nivel de host junto con las estadísticas de MongoDB, CPU, memoria, disco y red. Este contexto ayuda a distinguir entre problemas de base de datos y problemas de infraestructura subyacente.
La pestaña Asesores aún no tenía recomendaciones, pero las proporcionó para MySQL en nuestra prueba anterior. Esperamos que ofrezca sugerencias de optimización a medida que recopile más datos de MongoDB.
Actualizaciones de IA: En octubre de 2025, SolarWinds lanzó la función IA Agent con IA Query Assist (actualmente en vista previa técnica). IA Query Assist analiza los patrones de consulta de la base de datos y propone reescrituras optimizadas para mejorar el rendimiento automáticamente. Root Cause Assist (ahora disponible de forma general) genera análisis claros de causa raíz basados en alertas y anomalías para reducir el tiempo de resolución de problemas. Está prevista una disponibilidad más amplia de IA Agent en toda la cartera de SolarWinds para 202612.
Panel de New Relic
Fuimos a la sección de paneles, pero no apareció automáticamente ningún panel de MongoDB.
Buscamos “mongo” en el catálogo de paneles y encontramos dos opciones de MongoDB.
Seleccionamos el panel normal de MongoDB e hicimos clic en “Configurar MongoDB”.
Nos redirigió de nuevo a la configuración de la integración de MongoDB. La plataforma ya sabía que habíamos instalado MongoDB, ¿por qué enviarnos de vuelta a la instalación? Hicimos clic en “Listo” y continuamos al panel.
El panel se abrió completamente vacío. “No se reportó ningún valor para la verificación del servicio mongodb.can_connect”.
Comprobamos nuestra configuración usando newrelic-infra agent configtest.
Cuando ejecutamos el comando de prueba de configuración del agente newrelic-infra para comprobar si había problemas con nuestra configuración, notamos que integration_name estaba configurado como nri-prometheus. Durante la configuración del panel, New Relic mostró dos opciones de MongoDB, una de las cuales era la versión de Prometheus. Nada en la interfaz indicaba que se trataba de una integración diferente, por lo que nunca se me habría ocurrido que había seleccionado la de Prometheus. Esto no fue un error del usuario; simplemente no había orientación ni distinción en la interfaz.
Volvimos e instalamos el panel “MongoDB (Prometheus)”.
Esta vez, aparecieron los datos.
Pero este es el problema: ¿cómo lo averiguaría un usuario normal? El proceso de instalación fue confuso y ahora la selección del panel añadía otra capa de complejidad.
El diseño del panel resultaba extraño. La parte superior mostraba información total de servidores y bases de datos que cambia una vez al año, pero ocupaba un espacio privilegiado en la pantalla.
Debajo, “Saturación de conexiones” aparecía de forma destacada. Esta métrica solo importa cuando algo va mal. ¿Por qué ponerla arriba?
La sección “Operaciones de consulta” reportó 11.670 inserciones. El número era incorrecto. Insertamos 7 millones de registros en 1.400 operaciones por lotes. El gráfico no coincidía con la realidad.
La pestaña Bases de datos mostró el tamaño de la base de datos, el recuento de objetos y los tamaños de los índices. Estos números eran correctos: 7 millones de objetos. New Relic obtiene estos datos consultando directamente a MongoDB (“¿Cuántos documentos tiene?”). Pero el recuento de consultas en tiempo real falló.
La pestaña Colecciones incluía gráficos útiles para métricas a nivel de colección: tamaño (con vistas de tabla y gráfico), tamaño total con cambio porcentual, recuento de operaciones de lectura, latencia de lectura, recuento de operaciones de escritura, latencia de escritura, recuento de transacciones, latencia de transacciones, operaciones de acceso a índices, recuentos de ejecución de comandos, latencia de comandos, frecuencia de comandos y duración de comandos.
Notablemente ausentes: métricas del host. No podíamos ver el uso de CPU, memoria, disco o red del servidor que ejecutaba MongoDB. SolarWinds incluía este contexto, pero Datadog, al igual que New Relic, no lo hacía.
Más importante aún, no existía ningún análisis a nivel de consulta en ninguna parte. Sin patrones de consulta, sin perfilado, sin identificación de consultas lentas, sin detección de índices faltantes. Para la resolución de problemas de bases de datos, estas funciones importan.
Datadog panel
Hicimos clic en “Paneles” en el menú izquierdo. Apareció automáticamente un panel “MongoDB – Descripción general”.
Lo abrimos, pero estaba vacío.
El problema tardó en diagnosticarse. Durante la instalación, la configuración de autodescubrimiento de Datadog requería especificar qué bases de datos monitorear mediante una coincidencia de patrón. El patrón predeterminado no coincidía con el nombre de nuestra base de datos. Datadog nunca mencionó esto durante la configuración.
Cambiamos todos los patrones a .* (coincidir con todo) y reiniciamos el agente.
Pero, ¿por qué estaba el panel completamente vacío? Incluso sin métricas específicas de la base de datos, deberían haber aparecido el tiempo de actividad, el recuento de conexiones y las estadísticas del servidor. No lo hicieron.
Ejecutamos datadog-agent check mongo para depurar. El archivo de configuración tenía un error de sangría. El estricto requisito de formato de YAML nos atrapó. Después de corregirlo y volver a ejecutar nuestra prueba de carga con 5 millones de inserciones, finalmente aparecieron los datos.
Inmediatamente nos encontramos con problemas en el panel. La sección Registros mostraba “No accesible” aunque habíamos configurado la recopilación de registros en nuestro archivo YAML. El proceso de configuración de Datadog informó que todo estaba bien, pero los registros seguían sin funcionar.
El diseño del panel tenía poco sentido para nuestro caso de uso. La sección superior se centraba en estadísticas de fragmentación. No estábamos ejecutando un clúster fragmentado. La parte central mostraba métricas de conjuntos de réplica. No teníamos conjuntos de réplica. La parte inferior volvía a la fragmentación de nuevo. Aproximadamente el 60 % del panel mostraba secciones vacías para funciones que no usábamos.
La información útil ocupaba quizás el 40 % de la pantalla: tiempo de actividad, uso de memoria, E/S de red, consultas por segundo y latencia de lectura/escritura. Sin análisis de consultas, sin perfilado, sin detección de consultas lentas, sin recomendaciones de índices.
Ni siquiera podíamos determinar cuántas operaciones se ejecutaron desde este panel.
MongoDB entorno y metodología de la prueba de benchmark de monitoreo
Ejecutamos las tres herramientas en configuraciones idénticas para garantizar una comparación justa. Cada prueba usó:
- Base de datos: MongoDB 7.0 Community Edition
- Servidor: instancia AWS m6i.xlarge
- Punto de partida: instalación nueva con el agente de monitoreo principal ya instalado
Los tres proveedores requieren instalar su agente base antes de agregar integraciones específicas, como MongoDB. Completamos ese paso de antemano, por lo que nuestra prueba se centró únicamente en la experiencia de integración de MongoDB.
Qué medimos:
- Complejidad de configuración: número de pasos manuales, configuración automática frente a manual, claridad de las instrucciones y si la interfaz nos guió o nos dejó buscando los siguientes pasos.
- Consumo de recursos del agente: uso de CPU, memoria, E/S de disco y red durante inactividad y bajo carga (inserción de 7 millones de registros).
- Capacidades de monitoreo: calidad del panel, precisión de las métricas, análisis a nivel de consulta y funciones de resolución de problemas.
Consideraciones de seguridad
Se divulgó una vulnerabilidad grave llamada “MongoBleed” que afecta a las versiones de MongoDB Server anteriores a 8.0.17, 7.0.28, 6.0.27 y anteriores. Esta vulnerabilidad de lectura fuera de los límites sin autenticación podría permitir a los atacantes acceder a datos sensibles de la memoria. Las organizaciones que ejecutan MongoDB deben actualizar de inmediato a las versiones parcheadas: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 o 4.4.3034. Al seleccionar herramientas de monitoreo, asegúrese de que admitan métodos de autenticación seguros y no introduzcan riesgos de seguridad adicionales.
Abordamos cada herramienta como lo haría un usuario normal, sin leer la documentación de antemano y sin formación previa. Si algo no era evidente en la interfaz, lo anotamos.
Añadir como fuente preferidaMongoDB veredicto final del benchmark de monitoreo
Nos propusimos responder una pregunta simple: ¿qué plataforma de monitoreo facilita más la integración de MongoDB para equipos no técnicos?
Después de instalar las tres, ejecutar cargas de trabajo idénticas y evaluar los paneles, la respuesta quedó clara. Nuestra evaluación se basa en la integración básica de MongoDB de Datadog a enero de 2025. Datadog ha lanzado desde entonces Database Monitoring (DBM) para MongoDB (diciembre de 2024), que ofrece capacidades significativamente más profundas, incluido el perfilado de consultas, el análisis de operaciones lentas, los planes de explicación y el monitoreo de replicación. El producto DBM aborda muchas de las limitaciones identificadas en este benchmark5.
SolarWinds: creado para el monitoreo de bases de datos
SolarWinds ganó esta comparación de manera decisiva. La plataforma detectó de inmediato nuestro agente, nos guió a través de la configuración de credenciales mediante comandos de copiar y pegar, e implementó la integración automáticamente. La configuración tomó 5 minutos.
El panel apareció instantáneamente con información relevante. El perfilado de consultas mostró exactamente qué operaciones consumían más recursos. La plataforma capturó las 1.400 operaciones por lotes sin omitir ninguna. Cuando detuvimos MongoDB, SolarWinds detectó el fallo en 40 segundos.
La pestaña Consultas nos permite filtrar por errores, índices faltantes, respuestas lentas y advertencias, funciones que apoyan directamente la optimización de la base de datos. Se esperaba que la función Asesores proporcionara recomendaciones (aunque no generamos suficientes datos para activar ninguna durante nuestra prueba).
SolarWinds se centró en lo que los administradores de bases de datos realmente necesitan: análisis de consultas, perfilado de rendimiento e información procesable.
New Relic: perdido en la configuración
New Relic tardó 15 minutos en configurarse, pero el tiempo no fue el problema principal. La plataforma hizo preguntas en el orden incorrecto, requirió verificación manual de cosas que el agente podía comprobar automáticamente y nos obligó a instalar paquetes manualmente.
La confusión del panel empeoró las cosas. Instalamos el monitoreo de MongoDB, pero al seleccionar el panel predeterminado obtuvimos una pantalla vacía. Solo después de revisar los archivos de configuración nos dimos cuenta de que habíamos seleccionado el tipo de integración incorrecto. Un usuario normal no lo averiguaría.
Cuando finalmente aparecieron los datos, las métricas eran incorrectas. New Relic reportó 11.670 inserciones después de que realizáramos 1.400 operaciones por lotes, con un total de 7 millones de registros. La plataforma subestimó en un orden de magnitud.
Más críticamente, New Relic no proporcionó análisis a nivel de consulta. Sin perfilado, sin detección de consultas lentas, sin identificación de índices faltantes. Para la resolución de problemas de bases de datos, estas omisiones importan.
Datadog: se requiere trabajo manual
Datadog requirió más de 20 minutos de configuración y la mayor cantidad de configuración manual. Editamos los archivos YAML, determinamos dónde colocarlos y reiniciamos los servicios desde la línea de comandos.
El panel apareció automáticamente pero no mostró nada. La configuración de autodescubrimiento usaba un patrón que no coincidía con nuestra base de datos. Después de corregir el patrón y los errores de sangría de YAML, los datos finalmente se poblaron.
El panel en sí resultó estar mal diseñado para una instancia única de MongoDB. El sesenta por ciento de la pantalla estaba vacío, con secciones para fragmentación y conjuntos de réplica que no estábamos usando. El 40 % restante ofrecía métricas básicas: tiempo de actividad, memoria, E/S de red, consultas por segundo y latencia.
Sin análisis de consultas. Sin perfilado. Sin recomendaciones de optimización. No pudimos determinar con precisión los recuentos de operaciones en el panel.
Sin análisis de consultas. Sin perfilado. Sin recomendaciones de optimización. No pudimos determinar con precisión los recuentos de operaciones en el panel.
Actualización crítica (diciembre de 2024): después de completar este benchmark, Datadog lanzó Database Monitoring (DBM) para MongoDB, lo que cambia significativamente esta evaluación. DBM para MongoDB ahora ofrece:
- Análisis de operaciones lentas con muestras de consultas detalladas
- Planes de explicación para la optimización de consultas
- Monitoreo del estado de replicación y visualización del estado del clúster
- Información a nivel de operación e identificación de cuellos de botella de rendimiento
- Integración con el monitoreo del rendimiento de aplicaciones para una resolución de problemas unificada
DBM representa una mejora sustancial con respecto a la integración básica de MongoDB probada en este benchmark e incluye muchas de las funciones de análisis a nivel de consulta que estuvieron ausentes durante nuestras pruebas56. Las organizaciones que evalúan Datadog para el monitoreo de MongoDB deben evaluar específicamente el producto Database Monitoring en lugar de la integración básica probada aquí.
¿Qué herramienta de monitoreo de bases de datos funciona realmente cuando no eres experto en DevOps?
La experiencia de configuración
SolarWinds abrió con un modal preguntando qué desea monitorear. Usted elige “rendimiento de la base de datos”, selecciona MongoDB y la plataforma encuentra de inmediato el agente que ya instaló, mostrándole el sistema operativo, el ID de la instancia en la nube y el número de versión directamente en la pantalla de selección. Luego le da tres comandos de copiar y pegar para ejecutar en MongoDB, gestiona las credenciales y confirma la implementación. Cinco minutos, de principio a fin.
New Relic tardó quince minutos, y el tiempo ni siquiera era el problema real. La interfaz no dejaba de hacer preguntas que el agente podría haber respondido por sí mismo, como qué sistema operativo y qué versión de MongoDB, a pesar de que el agente ya estaba en el servidor. En un momento dado, usó de forma predeterminada comandos de instalación de Amazon Linux, aunque claramente estábamos ejecutando Ubuntu. El paso que finalmente rompió la experiencia: hay dos opciones de integración de MongoDB en el catálogo de paneles, una estándar y otra basada en Prometheus, y nada en la interfaz las distingue. Elegimos la incorrecta, obtuvimos un panel vacío y solo lo averiguamos revisando los archivos de configuración.
Datadog requirió más de veinte minutos de edición de YAML, adivinando rutas de archivos y reiniciando servicios desde la línea de comandos. La documentación ofrecida durante la configuración no es una guía; es un manual de referencia completo que cubre instancias independientes, conjuntos de réplica, clústeres fragmentados y configuración SSL, todo a la vez, para alguien que solo quiere monitorear una base de datos. Cuando finalmente aparecieron los datos, el panel comenzaba con estadísticas de fragmentación y métricas de conjuntos de réplica. No teníamos ninguna de las dos. Alrededor del sesenta por ciento de la pantalla estaba vacía.
Precisión de las métricas bajo carga
SolarWinds contó 1.400. Exactamente correcto. New Relic reportó 11.670, incorrecto en un orden de magnitud sin una explicación obvia, y pasó por alto por completo un pico de memoria durante la prueba. Cuando detuvimos el servicio de MongoDB, SolarWinds detectó el fallo en un lapso de treinta a cuarenta segundos.
En cuanto al consumo de recursos: New Relic usó alrededor de 90MB de RAM, Datadog alrededor de 330MB y SolarWinds alrededor de 500MB en nuestro servidor de 16GB. SolarWinds realizó aproximadamente cuarenta veces más lecturas de disco que New Relic, probablemente debido al trabajo local de perfilado de consultas. Para la mayoría de los entornos, nada de esto determinará su decisión.
La función que realmente los separa
Cada herramienta de monitoreo le dirá que algo está lento. La pregunta es si le dice por qué.
SolarWinds ofrece perfilado a nivel de consulta. La pestaña Perfilador mostró exactamente qué patrones de consulta se estaban ejecutando, cuánto tardó cada uno y cuántas muestras se capturaron. Puede filtrar por consultas que se ejecutaron sin un índice, devolvieron errores o generaron advertencias.
New Relic y Datadog mostraron solo métricas agregadas de latencia, recuento de conexiones y totales de operaciones. Sin perfilado, sin identificación de consultas lentas, sin detección de índices faltantes. Para confirmar que una base de datos está viva, es funcional. Para diagnosticar por qué tiene problemas, es un callejón sin salida.
Nota: Datadog lanzó un producto Database Monitoring para MongoDB en diciembre de 2024, después de nuestras pruebas, que añade análisis de operaciones lentas, planes de explicación y visibilidad a nivel de consulta. Probamos la integración estándar, que sigue siendo lo que la mayoría de los usuarios encuentran primero.
SolarWinds: si la optimización de la base de datos es su verdadera preocupación. Métricas precisas, configuración rápida y la única plataforma aquí que le dice no solo que una consulta es lenta, sino qué hacer al respecto.
New Relic: si ya lo usa para APM y necesita un estado básico de la base de datos en el mismo lugar. Rastrear una solicitud lenta desde el navegador a través del código hasta la llamada a la base de datos es realmente útil. No confíe en él para recuentos precisos de operaciones.
Datadog: si se siente cómodo con la configuración manual y desea una única plataforma en una pila compleja. Las más de 600 integraciones justifican la fricción de configuración para el equipo adecuado.
Cita este benchmark
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{dogan2026,
author = {Dogan, Sedat and Ermut, Sıla},
title = {{MongoDB Monitoreo: SolarWinds vs New Relic vs Datadog}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/mongodb-monitoring}},
note = {AIMultiple. Recuperado el 16 de septiembre de 2026}
}Resultados y marcas de tiempo de 38 puntos de datos. Descargue los datos resumidos que se muestran en los gráficos y las tablas de este artículo como un archivo ZIP que contiene 7 archivos CSV.
¿Quieres los datos granulares que hay detrás? Únete a Premium
Registro de cambios
5 actualizacionesSe reemplazó la sección "La diferencia principal" por "¿Qué herramienta de monitoreo de bases de datos funciona realmente si no eres un experto en DevOps?".
Se agregaron Actualizaciones de IA a la sección de SolarWinds.
Se añadieron Consideraciones de Seguridad a la metodología.
Enlaces de referencia
- Tiene 20 años de experiencia como hacker de sombrero blanco y gurú del desarrollo, con amplia experiencia en lenguajes de programación y arquitecturas de servidores.
- Es asesor de la junta directiva en un capital de riesgo que invierte en empresas tecnológicas en etapas tempranas y en Ödeal, una plataforma regional de pagos digitales que atiende a 125.000 comercios.
- Ha dirigido la infraestructura tecnológica y la ciberseguridad de siete elecciones nacionales y ha sido reconocido en el Salón de la Fama de la ciberseguridad por líderes tecnológicos globales, incluido Twitter.
Anteriormente trabajó como reclutadora en empresas de gestión de proyectos y consultoría. Sıla tiene un máster en Psicología Social y una licenciatura en Relaciones Internacionales.
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.