Überwachung und Sicherung von MongoDB mit ClusterControl Advisors

Die Verwaltung von Datenbankoperationen besteht zu 80 % aus dem Lesen und Interpretieren Ihrer Überwachungssysteme. Hunderte von Metriken können auf verschiedene Weise interpretiert und kombiniert werden, um Ihnen tiefe Einblicke in Ihre Datenbanksysteme und deren Optimierung zu geben. Wenn Sie mehrere Datenbanksysteme betreiben, kann die Überwachung dieser Systeme ziemlich lästig werden. Wenn die Interpretation und Kombination von Metriken viel Zeit in Anspruch nimmt, wäre es nicht großartig, wenn dies auf irgendeine Weise automatisiert werden könnte?

Aus diesem Grund haben wir Datenbankberater in ClusterControl erstellt:kleine Skripte, die Metriken für Sie interpretieren und kombinieren können und Ihnen gegebenenfalls Ratschläge geben. Für MySQL haben wir eine umfangreiche Bibliothek der am häufigsten verwendeten MySQL-Überwachungsprüfungen erstellt. Aber auch für MongoDB steht Ihnen eine breite Bibliothek an Ratgebern zur Verfügung. Für diesen Blogbeitrag haben wir die neun wichtigsten für Sie herausgesucht. Wir werden jeden einzelnen von ihnen im Detail beschreiben.

Die neun MongoDB-Berater, die wir in diesem Blogbeitrag behandeln werden, sind:

• Festplatten-Mount-Optionen prüfen
• Numa-Prüfung
• Sammelsperrprozentsatz (MMAP)
• Replikationsverzögerung
• Replikationsfenster
• Nicht fragmentierte Datenbanken und Sammlungen (nur Shard-Cluster)
• Authentifizierungsprüfung aktiviert
• Authentifizierungs-/Autorisierungsprüfung
• Fehlererkennung (neuer Berater)

Disk Mount Options Advisor

Es ist sehr wichtig, dass Ihre Festplatten optimal montiert sind. Mit dem ClusterControl Disk Mount Options Advisor schauen wir uns Ihre Datenfestplatte täglich genauer an. In diesem Ratgeber untersuchen wir das verwendete Dateisystem, Mount-Optionen und die io-Scheduler-Einstellungen des Betriebssystems.

Wir prüfen, ob Ihre Festplatten mit noatime und nodiratime gemountet wurden. Diese Einstellungen verringern die Leistung der Festplatten, da bei jedem Zugriff auf eine Datei oder ein Verzeichnis die Zugriffszeit auf die Festplatte geschrieben werden muss. Da dies kontinuierlich auf Datenbanken passiert, ist dies eine gute Leistungseinstellung und erhöht auch die Lebensdauer Ihrer SSDs.

Für Dateisysteme empfehlen wir die Verwendung moderner Dateisysteme wie xfs, zfs, ext4 oder btrfs. Diese Dateisysteme werden im Hinblick auf die Leistung erstellt. Der io-Scheduler sollte entweder auf noop sein oder Frist. Frist ist seit Jahren der Standard für Datenbanken, aber dank schnellerer Speicher wie SSDs der Noop Scheduler macht heutzutage mehr Sinn.

Numa Check Advisor

Für MongoDB aktivieren wir unsere NUMA Berater prüfen. Dieser Berater prüft, ob NUMA (Non-Uniform Access Memory) auf Ihrem System aktiviert wurde, und wenn dies der Fall ist, schalten Sie es aus.

Wenn Non-Uniform Access Memory aktiviert wurde, kann die CPU des Servers nur ihren eigenen Speicher direkt ansprechen und nicht die anderen CPUs in der Maschine. Auf diese Weise kann die CPU nur Speicher aus ihrem eigenen Speicherplatz zuweisen, und die Zuweisung von überschüssigem Speicher führt zu einer Swap-Nutzung. Diese Architektur hat einen starken Leistungsvorteil bei Anwendungen mit mehreren Prozessoren, die alle CPUs zuweisen, aber da MongoDB keine Anwendung mit mehreren Prozessoren ist, verringert sie die Leistung erheblich und könnte zu einer enormen Swap-Nutzung führen.

Sammelsperrprozentsatz (MMAP)

Als MMAP ein dateibasiertes Speichersystem ist, unterstützt es nicht das Sperren auf Dokumentebene, wie es in WiredTiger zu finden ist und RocksDB. Stattdessen die niedrigste Sperrebene für MMAP ist die Sammelschleuse. Das bedeutet, dass alle Schreibvorgänge in eine Sammlung (Einfügen, Aktualisieren oder Löschen) die gesamte Sammlung sperren. Wenn der Prozentsatz der Sperren zu hoch wird, deutet dies darauf hin, dass Sie Konfliktprobleme in der Sammlung haben. Wenn dies nicht richtig adressiert wird, kann dies Ihren Schreibdurchsatz zum Erliegen bringen. Daher ist es sehr hilfreich, einen Berater zu haben, der Sie im Voraus warnt.

MongoDB Replication Lag Advisor

Wenn Sie MongoDB für Lesevorgänge über Secondaries skalieren, ist es sehr wichtig, die Replikationsverzögerung im Auge zu behalten. Die MongoDB-Client-Treiber verwenden nur Secondaries, die nicht zu weit hinterherhinken, da Sie sonst riskieren, veraltete Daten bereitzustellen.

Innerhalb von MongoDB verfolgt die Primärdatenbank den Replikationsstatus ihrer Sekundärdatenbanken. Der Advisor ruft die Replikationsinformationen ab und überwacht die Replikationsverzögerung. Wenn die Verzögerung zu hoch wird, wird eine Warnung oder eine kritische Statusmeldung gesendet.

