MongoDB-Monitoring: SolarWinds vs New Relic vs Datadog
Wir installierten SolarWinds, Datadog und New Relic auf sauberen Systemen mit MongoDB 7.0, um zu testen. Wir durchliefen den gesamten Einrichtungsprozess jedes Tools und dokumentierten jeden Schritt und jede Hürde.
Benchmark-Ergebnisse der Tools zur MongoDB-Leistungsüberwachung
Plattform | Einrichtungszeit | Abfrage-Profiling | Metrikgenauigkeit | RAM-Nutzung | Am besten geeignet für |
|---|---|---|---|---|---|
5 Min. | ✓ | 100 % genau | Mittel (500MB) | Produktionsoptimierung | |
New Relic | 15 Min. | ✕ | Niedrig (23 bis 800 % Fehlerraten) | Niedrig (90MB) | Einfache Zustandsprüfungen |
Datadog | 20+ Min. | ✕ | Unklar | Mittel (330MB) | Multi-Tech-Überwachung |
Zusammenfassung der MongoDB-Überwachungsleistung
- SolarWinds schloss die Einrichtung in 5 Minuten mit automatischer Erkennung ab und bot Profiling auf Abfrageebene, das den anderen fehlte.
- New Relic benötigte 15 Minuten mit manuellen Verifizierungsschritten und meldete ungenaue Metriken.
- Datadog erforderte 20+ Minuten YAML-Bearbeitung und bot nur grundlegende Einblicke.
Sie können auch sehen, wie diese Plattformen MySQL überwachen und unsere Testumgebung und Methodik
1. Installations- & Onboarding-Erfahrung
1. SolarWinds
SolarWinds schloss die MongoDB-Integration in unter 5 Minuten ab. SolarWinds öffnet mit einem einfachen Modal: „Was möchten Sie überwachen?“ Wenn Sie Datenbankleistung auswählen, zeigt die Plattform die unterstützten Datenbanken direkt an.
Nach der Auswahl von MongoDB prüft SolarWinds, ob vorhandene Agenten existieren.
Die Plattform erkannte unseren zuvor installierten Agenten sofort.
Eine Funktion stach hervor: Die Benutzeroberfläche zeigt Agentendetails (Betriebssystem, Cloud-Instanz-ID, Version) direkt auf dem Auswahlbildschirm an. Kein Suchen in Dropdowns.
Nun fragt SolarWinds nach den MongoDB-Zugangsdaten. Wir gaben die Verbindungsdetails ein: localhost, Authentifizierungsmethode (passwortbasiert), Benutzername und Passwort. Der Anzeigename wurde mit unseren Serverinformationen automatisch ausgefüllt, verwendete jedoch den vollständigen internen Hostnamen anstelle des zuvor angegebenen Agentennamens.
Eine Kuriosität: Das Dropdown „Query Capture“ erschien ohne Erklärung. Wir wählten „Log“ und gingen weiter, ohne zu wissen, was die anderen Optionen bewirkten.
Der nächste Bildschirm zeigte drei auszuführende Datenbankbefehle. Jeder Befehl hatte eine Kopieren-Schaltfläche. Wir führten sie in MongoDB aus und klickten auf „Datenbank beobachten“.
Hier beeindruckte uns SolarWinds. Statt uns die Berechtigungen selbst herausfinden zu lassen, stellte es Kopier-und-Einfüge-Befehle bereit:
- Erstellen Sie einen Überwachungsbenutzer mit bestimmten Zugangsdaten
- Erteilen Sie die erforderlichen Berechtigungen (Rollen clusterMonitor und readAnyDatabase)
- Legen Sie die Profiling-Stufe fest
Ein Zusammenfassungsbildschirm zeigte unsere Konfiguration. Der Plugin-Status lautete: „Plugin wird bereitgestellt.“
Sekunden später änderte sich der Status zu „Plugin-Bereitstellung erfolgreich“ mit einem Link zum Dashboard. Einrichtung abgeschlossen.
Entdecken Sie die Observability von SolarWinds mit tiefgehendem MongoDB-Monitoring und Abfrage-Profiling. Erkunden Sie SolarWinds.
Website besuchen2. New Relic
New Relic benötigte ungefähr 15 Minuten für die Einrichtung, aber die Zeit war nicht das eigentliche Problem. Die Reibung entstand durch die Beantwortung von Fragen, die Plattform bereits hätte kennen sollen.
New Relic beginnt auf der Seite Integrationen & Agenten.
Wir suchten nach „mongo“ und fanden mehrere MongoDB-bezogene Integrationen.
Nach der Auswahl von MongoDB bat uns New Relic, eine Instrumentierungsmethode zu wählen.
Wir wählten „Auf einem 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 machten weiter.
Der nächste Bildschirm fragte nach den MongoDB-Hostdetails. Der Begriff „SCRAM“ erschien ohne Erklärung. Die meisten kennen dies als Benutzername-/Passwort-Authentifizierung, aber der technische Begriff sorgt für Verwirrung.
Nach dem Klicken auf „Weiter“ fragte uns 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 Kompatibilität der MongoDB-Version zu überprüfen. New Relic wollte, dass wir mongod --version ausführen und bestätigen, dass die Ausgabe den Anforderungen entspricht. Wir mussten den Befehl kopieren, zum Terminal wechseln, ihn ausführen, die Versionsnummer prüfen und zurückkommen, um auf „Weiter“ zu klicken.
Der Agent ist bereits auf dem Server installiert. Er könnte dies automatisch prüfen.
Nach dem Klicken auf „Weiter“ gelangten wir zum Schritt der Benutzererstellung. New Relic stellte ein MongoDB-Skript zum Erstellen des Überwachungsbenutzers bereit. Die Befehle waren klar, mit ordnungsgemäßen Rollenzuweisungen (clusterMonitor und readAnyDatabase). Wir mussten außerdem einen Verbindungstestbefehl ausführen, um zu überprüfen, dass der Benutzer korrekt funktionierte.
Dieser Ansatz war besser, als nach Root-Zugriff zu fragen, aber er setzte voraus, dass wir herausfinden würden, wo diese Befehle auszuführen sind.
Der nächste Bildschirm forderte uns auf, das Integrationspaket zu installieren. Jetzt will New Relic, dass wir manuell mit yum installieren. Obwohl der Agent bereits auf Ubuntu installiert ist, verwendet die Oberfläche standardmäßig Amazon Linux und stellt yum-Installationsbefehle anstelle von apt bereit. Wir erwarteten, dass die Plattform das richtige Betriebssystem automatisch anhand des installierten Agenten 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 sagte uns genau, wohin sie zu legen ist: /etc/newrelic-infra/integrations.d/. Wenigstens war der Dateipfad klar.
Wir erstellten die Datei, fügten die Konfiguration ein und klickten auf „Weiter“. Der letzte Bildschirm zeigte eine Schaltfläche „Verbindung testen“. Wir klickten darauf und warteten.
Der Test bestand. Einrichtung abgeschlossen.
3. Datadog
Datadog benötigte über 20 Minuten bis zum Abschluss. Die Integration funktionierte schließlich, aber bis dahin war erheblicher manueller Aufwand erforderlich.
Nach der Anmeldung gingen wir zu Integrationen und suchten nach „mongo“. Wir klickten auf MongoDB, und ein Modal erschien.
Die Übersicht zeigte, was das MongoDB-Monitoring umfasst, aber das Klicken auf „Integration installieren“ öffnete nur einen weiteren Bildschirm mit dichten Anweisungen.
Hier überforderte uns Datadog. Der Bildschirm zeigte ein vollständiges Referenzhandbuch, das jedes mögliche MongoDB-Szenario abdeckte: Standalone-Instanzen, Replica-Sets, geshardete Cluster, Authentifizierungsmethoden, SSL-Konfiguration und mehr.
Für jemanden, der nur eine einzelne MongoDB-Instanz überwachen möchte, wirkte die Textwand übermäßig.
Wir scrollten auf der Suche nach den grundlegenden Schritten:
- Erstellen Sie einen Überwachungsbenutzer in MongoDB
- Bearbeiten Sie die YAML-Konfigurationsdatei
- Starten Sie den Datadog-Agenten neu
Datadog stellte die MongoDB-Befehle zum Erstellen des Benutzers bereit, was hilfreich war. Aber was die YAML-Datei betraf, sagte die Dokumentation, man solle conf.yaml bearbeiten, ohne klar anzugeben, wohin diese Datei gehö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, legten sie im richtigen Verzeichnis ab und starteten den Agenten neu.
Dann kehrten wir zur Datadog-Oberfläche zurück und klickten auf „Integration installieren“.
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 stellten fest, dass MongoDB-Metriken sich zu füllen begannen.
2. Ressourcenverbrauch der Agenten
Wir haben überwacht, wie viele Ressourcen jeder Agent während des Betriebs verbrauchte. Der Test lief ungefähr 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 einfügten, mithilfe eines Skripts, das Zufallsdaten erzeugte. Dies simulierte reale Datenbankaktivität, während wir den Ressourcenverbrauch der Agenten maßen.
CPU-Verbrauch
Alle drei Agenten verbrauchten während des Tests minimale CPU-Ressourcen.
- New Relic zeigte den niedrigsten durchschnittlichen CPU-Verbrauch, hatte aber gelegentliche Spitzen, die 4 % erreichten. Diese Spitzen waren kurz und beeinträchtigten die Systemleistung nicht.
- SolarWinds hielt die konstanteste CPU-Nutzung bei und blieb bei etwa 3 % ohne signifikante Schwankungen.
- Datadog lag in der Mitte, im Durchschnitt knapp über 2 % mit stabiler Leistung während des gesamten Tests.
Speicherauslastung
Die Speicherauslastung zeigte deutlichere Unterschiede zwischen den Agenten.
New Relic verbrauchte ungefähr 5- bis 6x weniger Speicher als SolarWinds. Auf unserem 16GB-Testserver entsprach dies:
- New Relic: ~90MB
- Datadog: ~330MB
- Solarwinds: ~500MB
Für die meisten Produktionsserver sind diese Mengen unerheblich. Aber wenn Sie Agenten auf ressourcenbeschränkten Systemen betreiben oder Hunderte von Datenbanken überwachen, summiert sich der Unterschied.
Die Speichernutzung blieb bei allen drei Agenten während des gesamten Tests stabil. Es traten keine Speicherlecks oder unerwartetes Wachstum auf.
Disk-I/O
Die Festplattenaktivität variierte erheblich zwischen den Agenten.
SolarWinds führte deutlich mehr Festplatten-Lesevorgänge durch als die anderen beiden Agenten, etwa 40x so viele wie New Relic und 1.5x so viele wie Datadog. Dies deutet darauf hin, dass SolarWinds häufiger auf lokal gespeicherte Daten zugreift, möglicherweise wegen seiner Abfrage-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.
Netzwerknutzung
Der Netzwerkverkehr zeigte, wie viele Daten jeder Agent an sein Backend sendete.
Alle drei Agenten sendeten ähnliche Datenmengen über das Netzwerk. Datadog übertrug etwas weniger, möglicherweise aufgrund stärkerer Komprimierung oder anderer Sampling-Raten.
Der bidirektionale Verkehr ergibt Sinn, da Agenten Metriken senden und Konfigurationsaktualisierungen oder Befehle von der Plattform empfangen.
Zusammenfassung der Ressourcenauswirkungen
Keiner dieser Agenten wird Ihr System übermäßig belasten. Selbst unter Datenbanklast bei gleichzeitig laufenden drei Agenten blieb der Gesamtressourcenverbrauch für CPU und Speicher zusammen deutlich unter 10 %.
New Relic gewinnt bei der Speichereffizienz. SolarWinds verbraucht mehr Ressourcen, liefert aber detailliertere Analysen auf Abfrageebene. Datadog liegt in der Mitte.
Für die meisten Anwendungsfälle werden diese Ressourcenunterschiede Ihre Entscheidung nicht beeinflussen. Wählen Sie auf Basis von Funktionen und Benutzerfreundlichkeit, nicht anhand des Ressourcenverbrauchs.
3. Dashboard- & Überwachungsfunktionen
Nach Abschluss der Einrichtung mussten wir sehen, was jede Plattform tatsächlich anzeigt. Wir führten dieselbe Arbeitslast auf allen dreien aus: das Einfügen von 2 Millionen Datensätzen in Stapeln zu 5.000, gefolgt von weiteren 5 Millionen Datensätzen.
Das Skript verwendete Node.js mit Faker, um zufällige Benutzerdaten wie Namen, E-Mail-Adressen, Anschriften und Telefonnummern zu erzeugen. Dies lieferte uns einen realistischen dataset zur Überwachung.
Während die Einfügevorgänge liefen, überwachten wir den Ressourcenverbrauch der Agenten im Hintergrund.
Die Arbeitslast setzte MongoDB echter Belastung aus, wodurch wir sehen konnten, wie jede Plattform die Aktivität erfasste und anzeigte.
Solarwinds-Dashboard
Wir klickten im linken Menü auf „Datenbanken“ und sahen sofort unsere MongoDB-Instanz. Ein Klick, und ein vollständiges Dashboard erschien.
Der obere Bildschirmbereich zeigte den MongoDB-Zustand, die durchschnittliche Antwortzeit, den Durchsatz (Abfragen pro Sekunde) und die Fehleranzahl. Das Blasendiagramm „Top 10 Service-Aufschlüsselung“ zeigte die am häufigsten verwendeten Abfragemuster mit ihren Anzahlen und Prozentsätzen.
Die Zahlen erzählten eine Geschichte. Der Durchsatz zeigte durchschnittlich 3 Abfragen pro Sekunde. Die Aufschlüsselung zeigte 1.400 Einfügevorgänge. Warum 1.400 statt 7 Millionen?
Wir fügten 7 Millionen Datensätze in Stapeln zu 5.000 ein. Das sind 1.400 Stapeloperationen. SolarWinds erfasste jeden einzelnen Stapel, ohne einen zu verpassen.
Der Profiler-Tab zeigte Abfragemuster mit durchschnittlichen Ausführungszeiten.
Unsere Einfügeabfragen dauerten jeweils 4–5 Sekunden, was hoch erscheint, bis man bedenkt, dass jede Abfrage 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 Zustandsstatus auf „Schlecht“.
Der Abfragen-Tab bot erweiterte Filterung. Sie konnten Abfragen auflisten, die:
- Fehler zurückgaben
- Ohne richtige Indizes ausgeführt wurden
- Langsam antworteten
- Warnungen erzeugten
Jedes Abfragemuster zeigte, wann es erstmals auftrat, wann es zuletzt ausgeführt wurde, wie viele Stichproben erfasst wurden, sowie Ausführungsstatistiken. Für die Fehlerbehebung ist dieses Detailniveau wichtig.
Der Alerts-Tab ermöglichte es 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 Ressourcen-Tab zeigte Host-Metriken neben MongoDB-Statistiken, CPU, Speicher, Festplatte und Netzwerk. Dieser Kontext hilft, zwischen Datenbankproblemen und zugrunde liegenden Infrastrukturproblemen zu unterscheiden.
Der Advisors-Tab hatte noch keine Empfehlungen, bot diese jedoch für MySQL in unserem vorherigen Test an. Wir erwarten, dass er Optimierungsvorschläge liefert, sobald er mehr MongoDB-Daten sammelt.
KI-Updates: Im Oktober 2025 startete SolarWinds den KI Agent mit der Funktion KI Query Assist (derzeit in der Tech-Vorschau). KI Query Assist analysiert Datenbank-Abfragemuster und schlägt optimierte Neufassungen vor, um die Leistung automatisch zu verbessern. Root Cause Assist (jetzt allgemein verfügbar) erstellt klare Ursachenanalysen auf der Grundlage von Alerts und Anomalien, um die Fehlerbehebungszeit zu verkürzen. Eine breitere Verfügbarkeit des KI Agent im gesamten SolarWinds-Portfolio ist für 2026 geplant12.
New Relic Dashboard
Wir gingen zum Bereich Dashboards, aber es erschien kein automatisches MongoDB-Dashboard.
Wir suchten im Dashboard-Katalog nach „mongo“ und fanden zwei MongoDB-Optionen.
Wir wählten das reguläre MongoDB-Dashboard und klickten auf „MongoDB einrichten“.
Es leitete uns erneut zur MongoDB-Integrationseinrichtung weiter. Die Plattform wusste bereits, dass wir MongoDB installiert hatten – warum also zur Installation zurückschicken? Wir klickten auf „Fertig“ und gingen zum Dashboard weiter.
Das Dashboard öffnete sich vollständig leer. „Kein Wert gemeldet für den Service-Check mongodb.can_connect.“
Wir überprüften unsere Konfiguration mit newrelic-infra agent configtest.
Als wir den Befehl newrelic-infra agent configtest ausführten, um Probleme mit unserer Konfiguration zu prüfen, stellten wir fest, dass integration_name auf nri-prometheus gesetzt war. Während der Dashboard-Einrichtung zeigte New Relic zwei MongoDB-Optionen, von denen eine die Prometheus-Version war. Nichts in der Benutzeroberfläche wies darauf hin, dass dies eine andere Integration war, daher wäre mir nie in den Sinn gekommen, dass ich die Prometheus-Version ausgewählt hatte. Dies war kein Benutzerfehler; es gab einfach keine Anleitung oder Unterscheidung in der Oberfläche.
Wir gingen zurück und installierten das Dashboard „MongoDB (Prometheus)“.
Diesmal erschienen Daten.
Aber hier liegt das Problem: Wie sollte ein normaler Benutzer dies herausfinden? Der Installationsprozess war verwirrend, und die Dashboard-Auswahl fügte eine weitere Komplexitätsebene hinzu.
Das Layout des Dashboards wirkte seltsam. Oben wurden Gesamtzahlen zu Servern und Datenbanken angezeigt, die sich einmal im Jahr ändern, aber es nahm wertvolle Bildschirmfläche ein.
Darunter erschien „Verbindungssättigung“ prominent. Diese Metrik ist nur relevant, wenn etwas nicht stimmt. Warum sie oben platzieren?
Der Abschnitt „Abfrageoperationen“ meldete 11.670 Einfügungen. Die Zahl war falsch. Wir fügten 7 Millionen Datensätze in 1.400 Stapeloperationen ein. Das Diagramm entsprach nicht der Realität.
Der Datenbanken-Tab zeigte Datenbankgröße, Objektanzahl und Indexgrößen. Diese Zahlen waren korrekt: 7 Millionen Objekte. New Relic erhält diese Daten durch direkte Abfragen an MongoDB („Wie viele Dokumente haben Sie?“). Aber die Echtzeit-Abfragezählung schlug fehl.
Der Collections-Tab enthielt nützliche Diagramme für Metriken auf Collection-Ebene: Größe (sowohl Tabellen- als auch Diagrammansicht), Gesamtgröße mit prozentualer Änderung, Anzahl der Lesevorgänge, Leselatenz, Anzahl der Schreibvorgänge, Schreib-Latenz, Transaktionsanzahl, Transaktionslatenz, Indexzugriffsoperationen, Befehlsausführungsanzahl, Befehlslatenz, Befehlshäufigkeit und Befehlsdauer.
Auffallend abwesend: Host-Metriken. Wir konnten CPU, Speicher, Festplatte oder Netzwerknutzung des Servers, auf dem MongoDB läuft, nicht sehen. SolarWinds bot diesen Kontext, Datadog – wie New Relic – jedoch nicht.
Noch wichtiger: Es gab nirgendwo eine Analyse auf Abfrageebene. Keine Abfragemuster, kein Profiling, keine Identifizierung langsamer Abfragen, keine Erkennung fehlender Indizes. Für die Datenbank-Fehlerbehebung sind diese Funktionen wichtig.
Datadog-Dashboard
Wir klickten im linken Menü auf „Dashboards“. Ein Dashboard „MongoDB – Überblick“ erschien automatisch.
Wir öffneten es, aber es war leer.
Das Problem zu diagnostizieren dauerte. Während der Installation verlangte die Autodiscovery-Konfiguration von Datadog, per Musterabgleich festzulegen, welche Datenbanken überwacht werden sollen. Das Standardmuster passte nicht auf unseren Datenbanknamen. Datadog erwähnte dies während der Einrichtung nie.
Wir änderten alle Muster auf .* (alles abgleichen) und starteten den Agenten neu.
Aber warum war das Dashboard vollständig leer? Selbst ohne datenbankspezifische Metriken hätten Uptime, Verbindungsanzahl und Serverstatistiken erscheinen müssen. Das taten sie nicht.
Wir führten datadog-agent check mongo zum Debuggen aus. Die Konfigurationsdatei hatte einen Einrückungsfehler. Die strenge Formatierungsanforderung von YAML erwischte uns. Nachdem wir sie behoben und unseren Lasttest mit 5 Millionen Einfügungen erneut ausgeführt hatten, erschienen endlich Daten.
Wir stießen sofort auf Probleme mit dem Dashboard. Der Abschnitt Logs zeigte „Nicht zugänglich“ an, obwohl wir die Protokollsammlung in unserer YAML-Datei konfiguriert hatten. Der Einrichtungsprozess von Datadog meldete, dass alles in Ordnung sei, aber die Logs funktionierten immer noch nicht.
Das Dashboard-Layout ergab für unseren Anwendungsfall wenig Sinn. Der obere Bereich konzentrierte sich auf Sharding-Statistiken. Wir betrieben keinen Sharded Cluster. Die Mitte zeigte Replica-Set-Metriken. Wir hatten keine Replica Sets. Der untere Bereich kehrte wieder zum Sharding zurück. Etwa 60 % des Dashboards zeigten leere Abschnitte für Funktionen, die wir nicht nutzten.
Die nützlichen Informationen nahmen vielleicht 40 % des Bildschirms ein: Uptime, Speichernutzung, Netzwerk-I/O, Abfragen pro Sekunde und Lese-/Schreiblatenz. Keine Abfrageanalyse, kein Profiling, keine Erkennung langsamer Abfragen, keine Index-Empfehlungen.
Wir konnten anhand dieses Dashboards nicht einmal bestimmen, wie viele Operationen ausgeführt wurden.
Testumgebung und Methodik des MongoDB-Monitoring-Benchmarks
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 bereits installiertem Haupt-Monitoring-Agenten
Alle drei Anbieter verlangen, dass Sie ihren Basis-Agenten installieren, bevor Sie spezifische Integrationen wie MongoDB hinzufügen. Wir haben diesen Schritt im Voraus abgeschlossen, sodass sich unser Test ausschließlich auf die MongoDB-Integrationserfahrung konzentrierte.
Was wir gemessen haben:
- Einrichtungskomplexität: Anzahl manueller Schritte, automatische versus manuelle Konfiguration, Verständlichkeit der Anweisungen und ob die Oberfläche uns führte oder uns nach den nächsten Schritten suchen ließ.
- Ressourcenverbrauch der Agenten: CPU, Speicher, Disk-I/O und Netzwerknutzung im Leerlauf und unter Last (Einfügen von 7 Millionen Datensätzen).
- Überwachungsfunktionen: Dashboard-Qualität, Metrikgenauigkeit, Analyse auf Abfrageebene und Fehlerbehebungsfunktionen.
Sicherheitsaspekte
Eine schwerwiegende Schwachstelle namens „MongoBleed“ wurde offengelegt. Sie betrifft MongoDB-Serverversionen vor 8.0.17, 7.0.28, 6.0.27 und früher. Diese nicht authentifizierte Out-of-Bounds-Read-Schwachstelle könnte es Angreifern ermöglichen, auf sensible Speicherdaten zuzugreifen. Organisationen, die MongoDB betreiben, sollten umgehend auf gepatchte Versionen aktualisieren: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 oder 4.4.3034. Achten Sie bei der Auswahl von Überwachungstools darauf, dass sie sichere Authentifizierungsmethoden unterstützen und keine zusätzlichen Sicherheitsrisiken mit sich bringen.
Wir näherten uns jedem Tool wie ein normaler Benutzer, ohne vorher die Dokumentation zu lesen und ohne vorherige Schulung. Wenn etwas in der Oberfläche nicht offensichtlich war, notierten wir es.
Als bevorzugte Quelle hinzufügenEndgültiges Urteil des MongoDB-Monitoring-Benchmarks
Wir wollten eine einfache Frage beantworten: Welche Überwachungsplattform 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 mit Stand Januar 2025. Datadog hat inzwischen Database Monitoring (DBM) für MongoDB veröffentlicht (Dezember 2024), das erheblich tiefere Funktionen bietet, darunter Abfrage-Profiling, Analyse langsamer Operationen, Explain Plans und Replikationsüberwachung. Das DBM-Produkt behebt viele der in diesem Benchmark identifizierten Einschränkungen5.
SolarWinds: Für die Datenbanküberwachung entwickelt
SolarWinds gewann diesen Vergleich eindeutig. Die Plattform erkannte unseren Agenten sofort, führte uns per Kopier-und-Einfüge-Befehlen durch die Einrichtung der Zugangsdaten und implementierte die Integration automatisch. Die Einrichtung dauerte 5 Minuten.
Das Dashboard erschien sofort mit relevanten Informationen. Das Abfrage-Profiling zeigte genau, welche Operationen die meisten Ressourcen verbrauchten. Die Plattform erfasste alle 1.400 Stapeloperationen, ohne eine zu verpassen. Als wir MongoDB stoppten, erkannte SolarWinds den Ausfall innerhalb von 40 Sekunden.
Der Abfragen-Tab ermöglichte es uns, nach Fehlern, fehlenden Indizes, langsamen Antworten und Warnungen zu filtern – Funktionen, die Datenbankoptimierung direkt unterstützen. Von der Advisors-Funktion wurden Empfehlungen erwartet (wir erzeugten während unseres Tests jedoch nicht genügend Daten, um welche auszulösen).
SolarWinds konzentrierte sich auf das, was Datenbankadministratoren tatsächlich benötigen: Abfrageanalyse, Leistungs-Profiling und umsetzbare Erkenntnisse.
New Relic: In der Konfiguration verloren
New Relic benötigte 15 Minuten für die Einrichtung, aber die Zeit war nicht das Hauptproblem. Die Plattform stellte Fragen in der falschen Reihenfolge, verlangte manuelle Überprüfungen von Dingen, die der Agent automatisch prüfen könnte, und zwang uns, Pakete manuell zu installieren.
Die Dashboard-Verwirrung machte es noch schlimmer. Wir installierten die MongoDB-Überwachung, aber die Auswahl des Standard-Dashboards führte zu einem leeren Bildschirm. Erst nachdem wir uns in Konfigurationsdateien vertieft hatten, stellten wir fest, dass wir den falschen Integrationstyp ausgewählt hatten. Ein normaler Benutzer würde dies nicht herausfinden.
Als die Daten endlich erschienen, waren die Metriken falsch. New Relic meldete 11.670 Einfügungen, nachdem wir 1.400 Stapeloperationen durchgeführt hatten, insgesamt 7 Millionen Datensätze. Die Plattform unterzählte um eine Größenordnung.
Noch kritischer: New Relic bot keine Analyse auf Abfrageebene. Kein Profiling, keine Erkennung langsamer Abfragen, 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, wohin sie gelegt werden sollten, und starteten die Dienste über die Befehlszeile neu.
Das Dashboard erschien automatisch, zeigte aber nichts an. Die Autodiscovery-Konfiguration verwendete ein Muster, das nicht zu unserer Datenbank passte. Nachdem wir das Muster korrigiert und YAML-Einrückungsfehler behoben hatten, wurden die Daten endlich befüllt.
Das Dashboard selbst erwies sich für eine einzelne MongoDB-Instanz als schlecht gestaltet. Sechzig Prozent des Bildschirms waren leer, mit Abschnitten für Sharding- und Replica-Set-Funktionen, die wir nicht nutzten. Die restlichen 40 % boten grundlegende Metriken: Uptime, Speicher, Netzwerk-I/O, Abfragen pro Sekunde und Latenz.
Keine Abfrageanalyse. Kein Profiling. Keine Optimierungsempfehlungen. Wir konnten die Operationsanzahl auf dem Dashboard nicht genau bestimmen.
Keine Abfrageanalyse. Kein Profiling. Keine Optimierungsempfehlungen. Wir konnten die Operationsanzahl auf dem Dashboard nicht genau bestimmen.
Kritisches Update (Dezember 2024): Nach Abschluss dieses Benchmarks hat Datadog Database Monitoring (DBM) für MongoDB eingeführt, was diese Bewertung erheblich verändert. DBM für MongoDB bietet jetzt:
- Analyse langsamer Operationen mit detaillierten Abfragebeispielen
- Explain Plans für die Abfrageoptimierung
- Überwachung des Replikationsstatus und Visualisierung der Cluster-Zustände
- Einblicke auf Operationsebene und Identifizierung von Leistungsengpässen
- Integration mit Application Performance Monitoring für eine einheitliche Fehlerbehebung
DBM stellt ein erhebliches Upgrade gegenüber der in diesem Benchmark getesteten grundlegenden MongoDB-Integration dar und umfasst viele der Funktionen zur Analyse auf Abfrageebene, die während unserer Tests fehlten56. Organisationen, die Datadog für das MongoDB-Monitoring evaluieren, sollten ausdrücklich das Produkt Database Monitoring bewerten und nicht die hier getestete Basisintegration.
Welches DB-Überwachungstool funktioniert tatsächlich, wenn Sie kein DevOps-Experte sind?
Die Einrichtungserfahrung
SolarWinds öffnete mit einem Modal, das fragt, was Sie überwachen möchten. Sie wählen „Datenbankleistung“, wählen MongoDB, und die Plattform findet sofort den bereits installierten Agenten und zeigt Ihnen Betriebssystem, Cloud-Instanz-ID und Versionsnummer direkt auf dem Auswahlbildschirm. Dann gibt sie Ihnen drei Kopier-und-Einfüge-Befehle, die Sie in MongoDB ausführen, kümmert sich um die Zugangsdaten und bestätigt die Bereitstellung. Fünf Minuten vom Anfang bis zum Ende.
New Relic benötigte fünfzehn Minuten, und die Zeit war nicht einmal das eigentliche Problem. Die Oberfläche stellte weiterhin Fragen, die der Agent selbst hätte beantworten können, etwa nach dem Betriebssystem und der MongoDB-Version, obwohl der Agent bereits auf dem Server war. An einer Stelle wurden standardmäßig Amazon-Linux-Installationsbefehle angezeigt, obwohl wir eindeutig Ubuntu verwendeten. Der Schritt, der die Erfahrung endgültig verdarb: Es gibt zwei MongoDB-Integrationsoptionen im Dashboard-Katalog, eine Standard- und eine Prometheus-basierte, und nichts in der Benutzeroberfläche unterscheidet sie. Wir wählten die falsche, erhielten ein leeres Dashboard und fanden es erst heraus, indem wir in Konfigurationsdateien gruben.
Datadog erforderte über zwanzig Minuten YAML-Bearbeitung, das Raten von Dateipfaden und das Neustarten von Diensten über die Befehlszeile. Die während der Einrichtung angebotene Dokumentation ist kein Leitfaden, sondern ein vollständiges Referenzhandbuch, das Standalone-Instanzen, Replica Sets, Sharded Cluster und SSL-Konfiguration auf einmal abdeckt – für jemanden, der nur eine Datenbank überwachen möchte. Als die Daten endlich erschienen, begann das Dashboard mit Sharding-Statistiken und Replica-Set-Metriken. Wir hatten keines davon. Etwa sechzig Prozent des Bildschirms waren leer.
Metrikgenauigkeit unter Last
SolarWinds zählte 1.400. Genau richtig. New Relic meldete 11.670, um eine Größenordnung daneben, ohne offensichtliche Erklärung, und verpasste während des Tests eine Speicherspitze vollständig. Als wir den MongoDB-Dienst stoppten, erkannte SolarWinds den Ausfall innerhalb von dreißig bis vierzig Sekunden.
Beim Ressourcenverbrauch: New Relic verwendete etwa 90MB RAM, Datadog etwa 330MB und SolarWinds etwa 500MB auf unserem 16GB-Server. SolarWinds führte ungefähr vierzigmal mehr Festplatten-Lesevorgänge durch als New Relic, wahrscheinlich aufgrund lokaler Abfrage-Profiling-Arbeit. Für die meisten Umgebungen wird nichts davon Ihre Entscheidung bestimmen.
Das Merkmal, das sie tatsächlich unterscheidet
Jedes Überwachungstool wird Ihnen sagen, dass etwas langsam ist. Die Frage ist, ob es Ihnen sagt, warum.
SolarWinds bietet Profiling auf Abfrageebene. Der Profiler-Tab zeigte genau, welche Abfragemuster ausgeführt wurden, wie lange jedes dauerte und wie viele Stichproben erfasst wurden. Sie können nach Abfragen filtern, die ohne Index liefen, Fehler zurückgaben oder Warnungen erzeugten.
New Relic und Datadog zeigten nur aggregierte Metriken für Latenz, Verbindungsanzahl und Operationssummen. Kein Profiling, keine Identifizierung langsamer Abfragen, keine Erkennung fehlender Indizes. Um zu bestätigen, dass eine Datenbank lebt, brauchbar. Um zu diagnostizieren, warum sie Probleme hat, eine Sackgasse.
Hinweis: Datadog hat im Dezember 2024 nach unseren Tests ein Database-Monitoring-Produkt für MongoDB veröffentlicht, das die Analyse langsamer Operationen, Explain Plans und Sichtbarkeit auf Abfrageebene ergänzt. Wir haben die Standardintegration getestet, die weiterhin das ist, was die meisten Benutzer zuerst sehen.
SolarWinds: Wenn Datenbankoptimierung Ihr eigentliches Anliegen ist. Genaue Metriken, schnelle Einrichtung und die einzige Plattform hier, die Ihnen nicht nur sagt, dass eine Abfrage langsam ist, sondern auch, was Sie dagegen tun können.
New Relic: Wenn Sie es bereits für APM verwenden und grundlegende Datenbank-Zustände am selben Ort benötigen. Die Nachverfolgung einer langsamen Anfrage vom Browser über den Code bis zum Datenbankaufruf ist wirklich nützlich. Verlassen Sie sich nicht auf präzise Operationszahlen.
Datadog: Wenn Sie mit manueller Konfiguration vertraut sind und eine Plattform für einen komplexen Stack wünschen. Die mehr als 600 Integrationen rechtfertigen die Einrichtungsreibung für das richtige Team.
Zitieren Sie diesen Benchmark
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 Ermut, Sıla},
title = {{MongoDB-Monitoring: SolarWinds vs New Relic vs Datadog}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/mongodb-monitoring}},
note = {AIMultiple. Abgerufen am 16. September 2026}
}Ergebnisse und Zeitstempel von 38 Datenpunkten. Laden Sie die Zusammenfassungsdaten aus den Diagrammen und Tabellen dieses Artikels als ZIP-Datei herunter, die 7 CSV-Dateien enthält.
Möchten Sie die granularen Daten dahinter? Premium beitreten
Änderungsprotokoll
5 AktualisierungenDer Abschnitt „Der Kernunterschied“ wurde durch „Welches DB-Überwachungstool funktioniert wirklich, wenn Sie kein DevOps-Experte sind?“ ersetzt.
KI-Updates zum SolarWinds-Abschnitt hinzugefügt.
Sicherheitsaspekte zur Methodik hinzugefügt.
Referenzlinks
- Verfügt über 20 Jahre Erfahrung als White-Hat-Hacker und Entwicklungsguru mit umfassender Expertise in Programmiersprachen und Serverarchitekturen.
- Ist Beiratsmitglied bei einer VC, die in frühphasige Technologieunternehmen investiert, und bei Ödeal, einer regionalen digitalen Zahlungsplattform, die 125.000 Händler bedient.
- Hat die technologische Infrastruktur und Cybersicherheit von sieben nationalen Wahlen geleitet und wurde von globalen Technologieführern wie Twitter in die Hall of Fame für Cybersicherheit aufgenommen.
Zuvor arbeitete sie als Personalvermittlerin in Projektmanagement- und Beratungsunternehmen. Sıla hat einen Master of Science in Sozialpsychologie und einen Bachelor of Arts in Internationalen Beziehungen.
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.