MongoDB diagnostics tool speichert einen Verlauf über drei Monate
Ein MongoDB diagnostics tool namens mongo-health soll eine bekannte betriebliche Frage beantworten: Warum war die Datenbank vor einigen Tagen langsam, obwohl kein Alarm ausgelöst wurde und zu diesem Zeitpunkt niemand die Ursache untersuchte? Laut Percona bewahrt das Open-Source-Tool den detaillierten MongoDB-Diagnoseverlauf drei Monate lang auf, wertet ihn stündlich mit 68 Prüfungen aus und zeigt für jeden Cluster eine Gesamtbewertung an.
Die zugrunde liegenden Belege stammen aus Full Time Diagnostic Data Capture beziehungsweise FTDC, MongoDBs integrierter Sammlung betrieblicher Messwerte. Jeder mongod-Prozess, also das Programm, das einen MongoDB-Datenbankserver ausführt, zeichnet seine eigenen Metriken einmal pro Sekunde in einem diagnostic.data-Verzeichnis auf. Dadurch lassen sich ineffiziente Queries, verzögerte Storage-Vorgänge und Netzwerkprobleme erkennen, die möglicherweise nicht im Datenbank-Log erscheinen. Percona stellte bei einem Atlas M10 unter Produktionslast fest, dass nur zwei bis fünf Tage FTDC aufbewahrt wurden. Belege vom Donnerstag könnten daher bereits nicht mehr verfügbar sein, wenn ein Team am Montag mit der Untersuchung beginnt.
Ohne automatisierte Analyse muss ein Administrator die noch vorhandenen Dateien in einem Viewer öffnen und die Diagramme rund um den gemeldeten Zeitpunkt durcharbeiten. Eine offensichtliche Ursache kann bereits in den ersten zehn Diagrammen auftauchen, eine weniger sichtbare Ursache könnte jedoch die Prüfung von weiteren 40 erfordern. Die erfassten Daten können zeigen, dass eine Query für jedes Ergebnis zehn Millionen Dokumente liest, Storage-Vorgänge drei Minuten lang 400 Millisekunden pro Schreibvorgang benötigen oder ein Mitglied des replica set 30 Sekunden lang Pakete verliert. Ein replica set ist eine Gruppe von MongoDB-Servern, die für eine höhere Verfügbarkeit Kopien derselben Daten vorhalten. Das Problem besteht nicht unbedingt darin, dass Belege fehlen, sondern darin, das relevante Signal zu finden, bevor die Dateien verfallen.
mongo-health bewahrt drei Monate lang jede Sekunde der FTDC-Daten auf und berichtet, was passiert ist, welches Mitglied betroffen war, wie lange der Vorfall dauerte und welches Diagramm damit verbunden ist. Laut Percona steht die Software unter der Apache-2.0-Lizenz, läuft in drei Docker-Containern auf einem Laptop oder Server und installiert nichts auf den Datenbank-Hosts. Die GitHub-Anleitung beschreibt eine Installation mit vier Befehlen. In Perconas Test mit einem Atlas M10 enthielt die Oberfläche FTDC-Daten für 29,92 Tage. Wenn ein Cluster keine Daten mehr liefert, ändert sich sein Status zu „Not being watched“, statt weiterhin eine veraltete positive Bewertung anzuzeigen.
Einzelne Befunde enthalten ein Diagramm, einen kurzen Hinweis dazu, wo die Untersuchung beginnen sollte, und die Position des Vorfalls im Verlauf des Clusters. Ein Operator kann einen Befund als behoben markieren und eine Notiz hinzufügen. Anschließend verschwindet er aus dem aktiven Bericht, ein erneutes Auftreten wird jedoch als Wiederholung erkannt. Die 68 Prüfungen decken work queues, verfügbare Verarbeitungsslots, die als tickets bezeichnet werden, Cache und Arbeitsspeicher, Storage, Replikation, Verbindungen, Queries, Konfiguration und frühere Vorfälle ab. Die README-Datei des Projekts gruppiert die Prüfungen, während docs/rules.md ihre Schwellenwerte dokumentiert.
Percona demonstrierte fünf absichtlich erzeugte Fehler in einem aus drei Mitgliedern bestehenden Percona Server for MongoDB 8.0 replica set und dokumentierte einen sechsten, der unabhängig davon auf einem Atlas M10 auftrat. Im ersten Test begann um 20:53 Uhr eine Query ohne nutzbaren index. Zehn Minuten lang untersuchte der Server für jedes zurückgegebene Dokument ungefähr zehn Millionen Dokumente und wiederholte dieses Verhalten anschließend um 21:54 Uhr. Die Regel wird bei einem Verhältnis von mehr als 100 zu 1 aktiviert. Der Vorgang schlug nicht fehl und hinterließ nichts Nützliches im Log, doch der Befund identifizierte einen wahrscheinlich fehlenden index und die Startminute. Dadurch war ein Vergleich mit einem Anwendungs-Deployment möglich.
Ein Storage-Test begann um 22:13 Uhr und dauerte drei Minuten. Schreibvorgänge auf allen drei Mitgliedern benötigten 400 Millisekunden und lagen damit weit über dem Schwellenwert der Regel von 10 Millisekunden. mongo-health stufte den Vorfall als das dritte Ereignis dieser Art in diesem Cluster ein und verknüpfte die beiden vorherigen. Anhand dieses Verlaufs lässt sich eine einmalige Verlangsamung von einem wiederkehrenden Storage-Muster unterscheiden.
Das Atlas-Beispiel deutete stattdessen auf das Netzwerk hin. Am 5. Oktober um 08:25 Uhr übertrug ein Mitglied etwa 30 Sekunden lang bis zu 30 TCP segments pro Sekunde erneut. TCP segments sind Datenbestandteile, die über ein Netzwerk gesendet werden; eine erneute Übertragung bedeutet normalerweise, dass sie nicht erfolgreich angekommen sind. Die Prüfung beginnt bei fünf erneuten Übertragungen pro Sekunde. Da der Datenbankserver selbst schnell reagierte, deuteten die Belege auf Paketverlust während der Übertragung und nicht auf eine langsame Query hin. Dadurch erhielt der Operator ein Diagramm, das er einem Supportfall beifügen konnte.
Eine weitere Labor-Workload schrieb Daten wiederholt in großen Mengen neu. Die als checkpoint bezeichneten periodischen Vorgänge, durch die gespeicherte Änderungen dauerhaft gesichert werden, wurden normalerweise in weniger als einer Sekunde abgeschlossen, benötigten auf allen drei Mitgliedern jedoch plötzlich zwischen sechs und elf Sekunden. Dies geschah innerhalb von zehn Minuten zweimal. Die Regel verlangt checkpoint-Zeiten von mehr als einer Sekunde über einen Zeitraum von zwei Minuten und verhindert damit, dass eine einzelne Verzögerung als Befund erscheint. Percona weist darauf hin, dass diese kurzen Unterbrechungen in einem Throughput-Diagramm möglicherweise nicht erkennbar sind.
Ein separater Test machte ein Risiko sichtbar, bevor sich Benutzer beschwerten. Das replica set verarbeitete ungefähr 250 Schreibvorgänge pro Sekunde, doch jeder Schreibvorgang ersetzte ein vollständiges Dokument mit 20 KB und fügte dem journal, MongoDBs für die Wiederherstellung verwendeter Aufzeichnung von Änderungen, etwa 20 KiB hinzu. Die Regel greift ab 3,91 KiB pro Vorgang. Bei dieser Rate wäre das oplog, der geordnete Verlauf, mit dem Änderungen zwischen Mitgliedern eines replica set kopiert werden, bereits nach einer Stunde statt nach einem Tag voll. Ein Secondary-Server mit einem Rückstand von einer Stunde würde dann eine vollständige Resynchronisierung benötigen. Die sinnvolle Reaktion besteht darin, das Update-Muster zu korrigieren, bevor die Replikation ihr Wiederherstellungsfenster verliert.
Für den letzten Test reduzierte Percona den WiredTiger cache auf 128 MB und scannte eine Collection mit 1,9 GB. WiredTiger ist MongoDBs Storage Engine, und sein Cache hält häufig benötigte Daten im Arbeitsspeicher bereit. Vier Minuten lang rief er zwischen 20.000 und 68.000 Pages pro Sekunde vom Datenträger ab und überschritt damit den Schwellenwert der Regel von 10.000. Die benötigten Daten passten nicht in den Arbeitsspeicher. Statt allein den Arbeitsspeicher zum Problem zu erklären, weist der Befund die Operatoren an, die Disk-Latenz und die verfügbaren read tickets zu untersuchen, bevor sie entscheiden, ob mehr Arbeitsspeicher oder eine effizientere Query die geeignete Lösung ist.
Die Erfassungsmethoden hängen vom Deployment ab. Ein selbstverwaltetes replica set benötigt einen Benutzer mit der Rolle clusterMonitor, die Zugriff auf Monitoring-Informationen gewährt. Der Poller ruft getDiagnosticData bei jedem Mitglied in Intervallen von zehn Sekunden auf. Atlas erfordert einen API key mit Project Read Only, das als niedrigste Rolle beschrieben wird, und ruft FTDC-Dateien über die Atlas Admin API ab. Operatoren können außerdem diagnostic.data hochladen, das aus einem support bundle stammt.
Das Tool dient der rückblickenden Analyse und ist kein System für akute Warnmeldungen. Es liest FTDC einmal pro Stunde aus, sodass ein Problem bereits fast eine Stunde bestehen kann, bevor es angezeigt wird, und es alarmiert niemals einen Operator. Vorhandenes Live-Monitoring und bestehende Warnmeldungen bleiben daher notwendig. Derzeit unterstützt es nur replica sets und keine sharded clusters, die Daten auf mehrere Servergruppen verteilen. Seine Regeln stammen aus Big Hole, und das Repository dokumentiert jede einzelne davon.