MongoDB Monitoring: Operationen, Cache und Replica Sets
Überwachen Sie Latenz, WiredTiger Cache, Verbindungen, Replication Lag und Oplog Window jedes MongoDB-Deployments und sehen Sie, welcher Service die langsamen Queries sendet.
Warum MongoDB mit Obseria überwachen
Latenz pro Operationstyp
Reads, Writes und Commands werden getrennt gemessen. Sie sehen, ob eine Verlangsamung von Queries, Inserts oder Updates kommt.
Sichere Replica Sets
Replication Lag und Oplog Window pro Mitglied warnen, bevor ein Secondary zu weit zurückfällt, um aufzuholen.
Queries mit Codebezug
Datenbank-Spans aus der OpenTelemetry-Instrumentierung zeigen Collection, Operation und Endpunkt hinter jedem langsamen Request.
MongoDB-Komponenten, die Obseria überwacht
- mongod-Instanzen. Operationen, Latenz, Verbindungen, Cursor, Speicher und Netzwerk-I/O pro Instanz.
- WiredTiger Storage Engine. Cache Hits und Misses, Cache-Reads und belegte Concurrent Transaction Tickets.
- Replica Sets. Anzahl und Status der Mitglieder, Replication Lag, Oplog-Größe, Oplog Window und Replication Headroom.
- Datenbanken und Collections. Collections, Objekte, Daten- und Speichergröße, Anzahl und Größe der Indizes pro Datenbank.
- Indizes und Query-Ausführung. Index-Zugriffe, Collection Scans und gescannte Dokumente im Vergleich zu Ergebnissen.
- MongoDB Atlas. Atlas-Cluster über den OpenTelemetry-mongodbatlas-Receiver, der Metriken aus der Atlas API liest.
Die MongoDB-Kennzahlen, auf die es ankommt
Obseria erfasst diese Werte automatisch und zeigt sie in fertigen Dashboards und Alerts.Arbeitslast und Tempo
Zeigt, wie viele Anfragen die Datenbank bearbeitet und wie schnell sie antwortet, die Grundlage für schnelle Anwendungen.
Sichere Replikation
Zeigt, ob Sicherungskopien aktuell sind und wie viel Zeit Ihnen nach einem Ausfall für die Wiederherstellung bleibt.
Effiziente Abfragen
Macht ineffiziente Suchen, wartende Anfragen und abgebrochene Abrufe sichtbar, die Ihre Anwendungen unbemerkt ausbremsen.
Arbeitsspeicher und Cache
Zeigt, wie viel Speicher die Datenbank nutzt und wie gut sie häufig benötigte Daten griffbereit hält.
Alle 10 Metriken im Detail anzeigen
| Metrik | Einheit | Aussage |
|---|---|---|
mongodb.operation.count | {operations} | Operationen nach Typ (insert, query, update, delete, getmore, command). |
mongodb.operation.latency.time | us | Latenz pro Operationstyp für Reads, Writes und Commands. |
mongodb.connection.count | {connections} | Aktive, verfügbare und aktuelle Verbindungen; nahe null verfügbar blockiert Clients. |
mongodb.cache.operations | {operations} | WiredTiger Cache Hits und Misses; steigende Misses zeigen ein zu großes Working Set. |
mongodb.replica_set.lag | s | Wie weit ein Secondary hinter dem Primary liegt. |
mongodb.oplog.window | s | Vom Oplog abgedeckte Zeitspanne; der Lag muss deutlich darunter bleiben. |
mongodb.global_lock.time | ms | Zeit, in der der globale Lock gehalten wurde. |
mongodb.query_executor.collection_scan.count | {query} | Queries, die ganze Collections gescannt haben, ein Zeichen für fehlende Indizes. |
mongodb.cursor.timeout.count | {cursors} | Abgelaufene Cursor, oft von Clients, die sie nie schließen. |
mongodb.memory.usage | By | Resident und Virtual Memory des mongod-Prozesses. |
MongoDB-Monitoring in wenigen Minuten einrichten
- Schritt 1
Monitoring-User anlegen
Legen Sie einen MongoDB-User mit der eingebauten Rolle clusterMonitor an und hinterlegen Sie das Passwort als Umgebungsvariable.
- Schritt 2
mongodb-Receiver konfigurieren
Ergänzen Sie den mongodb-Receiver im OpenTelemetry Collector oder Obseria Agent und aktivieren Sie Metriken für Replication Lag, Oplog Window und Latenz.
- Schritt 3
Clients instrumentieren
Instrumentieren Sie die Services mit MongoDB-Treibern per OpenTelemetry, damit Datenbank-Spans Queries mit Requests verbinden.
receivers:
mongodb:
hosts:
- endpoint: mongo-0.mongo:27017
username: otel_monitor
password: ${env:MONGODB_PASSWORD}
collection_interval: 30s
tls:
insecure: false
ca_file: /etc/otel/mongo-ca.pem
metrics:
mongodb.replica_set.lag:
enabled: true
mongodb.oplog.window:
enabled: true
mongodb.operation.latency.time:
enabled: true
exporters:
otlphttp:
endpoint: ${env:OBSERIA_OTLP_ENDPOINT}
headers:
Authorization: "Bearer ${env:OBSERIA_TOKEN}"
service:
pipelines:
metrics:
receivers: [mongodb]
exporters: [otlphttp]
Sofort einsatzbereit
Dashboards, Alerts und SLOs, die bereitstehen, sobald die ersten Daten ankommen.
- MongoDB-Übersicht: Operationen, Latenz, Verbindungen
- Effizienz des WiredTiger Cache
- Replica-Set-Zustand, Replication Lag und Oplog Window
- Alert: Replication Lag über der Hälfte des Oplog Window
- Alert: Collection Scans oder Latenz über der Baseline
MongoDB-Monitoring: Darauf kommt es an
Warum MongoDB Monitoring wichtig ist
MongoDB ist beliebt, weil sich das Datenmodell ohne Migrationen anpassen lässt. Diese Flexibilität verlagert Verantwortung in die Anwendung: welche Felder indiziert sind, wie Dokumente wachsen, wie Queries aufgebaut sind. Performance-Probleme in MongoDB entstehen deshalb oft durch Codeänderungen und nicht durch die Datenbank selbst. MongoDB Monitoring muss Datenbankmetriken mit den Services und Queries verbinden, die die Last erzeugen.
Obseria erfasst Metriken mit dem mongodb-Receiver des OpenTelemetry Collectors, der serverStatus, dbStats und den Replica-Set-Status liest. Für MongoDB Atlas liest der mongodbatlas-Receiver Metriken aus der Atlas API. Datenbank-Spans Ihrer Services liefern den Query-Kontext.
Die MongoDB-Metriken, auf die es ankommt
Durchsatz und Latenz
mongodb.operation.count zeigt Operationen nach Typ, mongodb.operation.latency.time die Latenz für Reads, Writes und Commands. Steigt die Latenz nur bei Writes, deutet das auf Journaling, Write Concern der Replikation oder die Platte; steigt sie nur bei Reads, auf Indizes oder den Cache.
WiredTiger Cache
WiredTiger hält das Working Set im Cache. mongodb.cache.operations meldet Hits und Misses. Steigt der Anteil der Misses, gehen Lesezugriffe auf die Platte, und die Latenz folgt. Typische Ursachen sind wachsende Collections, neue Query-Muster auf kalten Daten oder ein zu kleiner Cache für die Instanz.
Verbindungen und Cursor
mongodb.connection.count unterscheidet aktuelle und verfügbare Verbindungen. Nähern sich die verfügbaren Verbindungen null, warten oder scheitern neue Clients. mongodb.cursor.timeout.count wächst, wenn Clients Cursor öffnen und nie vollständig lesen oder schließen.
Replikation
In einem Replica Set zeigt mongodb.replica_set.lag, wie weit jeder Secondary zurückliegt. mongodb.oplog.window ist die Historie, die das Oplog vorhält. Übersteigt der Lag jemals das Window, kann der Secondary nicht mehr aufholen und braucht einen vollständigen Resync.
Typische Probleme und wie Sie sie erkennen
- Fehlende Indizes:
mongodb.query_executor.collection_scan.countsteigt, und gescannte Dokumente übersteigen die zurückgegebenen bei Weitem. Der Datenbank-Span im Trace zeigt Collection und Endpunkt. - Cache-Druck: Cache Misses wachsen zusammen mit Plattenzugriffen auf dem Host. Prüfen Sie Working Set und Indexgrößen.
- Verbindungsstürme: Nach einem Deployment öffnen viele Anwendungs-Pods jeweils große Pools. Beobachten Sie aktuelle gegenüber verfügbaren Verbindungen.
- Replication Lag: Schreibspitzen oder ein überlasteter Secondary. Alarmieren Sie, wenn der Lag einen Anteil des Oplog Window übersteigt, zum Beispiel die Hälfte.
- Lock-Konflikte: Lange globale oder Collection-Lock-Zeiten bei Index-Builds oder großen Updates.
Best Practices für MongoDB Monitoring
- Nutzen Sie einen eigenen User mit der Rolle
clusterMonitorstatt eines Administratorkontos. - Überwachen Sie jedes Mitglied des Replica Sets, nicht nur den Primary, und versehen Sie Metriken mit dem Mitgliedsstatus.
- Beobachten Sie das Oplog Window zu Spitzenzeiten, denn dann ist es am kürzesten.
- Aktivieren Sie den Database Profiler nur kurz für Analysen mit einem Slow-Schwellwert; für dauerhafte Sichtbarkeit sorgen Datenbank-Spans.
- Halten Sie Query-Strukturen sichtbar, Werte aber maskiert; die Obseria Pipeline entfernt sensible Felder aus Datenbank-Spans beim Ingest.
So unterstützt Obseria Ihr MongoDB Monitoring
Obseria speichert MongoDB-Metriken, Logs und Datenbank-Spans an einem Ort in Obseria Lake. TopoGraph zeigt, welche Services welchen MongoDB-Cluster und welche Collection nutzen, sodass ein Latenz-Alert sofort die betroffenen Anwendungen nennt. Obseria Intelligence korreliert Verlangsamungen mit Deployments, neuen Query-Mustern, Cache Misses und Host-Metriken und zeigt die wahrscheinliche Ursache mit einer Beweiskette. Dashboards für Operationen, Cache und Replica-Set-Zustand, Alerts und SLOs sind enthalten.
Ein guter Rollout beginnt mit dem Receiver auf jedem Replica Set, gefolgt von OpenTelemetry-Instrumentierung in den Services mit dem meisten Datenbank-Traffic. Mit OQL filtern Sie anschließend Datenbank-Spans nach Collection und Operation und vergleichen ihre p95-Latenz mit den Cache Misses im selben Zeitraum, ohne die Plattform zu verlassen.
Für sharded Cluster empfiehlt es sich, Metriken jedes Shards und der mongos-Router getrennt zu betrachten. Ungleich verteilte Operationen zwischen Shards deuten auf einen ungünstigen Shard Key hin, der sich mit Datenbank-Spans pro Collection gut belegen lässt. Ein Alert auf das Oplog Window pro Shard verhindert, dass ein einzelner Secondary unbemerkt den Anschluss verliert.
Verwandte Integrationen
Passende Funktionen
Datenbank-Monitoring
Finden Sie die langsame Query hinter dem langsamen Endpunkt. Obseria verknüpft Datenbankmetriken, Query-Performance und Logs mit den Traces und Services, die sie aufrufen.
Mehr erfahrenDistributed Tracing
Verfolgen Sie jeden Request über Services, Queues und Datenbanken hinweg und finden Sie den langsamen Span oder die fehlerhafte Abhängigkeit in Sekunden.
Mehr erfahrenAnomalie-Erkennung
Obseria Intelligence lernt den normalen Rhythmus jedes Service, meldet echte Abweichungen statt Schwellenwert-Rauschen und fasst zusammenhängende Anomalien zu einem Problem mit wahrscheinlicher Ursache zusammen.
Mehr erfahrenMehr erfahren
Die vier Golden Signals: Latenz, Traffic, Fehler und Sättigung
Die vier Golden Signals erklärt: Latenz, Traffic, Fehler und Sättigung, der Bezug zu RED- und USE-Methode und die Messung mit OpenTelemetry.
Was ist eine Root-Cause-Analyse (RCA)?
Was ist eine Root-Cause-Analyse? Der RCA-Prozess für Software-Incidents, 5 Whys, Fishbone und Fehlerbaum, ein Praxisbeispiel und RCA mit KI.
Häufige Fragen zum MongoDB-Monitoring
Ja. Der OpenTelemetry-mongodbatlas-Receiver liest Cluster-Metriken mit einem API Key aus der Atlas API; selbst betriebene Deployments nutzen den mongodb-Receiver.
Die eingebaute Rolle clusterMonitor genügt, um Serverstatus, Replica-Set-Status und Datenbankstatistiken zu lesen.
Aktivieren Sie mongodb.replica_set.lag und mongodb.oplog.window im Receiver und alarmieren Sie, wenn der Lag einen relevanten Anteil des Oplog Window erreicht.
Nutzen Sie Datenbank-Spans aus der OpenTelemetry-Instrumentierung Ihres MongoDB-Treibers, um langsame Operationen pro Collection und Endpunkt zu sehen, und beobachten Sie Collection Scans als Hinweis auf fehlende Indizes.
Der Receiver führt leichtgewichtige Status-Kommandos im eingestellten Intervall aus, typischerweise alle 10 bis 60 Sekunden. Für die meisten Deployments ist das vernachlässigbar.
Starten Sie heute mit dem MongoDB-Monitoring
Binden Sie MongoDB in Minuten per OpenTelemetry oder Obseria Agent an. 14 Tage kostenlos.