Monitorización de MongoDB: SolarWinds vs New Relic vs Datadog
Para realizar pruebas, instalamos SolarWinds, Datadog y New Relic en sistemas limpios con MongoDB 7.0. Seguimos el proceso de configuración completo de cada herramienta, documentando cada paso y cada obstáculo.
Resultados de las pruebas comparativas de las herramientas de monitorización del rendimiento de MongoDB
Plataforma | Tiempo de configuración | Perfilado de consultas | Precisión métrica | Uso de RAM | Lo mejor para |
|---|---|---|---|---|---|
5 minutos | ✅ | ✅ 100% preciso | Mediano (500 MB) | Optimización de la producción | |
Nueva Reliquia | 15 minutos | ❌ | ❌ Baja (tasas de error del 23 al 800%) | Bajo (90 MB) | Controles básicos de salud |
Perro de datos | Más de 20 minutos | ❌ | ⚠️ No está claro | Mediano (330 MB) | Monitorización multitécnica |
Resumen del rendimiento de la monitorización de MongoDB
- SolarWinds completó la configuración en 5 minutos con detección automática y proporcionó un análisis de rendimiento a nivel de consulta del que carecían los demás.
- New Relic tardó 15 minutos con los pasos de verificación manual y arrojó métricas inexactas.
- Datadog requería más de 20 minutos de edición de YAML y solo ofrecía una visibilidad básica.
También puede ver cómo estas plataformas supervisan MySQL y nuestro entorno y metodología de pruebas.
1. Experiencia de instalación e incorporación
1. Solarwinds
SolarWinds completó la integración con MongoDB en menos de 5 minutos. SolarWinds se abre con una ventana modal sencilla: "¿Qué desea monitorizar?". Al seleccionar "Rendimiento de la base de datos ", la plataforma muestra de inmediato las bases de datos compatibles.
Tras seleccionar MongoDB, Solarwinds comprueba si existen agentes.
La plataforma detectó inmediatamente nuestro agente previamente instalado.
Una característica destacaba: la interfaz muestra los detalles del agente (sistema operativo, ID de instancia en la nube, versión) directamente en la pantalla de selección. No es necesario buscar en menús desplegables.
Ahora SolarWinds solicita las credenciales de MongoDB. Introdujimos los detalles de conexión: localhost, método de autenticación (basado en contraseña), nombre de usuario y contraseña. El nombre para mostrar se rellenó automáticamente con la información de nuestro servidor, aunque utilizó el nombre de host interno completo en lugar del nombre del agente que habíamos especificado anteriormente.
Una peculiaridad: el menú desplegable "Captura de consulta" apareció sin explicación. Seleccionamos "Registrar" y continuamos, sin saber qué hacían las demás opciones.
La siguiente pantalla mostraba tres comandos de base de datos para ejecutar. Cada comando tenía un botón para copiar. Los ejecutamos en MongoDB y pulsamos «Observar base de datos».
Aquí es donde Solarwinds nos impresionó. En lugar de pedirnos que averiguáramos los permisos, nos proporcionó comandos para copiar y pegar:
- Cree un usuario de supervisión con credenciales específicas.
- Otorgue 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 complemento indicaba "El complemento se está implementando".
Segundos después, el estado cambió a "Implementación del complemento exitosa" con un enlace para ver el panel de control. Configuración completada.
Descubra la observabilidad de SolarWinds con monitorización profunda de MongoDB y análisis de consultas. Explore SolarWinds.
Visita el sitio web2. Nueva Reliquia
Configurar New Relic llevó aproximadamente 15 minutos, pero el tiempo no fue el verdadero problema. La dificultad surgió al tener que responder preguntas que la plataforma ya debería haber sabido.
New Relic comienza en la página de Integraciones y Agentes.
Buscamos "mongo" y encontramos varias integraciones relacionadas con MongoDB.
Tras seleccionar MongoDB, New Relic nos pidió que eligiéramos un método de instrumentación.
Elegimos "En un host" ya que nuestro agente ya estaba instalado. La siguiente pantalla solicitaba el sistema operativo. Seleccionamos Linux. Nos pareció innecesario, puesto que el agente ya se estaba ejecutando en el servidor, pero continuamos.
La siguiente pantalla solicitaba los detalles del host de MongoDB. Apareció el término "SCRAM" 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 genera confusión.
Tras hacer clic en Continuar, New Relic nos preguntó en qué servidor instalarlo. Esta pregunta debería haber aparecido primero, no después de haber introducido los detalles de configuración. El agente ya estaba instalado en "aimultiple-benchmark", así que lo seleccionamos y continuamos.
La siguiente pantalla nos pedía verificar la compatibilidad de la versión de MongoDB. New Relic nos solicitaba ejecutar mongod --version y confirmar que el resultado coincidiera con sus requisitos. Tuvimos que copiar el comando, abrir la terminal, ejecutarlo, comprobar el número de versión y volver para hacer clic en continuar.
El agente ya está instalado en el servidor. Podría comprobarlo automáticamente.
Tras hacer clic en Continuar, llegamos al paso de creación de usuario. New Relic proporcionó un script de MongoDB para crear el usuario de monitorización. Los comandos eran claros, con las 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 de administrador, pero daba por sentado que averiguaríamos dónde ejecutar estos comandos.
La siguiente pantalla nos pidió que instaláramos el paquete de integración. Ahora New Relic nos pide que lo instalemos manualmente usando yum. Aunque el agente ya está instalado en Ubuntu, la interfaz muestra por defecto Amazon Linux 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 luego pasamos a la siguiente pantalla. New Relic nos proporcionó un archivo de configuración YAML y nos indicó exactamente dónde colocarlo: /etc/newrelic-infra/integrations.d/. Al menos la ruta del archivo era clara.
Creamos el archivo, pegamos la configuración y pulsamos Continuar. En la pantalla final apareció un botón de "Probar conexión". Pulsamos sobre él y esperamos.
La prueba ha sido superada. Configuración completada.
3. Datadog
Datadog tardó más de 20 minutos en completarse. La integración funcionó finalmente, pero llegar a ella requirió un esfuerzo manual considerable.
Tras iniciar sesión, fuimos a Integraciones y buscamos “mongo”. Hicimos clic en MongoDB y apareció una ventana modal.
La descripción general mostraba lo que incluye la monitorización de MongoDB, pero al hacer clic en "Instalar integración" simplemente se abría otra pantalla con instrucciones densas.
Aquí es donde Datadog nos sorprendió. La pantalla mostraba una guía de referencia completa que abarcaba todos los escenarios posibles de MongoDB: instancias independientes, conjuntos de réplicas, clústeres fragmentados, métodos de autenticación, configuración SSL y mucho más.
Para alguien que simplemente intentaba monitorizar una única instancia de MongoDB, la cantidad de texto resultaba excesiva.
Nos desplazamos buscando los pasos básicos:
- Crea un usuario de monitorización en MongoDB.
- Edita el archivo YAML de configuración.
- Reinicie el agente de Datadog.
Datadog proporcionó los comandos de MongoDB para crear el usuario, lo cual fue útil. Pero cuando se trataba del archivo YAML, la documentación indicaba que se editara conf.yaml sin especificar claramente dónde debía ubicarse dicho archivo.
Sabíamos por experiencia que pertenece a /etc/datadog-agent/conf.d/mongo.d/, pero las instrucciones ocultaron este detalle profundamente en 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ó. Ni mensaje de confirmación, ni notificación de éxito, ni redirección a un panel de control. Nada.
Esperamos un momento, luego navegamos manualmente a la sección de Paneles de control y vimos que las métricas de MongoDB comenzaban a aparecer.
2. Consumo de recursos del agente
Monitorizamos la cantidad de recursos que consumía cada agente durante su ejecución. La prueba duró aproximadamente 10 minutos, con los tres agentes recopilando datos simultáneamente de la misma instancia de MongoDB bajo carga.
Sometimos el sistema a una prueba de estrés insertando 2 millones de registros en MongoDB mediante un script que generaba datos aleatorios. Esto simuló la actividad de una base de datos real mientras medíamos el uso de recursos del agente.
Consumo de CPU
Los tres agentes utilizaron recursos mínimos de CPU durante la prueba.
- New Relic mostró el menor consumo promedio de CPU, pero presentó 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, situándose en torno al 3% sin variaciones significativas.
- Datadog se situó en un punto intermedio, con un promedio de poco más del 2% y un rendimiento estable a lo largo de la prueba.
Uso de memoria
El uso de la memoria mostró diferencias más significativas entre los agentes.
New Relic consumió aproximadamente entre 5 y 6 veces menos memoria que Solarwinds. En nuestro servidor de prueba de 16 GB, esto se tradujo en:
- New Relic: ~90 MB
- Datadog: ~330 MB
- Solarwinds: ~500 MB
Para la mayoría de los servidores de producción, estas cantidades no importarán. Pero si se ejecutan agentes en sistemas con recursos limitados o se supervisan 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 un crecimiento inesperado.
E/S de disco
La actividad del disco varió considerablemente entre los agentes.
SolarWinds realizó muchas más lecturas de disco que los otros dos agentes, aproximadamente 40 veces más que New Relic y 1,5 veces más que Datadog. Esto sugiere que SolarWinds accede a los datos almacenados localmente con mayor frecuencia, posiblemente para sus funciones de análisis de consultas.
Datadog fue el que menos datos escribió en el 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 la red
El tráfico de red mostraba la cantidad de datos que cada agente enviaba a su servidor.
Los tres agentes enviaron cantidades similares de datos a través de la red. Datadog transmitió un poco menos, posiblemente debido a una compresión más agresiva o a diferentes frecuencias 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 base de datos con los tres ejecutándose simultáneamente, el consumo total de recursos se mantuvo muy por debajo del 10 % para la CPU y la memoria combinadas.
New Relic destaca por su eficiencia en el uso de la memoria. Solarwinds consume más recursos, pero ofrece un análisis más detallado a nivel de consulta. Datadog se sitúa en un punto intermedio.
En la mayoría de los casos, estas diferencias en los recursos no influirán en tu decisión. Elige en función de las características y la facilidad de uso, no del consumo de recursos.
3. Panel de control y funcionalidades de monitorización
Tras completar la configuración, necesitábamos ver qué mostraba realmente cada plataforma. Ejecutamos la misma carga de trabajo en las tres: insertamos 2 millones de registros en lotes de 5000, seguidos de otros 5 millones de registros.
El script utilizó Node.js con Faker para generar datos de usuario aleatorios, como nombres, correos electrónicos, direcciones y números de teléfono. Esto nos proporcionó un conjunto de datos realista para monitorizar.
Mientras se ejecutaban las inserciones, monitorizamos el consumo de recursos del agente en segundo plano.
La carga de trabajo supuso una gran presión para MongoDB, lo que nos permitió ver cómo cada plataforma capturaba y mostraba la actividad.
Panel de control de Solarwinds
Hicimos clic en "Bases de datos" en el menú de la izquierda e inmediatamente vimos nuestra instancia de MongoDB. Con un solo clic, apareció un panel de control completo.
En la parte superior de la pantalla se mostraba el estado de MongoDB, el tiempo de respuesta promedio, el rendimiento (consultas por segundo) y el número de errores. El gráfico de burbujas «Los 10 patrones de consulta más frecuentes» mostraba los patrones de consulta más utilizados, junto con sus recuentos y porcentajes.
Las cifras lo decían todo. El rendimiento mostraba un promedio de 3 consultas por segundo. El desglose revelaba 1400 operaciones de inserción. ¿Por qué 1400 en lugar de 7 millones?
Insertamos 7 millones de registros en lotes de 5000. Eso equivale a 1400 operaciones por lotes. Solarwinds realizó un seguimiento de cada lote sin omitir ninguno.
La pestaña Perfilador mostraba patrones de consulta con tiempos de ejecución promedio.
Nuestras consultas de inserción tardaban entre 4 y 5 segundos cada una, lo que parece mucho hasta que recuerdas que cada consulta escribía 5.000 filas.
La pestaña Salud mostraba que todo funcionaba correctamente.
Detuvimos el servicio de MongoDB para ver con qué rapidez lo detectaría Solarwinds. En 30-40 segundos, el estado de salud cambió a "Malo".
La pestaña Consultas ofrecía filtrado avanzado. Podía listar las consultas que:
- Errores devueltos
- Se ejecutó sin los índices adecuados.
- Respondió lentamente
- Se generaron advertencias
Cada patrón de consulta mostraba cuándo apareció por primera vez, cuándo se ejecutó por última vez, cuántas muestras se capturaron y estadísticas de ejecución. Este nivel de detalle es importante para la resolución de problemas.
La pestaña Alertas nos permitió crear alertas específicas para MongoDB. Anteriormente habíamos creado una alerta de memoria para el host, pero ahora podíamos configurar notificaciones específicas para la base de datos.
La pestaña Recursos mostraba métricas a nivel de host junto con estadísticas de MongoDB, CPU, memoria, disco y red. Este contexto ayuda a distinguir entre problemas de la base de datos y problemas de infraestructura subyacente.
La pestaña Asesores aún no mostraba recomendaciones, pero sí 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ó el Agente de IA con la función de Asistencia para Consultas de IA (actualmente en versión preliminar). La Asistencia para Consultas de IA analiza los patrones de consulta de la base de datos y propone reescrituras optimizadas para mejorar el rendimiento automáticamente. La Asistencia para la Causa Raíz (ahora disponible para todos) genera análisis claros de la causa raíz basados en alertas y anomalías para reducir el tiempo de resolución de problemas. Se prevé que el Agente de IA esté disponible en todo el portafolio de SolarWinds para 2026. 1 2 .
Panel de control de New Relic
Fuimos a la sección de Paneles de control, pero no apareció ningún panel de control de MongoDB automáticamente.
Buscamos "mongo" en el catálogo del panel de control y encontramos dos opciones de MongoDB.
Seleccionamos el panel de control estándar de MongoDB e hicimos clic en "Configurar MongoDB".
Nos redirigió de nuevo a la configuración de integración de MongoDB. La plataforma ya sabía que habíamos instalado MongoDB, así que ¿por qué volver a la instalación? Hicimos clic en «Listo» y accedimos al panel de control.
El panel de control se abrió completamente vacío. "No se informó ningún valor para la comprobación del servicio mongodb.can_connect".
Verificamos nuestra configuración usando newrelic-infra agent configtest.
Al ejecutar el comando `newrelic-infra agent configtest` para comprobar si había problemas con la configuración, observamos que el `integration_name` estaba configurado como `nri-prometheus`. Durante la configuración del panel de control, New Relic mostró dos opciones de MongoDB, una de las cuales era la versión de Prometheus. Nada en la interfaz de usuario indicaba que se trataba de una integración diferente, por lo que jamás se me habría ocurrido seleccionar la de Prometheus. No fue un error del usuario; simplemente no había ninguna indicación ni distinción en la interfaz.
Volvimos atrás e instalamos el panel de control “MongoDB (Prometheus)”.
Esta vez aparecieron datos.
Pero aquí está el problema: ¿cómo podría un usuario normal resolver esto? El proceso de instalación fue confuso, y ahora la selección del panel de control añade otra capa de complejidad.
El diseño del panel de control resultaba extraño. En la parte superior se mostraba información sobre el total de servidores y bases de datos, que cambia una vez al año, pero ocupaba un espacio privilegiado en la pantalla.
Debajo, aparecía de forma destacada la métrica "Saturación de conexiones". Esta métrica solo importa cuando algo falla. ¿Por qué ponerla al principio?
La sección "Operaciones de consulta" reportó 11.670 inserciones. La cifra era incorrecta. Insertamos 7 millones de registros en 1.400 operaciones por lotes. El gráfico no reflejaba la realidad.
La pestaña Bases de datos mostraba el tamaño de la base de datos, el número de objetos y el tamaño de los índices. Estos números eran correctos: 7 millones de objetos. New Relic obtiene estos datos consultando directamente MongoDB («¿Cuántos documentos tienes?»). Pero el conteo de consultas en tiempo real falló.
La pestaña Colecciones incluía gráficos útiles para las 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 al índice, recuento de ejecuciones de comandos, latencia de comandos, frecuencia de comandos y duración de comandos.
Un dato notablemente ausente: las métricas del host. No pudimos ver el uso de CPU, memoria, disco ni red del servidor que ejecuta MongoDB. SolarWinds incluía esta información, pero Datadog, al igual que New Relic, no.
Más importante aún, no existía ningún análisis a nivel de consulta. Ni patrones de consulta, ni perfiles de rendimiento, ni identificación de consultas lentas, ni detección de índices faltantes. Para la resolución de problemas de bases de datos, estas características son fundamentales.
Panel de control de Datadog
Hicimos clic en “Paneles de control” en el menú de la izquierda. Apareció automáticamente un panel de control llamado “MongoDB – Descripción general”.
Lo abrimos, pero estaba vacío.
El problema tardó en diagnosticarse. Durante la instalación, la configuración de detección automática de Datadog requería especificar qué bases de datos monitorizar mediante una coincidencia de patrones. El patrón predeterminado no coincidía con el nombre de nuestra base de datos. Datadog no mencionó este problema durante la configuración.
Cambiamos todos los patrones a .* (coinciden con todo) y reiniciamos el agente.
Pero, ¿por qué el panel de control estaba completamente vacío? Incluso sin métricas específicas de la base de datos, deberían haber aparecido el tiempo de actividad, el número de conexiones y las estadísticas del servidor. No aparecieron.
Ejecutamos datadog-agent check mongo para depurar. El archivo de configuración tenía un error de indentación. El estricto formato de YAML nos pilló desprevenidos. Tras corregirlo y volver a ejecutar la prueba de carga con 5 millones de inserciones, finalmente aparecieron los datos.
Enseguida nos topamos con problemas en el panel de control. La sección de Registros mostraba el mensaje "No accesible" a pesar de que habíamos configurado la recopilación de registros en nuestro archivo YAML. El proceso de configuración de Datadog indicaba que todo estaba correcto, pero los registros seguían sin funcionar.
El diseño del panel de control no se ajustaba a nuestras necesidades. La sección superior se centraba en las estadísticas de fragmentación, pero no estábamos utilizando un clúster fragmentado. La sección central mostraba métricas de conjuntos de réplicas, pero tampoco teníamos conjuntos de réplicas. La sección inferior volvía a mostrar información sobre fragmentación. Aproximadamente el 60 % del panel mostraba secciones vacías correspondientes a funciones que no utilizábamos.
La información útil ocupaba aproximadamente el 40% de la pantalla: tiempo de actividad, uso de memoria, E/S de red, consultas por segundo y latencia de lectura/escritura. No había análisis de consultas, ni generación de perfiles, ni detección de consultas lentas, ni recomendaciones de índices.
Ni siquiera pudimos determinar cuántas operaciones se ejecutaron desde este panel de control.
Entorno y metodología de prueba
Ejecutamos las tres herramientas en configuraciones idénticas para garantizar una comparación justa. Cada prueba utilizó:
- Base de datos: MongoDB 7.0 Community Edition
- Servidor: instancia AWS m6i.xlarge
- Punto de partida: Instalación nueva con el agente de monitorización principal ya instalado.
Los tres proveedores requieren la instalación de su agente base antes de agregar integraciones específicas, como MongoDB. Realizamos ese paso previamente, por lo que nuestra prueba se centró exclusivamente en la experiencia de integración con MongoDB.
Lo que medimos:
- Complejidad de la 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 el estado inactivo y bajo carga (insertando 7 millones de registros).
- Funcionalidades de monitorización: calidad del panel de control, precisión de las métricas, análisis a nivel de consulta y funciones de resolución de problemas.
Consideraciones de seguridad
Se ha descubierto una grave vulnerabilidad denominada «MongoBleed», que afecta a las versiones de MongoDB Server anteriores a la 8.0.17, 7.0.28, 6.0.27 y anteriores. Esta vulnerabilidad de lectura fuera de límites sin autenticación podría permitir a los atacantes acceder a datos confidenciales de la memoria. Las organizaciones que utilizan MongoDB deben actualizar inmediatamente a las versiones parcheadas: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 o 4.4.30. 3 4 Al seleccionar herramientas de monitoreo, asegúrese de que admitan métodos de autenticación seguros y no introduzcan riesgos de seguridad adicionales.
Utilizamos cada herramienta como lo haría un usuario común, sin leer la documentación previamente y sin formación alguna. Si algo no resultaba evidente en la interfaz, lo anotábamos.
Veredicto final
Nos propusimos responder a una pregunta sencilla: ¿qué plataforma de monitorización facilita la integración de MongoDB a equipos no técnicos?
Tras instalar las tres soluciones, ejecutar cargas de trabajo idénticas y evaluar los paneles de control, la respuesta quedó clara. Nuestra evaluación se basa en la integración básica de Datadog con MongoDB a partir de enero de 2025. Desde entonces, Datadog ha lanzado Database Monitoring (DBM) para MongoDB (diciembre de 2024), que ofrece capacidades significativamente más avanzadas, incluyendo el análisis de consultas, el análisis de operaciones lentas, los planes de ejecución y la monitorización de la replicación. El producto DBM soluciona muchas de las limitaciones identificadas en esta prueba comparativa. 5 .
Solarwinds: Diseñado para la monitorización de bases de datos.
SolarWinds ganó esta comparativa de forma contundente. La plataforma detectó inmediatamente nuestro agente, nos guió en la configuración de credenciales mediante comandos de copiar y pegar, e implementó automáticamente la integración. La configuración tardó 5 minutos.
El panel de control apareció al instante con información relevante. El análisis de consultas mostró con precisión qué operaciones consumían más recursos. La plataforma registró las 1400 operaciones por lotes sin omitir ninguna. Al detener MongoDB, SolarWinds detectó el fallo en 40 segundos.
La pestaña Consultas nos permite filtrar por errores, índices faltantes, respuestas lentas y advertencias, características que contribuyen directamente a la optimización de la base de datos. Se esperaba que la función Asesores proporcionara recomendaciones (aunque no generamos suficientes datos para que se activara ninguna durante nuestra prueba).
Solarwinds se centró en lo que realmente necesitan los administradores de bases de datos: análisis de consultas, elaboración de perfiles de rendimiento e información práctica.
New Relic: Lost in Configuration
La configuración de New Relic tardó 15 minutos, pero el tiempo no fue el principal problema. La plataforma formulaba las preguntas en el orden incorrecto, requería la verificación manual de elementos que el agente podía comprobar automáticamente y nos obligaba a instalar paquetes manualmente.
La confusión con el panel de control empeoró las cosas. Instalamos la monitorización de MongoDB, pero al seleccionar el panel predeterminado, la pantalla aparecía en blanco. 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 se habría dado cuenta de esto.
Cuando finalmente aparecieron los datos, las métricas eran erróneas. New Relic informó de 11 670 inserciones tras realizar 1400 operaciones por lotes, lo que supuso un total de 7 millones de registros. La plataforma subestimó la cantidad real en un orden de magnitud.
Más importante aún, New Relic no proporcionaba análisis a nivel de consulta. No realizaba análisis de rendimiento, no detectaba consultas lentas ni identificaba índices faltantes. Para la resolución de problemas de bases de datos, estas omisiones son importantes.
Datadog: Se requiere trabajo manual.
Datadog requirió más de 20 minutos de configuración y la mayor parte de la configuración manual. Editamos los archivos YAML, determinamos dónde ubicarlos y reiniciamos los servicios desde la línea de comandos.
El panel de control apareció automáticamente, pero no mostraba nada. La configuración de detección automática utilizaba un patrón que no coincidía con nuestra base de datos. Tras corregir el patrón y los errores de indentación de YAML, finalmente se cargaron los datos.
El panel de control resultó estar mal diseñado para una instancia única de MongoDB. El sesenta por ciento de la pantalla estaba vacío, con secciones para funciones de fragmentación y conjuntos de réplicas que no utilizábamos. 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 elaboración de perfiles. Sin recomendaciones de optimización. No pudimos determinar con precisión el número de operaciones en el panel de control.
Sin análisis de consultas. Sin elaboración de perfiles. Sin recomendaciones de optimización. No pudimos determinar con precisión el número de operaciones en el panel de control.
Actualización crítica (diciembre de 2024) : Tras completar esta evaluación comparativa, Datadog lanzó Database Monitoring (DBM) para MongoDB, lo que modifica significativamente esta evaluación. DBM para MongoDB ahora ofrece:
- Análisis de operaciones lentas con ejemplos de consultas detalladas
- Explique los planes para la optimización de consultas.
- Monitorización del estado de replicación y visualización del estado del clúster.
- Identificación de información operativa y cuellos de botella en el rendimiento
- Integración con la monitorización del rendimiento de las 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 esta comparativa e incluye muchas de las características de análisis a nivel de consulta que estaban ausentes durante nuestras pruebas. 6 7 Las organizaciones que evalúen Datadog para la monitorización de MongoDB deberían evaluar específicamente el producto de monitorización de bases de datos en lugar de la integración básica probada aquí.
¿Qué herramienta de monitorización de bases de datos funciona realmente cuando no eres un experto en DevOps?
La experiencia de configuración
SolarWinds se abre con una ventana emergente que pregunta qué desea monitorizar. Seleccione «Rendimiento de la base de datos», elija MongoDB y la plataforma encontrará inmediatamente el agente que ya ha instalado, 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. A continuación, le proporciona tres comandos para copiar y pegar que debe 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 fue el verdadero problema. La interfaz seguía haciendo 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, ejecutó por defecto comandos de instalación de Amazon Linux, aunque claramente estábamos usando Ubuntu. El paso que finalmente arruinó la experiencia: hay dos opciones de integración de MongoDB en el catálogo del panel de control, una estándar y otra basada en Prometheus, y nada en la interfaz de usuario las distingue. Elegimos la incorrecta, obtuvimos un panel de control vacío y solo lo descubrimos al examinar 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 abarca instancias independientes, conjuntos de réplicas, clústeres fragmentados y configuración SSL, todo a la vez, para alguien que solo quiere monitorizar una base de datos. Cuando finalmente aparecieron los datos, el panel mostraba estadísticas de fragmentación y métricas de conjuntos de réplicas. No teníamos ninguna de las dos. Aproximadamente el sesenta por ciento de la pantalla estaba vacía.
Precisión métrica bajo carga
SolarWinds contabilizó 1400. Exactamente. New Relic reportó 11 670, un error de un orden de magnitud sin explicación aparente, y no detectó un pico de memoria durante la prueba. Al detener el servicio de MongoDB, SolarWinds detectó el fallo en treinta o cuarenta segundos.
En cuanto al consumo de recursos: New Relic utilizó alrededor de 90 MB de RAM, Datadog alrededor de 330 MB y SolarWinds alrededor de 500 MB en nuestro servidor de 16 GB. SolarWinds realizó aproximadamente cuarenta veces más lecturas de disco que New Relic, probablemente debido al análisis local del rendimiento de las consultas. En la mayoría de los entornos, ninguno de estos factores influirá en su decisión.
La característica que realmente los diferencia
Todas las herramientas de monitorización te dirán que algo va lento. La cuestión es si te dicen por qué .
SolarWinds ofrece análisis de rendimiento a nivel de consulta. La pestaña Perfilador muestra con precisión qué patrones de consulta se ejecutaron, cuánto tiempo tardó cada uno y cuántas muestras se capturaron. Puede filtrar por consultas que se ejecutaron sin índice, devolvieron errores o generaron advertencias.
New Relic y Datadog solo mostraban métricas agregadas de latencia, número de conexiones y totales de operaciones. No ofrecían análisis de rendimiento, identificación de consultas lentas ni detección de índices faltantes. Para confirmar que una base de datos está activa, son útiles. Para diagnosticar por qué tiene problemas, son un callejón sin salida.
Nota: Tras nuestras pruebas, Datadog lanzó en diciembre de 2024 un producto de monitorización de bases de datos para MongoDB que incluye análisis de operaciones lentas , planes de ejecución y visibilidad a nivel de consulta. Probamos la integración estándar, que sigue siendo la que la mayoría de los usuarios encuentran primero.
SolarWinds : Si la optimización de bases de datos es su principal preocupación. Métricas precisas, configuración rápida y la única plataforma que no solo le indica que una consulta es lenta, sino también qué hacer al respecto.
New Relic : Si ya lo usas para APM y necesitas monitorizar el estado básico de la base de datos en el mismo lugar, rastrear una solicitud lenta desde el navegador, pasando por el código, hasta la llamada a la base de datos es realmente útil. No confíes en él para obtener recuentos precisos de operaciones.
Datadog : Si te sientes cómodo con la configuración manual y deseas una única plataforma para una infraestructura compleja, sus más de 600 integraciones justifican la complejidad de la configuración para el equipo adecuado.
Enlaces de referencia
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios.