MongoDB Monitoraggio: SolarWinds vs New Relic vs Datadog
Abbiamo installato SolarWinds, Datadog e New Relic su sistemi puliti con MongoDB 7.0 per effettuare dei test. Abbiamo seguito l'intero processo di configurazione di ciascuno strumento, documentando ogni passaggio e ogni ostacolo incontrato.
MongoDB Risultati del benchmark degli strumenti di monitoraggio delle prestazioni
Piattaforma | Tempo di configurazione | Profilazione delle query | Precisione metrica | Utilizzo della RAM | Ideale per |
|---|---|---|---|---|---|
5 minuti | ✅ | Accuratezza al 100% | Medio (500 MB) | Ottimizzazione della produzione | |
Nuova reliquia | 15 minuti | ❌ | Basso (tassi di errore dal 23 all'800%) | Basso (90 MB) | Controlli sanitari di base |
Datadog | 20+ minuti | ❌ | Non chiaro | Medio (330 MB) | Monitoraggio multitecnologico |
MongoDB riepilogo delle 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 le verifiche manuali e ha riportato metriche inaccurate.
- Datadog richiedeva più di 20 minuti di modifica del file YAML e offriva solo una visibilità di base.
È inoltre possibile visualizzare come queste piattaforme monitorano MySQL , il nostro ambiente di test e la nostra metodologia.
1. Esperienza di installazione e onboarding
1. Solarwinds
SolarWinds ha completato l'integrazione 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 visualizza immediatamente i database supportati.
Dopo aver selezionato MongoDB, Solarwinds verifica la presenza di agenti esistenti.
La piattaforma ha rilevato immediatamente l'agente precedentemente installato.
Una caratteristica in particolare spicca: l'interfaccia visualizza i dettagli dell'agente (sistema operativo, ID dell'istanza cloud, versione) direttamente nella schermata di selezione. Non è necessario cercare tra i menu a tendina.
Ora SolarWinds richiede le credenziali MongoDB. Abbiamo inserito i dettagli di connessione: localhost, metodo di autenticazione (basato su password), nome utente e password. Il nome visualizzato è stato compilato automaticamente con le informazioni del nostro server, anche se ha utilizzato il nome host interno completo anziché il nome dell'agente che avevamo specificato in precedenza.
Una stranezza: il menu a tendina "Query Capture" è apparso senza alcuna spiegazione. Abbiamo selezionato "Log" e siamo andati avanti, non sapendo a cosa servissero le altre opzioni.
La schermata successiva presentava tre comandi di database da eseguire. Ogni comando aveva un pulsante "Copia". Li abbiamo eseguiti in MongoDB e abbiamo cliccato su "Osserva database".
Ecco dove Solarwinds ci ha impressionato. Invece di chiederci di capire come gestire i permessi, ci ha fornito comandi da copiare e incollare:
- Creare 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 che mostrava la nostra configurazione. Lo stato del plugin indicava "Il plugin è in fase di distribuzione".
Pochi secondi dopo, lo stato è cambiato in "Installazione del plugin riuscita" con un link per visualizzare la dashboard. Configurazione completata.
Scopri l'osservabilità SolarWinds con un monitoraggio MongoDB approfondito e la profilazione delle query. Esplora SolarWinds.
Visita il sito web2. Nuova reliquia
L'installazione di New Relic ha richiesto circa 15 minuti, ma il tempo non è stato il vero problema. La difficoltà è derivata dal dover rispondere a domande a cui la piattaforma avrebbe dovuto già saper rispondere.
New Relic inizia dalla pagina Integrazioni e agenti.
Abbiamo cercato "mongo" e abbiamo trovato diverse integrazioni correlate a MongoDB.
Dopo aver selezionato MongoDB, New Relic ci ha chiesto di scegliere un metodo di strumentazione.
Abbiamo selezionato "Su un host" poiché il nostro agente era già installato. La schermata successiva chiedeva il sistema operativo. Abbiamo scelto Linux. Ci sembrava superfluo, dato che l'agente era già in esecuzione sul server, ma abbiamo proseguito.
La schermata successiva richiedeva i dettagli dell'host MongoDB. Il termine "SCRAM" è apparso senza alcuna spiegazione. La maggior parte delle persone lo conosce come autenticazione tramite nome utente/password, ma il termine tecnico crea confusione.
Dopo aver cliccato su Continua, New Relic ci ha chiesto su quale server installare l'agente. Questa domanda avrebbe dovuto essere posta prima, non dopo che avevamo 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 chiedeva di verificare la compatibilità della versione MongoDB. New Relic voleva che eseguissimo il comando mongod --version e confermassimo che l'output corrispondesse ai suoi requisiti. Dovevamo copiare il comando, passare al terminale, eseguirlo, controllare il numero di versione e tornare indietro per cliccare su continua.
L'agente è già installato sul server. Potrebbe verificarlo automaticamente.
Dopo aver cliccato su continua, siamo arrivati alla fase 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 di connessione per verificare che l'utente funzionasse correttamente.
Questo approccio era migliore rispetto a richiedere l'accesso come 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 ci chiede di installarlo manualmente tramite yum. Nonostante l'agente sia già installato su Ubuntu, l'interfaccia utilizza di default Amazon Linux e fornisce comandi di installazione tramite yum anziché apt. Ci aspettavamo che la piattaforma rilevasse automaticamente il sistema operativo corretto dall'agente installato.
Abbiamo eseguito il comando apt corretto per Ubuntu, quindi siamo passati alla schermata successiva. New Relic ci ha fornito un file di configurazione YAML e ci ha indicato esattamente dove posizionarlo: /etc/newrelic-infra/integrations.d/ . Almeno il percorso del file era chiaro.
Abbiamo creato il file, incollato la configurazione e cliccato su Continua. Nella schermata finale è apparso un pulsante "Verifica connessione". Lo abbiamo cliccato e abbiamo atteso.
Il test è andato a buon fine. Configurazione completata.
3. Datadog
L'integrazione con Datadog ha richiesto oltre 20 minuti. Alla fine ha funzionato, ma per arrivarci è stato necessario un notevole sforzo manuale.
Dopo aver effettuato l'accesso, siamo andati su Integrazioni e abbiamo cercato "mongo". Abbiamo cliccato su MongoDB e si è aperta una finestra modale.
La panoramica mostrava cosa include il monitoraggio MongoDB, ma cliccando su "Installa integrazione" si apriva un'altra schermata con istruzioni dense di dettagli.
È qui che Datadog ci ha sbalorditi. Lo schermo mostrava una guida di riferimento completa che copriva ogni possibile scenario: istanze standalone, set di repliche, cluster sharded, metodi di autenticazione, configurazione SSL e altro ancora.
Per qualcuno che cercava semplicemente di monitorare una singola istanza di MongoDB, la quantità di testo sembrava eccessiva.
Abbiamo scorporato la pagina alla ricerca dei passaggi fondamentali:
- Creare 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 quando si è trattato del file YAML, la documentazione diceva di modificare conf.yaml senza specificare chiaramente dove questo file dovesse essere posizionato.
Sapevamo per esperienza che il percorso corretto era /etc/datadog-agent/conf.d/mongo.d/ , ma le istruzioni nascondevano questo dettaglio nelle profondità della documentazione.
Abbiamo creato l'utente MongoDB, scritto la configurazione YAML, l'abbiamo posizionata nella directory corretta e riavviato l'agente.
Quindi siamo tornati all'interfaccia di Datadog e abbiamo cliccato su "Installa integrazione".
Il pulsante è scomparso. Nessun messaggio di conferma, nessuna notifica di successo, nessun reindirizzamento a una dashboard. Niente.
Abbiamo atteso un attimo, poi siamo passati manualmente alla sezione Dashboard e abbiamo trovato MongoDB metriche che iniziavano a popolarsi.
2. Consumo di risorse dell'agente
Abbiamo monitorato la quantità di risorse consumate da 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 messo sotto stress il sistema inserendo 2 milioni di record in MongoDB utilizzando uno script che generava dati casuali. Questo ha simulato l'attività reale del database, mentre misuravamo l'utilizzo delle risorse da parte dell'agente.
Consumo della CPU
Durante il test, tutti e tre gli agenti hanno utilizzato risorse CPU minime.
- New Relic ha mostrato il consumo medio di CPU più basso, ma ha registrato picchi occasionali fino al 4%. Questi picchi sono stati brevi e non hanno influito sulle prestazioni del sistema.
- Solarwinds ha mantenuto l'utilizzo della CPU più costante, attestandosi intorno al 3% senza variazioni significative.
- Datadog si è posizionato a metà classifica, con una media di poco superiore al 2% e prestazioni stabili durante tutto il test.
Utilizzo della memoria
L'utilizzo della memoria ha mostrato differenze più significative tra gli agenti.
New Relic ha consumato circa 5-6 volte meno memoria rispetto a Solarwinds. Sul nostro server di test da 16 GB, questo si è tradotto in:
- Nuova reliquia: ~90 MB
- Datadog: ~330 MB
- Solarwinds: ~500 MB
Per la maggior parte dei server di produzione, queste cifre non saranno rilevanti. Ma se si eseguono agenti su sistemi con risorse limitate o si monitorano centinaia di database, la differenza si accumula.
L'utilizzo della memoria è rimasto stabile su tutti e tre gli agenti durante il test. Non si sono verificate perdite di memoria né incrementi inattesi.
I/O del disco
L'attività del disco variava considerevolmente tra i diversi agenti.
SolarWinds ha effettuato un numero significativamente maggiore di letture del disco rispetto agli altri due agenti, circa 40 volte di più rispetto a New Relic e 1,5 volte di più rispetto a Datadog. Ciò suggerisce che SolarWinds accede ai dati archiviati localmente con maggiore frequenza, probabilmente per le sue funzionalità di profilazione delle query.
Datadog ha scritto meno dati su disco, il che indica che memorizza meno dati localmente prima di inviarli al cloud.
New Relic ha mostrato il modello di I/O più bilanciato, con letture e scritture moderate.
Utilizzo della rete
Il traffico di rete ha mostrato la quantità di dati che ciascun agente ha inviato al proprio backend.
Tutti e tre gli agenti hanno inviato quantità di dati simili sulla rete. Datadog ne ha trasmessi leggermente meno, probabilmente a causa di una compressione più aggressiva o di frequenze di campionamento diverse.
Il traffico bidirezionale ha senso, poiché gli agenti inviano metriche e ricevono aggiornamenti di configurazione o comandi dalla piattaforma.
Sintesi dell'impatto sulle risorse
Nessuno di questi agenti sovraccaricherà 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 eccelle in termini di efficienza della memoria. Solarwinds utilizza più risorse ma offre analisi a livello di query più dettagliate. Datadog si posiziona a metà classifica.
Nella maggior parte dei casi, queste differenze in termini di risorse non influenzeranno la tua decisione. Scegli in base alle funzionalità e alla facilità d'uso, non al consumo di risorse.
3. Funzionalità di dashboard e monitoraggio
Dopo aver completato la configurazione, dovevamo verificare cosa mostrasse 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 utilizzava Node.js con Faker per generare dati casuali relativi a nomi utente, email, indirizzi fisici e numeri di telefono. Questo ci ha permesso di ottenere un set di dati realistico da monitorare.
Durante l'esecuzione degli inserimenti, abbiamo monitorato in background il consumo di risorse dell'agente.
Il carico di lavoro ha messo davvero sotto pressione MongoDB, il che ci ha permesso di vedere come ogni piattaforma ha catturato e visualizzato l'attività.
Pannello di controllo Solarwinds
Abbiamo cliccato su "Database" nel menu a sinistra e abbiamo immediatamente visualizzato la nostra istanza MongoDB. Con un solo clic, è apparsa una dashboard completa.
Nella parte superiore dello schermo venivano visualizzati lo stato di salute del servizio MongoDB, il tempo di risposta medio, la velocità di elaborazione (query al secondo) e il numero di errori. Il grafico a bolle "Top 10 Service Breakdown" mostrava i modelli di query più utilizzati con i relativi conteggi e percentuali.
I numeri parlavano da soli. La velocità di elaborazione mostrava una media di 3 query al secondo. L'analisi dettagliata rivelava 1.400 operazioni di inserimento. Perché 1.400 invece di 7 milioni?
Abbiamo inserito 7 milioni di record in lotti da 5.000. Ciò corrisponde a 1.400 operazioni batch. Solarwinds ha tracciato ogni singolo lotto senza perderne nemmeno uno.
La scheda Profiler mostrava i modelli di query con i tempi di esecuzione medi.
Le nostre query di inserimento hanno richiesto 4-5 secondi ciascuna, un tempo che può sembrare elevato finché non si considera che ogni query ha scritto 5.000 righe.
La scheda Salute mostrava che tutto funzionava correttamente.
Abbiamo interrotto il servizio MongoDB per vedere quanto velocemente Solarwinds se ne sarebbe accorta. Entro 30-40 secondi, lo stato di salute è cambiato in "Cattivo".
La scheda Query offriva filtri avanzati. Era possibile elencare le query che:
- Errori restituiti
- Eseguito senza indici appropriati
- Rispose lentamente
- Avvisi generati
Per ogni modello di query venivano mostrati la data della sua prima apparizione, l'ultima esecuzione, il numero di campioni acquisiti e le statistiche di esecuzione. Questo livello di dettaglio è fondamentale per la risoluzione dei problemi.
La scheda Avvisi ci ha permesso 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 Risorse mostrava metriche a livello host insieme a statistiche su CPU, memoria, disco e rete. Questo contesto aiuta a distinguere tra problemi del database e problemi dell'infrastruttura sottostante.
La scheda Advisors non conteneva ancora raccomandazioni, ma le aveva fornite per MySQL nel nostro test precedente. Prevediamo che offrirà suggerimenti di ottimizzazione man mano che raccoglierà più dati MongoDB.
Aggiornamenti sull'IA : nell'ottobre 2025, SolarWinds ha lanciato l'Agente AI con la funzionalità AI Query Assist (attualmente in anteprima tecnologica). AI Query Assist analizza i modelli di query del database e propone riscritture ottimizzate per migliorare automaticamente le prestazioni. Root Cause Assist (ora disponibile a livello generale) genera analisi chiare delle cause principali basate su avvisi e anomalie per ridurre i tempi di risoluzione dei problemi. Una maggiore disponibilità dell'Agente AI nell'intero portfolio SolarWinds è prevista per il 2026. 1 2 .
Dashboard di New Relic
Siamo andati alla sezione Dashboard, ma non è apparsa automaticamente alcuna dashboard MongoDB.
Abbiamo cercato “mongo” nel catalogo del dashboard e abbiamo trovato due opzioni MongoDB.
Abbiamo selezionato la dashboard standard MongoDB e abbiamo cliccato su "Configura MongoDB".
Ci ha reindirizzati di nuovo alla procedura di configurazione dell'integrazione MongoDB. La piattaforma sapeva già che avevamo installato MongoDB, quindi perché rimandarci all'installazione? Abbiamo cliccato su "Fine" e siamo passati alla dashboard.
La dashboard si è aperta completamente vuota. "Nessun valore segnalato per il controllo del servizio mongodb.can_connect."
Abbiamo verificato la nostra configurazione utilizzando newrelic-infra agent configtest .
Quando abbiamo eseguito il comando `newrelic-infra agent configtest` per verificare la presenza di problemi con la nostra configurazione, abbiamo notato che `integration_name` era impostato su `nri-prometheus`. Durante la configurazione della dashboard, New Relic ha mostrato due opzioni MongoDB, una delle quali era la versione per Prometheus. Nulla nell'interfaccia utente indicava che si trattava di un'integrazione diversa, quindi non mi sarebbe mai venuto in mente di aver selezionato quella per Prometheus. Non si è trattato di un errore dell'utente; semplicemente non c'era alcuna indicazione 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 già complicato, e ora la selezione della dashboard aggiungeva un ulteriore livello di complessità.
L'interfaccia del pannello di controllo risultava strana. La parte superiore mostrava il numero totale di server e database, informazioni che cambiano una volta all'anno, eppure occupava una posizione privilegiata sullo schermo.
Più in basso, in bella vista, compariva la voce "Saturazione della connessione". Questa metrica è rilevante solo quando qualcosa non va. Perché metterla in cima?
La sezione "Operazioni di query" riportava 11.670 inserimenti. Il numero era errato. Abbiamo inserito 7 milioni di record in 1.400 operazioni batch. Il grafico non corrispondeva alla realtà.
La scheda Database mostrava le dimensioni 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 della query in tempo reale non è andato a buon fine.
La scheda Raccolte include grafici utili per le metriche a livello di raccolta: dimensione (con visualizzazione sia in tabella che in grafico), dimensione totale con variazione percentuale, conteggio delle operazioni di lettura, latenza di lettura, conteggio delle operazioni di scrittura, latenza di scrittura, conteggio delle transazioni, latenza delle transazioni, operazioni di accesso all'indice, conteggio delle esecuzioni dei comandi, latenza dei comandi, frequenza dei comandi e durata dei comandi.
Notevolmente assenti: metriche dell'host. Non è stato possibile visualizzare l'utilizzo di CPU, memoria, disco o rete per il server che esegue 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 modello di query, nessuna profilazione, nessuna identificazione delle query lente, nessun rilevamento degli indici mancanti. Per la risoluzione dei problemi del database, queste funzionalità sono fondamentali.
Dashboard di Datadog
Abbiamo cliccato su "Dashboard" nel menu a sinistra. È apparsa automaticamente una dashboard denominata "MongoDB – Panoramica".
L'abbiamo aperto, ma era vuoto.
La diagnosi del problema ha richiesto tempo. Durante l'installazione, la configurazione di rilevamento automatico di Datadog richiedeva di specificare quali database monitorare utilizzando una corrispondenza di pattern. Il pattern predefinito non corrispondeva al nome del nostro database. Datadog non aveva mai menzionato questo aspetto 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, avrebbero dovuto essere visualizzati il tempo di attività, il numero di connessioni e le statistiche del server. Invece non lo erano.
Abbiamo eseguito il comando datadog-agent check mongo per effettuare il debug. Il file di configurazione presentava un errore di indentazione. Il rigoroso requisito di formattazione di YAML ci ha tratto in inganno. Dopo averlo corretto e aver rieseguito il test di carico con 5 milioni di inserimenti, i dati sono finalmente apparsi.
Abbiamo subito riscontrato problemi con la dashboard. La sezione Log risultava "Non accessibile" nonostante avessimo configurato la raccolta dei log nel nostro file YAML. La procedura di configurazione di Datadog segnalava che tutto era a posto, ma i log continuavano a non funzionare.
Il layout del pannello di controllo era poco adatto al nostro caso d'uso. La sezione superiore si concentrava sulle statistiche di sharding, ma noi non utilizzavamo un cluster sharded. La sezione centrale mostrava le metriche dei set di repliche, di cui non avevamo. La parte inferiore tornava a concentrarsi sullo sharding. Circa il 60% del pannello di controllo era costituito da sezioni vuote relative a funzionalità che non utilizzavamo.
Le informazioni utili occupavano forse il 40% dello schermo: tempo di attività, utilizzo 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, nessun suggerimento di indicizzazione.
Da questa dashboard non siamo riusciti nemmeno a determinare quante operazioni fossero state eseguite.
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 pulita con l'agente di monitoraggio principale già installato
Tutti e tre i fornitori richiedono l'installazione del loro agente di base prima di aggiungere integrazioni specifiche, come MongoDB. Abbiamo completato questo passaggio in precedenza, quindi il nostro test si è concentrato esclusivamente sull'esperienza di integrazione con MongoDB.
Cosa abbiamo misurato:
- Complessità della configurazione: numero di passaggi manuali, configurazione automatica o manuale, chiarezza delle istruzioni e se l'interfaccia ci ha guidato o ci ha lasciato alla ricerca dei passaggi successivi.
- Consumo di risorse dell'agente: CPU, memoria, I/O del disco e utilizzo della rete in fase di inattività e sotto carico (inserimento di 7 milioni di record).
- Funzionalità di monitoraggio: qualità del dashboard, accuratezza delle metriche, analisi a livello di query e funzionalità di risoluzione dei problemi.
Considerazioni sulla sicurezza
È stata scoperta una grave vulnerabilità denominata "MongoBleed", che interessa le versioni del server MongoDB precedenti alla 8.0.17, 7.0.28, 6.0.27 e versioni precedenti. Questa vulnerabilità di lettura fuori dai limiti senza autenticazione potrebbe consentire agli aggressori di accedere a dati sensibili in memoria. Le organizzazioni che utilizzano 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.30. 3 4 Quando si selezionano gli strumenti di monitoraggio, assicurarsi che supportino metodi di autenticazione sicuri e non introducano ulteriori rischi per la sicurezza.
Abbiamo utilizzato ogni strumento come farebbe un utente normale, senza leggere la documentazione in anticipo e senza alcuna formazione preliminare. Se qualcosa non era evidente nell'interfaccia, lo abbiamo annotato.
Verdetto finale
Ci siamo posti l'obiettivo di rispondere a una semplice domanda: quale piattaforma di monitoraggio semplifica l'integrazione di MongoDB per i team non tecnici?
Dopo aver installato tutti e tre i prodotti, eseguito carichi di lavoro identici e valutato le dashboard, la risposta è diventata chiara. La nostra valutazione si basa sull'integrazione base di Datadog per MongoDB a gennaio 2025. Da allora, Datadog ha rilasciato Database Monitoring (DBM) per MongoDB (dicembre 2024), che offre funzionalità significativamente più avanzate, tra cui la profilazione delle query, l'analisi delle operazioni lente, i piani di esecuzione e il monitoraggio della replica. Il prodotto DBM risolve molte delle limitazioni identificate in questo benchmark. 5 .
Solarwinds: progettato per il monitoraggio dei database.
SolarWinds ha vinto questo confronto in modo decisivo. La piattaforma ha rilevato immediatamente il nostro agente, ci ha guidato nella configurazione delle credenziali tramite comandi copia-incolla e ha implementato automaticamente l'integrazione. La configurazione ha richiesto 5 minuti.
La dashboard è apparsa immediatamente con le informazioni pertinenti. La profilazione delle query ha mostrato esattamente quali operazioni consumavano la maggior parte delle risorse. La piattaforma ha acquisito tutte le 1.400 operazioni batch senza perderne alcuna. Quando abbiamo interrotto MongoDB, SolarWinds ha rilevato l'errore entro 40 secondi.
La scheda Query ci permette di filtrare in base a errori, indici mancanti, risposte lente e avvisi, funzionalità che supportano direttamente l'ottimizzazione del database. La funzionalità Advisor avrebbe dovuto fornire raccomandazioni (anche se durante il nostro test non abbiamo generato dati sufficienti per attivarne alcuna).
Solarwinds si è concentrata su ciò di cui gli amministratori di database hanno effettivamente bisogno: analisi delle query, profilazione delle prestazioni e informazioni utili.
Nuova reliquia: Perso nella configurazione
L'installazione di New Relic ha richiesto 15 minuti, ma il tempo non è stato il problema principale. La piattaforma poneva le domande nell'ordine sbagliato, richiedeva la verifica manuale di elementi che l'agente avrebbe potuto controllare automaticamente e ci costringeva a installare manualmente i pacchetti.
La confusione nella dashboard ha peggiorato ulteriormente la situazione. Abbiamo installato il monitoraggio MongoDB, ma selezionando la dashboard predefinita abbiamo ottenuto 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 se ne accorgerebbe.
Quando i dati sono finalmente apparsi, le metriche erano errate. New Relic ha segnalato 11.670 inserimenti dopo che avevamo eseguito 1.400 operazioni batch, per un totale di 7 milioni di record. La piattaforma ha sottostimato il numero di record di un ordine di grandezza.
Ancora più importante, New Relic non forniva alcuna analisi a livello di query. Nessuna profilazione, nessun rilevamento di query lente, nessuna identificazione di indici mancanti. Per la risoluzione dei problemi del database, queste omissioni sono significative.
Datadog: Lavoro manuale richiesto
L'installazione di Datadog ha richiesto più di 20 minuti e la maggior parte della configurazione è stata manuale. Abbiamo modificato i file YAML, determinato la loro posizione e riavviato i servizi dalla riga di comando.
La dashboard è apparsa automaticamente ma non visualizzava nulla. La configurazione di rilevamento automatico utilizzava uno schema che non corrispondeva al nostro database. Dopo aver corretto lo schema e gli errori di indentazione YAML, i dati sono stati finalmente visualizzati.
La dashboard stessa si è rivelata mal progettata per un'istanza singola MongoDB. Il sessanta percento dello schermo era vuoto, con sezioni per funzionalità di sharding e set di repliche che non stavamo utilizzando. Il restante 40 percento offriva metriche di base: uptime, memoria, I/O di rete, query al secondo e latenza.
Nessuna analisi delle query. Nessuna profilazione. Nessun suggerimento di ottimizzazione. Non siamo riusciti a determinare con precisione il numero di operazioni sul pannello di controllo.
Nessuna analisi delle query. Nessuna profilazione. Nessun suggerimento di ottimizzazione. Non siamo riusciti a determinare con precisione il numero di operazioni sul pannello di controllo.
Aggiornamento critico (dicembre 2024) : Dopo il completamento di questo benchmark, Datadog ha lanciato Database Monitoring (DBM) per MongoDB, che modifica significativamente questa valutazione. DBM per MongoDB ora offre:
- Analisi delle operazioni lente con esempi di query dettagliati
- Spiega i piani per l'ottimizzazione delle query
- Monitoraggio dello stato di replica e visualizzazione dello stato di salute del cluster
- Analisi a livello operativo e identificazione dei colli di bottiglia nelle prestazioni
- Integrazione con il monitoraggio delle prestazioni delle applicazioni per una risoluzione unificata dei problemi.
DBM rappresenta un notevole miglioramento rispetto all'integrazione di base MongoDB testata in questo benchmark e include molte delle funzionalità di analisi a livello di query che erano assenti durante i nostri test 6 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 del database funziona davvero quando non si è esperti di DevOps?
L'esperienza di configurazione
SolarWinds si apre con una finestra modale che chiede cosa si desidera monitorare. Si seleziona "prestazioni del database", si sceglie MongoDB e la piattaforma trova immediatamente l'agente già installato, mostrando il sistema operativo, l'ID dell'istanza cloud e il numero di versione direttamente nella schermata di selezione. Quindi fornisce tre comandi da copiare e incollare da eseguire in MongoDB, gestisce le credenziali e conferma la distribuzione. Cinque minuti, dall'inizio alla fine.
L'installazione di New Relic ha richiesto quindici minuti, e il tempo non era nemmeno il vero problema. L'interfaccia continuava a porre domande a cui l'agente avrebbe potuto rispondere da solo, come ad esempio quale sistema operativo e quale versione di MongoDB, nonostante l'agente fosse già presente sul server. A un certo punto, ha impostato di default i comandi di installazione di Amazon Linux, anche se stavamo chiaramente utilizzando Ubuntu. Il passaggio che ha definitivamente compromesso l'esperienza: nel catalogo della dashboard sono presenti due opzioni di integrazione MongoDB, una standard e una basata su Prometheus, e nulla nell'interfaccia utente le distingue. Abbiamo scelto quella sbagliata, ottenendo una dashboard vuota, e l'abbiamo capito solo dopo aver esaminato i file di configurazione.
Per configurare Datadog sono stati necessari oltre venti minuti di modifica di file YAML, tentativi di indovinare i percorsi dei file e riavvii dei servizi da riga di comando. La documentazione fornita durante la configurazione non è una guida, ma un manuale di riferimento completo che tratta istanze standalone, set di repliche, cluster sharded e configurazione SSL, tutto in una volta, per chi desidera semplicemente monitorare un singolo database. Quando finalmente sono comparsi i dati, la dashboard mostrava principalmente statistiche sullo sharding e metriche sui set di repliche. Noi non avevamo né l'una né l'altra. Circa il sessanta percento dello schermo era vuoto.
Precisione metrica sotto carico
SolarWinds ha contato 1.400. Esattamente corretto. New Relic ha riportato 11.670, un ordine di grandezza errato senza alcuna spiegazione ovvia, e ha completamente mancato un picco di memoria durante il test. Quando abbiamo interrotto il servizio MongoDB, SolarWinds ha rilevato l'errore entro trenta o quaranta secondi.
Per quanto riguarda il consumo di risorse: New Relic ha utilizzato circa 90 MB di RAM, Datadog circa 330 MB e SolarWinds circa 500 MB sul nostro server da 16 GB. SolarWinds ha effettuato circa quaranta volte più letture del disco rispetto a New Relic, probabilmente a causa del lavoro di profilazione delle query locali. Nella maggior parte degli ambienti, nessuno di questi fattori influenzerà la vostra decisione.
La caratteristica che li distingue realmente
Ogni strumento di monitoraggio ti segnalerà che qualcosa è lento. La domanda è: ti dice anche perché ?
SolarWinds offre la profilazione a livello di query. La scheda Profiler mostra esattamente quali modelli di query vengono eseguiti, quanto tempo impiega ciascuno e quanti campioni vengono acquisiti. È possibile filtrare in base alle 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 totale delle operazioni. Nessuna profilazione, nessuna identificazione di query lente, nessun rilevamento di indici mancanti. Utili per confermare che un database è attivo, ma per diagnosticare le cause dei suoi problemi, sono un vicolo cieco.
Nota: Datadog ha rilasciato un prodotto di monitoraggio del database per MongoDB nel dicembre 2024, a seguito dei nostri test, che aggiunge l'analisi delle operazioni lente , i piani di esecuzione e la visibilità a livello di query. Abbiamo testato l'integrazione standard, che rimane quella che la maggior parte degli utenti incontra inizialmente.
SolarWinds : Se l'ottimizzazione del database è la tua vera preoccupazione. Metriche accurate, 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à utilizzando per l'APM e hai bisogno di informazioni di base sullo stato 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 non hai problemi con la configurazione manuale e desideri un'unica piattaforma per un'infrastruttura complessa, le oltre 600 integrazioni giustificano la complessità della configurazione iniziale, a patto che il team sia adatto.
Collegamenti di riferimento
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.