MongoDB Monitoring: SolarWinds vs New Relic vs Datadog
Wir haben SolarWinds, Datadog und New Relic auf sauberen Systemen mit MongoDB 7.0 installiert, um sie zu testen. Wir haben den vollständigen Einrichtungsprozess jedes Tools durchlaufen und jeden Schritt sowie jedes Hindernis dokumentiert.
MongoDB Benchmark-Ergebnisse für Performance-Monitoring-Tools
Plattform | Einrichtungszeit | Query-Profiling | Metrikgenauigkeit | RAM-Verbrauch | Am besten für |
|---|---|---|---|---|---|
5 Min | ✅ | 100% genau | Mittel (500MB) | Produktionsoptimierung | |
New Relic | 15 Min | ❌ | Niedrig (23 bis 800% Fehlerraten) | Niedrig (90MB) | Grundlegende Gesundheitschecks |
Datadog | 20+ Min | ❌ | Unklar | Mittel (330MB) | Monitoring über mehrere Technologien hinweg |
MongoDB Monitoring-Performance-Zusammenfassung
- SolarWinds schloss die Einrichtung in 5 Minuten mit automatischer Erkennung ab und bot Query-Level-Profiling, das den anderen fehlte.
- New Relic benötigte 15 Minuten mit manuellen Verifikationsschritten und meldete ungenaue Metriken.
- Datadog erforderte 20+ Minuten YAML-Bearbeitung und bot nur eine grundlegende Sichtbarkeit.
Sie können auch sehen, wie diese Plattformen MySQL überwachen und unsere Testumgebung und Methodik.
1. Installations- und Onboarding-Erfahrung
1. Solarwinds
SolarWinds schloss die MongoDB-Integration in unter 5 Minuten ab. Solarwinds öffnet sich mit einem einfachen Modal: „Was möchten Sie überwachen?" Wenn Sie Datenbank-Performance auswählen, zeigt die Plattform die unterstützten Datenbanken sofort an.
Nach der Auswahl von MongoDB prüft Solarwinds auf vorhandene Agenten.
Die Plattform erkannte unseren zuvor installierten Agenten sofort.
Eine Funktion stach hervor: Die Schnittstelle zeigt Agentendetails (Betriebssystem, Cloud-Instanz-ID, Version) direkt auf dem Auswahlbildschirm an. Kein Suchen durch Dropdown-Menüs.
Nun fragt SolarWinds nach MongoDB-Anmeldeinformationen. Wir gaben die Verbindungsdetails ein: localhost, Authentifizierungsmethode (passwortbasiert), Benutzername und Passwort. Der Anzeigename auto-füllte sich mit unseren Serverinformationen, obwohl er den vollständigen internen Hostnamen anstelle des zuvor angegebenen Agentennamens verwendete.
Eine Seltsamkeit: Das Dropdown-Menü „Query Capture" erschien ohne Erklärung. Wir wählten „Log" aus und machten weiter, unsicher, was die anderen Optionen bewirkten.
Der nächste Bildschirm präsentierte drei Datenbankbefehle zum Ausführen. Jeder Befehl hatte eine Kopier-Schaltfläche. Wir führten sie in MongoDB aus und klickten auf „Observe Database".
Hier beeindruckte uns Solarwinds. Anstatt uns zu bitten, Berechtigungen herauszufinden, stellte es Copy-Paste-Befehle bereit:
- Erstellen Sie einen Überwachungsbenutzer mit spezifischen Anmeldeinformationen
- Erteilen Sie die erforderlichen Berechtigungen (ClusterMonitor- und readAnyDatabase-Rollen)
- Legen Sie die Profiling-Ebene fest
Ein Zusammenfassungsbildschirm erschien und zeigte unsere Konfiguration. Der Plugin-Status zeigte „Plugin is being deployed" an.
Sekunden später änderte sich der Status zu „Plugin deployment is successful" mit einem Link zum Anzeigen des Dashboards. Einrichtung abgeschlossen.
Entdecken Sie SolarWinds Observability mit tiefgreifendem MongoDB-Monitoring und Query-Profiling. Entdecken Sie SolarWinds.
Website besuchen2. New Relic
New Relic benötigte etwa 15 Minuten zur Einrichtung, aber die Zeit war nicht das eigentliche Problem. Die Reibung entstand durch das Beantworten von Fragen, die die Plattform bereits kennen sollte.
New Relic beginnt auf der Seite „Integrations & Agents".
Wir suchten nach „mongo" und fanden mehrere MongoDB-bezogene Integrationen.
Nach der Auswahl von MongoDB bat uns New Relic, eine Instrumentierungsmethode auszuwählen.
Wir wählten „On a host", da unser Agent bereits installiert war. Der nächste Bildschirm fragte nach dem Betriebssystem. Wir wählten Linux. Dies fühlte sich unnötig an, da der Agent bereits auf dem Server lief, aber wir fuhren fort.
Der nächste Bildschirm fragte nach MongoDB-Host-Details. Der Begriff „SCRAM" erschien ohne Erklärung. Die meisten Menschen kennen dies als Benutzernamen/Passwort-Authentifizierung, aber der technische Begriff fügt Verwirrung hinzu.
Nach dem Klicken auf Weiter fragte New Relic, auf welchem Server installiert werden soll. Diese Frage hätte zuerst kommen sollen, nicht nachdem wir bereits Konfigurationsdetails eingegeben hatten. Der Agent war bereits auf „aimultiple-benchmark" installiert, also wählten wir ihn aus und fuhren fort.
Der nächste Bildschirm bat uns, die MongoDB-Versionskompatibilität zu überprüfen. New Relic wollte, dass wir mongod --version ausführen und bestätigen, dass die Ausgabe ihren Anforderungen entspricht. Wir mussten den Befehl kopieren, zu unserem Terminal wechseln, ihn ausführen, die Versionsnummer prüfen und zurückkehren, um auf Weiter zu klicken.
Der Agent ist bereits auf dem Server installiert. Es hätte dies automatisch überprüfen können.
Nach dem Klicken auf Weiter erreichten wir den Schritt zur Benutzererstellung. New Relic stellte ein MongoDB-Skript zur Verfügung, um den Überwachungsbenutzer zu erstellen. Die Befehle waren klar, mit korrekten Rollenzuweisungen (clusterMonitor und readAnyDatabase). Wir mussten auch einen Verbindungstestbefehl ausführen, um zu überprüfen, ob der Benutzer korrekt funktioniert.
Dieser Ansatz war besser als die Anforderung von Root-Zugriff, aber er ging davon aus, dass wir herausfinden würden, wo diese Befehle ausgeführt werden müssen.
Der nächste Bildschirm bat uns, das Integrationspaket zu installieren. Jetzt möchte New Relic, dass wir manuell mit yum installieren. Obwohl der Agent bereits auf Ubuntu installiert ist, stellt die Schnittstelle standardmäßig Amazon Linux ein und bietet yum-Installationsbefehle anstelle von apt. Wir erwarteten, dass die Plattform das richtige Betriebssystem vom installierten Agenten automatisch erkennt.
Wir führten den korrekten apt-Befehl für Ubuntu aus und wechselten dann zum nächsten Bildschirm. New Relic stellte eine YAML-Konfigurationsdatei bereit und sagte uns genau, wo sie platziert werden soll: /etc/newrelic-infra/integrations.d/. Zumindest war der Dateipfad klar.
Wir erstellten die Datei, fügten die Konfiguration ein und klickten auf Weiter. Der letzte Bildschirm zeigte eine „Test connection"-Schaltfläche. Wir klickten darauf und warteten.
Der Test bestand. Einrichtung abgeschlossen.
3. Datadog
Datadog benötigte über 20 Minuten zum Abschluss. Die Integration funktionierte schließlich, aber der Weg dorthin erforderte erhebliche manuelle Arbeit.
Nach dem Einloggen gingen wir zu Integrations und suchten nach „mongo". Wir klickten auf MongoDB und ein Modal erschien.
Die Übersicht zeigte, was MongoDB-Monitoring beinhaltet, aber das Klicken auf „Install Integration" öffnete nur einen weiteren Bildschirm mit dichten Anweisungen.
Hier wurde Datadog für uns überwältigend. Der Bildschirm zeigte einen vollständigen Referenzleitfaden, der alle möglichen MongoDB-Szenarien abdeckte: Standalone-Instanzen, Replikatsätze, Sharded-Cluster, Authentifizierungsmethoden, SSL-Konfiguration und mehr.
Für jemanden, der nur eine einzelne MongoDB-Instanz überwachen möchte, fühlte sich die Textwand als übertrieben an.
Wir scrollten durch, um nach den grundlegenden Schritten zu suchen:
- Erstellen Sie einen Überwachungsbenutzer in MongoDB
- Bearbeiten Sie die Konfigurations-YAML-Datei
- Starten Sie den Datadog-Agenten neu
Datadog stellte die MongoDB-Befehle zur Verfügung, um den Benutzer zu erstellen, was hilfreich war. Aber als es um die YAML-Datei ging, sagte die Dokumentation, dass conf.yaml bearbeitet werden sollte, ohne klar zu sagen, wo diese Datei hingehört.
Wir wussten aus Erfahrung, dass sie in /etc/datadog-agent/conf.d/mongo.d/ gehört, aber die Anweisungen vergruben dieses Detail tief in der Dokumentation.
Wir erstellten den MongoDB-Benutzer, schrieben die YAML-Konfiguration, platzierten sie im richtigen Verzeichnis und starteten den Agenten neu.
Dann gingen wir zurück zur Datadog-Oberfläche und klickten auf „Install Integration".
Die Schaltfläche verschwand. Keine Bestätigungsmeldung, keine Erfolgsbenachrichtigung, keine Weiterleitung zu einem Dashboard. Nichts.
Wir warteten einen Moment, navigierten dann manuell zum Abschnitt Dashboards und fanden MongoDB-Metriken, die sich zu füllen begannen.
2. Agenten-Ressourcenverbrauch
Wir überwachten, wie viel Ressourcen jeder Agent während des Betriebs verbrauchte. Der Test lief etwa 10 Minuten, wobei alle drei Agenten gleichzeitig Daten von derselben MongoDB-Instanz unter Last sammelten.
Wir belasteten das System, indem wir 2 Millionen Datensätze in MongoDB mit einem Skript einfügten, das zufällige Daten generierte. Dies simulierte reale Datenbankaktivitäten, während wir den Agenten-Ressourcenverbrauch maßen.
CPU-Verbrauch
Alle drei Agenten verwendeten während des Tests minimale CPU-Ressourcen.
- New Relic zeigte den niedrigsten durchschnittlichen CPU-Verbrauch, hatte jedoch gelegentliche Spitzen, die 4% erreichten. Diese Spitzen waren kurz und beeinträchtigten die Systemleistung nicht.
- Solarwinds hielt den konsistentesten CPU-Verbrauch aufrecht und blieb bei etwa 3% ohne signifikante Variation.
- Datadog lag in der Mitte, mit einem Durchschnitt von etwas über 2% und stabiler Leistung während des gesamten Tests.
Speicherverbrauch
Der Speicherverbrauch zeigte signifikante Unterschiede zwischen den Agenten.
New Relic verbrauchte etwa 5-6x weniger Speicher als Solarwinds. Auf unserem 16GB-Testserver entsprach dies:
- New Relic: ~90MB
- Datadog: ~330MB
- Solarwinds: ~500MB
Für die meisten Produktionsserver werden diese Mengen keine Rolle spielen. Aber wenn Sie Agenten auf ressourcenbeschränkten Systemen ausführen oder Hunderte von Datenbanken überwachen, summiert sich der Unterschied.
Der Speicherverbrauch blieb während des gesamten Tests bei allen drei Agenten stabil. Es traten keine Speicherlecks oder unerwartetes Wachstum auf.
Festplatten-I/O
Die Festplattenaktivität variierte erheblich zwischen den Agenten.
SolarWinds führte signifikant mehr Festplatten-Lesevorgänge durch als die anderen beiden Agenten, etwa 40-mal so viele wie New Relic und 1,5-mal so viele wie Datadog. Dies deutet darauf hin, dass SolarWinds häufiger auf lokal gespeicherte Daten zugreift, möglicherweise für seine Query-Profiling-Funktionen.
Datadog schrieb am wenigsten auf die Festplatte, was darauf hindeutet, dass es weniger Daten lokal puffert, bevor es sie in die Cloud sendet.
New Relic zeigte das ausgewogenste I/O-Muster mit moderaten Lese- und Schreibvorgängen.
Netzwerkverwendung
Der Netzwerkverkehr zeigte, wie viel Daten jeder Agent an sein Backend sendete.
Alle drei Agenten sendeten ähnliche Datenmengen über das Netzwerk. Datadog übertrug etwas weniger, möglicherweise aufgrund einer aggressiveren Komprimierung oder anderer Abtastraten.
Der bidirektionale Verkehr ergibt Sinn, da Agenten Metriken senden und Konfigurationsupdates oder Befehle von der Plattform erhalten.
Zusammenfassung der Ressourcenbelastung
Keiner dieser Agenten wird Ihr System belasten. Selbst unter Datenbanklast mit allen drei gleichzeitig laufenden Agenten blieb der gesamte Ressourcenverbrauch für CPU und Speicher zusammen weit unter 10%.
New Relic gewinnt bei der Speichereffizienz. Solarwinds verbraucht mehr Ressourcen, liefert aber eine detailliertere Analyse auf Query-Ebene. Datadog liegt in der Mitte.
Für die meisten Anwendungsfälle werden diese Ressourcenunterschiede Ihre Entscheidung nicht beeinflussen. Wählen Sie basierend auf Funktionen und Benutzerfreundlichkeit, nicht auf Ressourcenverbrauch.
Als bevorzugte Quelle hinzufügen3. Dashboard- und Monitoring-Fähigkeiten
Nach Abschluss der Einrichtung mussten wir sehen, was jede Plattform tatsächlich anzeigt. Wir führten die gleiche Arbeitslast über alle drei aus: Einfügen von 2 Millionen Datensätzen in Batches von 5.000, gefolgt von weiteren 5 Millionen Datensätzen.
Das Skript verwendete Node.js mit Faker, um zufällige Benutzerdatennamen, E-Mails, Adressen und Telefonnummern zu generieren. Dies gab uns einen realistischen Datensatz zur Überwachung.
Während die Einfügungen liefen, überwachten wir im Hintergrund den Agenten-Ressourcenverbrauch.
Die Arbeitslast belastete MongoDB wirklich, was uns zeigte, wie jede Plattform die Aktivität erfasste und anzeigte.
Solarwinds Dashboard
Wir klickten im linken Menü auf „Databases" und sahen sofort unsere MongoDB-Instanz. Ein Klick, und ein vollständiges Dashboard erschien.
Oben auf dem Bildschirm zeigte MongoDB-Gesundheit, durchschnittliche Antwortzeit, Durchsatz (Queries pro Sekunde) und Fehleranzahl an. Das „Top 10 Service Breakdown"-Blasendiagramm zeigte die am häufigsten verwendeten Query-Muster mit ihren Anzahlen und Prozentsätzen.
Die Zahlen erzählten eine Geschichte. Der Durchsatz zeigte durchschnittlich 3 Queries pro Sekunde. Die Aufschlüsselung zeigte 1.400 Einfüge-Operationen. Warum 1.400 statt 7 Millionen?
Wir fügten 7 Millionen Datensätze in Batches von 5.000 ein. Das sind 1.400 Batch-Operationen. Solarwinds verfolgte jeden einzelnen Batch, ohne einen zu verpassen.
Der Profiler-Tab zeigte Query-Muster mit durchschnittlichen Ausführungszeiten.
Unsere Einfüge-Queries dauerten jeweils 4-5 Sekunden, was hoch erscheint, bis man sich erinnert, dass jede Query 5.000 Zeilen schrieb.
Der Health-Tab zeigte, dass alles reibungslos lief.
Wir stoppten den MongoDB-Dienst, um zu sehen, wie schnell Solarwinds es bemerken würde. Innerhalb von 30-40 Sekunden änderte sich der Gesundheitsstatus zu „Bad".
Der Queries-Tab bot erweiterte Filterung. Sie konnten Queries auflisten, die:
- Fehler zurückgaben
- Ohne korrekte Indizes liefen
- Langsam reagierten
- Warnungen generierten
Jedes Query-Muster zeigte, wann es erstmals erschien, wann es zuletzt lief, wie viele Samples erfasst wurden und Ausführungsstatistiken. Für die Fehlerbehebung ist diese Detailtiefe wichtig.
Der Alerts-Tab ermöglichte uns, MongoDB-spezifische Alerts zu erstellen. Wir hatten zuvor einen Speicher-Alert für den Host erstellt, aber jetzt konnten wir datenbankspezifische Benachrichtigungen einrichten.
Der Resources-Tab zeigte Host-Level-Metriken neben MongoDB-Statistiken, CPU, Speicher, Festplatte und Netzwerk. Dieser Kontext hilft, Datenbankprobleme von zugrunde liegenden Infrastrukturproblemen zu unterscheiden.
Der Advisors-Tab hatte noch keine Empfehlungen, bot aber für MySQL in unserem vorherigen Test welche. Wir erwarten, dass er Optimierungsvorschläge bietet, sobald er mehr MongoDB-Daten sammelt.
AI-Updates: Im Oktober 2025 lancierte SolarWinds den AI Agent mit der AI Query Assist-Funktion (derzeit in Tech Preview). AI Query Assist analysiert Datenbank-Query-Muster und schlägt optimierte Neuschreibungen vor, um die Leistung automatisch zu verbessern. Root Cause Assist (jetzt allgemein verfügbar) generiert klare Ursachenanalysen basierend auf Alerts und Anomalien, um die Fehlerbehebungszeit zu verkürzen. Eine breitere Verfügbarkeit des AI Agent im SolarWinds-Portfolio ist für 2026 geplant1 2 .
New Relic Dashboard
Wir gingen zum Abschnitt Dashboards, aber kein MongoDB-Dashboard erschien automatisch.
Wir suchten nach „mongo" im Dashboard-Katalog und fanden zwei MongoDB-Optionen.
Wir wählten das reguläre MongoDB-Dashboard aus und klickten auf „Setup MongoDB.".
Es leitete uns zurück zur MongoDB-Integrations-Einrichtung. Die Plattform wusste bereits, dass wir MongoDB installiert hatten, also warum schickte sie uns zurück zur Installation? Wir klickten auf „Done" und fuhren zum Dashboard fort.
Das Dashboard öffnete sich völlig leer. „No value reported for service check mongodb.can_connect.".
Wir überprüften unsere Konfiguration mit newrelic-infra agent configtest.
Als wir den newrelic-infra agent configtest-Befehl ausführten, um nach Problemen mit unserer Konfiguration zu suchen, stellten wir fest, dass der integration_name auf nri-prometheus gesetzt war. Während des Dashboard-Setups zeigte New Relic zwei MongoDB-Optionen, von denen eine die Prometheus-Version war. Nichts in der UI deutete darauf hin, dass dies eine andere Integration war, also wäre mir nie eingefallen, dass ich die Prometheus-Version ausgewählt hatte. Dies war kein Benutzerfehler; es gab einfach keine Anleitung oder Unterscheidung in der Schnittstelle.
Wir gingen zurück und installierten das „MongoDB (Prometheus)"-Dashboard.
Dieses Mal erschienen Daten.
Aber hier ist das Problem: Wie würde ein normaler Benutzer das herausfinden? Der Installationsprozess war verwirrend, und nun fügte die Dashboard-Auswahl eine weitere Komplexitätsebene hinzu.
Das Dashboard-Layout fühlte sich seltsam an. Oben zeigte es Informationen zu Gesamtservern und Datenbanken, die sich einmal im Jahr ändern, und belegte dennoch prime Bildschirmfläche.
Darunter erschien „Connection Saturation" prominent. Diese Metrik ist nur wichtig, wenn etwas schiefgeht. Warum oben platzieren?
Der Abschnitt „Query Operations" meldete 11.670 Einfügungen. Die Zahl war falsch. Wir fügten 7 Millionen Datensätze in 1.400 Batch-Operationen ein. Das Diagramm entsprach nicht der Realität.
Der Databases-Tab zeigte Datenbankgröße, Objektanzahlen und Indexgrößen. Diese Zahlen waren korrekt: 7 Millionen Objekte. New Relic erhält diese Daten, indem es direkt bei MongoDB nachfragt („Wie viele Dokumente haben Sie?"). Aber das Echtzeit-Query-Zählen scheiterte.
Der Collections-Tab enthielt nützliche Diagramme für Sammlungs-Level-Metriken: Größe (mit Tabellen- und Diagrammansicht), Gesamtgröße mit prozentualer Änderung, Leseoperationsanzahl, Lese-Latenz, Schreiboperationsanzahl, Schreib-Latenz, Transaktionsanzahlen, Transaktions-Latenz, Indexzugriffsoperationen, Befehlsausführungsanzahlen, Befehls-Latenz, Befehlsfrequenz und Befehlsdauer.
Bemerkenswert abwesend: Host-Metriken. Wir konnten keine CPU-, Speicher-, Festplatten- oder Netzwerkverwendung für den Server sehen, auf dem MongoDB lief. SolarWinds enthielt diesen Kontext, aber Datadog, wie New Relic, nicht.
Noch wichtiger: Es gab nirgendwo eine Analyse auf Query-Ebene. Keine Query-Muster, kein Profiling, keine Erkennung langsamer Queries, keine Erkennung fehlender Indizes. Für die Datenbank-Fehlerbehebung sind diese Funktionen wichtig.
Datadog Dashboard
Wir klickten im linken Menü auf „Dashboards". Ein „MongoDB – Overview"-Dashboard erschien automatisch.
Wir öffneten es, aber es war leer.
Das Problem brauchte Zeit zur Diagnose. Während der Installation erforderte die Autodiscovery-Konfiguration von Datadog die Angabe, welche Datenbanken überwacht werden sollen, mittels eines Musterabgleichs. Das Standardmuster passte nicht auf unseren Datenbanknamen. Datadog erwähnte dies während des Setups nicht.
Wir änderten alle Muster in .* (alles abgleichen) und starteten den Agenten neu.
Aber warum war das Dashboard völlig leer? Selbst ohne datenbankspezifische Metriken sollten Verfügbarkeit, Verbindungsanzahlen und Server-Statistiken erschienen sein. Sie taten es nicht.
Wir führten datadog-agent check mongo zur Fehlerbehebung aus. Die Konfigurationsdatei hatte einen Einrückungsfehler. Die strenge Formatierungsanforderung von YAML fing uns. Nach dem Reparieren und erneuten Ausführen unseres Lasttests mit 5 Millionen Einfügungen erschienen endlich Daten.
Wir stießen sofort auf Probleme mit dem Dashboard. Der Logs-Abschnitt zeigte „Not Accessible" an, obwohl wir die Log-Sammlung in unserer YAML-Datei konfiguriert hatten. Das Setup-Verfahren von Datadog meldete, dass alles in Ordnung war, aber die Logs funktionierten immer noch nicht.
Das Dashboard-Layout ergab für unseren Anwendungsfall wenig Sinn. Der obere Abschnitt konzentrierte sich auf Sharding-Statistiken. Wir führten keinen Sharded-Cluster aus. Die Mitte zeigte Replikatsatz-Metriken. Wir hatten keine Replikatsätze. Unten ging es wieder um Sharding. Etwa 60% des Dashboards zeigten leere Abschnitte für Funktionen, die wir nicht nutzten.
Die nützlichen Informationen belegten vielleicht 40% des Bildschirms: Verfügbarkeit, Speicherverbrauch, Netzwerk-I/O, Queries pro Sekunde und Lese-/Schreib-Latenz. Keine Query-Analyse, kein Profiling, keine Erkennung langsamer Queries, keine Indexempfehlungen.
Wir konnten nicht einmal bestimmen, wie viele Operationen von diesem Dashboard aus liefen.
Testumgebung und Methodik
Wir führten alle drei Tools auf identischen Setups aus, um einen fairen Vergleich zu gewährleisten. Jeder Test verwendete:
- Datenbank: MongoDB 7.0 Community Edition
- Server: AWS m6i.xlarge Instanz
- Ausgangspunkt: Frische Installation mit dem Hauptmonitoring-Agenten bereits installiert
Alle drei Anbieter verlangen, dass Sie ihren Basis-Agenten installieren, bevor Sie spezifische Integrationen wie MongoDB hinzufügen. Wir haben diesen Schritt vorher abgeschlossen, sodass sich unser Test rein auf die MongoDB-Integrationserfahrung konzentrierte.
Was wir gemessen haben:
- Einrichtungskomplexität: Anzahl der manuellen Schritte, automatische versus manuelle Konfiguration, Klarheit der Anweisungen und ob die Schnittstelle uns führte oder uns nach nächsten Schritten suchen ließ.
- Agenten-Ressourcenverbrauch: CPU, Speicher, Festplatten-I/O und Netzwerkverwendung während Leerlauf und unter Last (Einfügen von 7 Millionen Datensätzen).
- Monitoring-Fähigkeiten: Dashboard-Qualität, Metrikgenauigkeit, Analyse auf Query-Ebene und Fehlerbehebungsfunktionen.
Sicherheitsüberlegungen
Eine schwere Schwachstelle namens „MongoBleed" wurde bekannt, die MongoDB Server-Versionen vor 8.0.17, 7.0.28, 6.0.27 und früher betrifft. Diese nicht-authentifizierte Out-of-Bounds-Lese-Schwachstelle könnte Angreifern ermöglichen, auf sensible Speicherdaten zuzugreifen. Organisationen, die MongoDB betreiben, sollten sofort auf gepatchte Versionen aktualisieren: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 oder 4.4.303 4 . Bei der Auswahl von Monitoring-Tools stellen Sie sicher, dass sie sichere Authentifizierungsmethoden unterstützen und keine zusätzlichen Sicherheitsrisiken einführen.
Wir näherten uns jedem Tool wie ein normaler Benutzer, ohne vorher Dokumentation zu lesen und ohne vorherige Schulung. Wenn etwas in der Schnittstelle nicht offensichtlich war, notierten wir es.
Endgültiges Urteil
Wir wollten eine einfache Frage beantworten: Welche Monitoring-Plattform macht die MongoDB-Integration für nicht-technische Teams am einfachsten?
Nach der Installation aller drei, dem Ausführen identischer Arbeitslasten und der Bewertung der Dashboards wurde die Antwort klar. Unsere Bewertung basiert auf der grundlegenden MongoDB-Integration von Datadog ab Januar 2025. Datadog hat seitdem Database Monitoring (DBM) für MongoDB (Dezember 2024) veröffentlicht, das signifikant tiefere Fähigkeiten bietet, einschließlich Query-Profiling, Analyse langsamer Operationen, Explain Plans und Replikationsüberwachung. Das DBM-Produkt adressiert viele der in diesem Benchmark identifizierten Einschränkungen5 .
Solarwinds: Für Datenbank-Monitoring gebaut
SolarWinds gewann diesen Vergleich entscheidend. Die Plattform erkannte unseren Agenten sofort, führte uns durch die Einrichtung von Anmeldeinformationen über Copy-and-Paste-Befehle und stellte die Integration automatisch bereit. Die Einrichtung dauerte 5 Minuten.
Das Dashboard erschien sofort mit relevanten Informationen. Das Query-Profiling zeigte genau, welche Operationen die meisten Ressourcen verbrauchten. Die Plattform erfasste alle 1.400 Batch-Operationen, ohne eine zu verpassen. Als wir MongoDB stoppten, erkannte SolarWinds den Fehler innerhalb von 40 Sekunden.
Der Queries-Tab ermöglicht es uns, nach Fehlern, fehlenden Indizes, langsamen Antworten und Warnungen zu filtern – Funktionen, die die Datenbankoptimierung direkt unterstützen. Die Advisors-Funktion sollte Empfehlungen bieten (obwohl wir nicht genügend Daten generierten, um während unseres Tests welche auszulösen).
Solarwinds konzentrierte sich auf das, was Datenbankadministratoren tatsächlich brauchen: Query-Analyse, Performance-Profiling und umsetzbare Erkenntnisse.
New Relic: In der Konfiguration verloren
New Relic benötigte 15 Minuten zur Einrichtung, aber die Zeit war nicht das Hauptproblem. Die Plattform stellte Fragen in der falschen Reihenfolge, erforderte manuelle Verifikation von Dingen, die der Agent automatisch überprüfen konnte, und zwang uns zur manuellen Installation von Paketen.
Die Dashboard-Verwirrung machte die Dinge schlimmer. Wir installierten MongoDB-Monitoring, aber die Auswahl des Standard-Dashboards führte zu einem leeren Bildschirm. Erst nachdem wir uns in Konfigurationsdateien eingearbeitet hatten, stellten wir fest, dass wir den falschen Integrationstyp ausgewählt hatten. Ein normaler Benutzer würde das nicht herausfinden.
Als die Daten endlich erschienen, waren die Metriken falsch. New Relic meldete 11.670 Einfügungen, nachdem wir 1.400 Batch-Operationen durchgeführt hatten, insgesamt 7 Millionen Datensätze. Die Plattform zählte um eine Größenordnung zu wenig.
Noch kritischer: New Relic bot keine Analyse auf Query-Ebene. Kein Profiling, keine Erkennung langsamer Queries, keine Identifizierung fehlender Indizes. Für die Datenbank-Fehlerbehebung sind diese Auslassungen wichtig.
Datadog: Manuelle Arbeit erforderlich
Datadog erforderte 20+ Minuten Einrichtung und die meiste manuelle Konfiguration. Wir bearbeiteten die YAML-Dateien, bestimmten, wo sie platziert werden sollten, und starteten die Dienste von der Kommandozeile neu.
Das Dashboard erschien automatisch, zeigte aber nichts an. Die Autodiscovery-Konfiguration verwendete ein Muster, das nicht auf unsere Datenbank passte. Nach dem Reparieren des Musters und Korrektur von YAML-Einrückungsfehlern wurden die Daten endlich befüllt.
Das Dashboard selbst erwies sich als schlecht für einzelne MongoDB-Instanzen designed. Sechzig Prozent des Bildschirms waren leer, mit Abschnitten für Sharding und Replikatsätze – Funktionen, die wir nicht nutzten. Die verbleibenden 40% boten grundlegende Metriken: Verfügbarkeit, Speicher, Netzwerk-I/O, Queries pro Sekunde und Latenz.
Keine Query-Analyse. Kein Profiling. Keine Optimierungsempfehlungen. Wir konnten die Operationsanzahl auf dem Dashboard nicht genau bestimmen.
Keine Query-Analyse. Kein Profiling. Keine Optimierungsempfehlungen. Wir konnten die Operationsanzahl auf dem Dashboard nicht genau bestimmen.
Kritisches Update (Dezember 2024): Nach Abschluss dieses Benchmarks lancierte Datadog Database Monitoring (DBM) für MongoDB, was diese Bewertung erheblich verändert. DBM für MongoDB bietet nun:
- Analyse langsamer Operationen mit detaillierten Query-Samples
- Explain Plans zur Query-Optimierung
- Überwachung des Replikationszustands und Visualisierung der Cluster-Gesundheit
- Insights auf Operationsebene und Identifizierung von Performance-Engpässen
- Integration mit Application Performance Monitoring für einheitliche Fehlerbehebung
DBM stellt ein erhebliches Upgrade gegenüber der in diesem Benchmark getesteten grundlegenden MongoDB-Integration dar und umfasst viele der Analysefunktionen auf Query-Ebene, die während unseres Tests fehlten6 7 . Organisationen, die Datadog für MongoDB-Monitoring evaluieren, sollten speziell das Database Monitoring-Produkt bewerten, nicht die hier getestete grundlegende Integration.
Welches DB-Monitoring-Tool funktioniert tatsächlich, wenn man kein DevOps-Experte ist?
Die Einrichtungserfahrung
SolarWinds öffnete sich mit einem Modal, das fragte, was Sie überwachen möchten. Sie wählen „database performance", wählen MongoDB aus, und die Plattform findet sofort den Agenten, den Sie bereits installiert haben, und zeigt Ihnen das Betriebssystem, die Cloud-Instanz-ID und die Versionsnummer direkt auf dem Auswahlbildschirm. Dann gibt es Ihnen drei Copy-Paste-Befehle, die Sie in MongoDB ausführen sollen, behandelt die Anmeldeinformationen und bestätigt die Bereitstellung. Fünf Minuten, von Anfang bis Ende.
New Relic benötigte fünfzehn Minuten, und die Zeit war nicht einmal das eigentliche Problem. Die Schnittstelle stellte ständig Fragen, die der Agent selbst beantworten könnte, wie welches Betriebssystem und welche MongoDB-Version, obwohl der Agent bereits auf dem Server war. An einem Punkt stellte es standardmäßig Amazon Linux-Installationsbefehle bereit, obwohl wir eindeutig Ubuntu ausführten. Der Schritt, der die Erfahrung schließlich brach: Es gibt zwei MongoDB-Integrationsoptionen im Dashboard-Katalog, eine Standard- und eine Prometheus-basierte, und nichts in der UI unterscheidet sie. Wir wählten die falsche aus, bekamen ein leeres Dashboard und merkten es erst, als wir uns in Konfigurationsdateien eingearbeitet hatten.
Datadog erforderte über zwanzig Minuten YAML-Bearbeitung, das Raten von Dateipfaden und das Neustarten von Diensten von der Kommandozeile. Die während des Setups angebotene Dokumentation ist kein Leitfaden; es ist ein vollständiges Referenzhandbuch, das Standalone-Instanzen, Replikatsätze, Sharded-Cluster und SSL-Konfiguration auf einmal abdeckt, für jemanden, der nur eine Datenbank überwachen möchte. Als Daten endlich erschienen, führte das Dashboard mit Sharding-Statistiken und Replikatsatz-Metriken. Wir hatten beides nicht. Etwa sechzig Prozent des Bildschirms waren leer.
Metrikgenauigkeit unter Last
SolarWinds zählte 1.400. Genau richtig. New Relic meldete 11.670, falsch um eine Größenordnung ohne offensichtliche Erklärung, und verpasste einen Speicher-Spike während des Tests vollständig. Als wir den MongoDB-Dienst stoppten, erkannte SolarWinds den Fehler innerhalb von dreißig bis vierzig Sekunden.
Hinsichtlich des Ressourcenverbrauchs: New Relic verwendete etwa 90MB RAM, Datadog etwa 330MB und SolarWinds etwa 500MB auf unserem 16GB-Server. SolarWinds führte etwa vierzigmal mehr Festplatten-Lesevorgänge durch als New Relic, wahrscheinlich aufgrund lokaler Query-Profiling-Arbeit. Für die meisten Umgebungen wird dies Ihre Entscheidung nicht beeinflussen.
Die Funktion, die sie tatsächlich trennt
Jedes Monitoring-Tool wird Ihnen sagen, dass etwas langsam ist. Die Frage ist, ob es Ihnen sagt, warum.
SolarWinds bietet Query-Level-Profiling. Der Profiler-Tab zeigte genau, welche Query-Muster ausgeführt wurden, wie lange jeder dauerte und wie viele Samples erfasst wurden. Sie können nach Queries filtern, die ohne Index liefen, Fehler zurückgaben oder Warnungen generierten.
New Relic und Datadog zeigten nur aggregierte Metriken für Latenz, Verbindungsanzahlen und Operationsgesamtwerte. Kein Profiling, keine Erkennung langsamer Queries, keine Identifizierung fehlender Indizes. Um zu bestätigen, dass eine Datenbank am Leben ist, machbar. Um zu diagnostizieren, warum sie kämpft, eine Sackgasse.
Hinweis: Datadog veröffentlichte im Dezember 2024 ein Database Monitoring-Produkt für MongoDB, nach unserem Testen, das Analyse langsamer Operationen, Explain Plans und Sichtbarkeit auf Query-Ebene hinzufügt. Wir testeten die Standardintegration, die für die meisten Benutzer das Erste bleibt, auf das sie stoßen.
SolarWinds: Wenn Datenbankoptimierung Ihr tatsächliches Anliegen ist. Akkurate Metriken, schnelle Einrichtung und die einzige Plattform hier, die Ihnen nicht nur sagt, dass eine Query langsam ist, sondern was Sie dagegen tun können.
New Relic: Wenn Sie es bereits für APM verwenden und grundlegende Datenbankgesundheit am selben Ort benötigen. Das Verfolgen einer langsamen Anfrage vom Browser durch den Code bis zum Datenbankaufruf ist wirklich nützlich. Verlassen Sie sich nicht auf genaue Operationsanzahlen.
Datadog: Wenn Sie mit manueller Konfiguration vertraut sind und eine Plattform über einen komplexen Stack hinweg wünschen. Die über 600 Integrationen rechtfertigen die Setup-Reibung für das richtige Team.
Diese Forschung zitieren
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@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. Abgerufen am 12. Juni 2026}
}Referenzlinks
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.