Dekodieren der MongoDB-Fehlerprotokolle

Manchmal kann das Decodieren von MongoDB-Fehlerprotokollen schwierig sein und große Teile Ihrer wertvollen Zeit in Anspruch nehmen. In diesem Artikel erfahren Sie, wie Sie die MongoDB-Fehlerprotokolle untersuchen, indem Sie jeden Teil der Protokollmeldungen analysieren.

Gemeinsames Format für MongoDB-Protokollzeilen

Hier ist das Protokollzeilenmuster für Version 3.0 und höher...

<timestamp> <severity> <component> [<context>] <message>

Protokollzeilenmuster nur für frühere Versionen von MongoDB enthalten:

<timestamp> [<context>] <message>

Sehen wir uns die einzelnen Tags an.

Zeitstempel

Das Zeitstempelfeld der Protokollnachricht speichert den genauen Zeitpunkt, zu dem eine Protokollnachricht in die Protokolldatei eingefügt wurde. Es gibt 4 Arten von Zeitstempeln, die von MongoDB unterstützt werden. Das Standardformat ist:iso8601-local. Sie können es mit dem Parameter --timeStampFormat ändern.

Schweregrad

Die folgende Tabelle beschreibt die Bedeutung aller möglichen Schweregrade.

Komponente

Nach Version 3.0 enthalten Protokollmeldungen jetzt „Komponente“, um eine funktionale Kategorisierung der Meldungen bereitzustellen. Auf diese Weise können Sie Ihre Suche einfach eingrenzen, indem Sie sich die spezifischen Komponenten ansehen.

Kontext

Der Kontextteil der Fehlermeldung enthält im Allgemeinen die Thread- oder Verbindungs-ID. Andere Werte können initandlisten sein. Dieser Teil ist von eckigen Klammern umgeben. Protokollmeldungen jeder neuen Verbindung zu MongoDB haben den Kontextwert „initandlisten“, für alle anderen Protokollmeldungen ist dies entweder die Thread-ID oder die Verbindungs-ID. Für z.B.

2018-05-29T19:06:29.731+0000 [initandlisten] connection accepted from 127.0.0.1:27017 #1000 (13 connections now open)
2018-05-29T19:06:35.770+0000 [conn1000] end connection 127.0.0.1:27017 (12 connections now open)

Nachricht

Enthält die eigentliche Protokollnachricht.

Speicherort der Protokolldatei

Der Standardspeicherort auf dem Server ist:/var/log/mongodb/mongodb.log

Wenn die Protokolldatei an diesem Speicherort nicht vorhanden ist, können Sie die MongoDB-Konfigurationsdatei einchecken. Sie finden die MongoDB-Konfigurationsdatei an einem dieser beiden Orte.

/etc/mongod.conf or /yourMongoDBpath/mongod.conf

Suchen Sie nach dem Öffnen der Konfigurationsdatei nach der Option logpath darin. Die logpath-Option teilt MongoDB mit, wo alle Nachrichten protokolliert werden sollen.

Analysieren einer einfachen Protokollnachricht

Hier ist ein Beispiel für eine typische MongoDB-Fehlermeldung...

2014-11-03T18:28:32.450-0500 I NETWORK [initandlisten] waiting for connections on port 27017

Zeitstempel:2014-11-03T18:28:32.450-0500
Schweregrad:I
Komponente:NETWORK
Kontext:[initandlisten]
Meldung:Warten auf Verbindungen auf Port 27017

Der wichtigste Teil dieses Fehlers ist der Nachrichtenteil. In den meisten Fällen können Sie den Fehler herausfinden, indem Sie sich dieses Feld ansehen. Manchmal, wenn Ihnen die Botschaft nicht klar ist, können Sie sich für das Komponententeil entscheiden. Für diese Nachricht ist der Wert der Komponente Network, was bedeutet, dass die Protokollnachricht mit einem Netzwerkproblem zusammenhängt.

Wenn Sie Ihren Fehler nicht beheben können, können Sie den Schweregrad der Protokollnachricht überprüfen, die besagt, dass diese Nachricht zu Informationszwecken dient. Darüber hinaus können Sie auch andere Teile der Protokollnachricht wie Zeitstempel oder Kontext überprüfen, um die vollständige Grundursache zu finden.

Häufige Fehlerprotokollmeldungen entschlüsseln

1. Nachricht:

   2018-05-10T21:19:46.942 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.

   Lösung: Admin-Benutzer in der Authentifizierungsdatenbank erstellen

2. Nachricht:

   2018-05-10T21:19:46.942 E COMMAND  [initandlisten] ** ERROR: getMore command failed. Cursor not found

   Lösung: Entfernen Sie die Zeitüberschreitung vom Cursor oder erhöhen Sie die Stapelgröße des Cursors.

3. Nachricht:

   2018-05-10T21:19:46.942 E INDEX  [initandlisten] ** ERROR:E11000 duplicate key error index: test.collection.$a.b_1 dup key: { : null }

   Lösung: Verletzung der Eindeutigkeitsschlüsseleinschränkung. Versuchen Sie, ein Dokument mit einem anderen Schlüssel einzufügen.

4. Nachricht:

   2018-05-10T21:19:46.942 E NETWORK  [initandlisten] ** ERROR:Timed out connecting to localhost:27017.

   Lösung: Die Latenz zwischen dem Treiber und dem Server ist zu groß, der Treiber kann aufgeben. Sie können die Einstellung ändern, indem Sie die Option connectionTimeout in der Verbindungszeichenfolge hinzufügen.

5. Nachricht:

   2018-05-10T21:19:46.942 E WRITE  [initandlisten] ** ERROR: A write operation resulted in an error. E11000 duplicate key error index: test.people.$_id_ dup key: { : 0 }

   Lösung: Entfernen Sie die Duplizierung des _id-Feldwerts aus widersprüchlichen Dokumenten.

6. Nachricht:

   2018-05-10T21:19:46.942 E NETWORK  [initandlisten] ** ERROR: No connection could be made because the target machine actively refused it 127.0.0.1:27017 at System.Net.Sockets.Socket.EndConnect

   Lösung: Entweder läuft der Server nicht auf Port 27017 oder versuchen Sie, den Server mit dem richtigen Host und Port neu zu starten.

Protokollverwaltungstools

MongoDB 3.0 hat seine Protokollierungsfunktionen aktualisiert, um bessere Einblicke in alle Datenbankaktivitäten zu bieten. Es gibt viele Protokollverwaltungstools auf dem Markt, wie MongoDB Ops Manager, Protokolleinträge, mtools usw.

Schlussfolgerung

Die Protokollierung ist für eine gute und ordnungsgemäße Datenbankverwaltung genauso wichtig wie die Replikation oder das Sharding. Für eine bessere Datenbankverwaltung sollte man in der Lage sein, die Protokolle einfach zu decodieren, um die Ausnahmen/Fehler schnell zu beheben. Ich hoffe, dass Sie sich nach dem Lesen dieses Tutorials beim Analysieren komplexer MongoDB-Protokolle wohler fühlen werden.