MongoDB Monitoring: SolarWinds vs New Relic vs Datadog
Abbiamo installato SolarWinds, Datadog e New Relic su sistemi puliti con MongoDB 7.0 per il test. Abbiamo attraversato l'intero processo di configurazione di ogni strumento, documentando ogni passaggio e ostacolo.
Risultati del benchmark degli strumenti di monitoraggio delle prestazioni di MongoDB
Piattaforma | Tempo di configurazione | Query Profiling | Accuratezza metriche | Utilizzo RAM | Ideale per |
|---|---|---|---|---|---|
5 min | ✅ | 100% accurato | Medio (500MB) | Ottimizzazione produzione | |
New Relic | 15 min | ❌ | Bassa (tassi di errore dal 23% all'800%) | Basso (90MB) | Controlli di salute di base |
Datadog | 20+ min | ❌ | Non chiaro | Medio (330MB) | Monitoraggio multi-tech |
Riepilogo prestazioni del monitoraggio di MongoDB
- SolarWinds ha completato la configurazione in 5 minuti con il rilevamento automatico e ha fornito un profiling a livello di query che agli altri mancava.
- New Relic ha richiesto 15 minuti con passaggi di verifica manuale e ha riportato metriche imprecise.
- Datadog ha richiesto oltre 20 minuti di editing YAML e ha offerto solo una visibilità di base.
Puoi anche vedere come queste piattaforme monitorano MySQL e il nostro ambiente di test e la metodologia
1. Esperienza di Installazione e Onboarding
1. Solarwinds
SolarWinds ha completato l'integrazione di MongoDB in meno di 5 minuti. Solarwinds si apre con un semplice modal: “Cosa vuoi monitorare?”. Quando selezioni prestazioni del database, la piattaforma mostra subito i database supportati.
Dopo aver selezionato MongoDB, Solarwinds controlla se esistono agent già installati.
La piattaforma ha immediatamente rilevato il nostro agent precedentemente installato.
Una funzionalità è risaltata: l'interfaccia mostra i dettagli dell'agent (sistema operativo, ID istanza cloud, versione) direttamente nella schermata di selezione. Nessuna ricerca tra menu a discesa.
Ora SolarWinds richiede le credenziali di MongoDB. Abbiamo inserito i dettagli di connessione: localhost, metodo di autenticazione (basato su password), nome utente e password. Il nome visualizzato è stato auto-compilato con le informazioni del nostro server, sebbene abbia utilizzato l'intero hostname interno invece del nome dell'agent specificato in precedenza.
Una stranezza: il menu a discesa “Query Capture” è apparso senza spiegazioni. Abbiamo selezionato “Log” e siamo andati avanti, non sapendo cosa facessero le altre opzioni.
La schermata successiva presentava tre comandi del database da eseguire. Ogni comando aveva un pulsante di copia. Li abbiamo eseguiti in MongoDB e abbiamo cliccato su “Observe Database”.
Ecco dove Solarwinds ci ha colpito. Invece di chiederci di capire i permessi, ha fornito comandi copia-incolla:
- Crea un utente di monitoraggio con credenziali specifiche
- Concedi i privilegi necessari (ruoli clusterMonitor e readAnyDatabase)
- Imposta il livello di profiling
È apparsa una schermata di riepilogo che mostrava la nostra configurazione. Lo stato del plugin indicava “Plugin is being deployed”.
Pochi secondi dopo, lo stato è cambiato in “Plugin deployment is successful” con un link per visualizzare la dashboard. Configurazione completata.
Scopri l'Osservabilità di SolarWinds con monitoraggio profondo di MongoDB e query profiling. Esplora SolarWinds.
Visita il sito web2. New Relic
New Relic ha richiesto circa 15 minuti per la configurazione, ma il tempo non era il vero problema. L'attrito derivava dal dover rispondere a domande che la piattaforma avrebbe già dovuto conoscere.
New Relic inizia dalla pagina Integrations & Agents.
Abbiamo cercato “mongo” e trovato diverse integrazioni relative a MongoDB.
Dopo aver selezionato MongoDB, New Relic ci ha chiesto di scegliere un metodo di strumentazione.
Abbiamo scelto “On a host” poiché il nostro agent era già installato. La schermata successiva chiedeva il sistema operativo. Abbiamo selezionato Linux. Questo sembrava superfluo dato che l'agent era già in esecuzione sul server, ma abbiamo continuato.
La schermata successiva chiedeva i dettagli dell'host MongoDB. Il termine “SCRAM” è apparso senza spiegazioni. La maggior parte delle persone lo conosce come autenticazione username/password, ma il termine tecnico aggiunge confusione.
Dopo aver cliccato su continua, New Relic ci ha chiesto su quale server installare. Questa domanda sarebbe dovuta arrivare per prima, non dopo che avevamo già inserito i dettagli di configurazione. L'agent era già installato su “aimultiple-benchmark”, quindi lo abbiamo selezionato e siamo proseguiti.
La schermata successiva ci ha chiesto di verificare la compatibilità della versione di MongoDB. New Relic voleva che eseguissimo mongod --version e confermassimo che l'output corrispondesse ai suoi requisiti. Abbiamo dovuto copiare il comando, passare al nostro terminale, eseguirlo, controllare il numero di versione e tornare indietro per cliccare su continua.
L'agent è già installato sul server. Potrebbe controllare questo automaticamente.
Dopo aver cliccato su continua, siamo arrivati al passaggio di creazione dell'utente. New Relic ha fornito uno script MongoDB per creare l'utente di monitoraggio. I comandi erano chiari, con le corrette assegnazioni di ruolo (clusterMonitor e readAnyDatabase). Abbiamo anche dovuto eseguire un comando di test della connessione per verificare che l'utente funzionasse correttamente.
Questo approccio era migliore rispetto a chiedere l'accesso root, ma presupponeva che avremmo capito dove eseguire questi comandi.
La schermata successiva ci ha chiesto di installare il pacchetto di integrazione. Ora New Relic vuole che installiamo manualmente usando yum. Anche se l'agent è già installato su Ubuntu, l'interfaccia predefinisce Amazon Linux e fornisce comandi di installazione yum invece di apt. Ci aspettavamo che la piattaforma rilevasse automaticamente l'OS corretto dall'agent installato.
Abbiamo eseguito il corretto comando apt per Ubuntu, poi siamo passati alla schermata successiva. New Relic ha fornito un file di configurazione YAML e ci ha detto esattamente dove metterlo: /etc/newrelic-infra/integrations.d/. Almeno il percorso del file era chiaro.
Abbiamo creato il file, incollato la configurazione e cliccato su Continua. L'ultima schermata mostrava un pulsante “Test connection”. Abbiamo cliccato e abbiamo aspettato.
Il test è passato. Configurazione completata.
3. Datadog
Datadog ha richiesto oltre 20 minuti per essere completato. L'integrazione ha funzionato alla fine, ma arrivarci ha richiesto uno sforzo manuale significativo.
Dopo aver effettuato l'accesso, siamo andati su Integrations e abbiamo cercato “mongo”. Abbiamo cliccato su MongoDB ed è apparso un modal.
La panoramica mostrava cosa include il monitoraggio di MongoDB, ma cliccando su “Install Integration” si è aperta un'altra schermata con istruzioni dense.
È qui che Datadog ci ha sopraffatti. La schermata mostrava una guida di riferimento completa che copriva ogni possibile scenario di MongoDB: istanze standalone, replica set, cluster sharded, metodi di autenticazione, configurazione SSL e altro ancora.
Per chi cerca solo di monitorare una singola istanza di MongoDB, quel muro di testo sembrava eccessivo.
Abbiamo scorso la pagina cercando i passaggi di base:
- Crea un utente di monitoraggio in MongoDB
- Modifica il file di configurazione YAML
- Riavvia l'agent Datadog
Datadog ha fornito i comandi MongoDB per creare l'utente, il che è stato utile. Ma quando si è arrivati al file YAML, la documentazione diceva di modificare conf.yaml senza dichiarare chiaramente dove dovesse andare questo file.
Sapevamo per esperienza che appartiene a /etc/datadog-agent/conf.d/mongo.d/, ma le istruzioni nascondevano questo dettaglio in profondità nella documentazione.
Abbiamo creato l'utente MongoDB, scritto la configurazione YAML, l'abbiamo inserita nella directory corretta e abbiamo riavviato l'agent.
Poi siamo tornati all'interfaccia di Datadog e abbiamo cliccato su “Install Integration”.
Il pulsante è scomparso. Nessun messaggio di conferma, nessuna notifica di successo, nessun reindirizzamento a una dashboard. Nulla.
Abbiamo aspettato un momento, poi siamo navigati manualmente nella sezione Dashboards e abbiamo trovato le metriche di MongoDB che iniziavano a popolarsi.
2. Consumo di Risorse dell'Agent
Abbiamo monitorato quante risorse consumava ogni agent durante l'esecuzione. Il test è durato circa 10 minuti con tutti e tre gli agent che raccoglievano dati simultaneamente dalla stessa istanza di MongoDB sotto carico.
Abbiamo stressato il sistema inserendo 2 milioni di record in MongoDB utilizzando uno script che generava dati casuali. Questo ha simulato l'attività del database nel mondo reale mentre misuravamo l'utilizzo delle risorse dell'agent.
Consumo CPU
Tutti e tre gli agent hanno utilizzato risorse CPU minime durante il test.
- New Relic ha mostrato il consumo medio di CPU più basso, ma ha avuto picchi occasionali che raggiungevano il 4%. Questi picchi erano brevi e non hanno influito sulle prestazioni del sistema.
- Solarwinds ha mantenuto l'utilizzo della CPU più costante, rimanendo intorno al 3% senza variazioni significative.
- Datadog si è posizionato nel mezzo, con una media di poco superiore al 2% e prestazioni stabili per tutto il test.
Utilizzo della Memoria
L'utilizzo della memoria ha mostrato differenze più significative tra gli agent.
New Relic ha consumato circa 5-6 volte meno memoria rispetto a Solarwinds. Sul nostro server di test da 16GB, questo si è tradotto in:
- New Relic: ~90MB
- Datadog: ~330MB
- Solarwinds: ~500MB
Per la maggior parte dei server di produzione, queste quantità non saranno rilevanti. Ma se esegui agent su sistemi con risorse limitate o monitori centinaia di database, la differenza si accumula.
L'utilizzo della memoria è rimasto stabile per tutti e tre gli agent durante il test. Non si sono verificati leak di memoria o crescite inaspettate.
Disk I/O
L'attività del disco è variata considerevolmente tra gli agent.
SolarWinds ha eseguito significativamente più letture di disco rispetto agli altri due agent, circa 40 volte più di New Relic e 1,5 volte più di Datadog. Ciò suggerisce che SolarWinds acceda più frequentemente ai dati memorizzati localmente, probabilmente per le sue funzionalità di query profiling.
Datadog ha scritto meno sul disco, indicando che effettua meno buffering di dati localmente prima di inviarli al cloud.
New Relic ha mostrato il pattern di I/O più equilibrato con letture e scritture moderate.
Utilizzo della Rete
Il traffico di rete ha mostrato quanti dati ogni agent ha inviato al proprio backend.
Tutti e tre gli agent hanno inviato quantità simili di dati sulla rete. Datadog ne ha trasmessi leggermente meno, forse a causa di una compressione più aggressiva o di tassi di campionamento differenti.
Il traffico bidirezionale ha senso, poiché gli agent inviano metriche e ricevono aggiornamenti di configurazione o comandi dalla piattaforma.
Riepilogo Impatto Risorse
Nessuno di questi agent affaticherà il tuo sistema. Anche sotto carico del database con tutti e tre in esecuzione simultaneamente, il consumo totale di risorse è rimasto ben al di sotto del 10% per CPU e memoria combinate.
New Relic vince per efficienza della memoria. Solarwinds usa più risorse ma fornisce un'analisi a livello di query più dettagliata. Datadog si posiziona nel mezzo.
Per la maggior parte dei casi d'uso, queste differenze di risorse non influenzeranno la tua decisione. Scegli in base alle funzionalità e all'usabilità, non al consumo di risorse.
Aggiungi come fonte preferita3. Dashboard e Capacità di Monitoraggio
Dopo aver completato la configurazione, avevamo bisogno di vedere cosa mostra effettivamente ogni piattaforma. Abbiamo eseguito lo stesso carico di lavoro su tutte e tre: inserimento di 2 milioni di record in lotti di 5.000, seguiti da altri 5 milioni di record.
Lo script ha utilizzato Node.js con Faker per generare nomi utente, email, indirizzi e numeri di telefono casuali. Questo ci ha fornito un dataset realistico da monitorare.
Mentre venivano eseguiti gli inserimenti, abbiamo monitorato il consumo di risorse dell'agent in background.
Il carico di lavoro ha messo sotto stress reale MongoDB, il che ci ha permesso di vedere come ogni piattaforma catturava e visualizzava l'attività.
Dashboard Solarwinds
Abbiamo cliccato su “Databases” nel menu a sinistra e abbiamo immediatamente visto la nostra istanza di MongoDB. Un clic, ed è apparsa una dashboard completa.
La parte superiore della schermata mostrava la salute di MongoDB, il tempo di risposta medio, il throughput (query al secondo) e il conteggio degli errori. Il grafico a bolle “Top 10 Service Breakdown” mostrava i pattern di query più utilizzati con i relativi conteggi e percentuali.
I numeri raccontavano una storia. Il throughput mostrava in media 3 query al secondo. Il breakdown mostrava 1.400 operazioni di inserimento. Perché 1.400 invece di 7 milioni?
Abbiamo inserito 7 milioni di record in lotti di 5.000. Sono 1.400 operazioni batch. Solarwinds ha tracciato ogni singolo batch senza dimenticarne nessuno.
La scheda Profiler mostrava i pattern di query con i tempi medi di esecuzione.
Le nostre query di inserimento richiedevano 4-5 secondi ciascuna, il che sembra molto finché non ricordi che ogni query scriveva 5.000 righe.
La scheda Health mostrava che tutto funzionava senza problemi.
Abbiamo interrotto il servizio MongoDB per vedere quanto velocemente Solarwinds se ne sarebbe accorto. Entro 30-40 secondi, lo stato di salute è cambiato in “Bad”.
La scheda Queries forniva un filtraggio avanzato. Potevi elencare le query che:
- Hanno restituito errori
- Sono state eseguite senza indici appropriati
- Hanno risposto lentamente
- Hanno generato avvisi
Ogni pattern di query mostrava quando è apparso per la prima volta, quando è stato eseguito l'ultima volta, quanti campioni sono stati catturati e le statistiche di esecuzione. Per la risoluzione dei problemi, questo livello di dettaglio è fondamentale.
La scheda Alerts ci ha permesso di creare avvisi specifici per MongoDB. Avevamo creato un avviso di memoria per l'host in precedenza, ma ora potevamo impostare notifiche specifiche per il database.
La scheda Resources mostrava metriche a livello di host insieme alle statistiche di MongoDB, CPU, memoria, disco e rete. Questo contesto aiuta a distinguere tra problemi del database e problemi dell'infrastruttura sottostante.
La scheda Advisors non aveva ancora raccomandazioni, ma le aveva fornite per MySQL nel nostro test precedente. Ci aspettiamo che offra suggerimenti di ottimizzazione man mano che raccoglie più dati di MongoDB.
Aggiornamenti AI: nell'ottobre 2025, SolarWinds ha lanciato l'AI Agent con la funzionalità AI Query Assist (attualmente in tech preview). AI Query Assist analizza i pattern di query del database e propone riscritture ottimizzate per migliorare automaticamente le prestazioni. Root Cause Assist (ora generalmente disponibile) genera analisi chiare della causa radice basate su avvisi e anomalie per ridurre i tempi di risoluzione dei problemi. La disponibilità più ampia dell'AI Agent in tutto il portfolio SolarWinds è prevista per il 20261 2 .
Dashboard New Relic
Siamo andati nella sezione Dashboards, ma nessuna dashboard di MongoDB è apparsa automaticamente.
Abbiamo cercato “mongo” nel catalogo delle dashboard e abbiamo trovato due opzioni per MongoDB.
Abbiamo selezionato la dashboard regolare di MongoDB e abbiamo cliccato su “Setup MongoDB.”
Siamo stati reindirizzati nuovamente alla configurazione dell'integrazione MongoDB. La piattaforma sapeva già che avevamo installato MongoDB, quindi perché rimandarci all'installazione? Abbiamo cliccato su “Done” e siamo passati alla dashboard.
La dashboard si è aperta completamente vuota. “No value reported for service check mongodb.can_connect.”
Abbiamo controllato la nostra configurazione usando newrelic-infra agent configtest.
Quando abbiamo eseguito il comando configtest dell'agent newrelic-infra per controllare eventuali problemi con la nostra configurazione, abbiamo notato che l'integration_name era impostato su nri-prometheus. Durante la configurazione della dashboard, New Relic aveva mostrato due opzioni per MongoDB, una delle quali era la versione Prometheus. Nulla nell'interfaccia indicava che si trattasse di un'integrazione diversa, quindi non mi sarebbe mai passato per la testa di aver selezionato quella di Prometheus. Questo non è stato un errore dell'utente; semplicemente non c'era alcuna guida o distinzione nell'interfaccia.
Siamo tornati indietro e abbiamo installato la dashboard “MongoDB (Prometheus)”.
Questa volta, i dati sono apparsi.
Ma ecco il problema: come farebbe un utente normale a capirlo? Il processo di installazione era confuso, e ora la selezione della dashboard ha aggiunto un altro livello di complessità.
Il layout della dashboard sembrava strano. La parte superiore mostrava informazioni totali su server e database che cambiano una volta all'anno, eppure occupava lo spazio più prezioso della schermata.
Sotto, appariva in modo prominente la “Connection Saturation”. Questa metrica conta solo quando qualcosa non va. Perché metterla in alto?
La sezione “Query Operations” riportava 11.670 inserimenti. Il numero era sbagliato. Abbiamo inserito 7 milioni di record in 1.400 operazioni batch. Il grafico non corrispondeva alla realtà.
La scheda Databases mostrava la dimensione del database, il conteggio degli oggetti e le dimensioni degli indici. Questi numeri erano corretti: 7 milioni di oggetti. New Relic ottiene questi dati interrogando MongoDB direttamente (“Quanti documenti hai?”). Ma il conteggio delle query in tempo reale è fallito.
La scheda Collections includeva grafici utili per le metriche a livello di collezione: dimensione (con visualizzazioni sia a tabella che a grafico), dimensione totale con variazione percentuale, conteggio operazioni di lettura, latenza di lettura, conteggio operazioni di scrittura, latenza di scrittura, conteggi transazioni, latenza transazioni, operazioni di accesso agli indici, conteggi esecuzione comandi, latenza comandi, frequenza comandi e durata comandi.
Notevolmente assenti: le metriche dell'host. Non potevamo vedere l'utilizzo di CPU, memoria, disco o rete per il server che eseguiva MongoDB. SolarWinds includeva questo contesto, ma Datadog, come New Relic, no.
Ancora più importante, non esisteva alcuna analisi a livello di query. Nessun pattern di query, nessun profiling, nessun'identificazione di slow query, nessun rilevamento di indici mancanti. Per la risoluzione dei problemi del database, queste funzionalità sono fondamentali.
Dashboard Datadog
Abbiamo cliccato su “Dashboards” nel menu a sinistra. È apparsa automaticamente una dashboard “MongoDB – Overview”.
L'abbiamo aperta, ma era vuota.
Il problema ha richiesto tempo per essere diagnosticato. Durante l'installazione, la configurazione di autodiscovery di Datadog richiedeva di specificare quali database monitorare utilizzando un pattern di corrispondenza. Il pattern predefinito non corrispondeva al nome del nostro database. Datadog non ha mai menzionato questo durante la configurazione.
Abbiamo cambiato tutti i pattern in .* (corrispondenza totale) e abbiamo riavviato l'agent.
Ma perché la dashboard era completamente vuota? Anche senza metriche specifiche del database, l'uptime, i conteggi di connessione e le statistiche del server avrebbero dovuto apparire. Non è successo.
Abbiamo eseguito datadog-agent check mongo per fare il debug. Il file di configurazione aveva un errore di indentazione. Il rigido requisito di formattazione di YAML ci ha beccato. Dopo averlo corretto e aver rieseguito il nostro test di carico con 5 milioni di inserimenti, i dati sono finalmente apparsi.
Siamo immediatamente incappati in problemi con la dashboard. La sezione Logs mostrava “Not Accessible” nonostante avessimo configurato la raccolta dei log nel nostro file YAML. Il processo di configurazione di Datadog riportava che tutto era a posto, ma i log ancora non funzionavano.
Il layout della dashboard aveva poco senso per il nostro caso d'uso. La sezione superiore si concentrava sulle statistiche di sharding. Non stavamo eseguendo un cluster sharded. La parte centrale mostrava metriche del replica set. Non avevamo replica set. La parte inferiore tornava di nuovo allo sharding. Circa il 60% della dashboard mostrava sezioni vuote per funzionalità che non stavamo utilizzando.
Le informazioni utili occupavano forse il 40% della schermata: uptime, utilizzo della memoria, I/O di rete, query al secondo e latenza di lettura/scrittura. Nessuna analisi delle query, nessun profiling, nessun rilevamento di slow query, nessuna raccomandazione sugli indici.
Non potevamo nemmeno determinare quanti operazioni fossero state eseguite da questa dashboard.
Ambiente di Test e Metodologia
Abbiamo eseguito tutti e tre gli strumenti su configurazioni identiche per garantire un confronto equo. Ogni test ha utilizzato:
- Database: MongoDB 7.0 Community Edition
- Server: istanza AWS m6i.xlarge
- Punto di partenza: Installazione fresca con l'agent di monitoraggio principale già installato
Tutti e tre i fornitori richiedono l'installazione del loro agent di base prima di aggiungere integrazioni specifiche, come MongoDB. Abbiamo completato quel passaggio in precedenza, quindi il nostro test si è concentrato puramente sull'esperienza di integrazione di MongoDB.
Cosa abbiamo misurato:
- Complessità di configurazione: Numero di passaggi manuali, configurazione automatica rispetto a quella manuale, chiarezza delle istruzioni e se l'interfaccia ci ha guidati o ci ha lasciato cercare i passaggi successivi.
- Consumo di risorse dell'agent: CPU, memoria, I/O del disco e utilizzo della rete durante l'inattività e sotto carico (inserimento di 7 milioni di record).
- Capacità di monitoraggio: Qualità della dashboard, accuratezza delle metriche, analisi a livello di query e funzionalità di risoluzione dei problemi.
Considerazioni sulla Sicurezza
È stata divulgata una grave vulnerabilità chiamata “MongoBleed”, che interessa le versioni del Server MongoDB precedenti alla 8.0.17, 7.0.28, 6.0.27 e precedenti. Questa vulnerabilità di lettura fuori limite non autenticata potrebbe consentire agli aggressori di accedere a dati sensibili in memoria. Le organizzazioni che utilizzano MongoDB dovrebbero aggiornare immediatamente alle versioni patchate: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 o 4.4.303 4 . Quando si selezionano gli strumenti di monitoraggio, assicurarsi che supportino metodi di autenticazione sicuri e non introducano rischi di sicurezza aggiuntivi.
Abbiamo approcciato ogni strumento come farebbe un utente regolare, senza leggere la documentazione in precedenza e senza alcuna formazione prioritaria. Se qualcosa non era apparente nell'interfaccia, lo abbiamo annotato.
Verdetto Finale
Ci siamo posti l'obiettivo di rispondere a una domanda semplice: quale piattaforma di monitoraggio rende l'integrazione di MongoDB più semplice per i team non tecnici?
Dopo aver installato tutti e tre, aver eseguito carichi di lavoro identici e aver valutato le dashboard, la risposta è diventata chiara. La nostra valutazione si basa sull'integrazione di base di MongoDB di Datadog a gennaio 2025. Datadog ha successivamente rilasciato Database Monitoring (DBM) per MongoDB (dicembre 2024), che fornisce capacità significativamente più profonde, tra cui query profiling, analisi delle operazioni lente, explain plan e monitoraggio della replica. Il prodotto DBM affronta molte delle limitazioni identificate in questo benchmark5 .
Solarwinds: Costruito per il Monitoraggio del Database
SolarWinds ha vinto questo confronto in modo decisivo. La piattaforma ha immediatamente rilevato il nostro agent, ci ha guidati nella configurazione delle credenziali tramite comandi copia-incolla e ha distribuito automaticamente l'integrazione. La configurazione ha richiesto 5 minuti.
La dashboard è apparsa istantaneamente con informazioni pertinenti. Il query profiling ha mostrato esattamente quali operazioni consumavano più risorse. La piattaforma ha catturato tutte le 1.400 operazioni batch senza dimenticarne alcuna. Quando abbiamo interrotto MongoDB, SolarWinds ha rilevato il guasto entro 40 secondi.
La scheda Queries ci permette di filtrare per errori, indici mancanti, risposte lente e avvisi: funzionalità che supportano direttamente l'ottimizzazione del database. La funzione Advisors doveva fornire raccomandazioni (anche se non abbiamo generato abbastanza dati per attivarne alcuna durante il nostro test).
Solarwinds si è concentrato su ciò di cui gli amministratori di database hanno effettivamente bisogno: analisi delle query, profiling delle prestazioni e insight azionabili.
New Relic: Perso nella Configurazione
New Relic ha richiesto 15 minuti per la configurazione, ma il tempo non era il problema principale. La piattaforma ha posto domande nell'ordine sbagliato, ha richiesto la verifica manuale di cose che l'agent avrebbe potuto controllare automaticamente e ci ha costretti a installare manualmente i pacchetti.
La confusione della dashboard ha peggiorato le cose. Abbiamo installato il monitoraggio di MongoDB, ma la selezione della dashboard predefinita ha portato a una schermata vuota. Solo dopo aver scavato nei file di configurazione ci siamo resi conto di aver selezionato il tipo di integrazione sbagliato. Un utente normale non lo avrebbe capito.
Quando i dati sono finalmente apparsi, le metriche erano sbagliate. New Relic ha riportato 11.670 inserimenti dopo che avevamo eseguito 1.400 operazioni batch, per un totale di 7 milioni di record. La piattaforma ha sottostimato di un ordine di grandezza.
Ancora più critico, New Relic non ha fornito alcuna analisi a livello di query. Nessun profiling, nessun rilevamento di slow query, nessuna identificazione di indici mancanti. Per la risoluzione dei problemi del database, queste omissioni sono rilevanti.
Datadog: Richiesto Lavoro Manuale
Datadog ha richiesto oltre 20 minuti di configurazione e la maggiore quantità di configurazione manuale. Abbiamo modificato i file YAML, determinato dove posizionarli e riavviato i servizi dalla riga di comando.
La dashboard è apparsa automaticamente ma non mostrava nulla. La configurazione di autodiscovery utilizzava un pattern che non corrispondeva al nostro database. Dopo aver corretto il pattern e gli errori di indentazione YAML, i dati sono stati finalmente popolati.
La dashboard stessa si è rivelata mal progettata per MongoDB a istanza singola. Il sessanta percento della schermata era vuoto, con sezioni per sharding e replica set, funzionalità che non stavamo utilizzando. Il restante 40% offriva metriche di base: uptime, memoria, I/O di rete, query al secondo e latenza.
Nessuna analisi delle query. Nessun profiling. Nessuna raccomandazione di ottimizzazione. Non potevamo determinare accuratamente i conteggi delle operazioni sulla dashboard.
Nessuna analisi delle query. Nessun profiling. Nessuna raccomandazione di ottimizzazione. Non potevamo determinare accuratamente i conteggi delle operazioni sulla dashboard.
Aggiornamento Critico (Dicembre 2024): Dopo il completamento di questo benchmark, Datadog ha lanciato Database Monitoring (DBM) per MongoDB, il che cambia significativamente questa valutazione. DBM per MongoDB ora fornisce:
- Analisi delle operazioni lente con campioni di query dettagliati
- Explain plan per l'ottimizzazione delle query
- Monitoraggio dello stato della replica e visualizzazione della salute del cluster
- Insight a livello di operazione e identificazione dei colli di bottiglia delle prestazioni
- Integrazione con il monitoraggio delle prestazioni delle applicazioni per una risoluzione dei problemi unificata
DBM rappresenta un aggiornamento sostanziale rispetto all'integrazione di base di MongoDB testata in questo benchmark e include molte delle funzionalità di analisi a livello di query che erano assenti durante i nostri test6 7 . Le organizzazioni che valutano Datadog per il monitoraggio di MongoDB dovrebbero valutare specificamente il prodotto Database Monitoring piuttosto che l'integrazione di base testata qui.
Quale strumento di monitoraggio DB funziona davvero quando non sei un esperto DevOps?
L'esperienza di configurazione
SolarWinds si apre con un modal che chiede cosa vuoi monitorare. Scegli “prestazioni del database”, selezioni MongoDB e la piattaforma trova immediatamente l'agent che hai già installato, mostrandoti il sistema operativo, l'ID dell'istanza cloud e il numero di versione proprio lì nella schermata di selezione. Quindi ti fornisce tre comandi copia-incolla da eseguire in MongoDB, gestisce le credenziali e conferma la distribuzione. Cinque minuti, dall'inizio alla fine.
New Relic ha richiesto quindici minuti, e il tempo non era nemmeno il vero problema. L'interfaccia continuava a porre domande a cui l'agent avrebbe potuto rispondere da solo, come quale sistema operativo e quale versione di MongoDB, nonostante l'agent fosse già sul server. A un certo punto, ha impostato per impostazione predefinita i comandi di installazione di Amazon Linux, anche se stavamo chiaramente eseguendo Ubuntu. Il passaggio che ha definitivamente rovinato l'esperienza: ci sono due opzioni di integrazione MongoDB nel catalogo delle dashboard, una standard e una basata su Prometheus, e nulla nell'interfaccia le distingue. Abbiamo scelto quella sbagliata, abbiamo ottenuto una dashboard vuota e l'abbiamo capito solo scavando nei file di configurazione.
Datadog ha richiesto oltre venti minuti di editing YAML, ipotesi sui percorsi dei file e riavvii dei servizi dalla riga di comando. La documentazione offerta durante la configurazione non è una guida; è un manuale di riferimento completo che copre istanze standalone, replica set, cluster sharded e configurazione SSL, tutto insieme, per qualcuno che vuole solo monitorare un database. Quando i dati sono finalmente apparsi, la dashboard iniziava con statistiche di sharding e metriche di replica set. Non avevamo nessuno dei due. Circa il sessanta percento della schermata era vuoto.
Accuratezza delle metriche sotto carico
SolarWinds ha contato 1.400. Esattamente giusto. New Relic ha riportato 11.670, sbagliando di un ordine di grandezza senza una spiegazione ovvia, e ha mancato completamente un picco di memoria durante il test. Quando abbiamo interrotto il servizio MongoDB, SolarWinds ha rilevato il guasto entro trenta o quaranta secondi.
Sul consumo di risorse: New Relic ha utilizzato circa 90MB di RAM, Datadog circa 330MB e SolarWinds circa 500MB sul nostro server da 16GB. SolarWinds ha eseguito circa quaranta volte più letture di disco rispetto a New Relic, probabilmente a causa del lavoro di query profiling locale. Per la maggior parte degli ambienti, nulla di tutto ciò influenzerà la tua decisione.
La funzionalità che li separa davvero
Ogni strumento di monitoraggio ti dirà che qualcosa è lento. La domanda è se ti dice perché.
SolarWinds offre il profiling a livello di query. La scheda Profiler mostrava esattamente quali pattern di query venivano eseguiti, quanto tempo richiedeva ciascuno e quanti campioni erano stati catturati. Puoi filtrare per query eseguite senza un indice, che hanno restituito errori o che hanno generato avvisi.
New Relic e Datadog hanno mostrato solo metriche aggregate per latenza, conteggi di connessione e totali di operazioni. Nessun profiling, nessuna identificazione di slow query, nessun rilevamento di indici mancanti. Per confermare che un database sia attivo, è accettabile. Per diagnosticare perché è in difficoltà, è un vicolo cieco.
Nota: Datadog ha rilasciato un prodotto Database Monitoring per MongoDB a dicembre 2024, dopo i nostri test, che aggiunge l'analisi delle operazioni lente, explain plan e visibilità a livello di query. Abbiamo testato l'integrazione standard, che rimane quella che la maggior parte degli utenti incontra per prima.
SolarWinds: Se l'ottimizzazione del database è la tua reale preoccupazione. Metriche accurate, configurazione rapida e l'unica piattaforma qui che ti dice non solo che una query è lenta, ma cosa farci.
New Relic: Se lo stai già usando per l'APM e hai bisogno della salute di base del database nello stesso posto. Tracciare una richiesta lenta dal browser attraverso il codice fino alla chiamata al database è genuinamente utile. Non fare affidamento su di esso per conteggi precisi delle operazioni.
Datadog: Se ti senti a tuo agio con la configurazione manuale e desideri un'unica piattaforma per uno stack complesso. Le oltre 600 integrazioni giustificano l'attrito della configurazione per il team giusto.
Cita questa ricerca
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{dogan2026,
author = {Dogan, Sedat and Sezer, Sena},
title = {{MongoDB Monitoring: SolarWinds vs New Relic vs Datadog}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/mongodb-monitoring}},
note = {AIMultiple. Consultato il 12 Giugno 2026}
}Collegamenti di riferimento
![Schermata Test the connection che mostra lo stato "Not tested"]](https://aimultiple.com/wp-content/uploads/2025/12/11.png.webp "Schermata Test the connection che mostra lo stato \"Not tested\"]")
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.