MongoDB Monitoraggio: SolarWinds vs New Relic vs Datadog
Abbiamo installato SolarWinds, Datadog e New Relic su sistemi puliti con MongoDB 7.0 per testarli. Abbiamo seguito l'intero processo di configurazione di ogni strumento, documentando ogni passaggio e intoppo.
MongoDB risultati benchmark degli strumenti di monitoraggio delle prestazioni
Piattaforma | Tempo di configurazione | Profilazione delle query | Precisione delle metriche | RAM Utilizzo | Ideale per |
|---|---|---|---|---|---|
5 min | ✓ | 100% accurato | Medio (500MB) | Ottimizzazione della produzione | |
New Relic | 15 min | ✕ | Bassa (tassi di errore dal 23 al 800%) | Basso (90MB) | Controlli di salute di base |
Datadog | 20+ min | ✕ | Poco chiara | Medio (330MB) | Monitoraggio multi-tecnologia |
MongoDB riepilogo prestazioni di monitoraggio
- SolarWinds ha completato la configurazione in 5 minuti con rilevamento automatico e ha fornito una profilazione a livello di query che gli altri non avevano.
- New Relic ha impiegato 15 minuti con passaggi di verifica manuali e ha riportato metriche imprecise.
- Datadog ha richiesto 20+ minuti di modifica dei file 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. Installazione ed esperienza di onboarding
1. SolarWinds
SolarWinds ha completato l'integrazione con MongoDB in meno di 5 minuti. SolarWinds si apre con una semplice finestra modale: "Cosa vuoi monitorare?" Quando selezioni le prestazioni del database, la piattaforma mostra subito i database supportati.
Dopo aver selezionato MongoDB, SolarWinds verifica la presenza di agenti esistenti.
La piattaforma ha rilevato immediatamente il nostro agente precedentemente installato.
Una funzionalità è emersa: l'interfaccia mostra i dettagli dell'agente (sistema operativo, ID istanza cloud, versione) direttamente nella schermata di selezione. Nessuna ricerca nei 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 autocompilato con le informazioni del nostro server, ma ha usato il nome host interno completo anziché il nome dell'agente 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 di database da eseguire. Ogni comando aveva un pulsante di copia. Li abbiamo eseguiti in MongoDB e abbiamo fatto clic su "Osserva database".
È qui che SolarWinds ci ha impressionati. Invece di chiederci di capire i permessi, ci 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 profilazione
È apparsa una schermata di riepilogo con la nostra configurazione. Lo stato del plugin mostrava "Il plugin è in fase di distribuzione".
Pochi secondi dopo, lo stato è cambiato in "Distribuzione del plugin riuscita" con un link per visualizzare la dashboard. Configurazione completata.
Scopri l'osservabilità di SolarWinds con monitoraggio approfondito di MongoDB e profilazione delle query. 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 rispondere a domande che la piattaforma avrebbe dovuto già 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 "Su un host" poiché il nostro agente era già installato. La schermata successiva ha chiesto il sistema operativo. Abbiamo selezionato Linux. Sembrava superfluo, dato che l'agente era già in esecuzione sul server, ma abbiamo continuato.
La schermata successiva ha chiesto i dettagli dell'host di MongoDB. Il termine "SCRAM" è apparso senza spiegazioni. La maggior parte delle persone lo conosce come autenticazione con nome utente e password, ma il termine tecnico genera confusione.
Dopo aver fatto clic su "continua", New Relic ci ha chiesto su quale server installare. Questa domanda avrebbe dovuto venire prima, non dopo aver già inserito i dettagli di configurazione. L'agente era già installato su "aimultiple-benchmark", quindi lo abbiamo selezionato e abbiamo continuato.
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 terminale, eseguirlo, controllare il numero di versione e tornare a fare clic su continua.
L'agente è già installato sul server. Potrebbe verificarlo automaticamente.
Dopo aver fatto clic 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 assegnazioni di ruoli appropriate (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 capissimo dove eseguire questi comandi.
La schermata successiva ci ha chiesto di installare il pacchetto di integrazione. Ora New Relic ci chiede di installare manualmente usando yum. Anche se l'agente è già installato su Ubuntu, l'interfaccia prevede come impostazione predefinita Amazon Linux e fornisce comandi di installazione yum invece di apt. Ci aspettavamo che la piattaforma rilevasse automaticamente il sistema operativo corretto dall'agente installato.
Abbiamo eseguito il comando apt corretto per Ubuntu, poi siamo passati alla schermata successiva. New Relic ha fornito un file di configurazione YAML e ci ha detto esattamente dove posizionarlo: /etc/newrelic-infra/integrations.d/. Almeno il percorso del file era chiaro.
Abbiamo creato il file, incollato la configurazione e fatto clic su Continua. La schermata finale mostrava un pulsante "Test connessione". Abbiamo fatto clic e aspettato.
Il test è riuscito. Configurazione completata.
3. Datadog
Datadog ha richiesto oltre 20 minuti per essere completato. L'integrazione alla fine ha funzionato, ma è stato necessario un notevole impegno manuale.
Dopo aver effettuato l'accesso, siamo andati su Integrations e abbiamo cercato "mongo". Abbiamo fatto clic su MongoDB ed è apparsa una finestra modale.
La panoramica mostrava cosa include il monitoraggio di MongoDB, ma cliccando su "Installa integrazione" si apriva solo un'altra schermata con istruzioni dense.
È qui che Datadog ci ha travolto. La schermata mostrava una guida di riferimento completa su ogni possibile scenario MongoDB: istanze standalone, set di replica, cluster shardizzati, metodi di autenticazione, configurazione SSL e altro ancora.
Per chi cerca solo di monitorare una singola istanza MongoDB, il muro di testo è sembrato 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'agente Datadog
Datadog ha fornito i comandi MongoDB per creare l'utente, il che è stato utile. Ma per quanto riguarda il file YAML, la documentazione diceva di modificare conf.yaml senza indicare chiaramente dove posizionarlo.
Sapevamo per esperienza che va in /etc/datadog-agent/conf.d/mongo.d/, ma le istruzioni hanno nascosto questo dettaglio in profondità nella documentazione.
Abbiamo creato l'utente MongoDB, scritto la configurazione YAML, posizionato il file nella directory corretta e riavviato l'agente.
Poi siamo tornati nell'interfaccia di Datadog e abbiamo fatto clic su "Installa integrazione".
Il pulsante è scomparso. Nessun messaggio di conferma, nessuna notifica di successo, nessun reindirizzamento a una dashboard. Nulla.
Abbiamo atteso un momento, poi siamo andati manualmente alla sezione Dashboards e abbiamo trovato le metriche di MongoDB che iniziavano a popolarsi.
2. Consumo di risorse dell'agente
Abbiamo monitorato quante risorse consumava ciascun agente durante l'esecuzione. Il test è durato circa 10 minuti con tutti e tre gli agenti che raccoglievano dati simultaneamente dalla stessa istanza MongoDB sotto carico.
Abbiamo stressato il sistema inserendo 2 milioni di record in MongoDB usando uno script che generava dati casuali. Questo ha simulato l'attività reale del database mentre misuravamo l'uso delle risorse degli agenti.
Consumo di CPU
Tutti e tre gli agenti hanno usato risorse CPU minime durante il test.
- New Relic ha mostrato il consumo medio di CPU più basso, ma ha avuto picchi occasionali fino a 4%. Questi picchi sono stati brevi e non hanno influito sulle prestazioni del sistema.
- Solarwinds ha mantenuto l'uso della CPU più costante, rimanendo intorno al 3% senza variazioni significative.
- Datadog si è collocato a metà, con una media di poco superiore al 2% e prestazioni stabili durante tutto il test.
Uso della memoria
L'uso della memoria ha mostrato differenze più significative tra gli agenti.
New Relic ha consumato circa 5-6x in meno di memoria rispetto a Solarwinds. Sul nostro server di test da 16GB, questo si traduceva in:
- New Relic: ~90MB
- Datadog: ~330MB
- Solarwinds: ~500MB
Per la maggior parte dei server di produzione, queste quantità non faranno differenza. Ma se esegui agenti su sistemi con risorse limitate o monitori centinaia di database, la differenza si accumula.
L'uso della memoria è rimasto stabile per tutti e tre gli agenti durante il test. Non si sono verificati memory leak o crescite impreviste.
I/O del disco
L'attività del disco è variata notevolmente tra gli agenti.
SolarWinds ha eseguito significativamente più letture dal disco rispetto agli altri due agenti, circa 40x in più di New Relic e 1.5x in più di Datadog. Questo suggerisce che SolarWinds accede più frequentemente ai dati archiviati localmente, forse per le sue funzionalità di profilazione delle query.
Datadog ha scritto meno di tutti su disco, indicando che memorizza meno dati localmente prima di inviarli al cloud.
New Relic ha mostrato il pattern di I/O più bilanciato con letture e scritture moderate.
Uso della rete
Il traffico di rete ha mostrato quanti dati ogni agente inviava al proprio backend.
Tutti e tre gli agenti hanno inviato quantità simili di dati sulla rete. Datadog ha trasmesso leggermente meno, forse a causa di una compressione più aggressiva o di tassi di campionamento diversi.
Il traffico bidirezionale ha senso, poiché gli agenti inviano metriche e ricevono aggiornamenti di configurazione o comandi dalla piattaforma.
Riepilogo dell'impatto sulle risorse
Nessuno di questi agenti metterà sotto stress il tuo sistema. Anche sotto carico del database con tutti e tre in esecuzione contemporaneamente, il consumo totale di risorse è rimasto ben al di sotto del 10% per CPU e memoria combinati.
New Relic vince sull'efficienza della memoria. Solarwinds usa più risorse ma offre un'analisi a livello di query più dettagliata. Datadog si colloca a metà.
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.
3. Dashboard e funzionalità di monitoraggio
Dopo aver completato la configurazione, dovevamo vedere cosa mostrava effettivamente ciascuna piattaforma. Abbiamo eseguito lo stesso carico di lavoro su tutte e tre: inserimento di 2 milioni di record in lotti da 5.000, seguito da altri 5 milioni di record.
Lo script usava Node.js con Faker per generare dati utente casuali: nomi, email, indirizzi e numeri di telefono. Questo ci ha fornito un dataset realistico da monitorare.
Mentre venivano eseguiti gli inserimenti, monitoravamo in background il consumo di risorse degli agenti.
Il carico di lavoro ha messo sotto stress reale MongoDB, permettendoci di vedere come ciascuna piattaforma catturava e visualizzava l'attività.
Dashboard SolarWinds
Abbiamo fatto clic su "Database" nel menu a sinistra e abbiamo subito visto la nostra istanza MongoDB. Un clic ed è apparsa una dashboard completa.
La parte superiore della schermata mostrava lo stato di salute di MongoDB, il tempo di risposta medio, il throughput (query al secondo) e il numero di errori. Il grafico a bolle "Top 10 Service Breakdown" mostrava i pattern di query usati più frequentemente con i relativi conteggi e percentuali.
I numeri raccontavano una storia. Il throughput mostrava in media 3 query al secondo. Il dettaglio mostrava 1.400 operazioni di inserimento. Perché 1.400 invece di 7 milioni?
Abbiamo inserito 7 milioni di record in lotti da 5.000. Sono 1.400 operazioni batch. Solarwinds ha tracciato ogni singolo lotto senza perderne uno.
La scheda Profiler mostrava i pattern di query con i tempi medi di esecuzione.
Le nostre query di inserimento impiegavano 4-5 secondi ciascuna, il che sembra tanto finché non si ricorda che ogni query scriveva 5.000 righe.
La scheda Health mostrava che tutto funzionava correttamente.
Abbiamo arrestato il servizio MongoDB per vedere quanto rapidamente Solarwinds se ne sarebbe accorto. Entro 30-40 secondi, lo stato di salute è cambiato in "Bad".
La scheda Queries offriva filtri avanzati. Era possibile elencare le query che:
- Restituivano errori
- Venivano eseguite senza indici adeguati
- Rispondevano lentamente
- Generavano avvisi
Ogni pattern di query mostrava quando era apparso per la prima volta, quando era stato eseguito l'ultima volta, quanti campioni erano stati catturati e le statistiche di esecuzione. Per la risoluzione dei problemi, questo livello di dettaglio è importante.
La scheda Alerts ci permetteva di creare avvisi specifici per MongoDB. In precedenza avevamo creato un avviso di memoria per l'host, ma ora potevamo impostare notifiche specifiche per il database.
La scheda Resources mostrava le 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 MongoDB.
Aggiornamenti IA: A ottobre 2025, SolarWinds ha lanciato l'IA Agent con la funzionalità IA Query Assist (attualmente in anteprima tecnica). IA 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 delle cause principali basate su avvisi e anomalie per ridurre i tempi di risoluzione dei problemi. Una disponibilità più ampia dell'IA Agent in tutto il portfolio di SolarWinds è prevista per il 202612.
Dashboard New Relic
Siamo andati alla sezione Dashboards, ma non è apparsa automaticamente nessuna dashboard MongoDB.
Abbiamo cercato "mongo" nel catalogo delle dashboard e abbiamo trovato due opzioni MongoDB.
Abbiamo selezionato la dashboard MongoDB standard e abbiamo fatto clic su "Configura MongoDB".
Ci ha reindirizzati nuovamente alla configurazione dell'integrazione MongoDB. La piattaforma sapeva già che avevamo installato MongoDB, quindi perché rimandarci all'installazione? Abbiamo fatto clic su "Done" e siamo passati alla dashboard.
La dashboard si è aperta completamente vuota. "Nessun valore riportato per il controllo del servizio mongodb.can_connect."
Abbiamo controllato la nostra configurazione usando newrelic-infra agent configtest.
Quando abbiamo eseguito il comando newrelic-infra agent configtest per verificare eventuali problemi nella nostra configurazione, abbiamo notato che integration_name era impostato su nri-prometheus. Durante la configurazione della dashboard, New Relic mostrava due opzioni MongoDB, una delle quali era la versione Prometheus. Nulla nell'interfaccia indicava che si trattasse di un'integrazione diversa, quindi non mi sarebbe mai venuto in mente di aver selezionato quella Prometheus. Non è stato un errore dell'utente; semplicemente non c'erano indicazioni o distinzioni nell'interfaccia.
Siamo tornati indietro e abbiamo installato la dashboard "MongoDB (Prometheus)".
Questa volta sono apparsi i dati.
Ma ecco il problema: come farebbe un utente normale a capirlo? Il processo di installazione era confuso e ora la selezione della dashboard aggiungeva un ulteriore livello di complessità.
Il layout della dashboard sembrava strano. La parte superiore mostrava informazioni su server e database totali che cambiano una volta all'anno, eppure occupava la parte più visibile dello schermo.
Sotto, "Saturazione della connessione" appariva in evidenza. Questa metrica conta solo quando qualcosa non va. Perché metterla in alto?
La sezione "Operazioni sulle query" riportava 11.670 inserimenti. Il numero era sbagliato. Avevamo 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 numero di oggetti e le dimensioni degli indici. Questi numeri erano corretti: 7 milioni di oggetti. New Relic ottiene questi dati interrogando direttamente MongoDB ("Quanti documenti hai?"). Ma il conteggio delle query in tempo reale non ha funzionato.
La scheda Collections includeva grafici utili per le metriche a livello di collezione: dimensione (con visualizzazioni sia tabellari sia grafiche), dimensione totale con variazione percentuale, numero di operazioni di lettura, latenza di lettura, numero di operazioni di scrittura, latenza di scrittura, numero di transazioni, latenza delle transazioni, operazioni di accesso agli indici, numero di esecuzioni dei comandi, latenza dei comandi, frequenza dei comandi e durata dei comandi.
Da notare l'assenza delle metriche host. Non potevamo vedere CPU, memoria, disco o utilizzo della rete per il server che eseguiva MongoDB. SolarWinds includeva questo contesto, ma Datadog, come New Relic, non lo faceva.
Ancora più importante, non esisteva alcuna analisi a livello di query. Nessun pattern di query, nessuna profilazione, nessuna identificazione delle query lente, nessun rilevamento degli indici mancanti. Per la risoluzione dei problemi del database, queste funzionalità sono importanti.
Dashboard di Datadog
Abbiamo fatto clic 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 usando un pattern di corrispondenza. Il pattern predefinito non corrispondeva al nome del nostro database. Datadog non lo ha mai menzionato durante la configurazione.
Abbiamo modificato tutti i pattern in .* (corrispondenza con tutto) e riavviato l'agente.
Ma perché la dashboard era completamente vuota? Anche senza metriche specifiche del database, uptime, numero di connessioni e statistiche del server sarebbero dovuti apparire. Non è stato così.
Abbiamo eseguito datadog-agent check mongo per eseguire il debug. Il file di configurazione aveva un errore di indentazione. I rigidi requisiti di formattazione di YAML ci hanno colti in fallo. Dopo averlo corretto e rieseguito il nostro test di carico con 5 milioni di inserimenti, i dati sono finalmente apparsi.
Abbiamo subito riscontrato problemi con la dashboard. La sezione Logs mostrava "Non accessibile" anche se avevamo configurato la raccolta dei log nel nostro file YAML. Il processo di configurazione di Datadog indicava che tutto andava bene, ma i log continuavano a non funzionare.
Il layout della dashboard aveva poco senso per il nostro caso d'uso. La sezione superiore si concentrava sulle statistiche di sharding. Non avevamo un cluster shardizzato. La parte centrale mostrava le metriche dei set di replica. Non avevamo set di replica. La parte inferiore tornava di nuovo allo sharding. Circa il 60% della dashboard mostrava sezioni vuote per funzionalità che non stavamo usando.
Le informazioni utili occupavano forse il 40% della schermata: uptime, uso della memoria, I/O di rete, query al secondo e latenza di lettura/scrittura. Nessuna analisi delle query, nessuna profilazione, nessun rilevamento delle query lente, nessuna raccomandazione sugli indici.
Non siamo nemmeno riusciti a determinare quante operazioni erano state eseguite da questa dashboard.
MongoDB ambiente e metodologia di test del benchmark di monitoraggio
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 pulita con l'agente di monitoraggio principale già installato
Tutti e tre i fornitori richiedono di installare il proprio agente di base prima di aggiungere integrazioni specifiche, come MongoDB. Abbiamo completato questo passaggio in anticipo, quindi il nostro test si è concentrato esclusivamente sull'esperienza di integrazione con 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 guidava o ci lasciava a cercare i passaggi successivi.
- Consumo di risorse dell'agente: CPU, memoria, I/O del disco e utilizzo della rete in idle e sotto carico (inserimento di 7 milioni di record).
- Funzionalità di monitoraggio: Qualità della dashboard, precisione delle metriche, analisi a livello di query e funzionalità di risoluzione dei problemi.
Considerazioni sulla sicurezza
Una grave vulnerabilità chiamata "MongoBleed" è stata divulgata e interessa le versioni di MongoDB Server precedenti a 8.0.17, 7.0.28, 6.0.27 e precedenti. Questa vulnerabilità non autenticata di lettura fuori dai limiti potrebbe consentire agli aggressori di accedere a dati sensibili in memoria. Le organizzazioni che eseguono MongoDB dovrebbero aggiornare immediatamente alle versioni corrette: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 o 4.4.3034. Quando si selezionano strumenti di monitoraggio, assicurarsi che supportino metodi di autenticazione sicuri e non introducano rischi aggiuntivi per la sicurezza.
Abbiamo affrontato ogni strumento come farebbe un utente normale, senza leggere in anticipo la documentazione e senza alcuna formazione precedente. Se qualcosa non era evidente nell'interfaccia, lo abbiamo annotato.
Aggiungi come fonte preferitaMongoDB verdetto finale del benchmark di monitoraggio
Siamo partiti per rispondere a una domanda semplice: quale piattaforma di monitoraggio rende più semplice l'integrazione di MongoDB per i team non tecnici?
Dopo aver installato tutti e tre, eseguito carichi di lavoro identici e valutato le dashboard, la risposta è diventata chiara. La nostra valutazione si basa sull'integrazione di base di Datadog per MongoDB a gennaio 2025. Datadog ha da allora rilasciato Database Monitoring (DBM) per MongoDB (dicembre 2024), che offre funzionalità significativamente più approfondite, tra cui profilazione delle query, analisi delle operazioni lente, piani di spiegazione e monitoraggio della replica. Il prodotto DBM affronta molti dei limiti identificati in questo benchmark5.
SolarWinds: Fatto per il monitoraggio dei database
SolarWinds ha vinto nettamente questo confronto. La piattaforma ha rilevato immediatamente il nostro agente, ci ha guidato nella configurazione delle credenziali tramite comandi copia-incolla e ha distribuito automaticamente l'integrazione. La configurazione ha richiesto 5 minuti.
La dashboard è apparsa immediatamente con informazioni pertinenti. La profilazione delle query mostrava esattamente quali operazioni consumavano più risorse. La piattaforma ha catturato tutte le 1.400 operazioni batch senza perderne nessuna. Quando abbiamo arrestato MongoDB, SolarWinds ha rilevato il guasto entro 40 secondi.
La scheda Queries ci permetteva di filtrare per errori, indici mancanti, risposte lente e avvisi, funzionalità che supportano direttamente l'ottimizzazione del database. La funzionalità Advisors avrebbe dovuto fornire raccomandazioni (anche se non abbiamo generato abbastanza dati da attivarne una durante il test).
Solarwinds si è concentrata su ciò di cui gli amministratori di database hanno realmente bisogno: analisi delle query, profilazione delle prestazioni e approfondimenti concreti.
New Relic: Perso nella configurazione
New Relic ha richiesto 15 minuti per la configurazione, ma il tempo non era il problema principale. La piattaforma faceva domande nell'ordine sbagliato, richiedeva la verifica manuale di cose che l'agente poteva controllare automaticamente e ci obbligava a installare manualmente i pacchetti.
La confusione sulla dashboard ha peggiorato le cose. Abbiamo installato il monitoraggio di MongoDB, ma selezionando la dashboard predefinita si otteneva una schermata vuota. Solo dopo aver esaminato i file di configurazione ci siamo resi conto di aver selezionato il tipo di integrazione sbagliato. Un utente normale non riuscirebbe a capirlo.
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 forniva alcuna analisi a livello di query. Nessuna profilazione, nessun rilevamento di query lente, nessuna identificazione degli indici mancanti. Per la risoluzione dei problemi del database, queste omissioni contano.
Datadog: Richiesto lavoro manuale
Datadog ha richiesto 20+ minuti di configurazione e la maggior parte del lavoro 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 usava un pattern che non corrispondeva al nostro database. Dopo aver corretto il pattern e gli errori di indentazione YAML, i dati sono finalmente stati popolati.
La dashboard stessa si è rivelata progettata male per una singola istanza di MongoDB. Il sessanta percento della schermata era vuoto, con sezioni per funzionalità di sharding e set di replica che non stavamo usando. Il restante 40% offriva metriche di base: uptime, memoria, I/O di rete, query al secondo e latenza.
Nessuna analisi delle query. Nessuna profilazione. Nessuna raccomandazione di ottimizzazione. Non siamo riusciti a determinare con precisione il numero di operazioni dalla dashboard.
Nessuna analisi delle query. Nessuna profilazione. Nessuna raccomandazione di ottimizzazione. Non siamo riusciti a determinare con precisione il numero di operazioni dalla dashboard.
Aggiornamento critico (dicembre 2024): Dopo il completamento di questo benchmark, Datadog ha lanciato Database Monitoring (DBM) per MongoDB, cambiando significativamente questa valutazione. DBM per MongoDB ora offre:
- Analisi delle operazioni lente con campioni di query dettagliati
- Piani di spiegazione per l'ottimizzazione delle query
- Monitoraggio dello stato della replica e visualizzazione dello stato del cluster
- Approfondimenti 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 assenti durante i nostri test56. 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 del database funziona davvero quando non sei un esperto DevOps?
L'esperienza di configurazione
SolarWinds si è aperta con una finestra modale che chiedeva cosa vuoi monitorare. Scegli "prestazioni del database", selezioni MongoDB e la piattaforma trova immediatamente l'agente già installato, mostrandoti sistema operativo, ID istanza cloud e numero di versione direttamente nella schermata di selezione. Poi 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 impiegato quindici minuti e il tempo non era nemmeno il vero problema. L'interfaccia continuava a fare domande a cui l'agente poteva rispondere da solo, come il sistema operativo e la versione di MongoDB, nonostante l'agente fosse già sul server. A un certo punto, proponeva come predefiniti i comandi di installazione di Amazon Linux, anche se stavamo chiaramente usando Ubuntu. Il passaggio che ha definitivamente rovinato l'esperienza: nel catalogo delle dashboard ci sono due opzioni di integrazione MongoDB, una standard e una basata su Prometheus, e nulla nell'interfaccia le distingue. Abbiamo scelto quella sbagliata, ottenuto una dashboard vuota e l'abbiamo capito solo scavando nei file di configurazione.
Datadog ha richiesto più di venti minuti di modifica dei file YAML, ipotesi sui percorsi dei file e riavvio dei servizi dalla riga di comando. La documentazione offerta durante la configurazione non è una guida; è un manuale di riferimento completo che copre istanze standalone, set di replica, cluster shardizzati e configurazione SSL, tutto in una volta, per chi vuole solo monitorare un database. Quando finalmente sono apparsi i dati, la dashboard iniziava con statistiche di sharding e metriche dei set di replica. Non avevamo né l'una né le altre. Circa il sessanta percento della schermata era vuoto.
Precisione delle metriche sotto carico
SolarWinds ha contato 1.400. Esattamente giusto. New Relic ha riportato 11.670, sbagliato di un ordine di grandezza senza una spiegazione ovvia, e ha perso completamente un picco di memoria durante il test. Quando abbiamo arrestato il servizio MongoDB, SolarWinds ha rilevato il guasto entro trenta o quaranta secondi.
Per quanto riguarda il consumo di risorse: New Relic ha usato circa 90MB di RAM, Datadog circa 330MB e SolarWinds circa 500MB sul nostro server da 16GB. SolarWinds ha eseguito circa quaranta volte più letture dal disco rispetto a New Relic, probabilmente a causa del lavoro locale di profilazione delle query. Per la maggior parte degli ambienti, nulla di tutto ciò influenzerà la tua decisione.
La funzionalità che li distingue davvero
Ogni strumento di monitoraggio ti dirà che qualcosa è lento. La domanda è se ti dice perché.
SolarWinds offre una profilazione a livello di query. La scheda Profiler mostrava esattamente quali pattern di query erano in esecuzione, quanto tempo impiegava 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 mostravano solo metriche aggregate per latenza, numero di connessioni e totali delle operazioni. Nessuna profilazione, nessuna identificazione delle query lente, nessun rilevamento degli indici mancanti. Per confermare che un database è vivo, può funzionare. 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 analisi delle operazioni lente, piani di spiegazione e visibilità a livello di query. Abbiamo testato l'integrazione standard, che rimane ciò che la maggior parte degli utenti incontra per prima.
SolarWinds: Se la tua reale preoccupazione è l'ottimizzazione del database. Metriche precise, configurazione rapida e l'unica piattaforma qui che ti dice non solo che una query è lenta, ma anche cosa fare al riguardo.
New Relic: Se lo stai già usando per l'APM e hai bisogno di uno stato di salute di base del database nello stesso posto. Tracciare una richiesta lenta dal browser attraverso il codice fino alla chiamata al database è davvero utile. Non fare affidamento su di esso per conteggi precisi delle operazioni.
Datadog: Se sei a tuo agio con la configurazione manuale e vuoi un'unica piattaforma per uno stack complesso. Le oltre 600 integrazioni giustificano l'attrito di configurazione per il team giusto.
Cita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{dogan2026,
author = {Dogan, Sedat and Ermut, Sıla},
title = {{MongoDB Monitoraggio: SolarWinds vs New Relic vs Datadog}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/mongodb-monitoring}},
note = {AIMultiple. Consultato il 16 settembre 2026}
}Risultati e timestamp di 38 punti dati. Scarica i dati di sintesi mostrati nei grafici e nelle tabelle di questo articolo come file ZIP contenente 7 file CSV.
Vuoi i dati granulari che ci stanno dietro? Passa a Premium
Registro delle modifiche
5 aggiornamentiSostituita la sezione "La differenza fondamentale" con "Quale strumento di monitoraggio DB funziona davvero se non sei un esperto DevOps?".
Aggiunti aggiornamenti AI alla sezione SolarWinds.
Aggiunte Considerazioni sulla Sicurezza alla metodologia.
Collegamenti di riferimento
- Ha 20 anni di esperienza come hacker white-hat e guru dello sviluppo, con una vasta competenza nei linguaggi di programmazione e nelle architetture dei server.
- È consulente del consiglio di amministrazione presso una società di venture capital che investe in aziende tecnologiche in fase iniziale e presso Ödeal, una piattaforma di pagamento digitale regionale che serve 125.000 commercianti.
- Ha guidato l'infrastruttura tecnologica e la cybersecurity di sette elezioni nazionali ed è stato riconosciuto nella Hall of Fame della cybersecurity da leader tecnologici globali tra cui Twitter.
In precedenza ha lavorato come reclutatrice in società di project management e consulenza. Sıla ha conseguito un Master of Science in Psicologia Sociale e un Bachelor of Arts in Relazioni Internazionali.
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.