MongoDB-Überwachung: SolarWinds vs. New Relic vs. Datadog
Wir installierten SolarWinds, Datadog und New Relic auf sauberen Systemen mit MongoDB 7.0 zu Testzwecken. Wir durchliefen den kompletten Einrichtungsprozess jedes Tools und dokumentierten jeden Schritt und jedes Problem.
MongoDB Performance Monitoring Tools Benchmark-Ergebnisse
Plattform | Einrichtungszeit | Abfrageprofilierung | Metrische Genauigkeit | RAM-Nutzung | Am besten geeignet für |
|---|---|---|---|---|---|
5 Minuten | ✅ | ✅ 100 % genau | Mittel (500 MB) | Produktionsoptimierung | |
New Relic | 15 Minuten | ❌ | ❌ Niedrig (Fehlerraten von 23 bis 800 %) | Niedrig (90 MB) | Grundlegende Gesundheitschecks |
Datadog | 20+ Minuten | ❌ | ⚠️ Unklar | Mittel (330 MB) | Multi-Tech-Überwachung |
MongoDB-Überwachungsleistungsübersicht
- SolarWinds schloss die Einrichtung in 5 Minuten mit automatischer Erkennung ab und bot eine Abfrageprofilierung, die den anderen fehlte.
- New Relic benötigte 15 Minuten für die manuelle Überprüfung und meldete ungenaue Messwerte.
- Datadog erforderte mehr als 20 Minuten YAML-Bearbeitung und bot nur grundlegende Einblicke.
Sie können außerdem sehen, wie diese Plattformen MySQL sowie unsere Testumgebung und -methodik überwachen.
1. Installations- und Onboarding-Erfahrung
1. Solarwinds
SolarWinds schloss die MongoDB-Integration in weniger als 5 Minuten ab. SolarWinds öffnet sich mit einem einfachen Dialogfeld: „Was möchten Sie überwachen?“ Bei Auswahl von „Datenbankleistung “ werden die unterstützten Datenbanken direkt angezeigt.
Nach der Auswahl von MongoDB prüft Solarwinds, ob bereits Agenten vorhanden sind.
Die Plattform hat unseren zuvor installierten Agenten sofort erkannt.
Ein Merkmal stach besonders hervor: Die Benutzeroberfläche zeigt Agentendetails (Betriebssystem, Cloud-Instanz-ID, Version) direkt auf dem Auswahlbildschirm an. Kein Suchen in Dropdown-Menüs.
SolarWinds fragt nun nach den MongoDB-Zugangsdaten. Wir haben die Verbindungsdetails eingegeben: localhost, Authentifizierungsmethode (passwortbasiert), Benutzername und Passwort. Der Anzeigename wurde automatisch mit unseren Serverinformationen ausgefüllt, allerdings wurde der vollständige interne Hostname anstelle des zuvor angegebenen Agentennamens verwendet.
Eine Merkwürdigkeit: Das Dropdown-Menü „Abfrageerfassung“ erschien ohne Erklärung. Wir wählten „Protokoll“ und fuhren fort, ohne zu wissen, was die anderen Optionen bewirkten.
Im nächsten Bildschirm wurden drei Datenbankbefehle zur Ausführung angezeigt. Jeder Befehl verfügte über eine Kopierschaltfläche. Wir führten sie in MongoDB aus und klickten auf „Datenbank beobachten“.
Hier hat uns SolarWinds beeindruckt. Anstatt uns die Berechtigungen selbst ermitteln zu lassen, stellte es Befehle zum Kopieren und Einfügen bereit:
- Erstellen Sie einen Überwachungsbenutzer mit spezifischen Anmeldeinformationen.
- Gewähren Sie die erforderlichen Berechtigungen (Rollen clusterMonitor und readAnyDatabase).
- Profilierungsstufe festlegen
Es erschien eine Übersichtsseite mit unserer Konfiguration. Der Plugin-Status zeigte „Plugin wird bereitgestellt“ an.
Wenige Sekunden später änderte sich der Status zu „Plugin-Bereitstellung erfolgreich“ mit einem Link zum Dashboard. Einrichtung abgeschlossen.
Entdecken Sie SolarWinds Observability mit umfassendem MongoDB-Monitoring und Abfrageprofiling. Erfahren Sie mehr über SolarWinds.
Website besuchen2. New Relic
Die Einrichtung von New Relic dauerte etwa 15 Minuten, aber die Zeit war nicht das eigentliche Problem. Die Schwierigkeiten entstanden durch die Beantwortung von Fragen, die die Plattform eigentlich schon hätte beantworten müssen.
New Relic beginnt auf der Seite „Integrationen & Agenten“.
Wir suchten nach „mongo“ und fanden mehrere MongoDB-bezogene Integrationen.
Nach der Auswahl von MongoDB forderte New Relic uns auf, eine Instrumentierungsmethode auszuwählen.
Wir wählten „Auf einem Host“, da unser Agent bereits installiert war. Im nächsten Bildschirm wurden wir nach dem Betriebssystem gefragt. Wir wählten Linux. Das erschien uns überflüssig, da der Agent ja bereits auf dem Server lief, aber wir fuhren fort.
Im nächsten Bildschirm wurden die MongoDB-Hostdetails abgefragt. Der Begriff „SCRAM“ erschien ohne Erklärung. Die meisten kennen dies als Benutzername/Passwort-Authentifizierung, doch der Fachbegriff stiftet Verwirrung.
Nach dem Klick auf „Weiter“ fragte New Relic, auf welchem Server die Installation erfolgen sollte. Diese Frage hätte zuerst gestellt werden müssen, nicht erst nach Eingabe der Konfigurationsdetails. Der Agent war bereits auf „aimultiple-benchmark“ installiert, daher wählten wir diesen Server aus und fuhren fort.
Im nächsten Bildschirm wurden wir aufgefordert, die MongoDB-Versionskompatibilität zu überprüfen. New Relic verlangte, dass wir den Befehl mongod --version ausführen und bestätigen, dass die Ausgabe den Anforderungen entspricht. Wir mussten den Befehl kopieren, zu unserem Terminal wechseln, ihn ausführen, die Versionsnummer überprüfen und anschließend zurückkehren, um auf „Weiter“ zu klicken.
Der Agent ist bereits auf dem Server installiert. Er könnte dies automatisch überprüfen.
Nach dem Klick auf „Weiter“ gelangten wir zur Benutzererstellung. New Relic stellte ein MongoDB-Skript zur Erstellung des Überwachungsbenutzers bereit. Die Befehle waren eindeutig und die Rollen (clusterMonitor und readAnyDatabase) korrekt zugewiesen. Wir mussten außerdem einen Verbindungstest durchführen, um die korrekte Funktion des Benutzers zu überprüfen.
Dieser Ansatz war besser als die Anforderung von Root-Zugriff, setzte aber voraus, dass wir herausfinden würden, wo wir diese Befehle ausführen sollten.
Im nächsten Bildschirm wurden wir aufgefordert, das Integrationspaket zu installieren. New Relic verlangt nun die manuelle Installation mit yum. Obwohl der Agent bereits unter Ubuntu installiert ist, verwendet die Benutzeroberfläche standardmäßig Amazon Linux und bietet yum-Installationsbefehle anstelle von apt an. Wir hatten erwartet, dass die Plattform das korrekte Betriebssystem anhand des installierten Agenten automatisch erkennt.
Wir führten den korrekten apt-Befehl für Ubuntu aus und gingen dann zum nächsten Bildschirm. New Relic stellte eine YAML-Konfigurationsdatei bereit und gab uns genau an, wo wir sie ablegen sollten: /etc/newrelic-infra/integrations.d/. Zumindest der Dateipfad war eindeutig.
Wir erstellten die Datei, fügten die Konfiguration ein und klickten auf „Weiter“. Auf dem letzten Bildschirm erschien die Schaltfläche „Verbindung testen“. Wir klickten darauf und warteten.
Der Test wurde erfolgreich abgeschlossen. Einrichtung abgeschlossen.
3. Datadog
Die Datadog-Integration dauerte über 20 Minuten. Sie funktionierte schließlich, erforderte aber einen erheblichen manuellen Aufwand.
Nach dem Einloggen gingen wir zu Integrationen und suchten nach „mongo“. Wir klickten auf MongoDB, woraufhin ein Modal erschien.
Die Übersicht zeigte, was die MongoDB-Überwachung umfasst, aber ein Klick auf „Integration installieren“ öffnete lediglich ein weiteres Fenster mit umfangreichen Anweisungen.
Hier hat uns Datadog wirklich beeindruckt. Auf dem Bildschirm wurde ein vollständiges Referenzhandbuch angezeigt, das jedes mögliche MongoDB-Szenario abdeckte: Standalone-Instanzen, Replikatsätze, Sharded Cluster, Authentifizierungsmethoden, SSL-Konfiguration und vieles mehr.
Für jemanden, der lediglich eine einzelne MongoDB-Instanz überwachen möchte, wirkte der Textwust übertrieben.
Wir haben die Liste durchgescrollt, um die grundlegenden Schritte zu finden:
- Erstellen Sie einen Überwachungsbenutzer in MongoDB
- Bearbeiten Sie die Konfigurations-YAML-Datei.
- Starten Sie den Datadog-Agenten neu.
Datadog stellte die MongoDB-Befehle zum Erstellen des Benutzers bereit, was hilfreich war. Bezüglich der YAML-Datei hieß es in der Dokumentation jedoch, man solle conf.yaml bearbeiten, ohne klar anzugeben, wo diese Datei abgelegt werden soll.
Wir wussten aus Erfahrung, dass es in /etc/datadog-agent/conf.d/mongo.d/ gehört, aber die Anweisungen haben dieses Detail tief in der Dokumentation versteckt.
Wir haben den MongoDB-Benutzer erstellt, die YAML-Konfiguration geschrieben, sie im richtigen Verzeichnis abgelegt und den Agenten neu gestartet.
Dann kehrten wir zur Datadog-Oberfläche zurück und klickten auf „Integration installieren“.
Der Button war verschwunden. Keine Bestätigungsmeldung, keine Erfolgsmeldung, keine Weiterleitung zum Dashboard. Nichts.
Wir warteten einen Moment, navigierten dann manuell zum Dashboard-Bereich und stellten fest, dass die MongoDB-Metriken allmählich angezeigt wurden.
2. Ressourcenverbrauch des Agenten
Wir überwachten den Ressourcenverbrauch jedes Agenten während des Betriebs. Der Test lief etwa 10 Minuten, wobei alle drei Agenten gleichzeitig unter Last Daten von derselben MongoDB-Instanz erfassten.
Wir belasteten das System, indem wir mithilfe eines Skripts, das Zufallsdaten generierte, 2 Millionen Datensätze in MongoDB einfügten. Dies simulierte reale Datenbankaktivitäten, während wir die Ressourcennutzung des Agenten maßen.
CPU-Auslastung
Alle drei Agenten benötigten während des Tests nur minimale CPU-Ressourcen.
- New Relic wies die niedrigste durchschnittliche CPU-Auslastung auf, verzeichnete jedoch gelegentlich Spitzenwerte von bis zu 4 %. Diese Spitzenwerte waren kurz und beeinträchtigten die Systemleistung nicht.
- Solarwinds wies die konstanteste CPU-Auslastung auf, die sich bei etwa 3 % ohne nennenswerte Schwankungen einpendelte.
- Datadog landete im Mittelfeld mit einem Durchschnittswert von knapp über 2 % und einer stabilen Leistung während des gesamten Tests.
Speichernutzung
Die Speichernutzung wies deutlichere Unterschiede zwischen den Agenten auf.
New Relic benötigte etwa 5- bis 6-mal weniger Arbeitsspeicher als SolarWinds. Auf unserem Testserver mit 16 GB RAM ergab sich Folgendes:
- New Relic: ~90 MB
- Datadog: ~330 MB
- Solarwinds: ~500 MB
Für die meisten Produktionsserver spielen diese Mengen keine Rolle. Wenn Sie jedoch Agenten auf ressourcenbeschränkten Systemen betreiben oder Hunderte von Datenbanken überwachen, summiert sich der Unterschied.
Die Speichernutzung blieb während des gesamten Tests bei allen drei Agenten stabil. Es traten keine Speicherlecks oder unerwartetes Speicherwachstum auf.
Festplatten-E/A
Die Festplattenaktivität variierte zwischen den Agenten erheblich.
SolarWinds führte deutlich mehr Festplattenzugriffe durch als die beiden anderen 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 aufgrund seiner Abfrageprofilierungsfunktionen.
Datadog schrieb am wenigsten auf die Festplatte, was darauf hindeutet, dass weniger Daten lokal zwischengespeichert werden, bevor sie in die Cloud gesendet werden.
New Relic wies das ausgeglichenste I/O-Muster mit moderaten Lese- und Schreibvorgängen auf.
Netzwerknutzung
Der Netzwerkverkehr zeigte an, wie viele Daten jeder Agent an sein Backend sendete.
Alle drei Agenten übermittelten ähnliche Datenmengen über das Netzwerk. Datadog übertrug etwas weniger, möglicherweise aufgrund einer aggressiveren Komprimierung oder unterschiedlicher Abtastraten.
Der bidirektionale Datenverkehr ist sinnvoll, da die Agenten Metriken senden und Konfigurationsaktualisierungen oder Befehle von der Plattform empfangen.
Zusammenfassung der Ressourcenauswirkungen
Keiner dieser Agenten wird Ihr System überlasten. Selbst unter hoher Datenbanklast, wenn alle drei gleichzeitig ausgeführt werden, blieb die Gesamtressourcenauslastung (CPU und Arbeitsspeicher kombiniert) deutlich unter 10 %.
New Relic punktet mit seiner Speichereffizienz. SolarWinds benötigt mehr Ressourcen, liefert aber detailliertere Analysen auf Abfrageebene. Datadog liegt im Mittelfeld.
In den meisten Anwendungsfällen werden diese Ressourcenunterschiede Ihre Entscheidung nicht beeinflussen. Wählen Sie anhand der Funktionen und der Benutzerfreundlichkeit, nicht des Ressourcenverbrauchs.
3. Dashboard- und Überwachungsfunktionen
Nach Abschluss der Einrichtung wollten wir überprüfen, was die einzelnen Plattformen tatsächlich anzeigen. Wir führten auf allen drei Plattformen die gleiche Arbeitslast aus: Wir fügten zunächst 2 Millionen Datensätze in Batches von 5.000 ein, gefolgt von weiteren 5 Millionen Datensätzen.
Das Skript nutzte Node.js mit Faker, um zufällige Benutzerdaten wie Namen, E-Mail-Adressen, Anschriften und Telefonnummern zu generieren. Dadurch erhielten wir einen realistischen Datensatz für die Überwachung.
Während die Einfügungen ausgeführt wurden, überwachten wir im Hintergrund den Ressourcenverbrauch des Agenten.
Die Arbeitslast setzte MongoDB stark unter Druck, wodurch wir sehen konnten, wie die einzelnen Plattformen die Aktivitäten erfassten und darstellten.
Solarwinds Dashboard
Wir klickten im linken Menü auf „Datenbanken“ und sahen sofort unsere MongoDB-Instanz. Ein Klick genügte, und ein vollständiges Dashboard erschien.
Im oberen Bildschirmbereich wurden der MongoDB-Status, die durchschnittliche Antwortzeit, der Durchsatz (Abfragen pro Sekunde) und die Fehleranzahl angezeigt. Das Blasendiagramm „Top 10 Service-Übersicht“ visualisierte die am häufigsten verwendeten Abfragemuster mit ihren jeweiligen Häufigkeiten und Prozentwerten.
Die Zahlen sprachen für sich. Der Durchsatz lag im Durchschnitt bei 3 Anfragen pro Sekunde. Die Aufschlüsselung ergab 1.400 Einfügevorgänge. Warum 1.400 statt 7 Millionen?
Wir haben 7 Millionen Datensätze in Gruppen von je 5.000 eingefügt. Das entspricht 1.400 Stapelverarbeitungen. SolarWinds hat jede einzelne Stapelverarbeitung lückenlos überwacht.
Auf der Registerkarte „Profiler“ wurden Abfragemuster mit durchschnittlichen Ausführungszeiten angezeigt.
Unsere Einfügeabfragen dauerten jeweils 4-5 Sekunden, was viel erscheint, bis man bedenkt, dass jede Abfrage 5.000 Zeilen schrieb.
Im Gesundheits-Tab wurde angezeigt, dass alles reibungslos lief.
Wir haben den MongoDB-Dienst gestoppt, um zu sehen, wie schnell SolarWinds dies bemerken würde. Innerhalb von 30–40 Sekunden änderte sich der Status auf „Schlecht“.
Die Registerkarte „Abfragen“ bot erweiterte Filteroptionen. Sie konnten Abfragen auflisten, die Folgendes umfassten:
- Zurückgegebene Fehler
- Wurde ohne korrekte Indizes ausgeführt
- Reagierte langsam
- Generierte Warnungen
Jedes Abfragemuster zeigte an, wann es erstmals auftrat, wann es zuletzt ausgeführt wurde, wie viele Stichproben erfasst wurden und enthielt Ausführungsstatistiken. Für die Fehlersuche ist dieser Detailgrad wichtig.
Über den Tab „Warnungen“ konnten wir MongoDB-spezifische Warnungen erstellen. Wir hatten zuvor bereits eine Speicherwarnung für den Host erstellt, konnten nun aber datenbankspezifische Benachrichtigungen einrichten.
Der Reiter „Ressourcen“ zeigte neben MongoDB-Statistiken auch Metriken auf Hostebene sowie CPU-, Speicher-, Festplatten- und Netzwerkauslastung an. Dieser Kontext hilft, zwischen Datenbankproblemen und zugrundeliegenden Infrastrukturproblemen zu unterscheiden.
Der Reiter „Berater“ enthielt noch keine Empfehlungen, lieferte aber in unserem vorherigen Test welche für MySQL. Wir gehen davon aus, dass er Optimierungsvorschläge bietet, sobald mehr MongoDB-Daten erfasst sind.
KI-Updates : Im Oktober 2025 hat SolarWinds den KI-Agenten mit der Funktion „KI-Abfrageunterstützung“ (derzeit in der technischen Vorschau) eingeführt. Die KI-Abfrageunterstützung analysiert Datenbankabfragemuster und schlägt automatisch optimierte Umschreibungen zur Leistungssteigerung vor. Die Funktion „Ursachenanalyse“ (jetzt allgemein verfügbar) generiert auf Basis von Warnmeldungen und Anomalien übersichtliche Ursachenanalysen, um die Fehlersuche zu beschleunigen. Die breitere Verfügbarkeit des KI-Agenten im gesamten SolarWinds-Portfolio ist für 2026 geplant. 1 2 .
New Relic Dashboard
Wir haben den Bereich „Dashboards“ aufgerufen, aber es wurde kein MongoDB-Dashboard automatisch angezeigt.
Wir haben im Dashboard-Katalog nach „mongo“ gesucht und zwei MongoDB-Optionen gefunden.
Wir haben das reguläre MongoDB-Dashboard ausgewählt und auf „MongoDB einrichten“ geklickt.
Wir wurden erneut zur MongoDB-Integrationskonfiguration weitergeleitet. Die Plattform wusste bereits, dass wir MongoDB installiert hatten, warum also die erneute Installation? Wir klickten auf „Fertig“ und gelangten zum Dashboard.
Das Dashboard war völlig leer. „Für die Dienstprüfung mongodb.can_connect wurde kein Wert gemeldet.“
Wir haben unsere Konfiguration mit newrelic-infra agent configtest überprüft.
Als wir den Befehl `newrelic-infra agent configtest` ausführten, um unsere Konfiguration auf Fehler zu überprüfen, stellten wir fest, dass `integration_name` auf `nri-prometheus` gesetzt war. Während der Dashboard-Einrichtung zeigte New Relic zwei MongoDB-Optionen an, darunter die Prometheus-Version. Die Benutzeroberfläche wies nicht darauf hin, dass es sich um eine andere Integration handelte, daher wäre mir nie in den Sinn gekommen, dass ich die Prometheus-Integration ausgewählt hatte. Es handelte sich nicht um einen Benutzerfehler; es gab schlichtweg keine Hinweise oder Unterscheidung in der Benutzeroberfläche.
Wir sind zurückgegangen und haben das „MongoDB (Prometheus)“-Dashboard installiert.
Diesmal erschienen Daten.
Aber hier liegt das Problem: Wie soll ein normaler Benutzer das herausfinden? Der Installationsprozess war verwirrend, und jetzt hat die Auswahl des Dashboards die Sache noch komplizierter gemacht.
Das Layout des Dashboards wirkte seltsam. Oben wurden die Gesamtzahl der Server und Datenbanken angezeigt, die sich nur einmal im Jahr ändern, dennoch nahm diese Anzeige einen prominenten Platz auf dem Bildschirm ein.
Darunter prangte prominent die Angabe „Verbindungssättigung“. Diese Kennzahl ist nur relevant, wenn etwas nicht stimmt. Warum wird sie also ganz oben angezeigt?
Im Abschnitt „Abfragevorgänge“ wurden 11.670 Einfügungen gemeldet. Diese Zahl war falsch. Wir haben 7 Millionen Datensätze in 1.400 Batch-Operationen eingefügt. Die Grafik entsprach nicht der Realität.
Der Tab „Datenbanken“ zeigte die Datenbankgröße, die Anzahl der Objekte und die Indexgrößen an. Diese Zahlen waren korrekt: 7 Millionen Objekte. New Relic ermittelt diese Daten durch eine direkte Abfrage von MongoDB („Wie viele Dokumente haben Sie?“). Die Echtzeit-Zählung der Objekte schlug jedoch fehl.
Die Registerkarte „Sammlungen“ enthielt nützliche Diagramme für Metriken auf Sammlungsebene: Größe (sowohl in Tabellen- als auch in Diagrammansicht), Gesamtgröße mit prozentualer Veränderung, Anzahl der Lesevorgänge, Leselatenz, Anzahl der Schreibvorgänge, Schreiblatenz, Anzahl der Transaktionen, Transaktionslatenz, Indexzugriffe, Anzahl der Befehlsausführungen, Befehlslatenz, Befehlshäufigkeit und Befehlsdauer.
Auffällig fehlten die Host-Metriken. Wir konnten weder die CPU-, Speicher-, Festplatten- noch die Netzwerkauslastung des Servers, auf dem MongoDB lief, einsehen. SolarWinds bot diese Informationen an, Datadog – wie auch New Relic – jedoch nicht.
Noch wichtiger ist jedoch, dass es keinerlei Abfrageanalyse gab. Weder Abfragemuster noch Profiling, die Identifizierung langsamer Abfragen oder die Erkennung fehlender Indizes wurden durchgeführt. Für die Fehlerbehebung in Datenbanken sind diese Funktionen jedoch entscheidend.
Datadog Dashboard
Wir klickten im linken Menü auf „Dashboards“. Ein „MongoDB – Übersicht“-Dashboard erschien automatisch.
Wir öffneten es, aber es war leer.
Die Fehlersuche gestaltete sich zeitaufwendig. Bei der Installation erforderte die automatische Datenbankerkennung von Datadog die Angabe der zu überwachenden Datenbanken anhand eines Suchmusters. Das Standardmuster stimmte jedoch nicht mit unserem Datenbanknamen überein. Datadog wies während der Einrichtung nicht darauf hin.
Wir haben alle Muster auf .* geändert (alles muss übereinstimmen) und den Agenten neu gestartet.
Warum war das Dashboard aber völlig leer? Selbst ohne datenbankspezifische Metriken hätten Verfügbarkeit, Verbindungsanzahl und Serverstatistiken angezeigt werden müssen. Sie wurden nicht angezeigt.
Wir haben datadog-agent check mongo zur Fehlersuche ausgeführt. Die Konfigurationsdatei enthielt einen Einrückungsfehler. Die strengen Formatierungsanforderungen von YAML führten zu diesem Fehler. Nachdem wir ihn behoben und unseren Lasttest mit 5 Millionen Einfügungen erneut ausgeführt hatten, wurden die Daten schließlich angezeigt.
Wir hatten sofort Probleme mit dem Dashboard. Im Bereich „Protokolle“ wurde „Nicht zugänglich“ angezeigt, obwohl wir die Protokollerfassung in unserer YAML-Datei konfiguriert hatten. Der Einrichtungsprozess von Datadog meldete, dass alles in Ordnung sei, aber die Protokolle funktionierten trotzdem nicht.
Das Dashboard-Layout war für unseren Anwendungsfall wenig sinnvoll. Der obere Bereich konzentrierte sich auf Sharding-Statistiken. Wir betrieben jedoch keinen Sharding-Cluster. Im mittleren Bereich wurden Replica-Set-Metriken angezeigt. Wir verwendeten keine Replica Sets. Im unteren Bereich wurde erneut auf Sharding eingegangen. Rund 60 % des Dashboards zeigten leere Bereiche für Funktionen, die wir nicht nutzten.
Die relevanten Informationen nahmen etwa 40 % des Bildschirms ein: Betriebszeit, Speichernutzung, Netzwerk-E/A, Anfragen pro Sekunde und Lese-/Schreiblatenz. Keine Anfrageanalyse, kein Profiling, keine Erkennung langsamer Anfragen, keine Indexempfehlungen.
Wir konnten über dieses Dashboard nicht einmal feststellen, wie viele Operationen ausgeführt wurden.
Testumgebung und -methodik
Wir haben alle drei Tools unter identischen Bedingungen ausgeführt, um einen fairen Vergleich zu gewährleisten. Jeder Test verwendete:
- Datenbank: MongoDB 7.0 Community Edition
- Server: AWS m6i.xlarge-Instanz
- Ausgangspunkt: Neuinstallation mit bereits installiertem Hauptüberwachungsagenten.
Alle drei Anbieter verlangen, dass Sie ihren Basisagenten installieren, bevor Sie spezifische Integrationen wie MongoDB hinzufügen können. Wir haben diesen Schritt im Voraus erledigt, daher konzentrierte sich unser Test ausschließlich auf die MongoDB-Integration.
Was wir gemessen haben:
- Einrichtungsaufwand: Anzahl der manuellen Schritte, automatische versus manuelle Konfiguration, Verständlichkeit der Anweisungen und ob die Benutzeroberfläche uns durch die nächsten Schritte geführt hat oder uns auf die Suche nach den nächsten Schritten geschickt hat.
- Ressourcenverbrauch des Agenten: CPU-, Speicher-, Festplatten-E/A- und Netzwerknutzung im Leerlauf und unter Last (Einfügen von 7 Millionen Datensätzen).
- Überwachungsfunktionen: Dashboard-Qualität, Genauigkeit der Metriken, Analyse auf Abfrageebene und Funktionen zur Fehlerbehebung.
Sicherheitsüberlegungen
Eine schwerwiegende Sicherheitslücke namens „MongoBleed“ wurde bekannt, die MongoDB Server-Versionen vor 8.0.17, 7.0.28, 6.0.27 und älter betrifft. Diese Schwachstelle, die unauthentifiziertes Lesen außerhalb des zulässigen Speicherbereichs ermöglicht, kann Angreifern Zugriff auf sensible Speicherdaten verschaffen. Organisationen, die MongoDB einsetzen, sollten umgehend auf die gepatchten Versionen 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 oder 4.4.30 aktualisieren. 3 4 Achten Sie bei der Auswahl von Überwachungstools darauf, dass diese sichere Authentifizierungsmethoden unterstützen und keine zusätzlichen Sicherheitsrisiken mit sich bringen.
Wir gingen an jedes Tool wie ein normaler Benutzer heran, ohne vorher die Dokumentation zu lesen und ohne jegliche Vorkenntnisse. Sollte uns etwas in der Benutzeroberfläche nicht ersichtlich gewesen sein, notierten wir es.
Endgültiges Urteil
Wir wollten eine einfache Frage beantworten: Welche Monitoring-Plattform ermöglicht die einfachste MongoDB-Integration für Teams ohne technische Vorkenntnisse?
Nach der Installation aller drei Lösungen, dem Ausführen identischer Workloads und der Auswertung der Dashboards war das Ergebnis eindeutig. Unsere Bewertung basiert auf der grundlegenden MongoDB-Integration von Datadog (Stand: Januar 2025). Datadog hat inzwischen Database Monitoring (DBM) für MongoDB (Dezember 2024) veröffentlicht, das deutlich erweiterte Funktionen bietet, darunter Abfrageprofilierung, Analyse langsamer Operationen, Ausführungspläne und Replikationsüberwachung. DBM behebt viele der in diesem Benchmark identifizierten Einschränkungen. 5 .
SolarWinds: Entwickelt für die Datenbanküberwachung
SolarWinds ging in diesem Vergleich als klarer Sieger hervor. Die Plattform erkannte unseren Agenten sofort, führte uns per Copy-and-Paste-Befehl durch die Einrichtung der Anmeldeinformationen und stellte die Integration automatisch bereit. Die Einrichtung dauerte nur 5 Minuten.
Das Dashboard erschien sofort mit allen relevanten Informationen. Die Abfrageprofilierung zeigte genau, welche Operationen die meisten Ressourcen verbrauchten. Die Plattform erfasste alle 1.400 Batch-Operationen lückenlos. Als wir MongoDB stoppten, erkannte SolarWinds den Fehler innerhalb von 40 Sekunden.
Über den Tab „Abfragen“ können wir nach Fehlern, fehlenden Indizes, langsamen Antwortzeiten und Warnungen filtern – Funktionen, die die Datenbankoptimierung direkt unterstützen. Die Funktion „Berater“ sollte Empfehlungen liefern (allerdings haben wir während unseres Tests nicht genügend Daten generiert, um welche auszulösen).
Solarwinds konzentrierte sich auf das, was Datenbankadministratoren tatsächlich benötigen: Abfrageanalyse, Leistungsprofilierung und umsetzbare Erkenntnisse.
New Relic: Verloren in der Konfiguration
Die Einrichtung von New Relic dauerte 15 Minuten, aber die Zeit war nicht das Hauptproblem. Die Plattform stellte die Fragen in der falschen Reihenfolge, verlangte die manuelle Bestätigung von Dingen, die der Agent automatisch überprüfen konnte, und zwang uns zur manuellen Installation von Paketen.
Die Verwirrung um das Dashboard verschlimmerte die Situation. Wir hatten die MongoDB-Überwachung installiert, aber die Auswahl des Standard-Dashboards führte zu einer leeren Seite. Erst nach eingehender Untersuchung der Konfigurationsdateien stellten wir fest, dass wir den falschen Integrationstyp ausgewählt hatten. Ein normaler Benutzer hätte das nicht bemerkt.
Als die Daten schließlich verfügbar waren, stimmten die Messwerte nicht. New Relic meldete 11.670 Einfügungen, nachdem wir 1.400 Batch-Operationen mit insgesamt 7 Millionen Datensätzen durchgeführt hatten. Die Plattform hatte die Anzahl um eine Größenordnung zu niedrig gezählt.
Noch kritischer ist jedoch, dass New Relic keine Abfrageanalyse bot. Weder Profiling noch die Erkennung langsamer Abfragen oder fehlender Indizes wurden durchgeführt. Für die Fehlerbehebung in Datenbanken sind diese Lücken von entscheidender Bedeutung.
Datadog: Manuelle Arbeit erforderlich
Datadog erforderte über 20 Minuten Einrichtungszeit und den größten manuellen Konfigurationsaufwand. Wir bearbeiteten die YAML-Dateien, legten deren Speicherort fest und starteten die Dienste über die Kommandozeile neu.
Das Dashboard erschien automatisch, zeigte aber keine Daten an. Die Konfiguration der automatischen Datenerkennung verwendete ein Muster, das nicht zu unserer Datenbank passte. Nachdem wir das Muster korrigiert und die Einrückungsfehler im YAML-Code behoben hatten, wurden die Daten schließlich angezeigt.
Das Dashboard erwies sich für eine MongoDB-Einzelinstanz als schlecht konzipiert. Sechzig Prozent des Bildschirms waren leer und enthielten Bereiche für Sharding- und Replica-Set-Funktionen, die wir nicht nutzten. Die verbleibenden 40 % boten grundlegende Metriken: Verfügbarkeit, Speichernutzung, Netzwerk-I/O, Abfragen pro Sekunde und Latenz.
Keine Abfrageanalyse. Keine Profilerstellung. Keine Optimierungsempfehlungen. Wir konnten die Anzahl der Operationen im Dashboard nicht genau ermitteln.
Keine Abfrageanalyse. Keine Profilerstellung. Keine Optimierungsempfehlungen. Wir konnten die Anzahl der Operationen im Dashboard nicht genau ermitteln.
Wichtige Aktualisierung (Dezember 2024) : Nach Abschluss dieses Benchmarks hat Datadog Database Monitoring (DBM) für MongoDB eingeführt, was diese Bewertung maßgeblich beeinflusst. DBM für MongoDB bietet nun Folgendes:
- Analyse langsamer Operationen mit detaillierten Abfragebeispielen
- Erläutern Sie die Pläne zur Abfrageoptimierung.
- Überwachung des Replikationsstatus und Visualisierung der Clustergesundheit
- Einblicke auf Betriebsebene und Identifizierung von Leistungsengpässen
- Integration mit Anwendungsleistungsüberwachung für einheitliche Fehlerbehebung
DBM stellt eine deutliche Verbesserung gegenüber der in diesem Benchmark getesteten einfachen MongoDB-Integration dar und beinhaltet viele der Abfrageanalysefunktionen, die während unserer Tests fehlten. 6 7 Organisationen, die Datadog für die MongoDB-Überwachung evaluieren, sollten sich speziell mit dem Produkt „Datenbanküberwachung“ befassen und nicht mit der hier getesteten grundlegenden Integration.
Welches DB-Monitoring-Tool funktioniert tatsächlich, wenn man kein DevOps-Experte ist?
Das Einrichtungserlebnis
SolarWinds öffnete sich mit einem Dialogfeld, in dem Sie die zu überwachenden Bereiche auswählten. Sie wählten „Datenbankleistung“, dann MongoDB, und die Plattform fand sofort den bereits installierten Agenten und zeigte Ihnen direkt im Auswahlbildschirm Betriebssystem, Cloud-Instanz-ID und Versionsnummer an. Anschließend wurden Ihnen drei Befehle zum Kopieren und Einfügen für MongoDB bereitgestellt, die Anmeldeinformationen wurden automatisch verarbeitet und die Bereitstellung bestätigt. Der gesamte Vorgang dauerte nur fünf Minuten.
New Relic brauchte fünfzehn Minuten, und die Wartezeit war nicht einmal das eigentliche Problem. Die Benutzeroberfläche stellte ständig Fragen, die der Agent selbst hätte beantworten können, wie etwa nach dem Betriebssystem und der MongoDB-Version, obwohl der Agent bereits auf dem Server installiert war. Einmal verwendete er sogar standardmäßig die Installationsbefehle für Amazon Linux, obwohl wir eindeutig Ubuntu nutzten. Der entscheidende Fehler: Im Dashboard-Katalog gibt es zwei MongoDB-Integrationsoptionen – eine Standard- und eine Prometheus-basierte –, die in der Benutzeroberfläche nicht unterschieden werden. Wir wählten die falsche, erhielten ein leeres Dashboard und konnten den Fehler erst durch das Durchsuchen der Konfigurationsdateien beheben.
Datadog erforderte über zwanzig Minuten YAML-Bearbeitung, das Erraten von Dateipfaden und das Neustarten von Diensten über die Kommandozeile. Die während der Einrichtung angebotene Dokumentation ist keine Anleitung, sondern ein umfassendes Nachschlagewerk, das Standalone-Instanzen, Replikatsets, Sharded Cluster und SSL-Konfigurationen abdeckt – alles auf einmal, für jemanden, der lediglich eine einzige Datenbank überwachen möchte. Als endlich Daten angezeigt wurden, präsentierte das Dashboard Sharding-Statistiken und Replikatset-Metriken. Diese waren bei uns nicht vorhanden. Etwa sechzig Prozent des Bildschirms waren leer.
Metrische Genauigkeit unter Last
SolarWinds zählte 1.400. Genau richtig. New Relic meldete 11.670, eine um eine Größenordnung falsche Zahl ohne erkennbare Erklärung, und übersah dabei einen Speicherspitzenwert während des Tests vollständig. Als wir den MongoDB-Dienst stoppten, erkannte SolarWinds den Fehler innerhalb von 30 bis 40 Sekunden.
Zum Ressourcenverbrauch: New Relic benötigte auf unserem 16-GB-Server etwa 90 MB RAM, Datadog etwa 330 MB und SolarWinds etwa 500 MB. SolarWinds führte ungefähr vierzigmal mehr Festplattenzugriffe durch als New Relic, vermutlich aufgrund der lokalen Abfrageprofilierung. In den meisten Umgebungen ist dies jedoch nicht entscheidungsrelevant.
Das Merkmal, das sie tatsächlich unterscheidet
Jedes Überwachungstool zeigt Ihnen an, dass etwas langsam ist. Die Frage ist, ob es Ihnen auch den Grund dafür nennt.
SolarWinds bietet Profiling auf Abfrageebene. Der Profiler-Tab zeigte genau an, welche Abfragemuster ausgeführt wurden, wie lange jede Ausführung dauerte und wie viele Samples erfasst wurden. Sie können nach Abfragen filtern, die ohne Index ausgeführt wurden, Fehler zurückgaben oder Warnungen generierten.
New Relic und Datadog zeigten lediglich aggregierte Metriken für Latenz, Verbindungsanzahl und Gesamtzahl der Operationen an. Keine Profilerstellung, keine Identifizierung langsamer Abfragen, keine Erkennung fehlender Indizes. Zur Bestätigung, dass eine Datenbank erreichbar ist, brauchbar. Zur Diagnose von Problemen jedoch unbrauchbar.
Hinweis: Datadog hat im Dezember 2024, nach unseren Tests, ein Produkt zur Datenbanküberwachung für MongoDB veröffentlicht, das Analysen langsamer Operationen, Ausführungspläne und Einblick in Abfragen bietet . Wir haben die Standardintegration getestet, die nach wie vor die erste Lösung für die meisten Benutzer ist.
SolarWinds : Wenn Datenbankoptimierung Ihr Hauptanliegen ist. Präzise Metriken, schnelle Einrichtung und die einzige Plattform, die Ihnen nicht nur anzeigt, dass eine Abfrage langsam ist, sondern auch Lösungsvorschläge liefert.
New Relic : Wenn Sie es bereits für APM verwenden und grundlegende Datenbankzustandsinformationen benötigen, ist die Nachverfolgung einer langsamen Anfrage vom Browser über den Code bis zum Datenbankaufruf durchaus nützlich. Verlassen Sie sich jedoch nicht auf diese Funktion, um genaue Operationszählungen durchzuführen.
Datadog : Wenn Sie mit manueller Konfiguration vertraut sind und eine einheitliche Plattform für eine komplexe Systemarchitektur wünschen, rechtfertigen die über 600 Integrationen den etwas aufwendigeren Einrichtungsaufwand für das richtige Team.
Referenzlinks
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich.