De MongoDB-foutlogboeken decoderen

Soms kan het decoderen van MongoDB-foutlogboeken lastig zijn en een groot deel van uw kostbare tijd in beslag nemen. In dit artikel leren we hoe we de MongoDB-foutlogboeken kunnen onderzoeken door elk deel van de logboekberichten te ontleden.

Algemeen formaat voor MongoDB-logregels

Hier is het log-lijnpatroon voor versie 3.0 en hoger...

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

Loglijnpatroon voor eerdere versies van MongoDB alleen inbegrepen:

<timestamp> [<context>] <message>

Laten we naar elke tag kijken.

Tijdstempels

Tijdstempelveld van logbericht slaat de exacte tijd op waarop een logbericht in het logbestand is ingevoegd. Er worden 4 soorten tijdstempels ondersteund door MongoDB. Het standaardformaat is:iso8601-local. U kunt dit wijzigen met de parameter --timeStampFormat.

Ernst

De volgende tabel beschrijft de betekenis van alle mogelijke ernstniveaus.

Onderdeel

Na versie 3.0 bevatten logberichten nu "component" om een ​​functionele categorisering van de berichten te bieden. Hierdoor kunt u uw zoekopdracht gemakkelijk verfijnen door naar de specifieke componenten te kijken.

Context

Het contextgedeelte van het foutbericht bevat over het algemeen de thread of verbindings-ID. Andere waarden kunnen worden initluister. Dit deel is omgeven door vierkante haken. Logberichten van een nieuwe verbinding met MongoDB hebben een contextwaarde als initandlisten, voor alle andere logberichten is dit ofwel een thread-ID of een verbindings-ID. Voor bijv.

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)

Bericht

Bevat het eigenlijke logbericht.

Locatie logbestand

De standaardlocatie op de server is:/var/log/mongodb/mongodb.log

Als het logbestand op deze locatie niet aanwezig is, kunt u het MongoDB-configuratiebestand inchecken. U kunt het MongoDB-configuratiebestand op een van deze twee locaties vinden.

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

Nadat u het configuratiebestand hebt geopend, zoekt u naar de optie logpath erin. logpath-optie vertelt MongoDB waar alle berichten moeten worden gelogd.

Een eenvoudig logbericht analyseren

Hier is een voorbeeld van een typische MongoDB-foutmelding...

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

Tijdstempel:2014-11-03T18:28:32.450-0500
Severity:I
Component:NETWORK
Context:[initandlisten]
Bericht:wachten op verbindingen op poort 27017

Het belangrijkste onderdeel van deze fout is het berichtgedeelte. In de meeste gevallen kunt u de fout achterhalen door naar dit veld te kijken. Soms is de boodschap voor u niet duidelijk, dan kunt u voor het onderdeel gaan. Voor dit bericht is de waarde van Component Netwerk, wat betekent dat het logbericht gerelateerd is aan een netwerkprobleem.

Als u uw fout niet kunt oplossen, kunt u de ernst van het logbericht controleren waarin staat dat dit bericht voor informatieve doeleinden is. Verder kun je ook andere delen van het logbericht bekijken, zoals tijdstempel of context, om de volledige hoofdoorzaak te vinden.

Decodering van algemene foutenlogboekberichten

1. Bericht:

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

   Oplossing: Maak een admin-gebruiker aan in de authenticatiedatabase

2. Bericht:

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

   Oplossing: Verwijder de time-out van de cursor of vergroot de batchgrootte van de cursor.

3. Bericht:

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

   Oplossing: Overtreding van een unieke sleutelbeperking. Probeer een document met een andere sleutel in te voegen.

4. Bericht:

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

   Oplossing: De latentie tussen de driver en de server is te groot, de driver kan het opgeven. U kunt de instelling wijzigen door de optie connectionTimeout toe te voegen aan de verbindingsreeks.

5. Bericht:

   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 }

   Oplossing: Verwijder duplicatie van _id veldwaarde uit conflicterende documenten.

6. Bericht:

   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

   Oplossing: Een van beide servers draait niet op poort 27017 of probeer de server opnieuw op te starten met de juiste host en poort.

Hulpprogramma's voor logbeheer

MongoDB 3.0 heeft zijn logboekfuncties bijgewerkt om betere inzichten te bieden voor alle database-activiteiten. Er zijn veel tools voor logboekbeheer op de markt beschikbaar, zoals MongoDB Ops Manager, logboekitems, mtools enz.

Conclusie

Logging is net zo belangrijk als Replicatie of Sharding voor goed en correct databasebeheer. Voor een beter databasebeheer moet men de logs gemakkelijk kunnen decoderen om de uitzonderingen/fouten snel te corrigeren. Ik hoop dat je je na het lezen van deze tutorial meer op je gemak zult voelen bij het analyseren van complexe MongoDB-logboeken.