MongoDB Replication Window Advisor

Neben der Replikationsverzögerung ist das Replikationsfenster eine wichtige Metrik, die es zu beobachten gilt. Das MongoDB-Oplog ist eine einzelne Sammlung, die auf eine (voreingestellte) Größe begrenzt wurde. Sobald das Oplog das Ende erreicht und eine neue Transaktion gespeichert werden muss, wird die älteste Transaktion entfernt, um Platz für die neue Transaktion zu schaffen. Das Replikationsfenster gibt die Anzahl der Sekunden zwischen der ältesten und neuesten Transaktion im Oplog wieder.

Diese Metrik ist sehr wichtig, da Sie wissen müssen, wie lange Sie einen Secondary aus dem replicaSet herausnehmen können, bevor er den Master nicht mehr einholen kann, weil er bei der Replikation zu weit zurückliegt. Auch wenn eine Sekundärseite ins Hintertreffen gerät, wäre es gut zu wissen, wie lange wir dies tolerieren können, bevor die Sekundärseite nicht mehr aufholen kann.

In der MongoDB-Shell steht eine Funktion zur Berechnung des Replikationsfensters zur Verfügung. Dieser Advisor in ClusterControl verwendet die Funktion, um die gleiche Berechnung durchzuführen. Der Vorteil wäre, dass Sie jetzt bei einem zu kurzen Replikationsfenster gewarnt werden können.

MongoDB Un-Sharded Databases and Collections Advisor

In einem geshardeten MongoDB-Cluster werden alle nicht geshardeten Datenbanken und Sammlungen vom MongoDB-Shard-Router einem primären Standard-Shard zugewiesen. Dieser primäre Shard kann zwischen den Datenbanken und Sammlungen variieren, aber im Allgemeinen wäre dies der Shard mit dem meisten verfügbaren Speicherplatz.

Eine nicht fragmentierte Datenbank oder Sammlung stellt nicht sofort ein Risiko für Ihren Cluster dar. Wenn jedoch eine Anwendung oder ein Benutzer beginnt, große Datenmengen auf einen dieser zu schreiben, könnte der primäre Shard schnell voll werden und einen Ausfall auf diesem Shard verursachen. Da die Datenbank oder Sammlung nicht fragmentiert ist, kann sie keine anderen Shards verwenden.

Aus diesem Grund haben wir einen Ratgeber erstellt, der dies verhindert. Der Advisor scannt alle Datenbanken und Sammlungen und warnt Sie, wenn sie nicht geteilt wurden.

Authentifizierungsaktivierungsprüfung

Ohne Aktivierung der Authentifizierung in MongoDB wird jeder Benutzer, der sich anmeldet, als Administrator behandelt. Dies ist ein ernstes Risiko, da normalerweise Administratoraufgaben wie das Erstellen von Benutzern oder das Erstellen von Backups jetzt für jedermann verfügbar sind. Dies führte in Kombination mit exponierten MongoDB-Servern zu den jüngsten MongoDB-Lösegeld-Hacks, während eine einfache Aktivierung der Authentifizierung die meisten dieser Fälle verhindert hätte.

Wir haben einen Advisor implementiert, der überprüft, ob auf Ihren MongoDB-Servern die Authentifizierung aktiviert ist. Dies kann explizit erfolgen, indem Sie dies in der Konfiguration festlegen, oder implizit, indem Sie die Schlüsseldatei für die Replikation aktivieren. Wenn dieser Ratgeber nicht erkennt, dass die Authentifizierung aktiviert wurde, sollten Sie sofort handeln, da Ihr Server gefährdet ist, kompromittiert zu werden.

Authentifizierung/Autorisierung Plausibilitätsprüfung

Neben dem Advisor mit aktivierter Authentifizierung haben wir auch einen Advisor erstellt, der eine Plausibilitätsprüfung sowohl für die Authentifizierung als auch für die Autorisierung in MongoDB durchführt.

In MongoDB wird die Authentifizierung und Autorisierung nicht an einer zentralen Stelle platziert, sondern auf Datenbankebene durchgeführt und gespeichert. Normalerweise stellen Benutzer eine Verbindung zur Datenbank her und authentifizieren sich bei der Datenbank, die sie verwenden möchten. Mit den richtigen Genehmigungen ist es jedoch auch möglich, sich gegen andere (unabhängige) Datenbanken zu authentifizieren und dennoch eine andere Datenbank zu verwenden. Normalerweise ist dies völlig in Ordnung, es sei denn, ein Benutzer hat übermäßige Rechte (wie die Admin-Rolle) über eine andere Datenbank.

In diesem Ratgeber überprüfen wir, ob diese übermäßigen Rollen vorhanden sind und ob sie eine Bedrohung darstellen könnten. Gleichzeitig prüfen wir auch auf schwache und leicht zu erratende Passwörter.

Fehlererkennung (neuer Berater)

In MongoDB wird jeder aufgetretene Fehler gezählt oder protokolliert. Innerhalb von MongoDB gibt es eine große Vielfalt möglicher Fehler:Benutzer-Asserts, reguläre Asserts, Warnungen und sogar interne Serverausnahmen. Wenn es Trends bei diesen Fehlern gibt, liegt wahrscheinlich entweder eine Fehlkonfiguration oder ein Anwendungsproblem vor.

Dieser Ratgeber wird sich die Statistiken von MongoDB-Fehlern (Asserts) ansehen und daraus einen Sinn machen. Wir interpretieren die gefundenen Trends und geben Ratschläge, wie Sie Fehler in Ihrer MongoDB-Umgebung verringern können!