Avkodning av MongoDB-felloggarna

Ibland kan det vara svårt att avkoda MongoDB-felloggar och kan ta stora delar av din värdefulla tid. I den här artikeln kommer vi att lära oss hur man undersöker MongoDB-felloggarna genom att dissekera varje del av loggmeddelandena.

Gemensamt format för MongoDB-logglinjer

Här är logglinjemönstret för version 3.0 och senare...

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

Logglinjemönster för tidigare versioner av MongoDB ingår endast:

<timestamp> [<context>] <message>

Låt oss titta på varje tagg.

Tidsstämplar

Tidstämpelfältet för loggmeddelandet lagrar den exakta tidpunkten när ett loggmeddelande infogades i loggfilen. Det finns 4 typer av tidsstämplar som stöds av MongoDB. Standardformatet är:iso8601-local. Du kan ändra det med parametern --timeStampFormat.

Allvarlighetsgrad

Följande tabell beskriver innebörden av alla möjliga svårighetsgradsnivåer.

Komponent

Efter version 3.0 innehåller loggmeddelanden nu "komponent" för att tillhandahålla en funktionell kategorisering av meddelandena. Detta gör att du enkelt kan begränsa din sökning genom att titta på de specifika komponenterna.

Kontext

Kontextdelen av felmeddelandet innehåller vanligtvis tråden eller anslutnings-ID. Andra värden kan vara initandlisten. Denna del är omgiven av hakparenteser. Loggmeddelanden för en ny anslutning till MongoDB kommer att ha kontextvärde som initandlisten, för alla andra loggmeddelanden kommer det att vara antingen tråd-id eller anslutnings-id. För t.ex.

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)

Meddelande

Innehåller själva loggmeddelandet.

Loggfilsplats

Standardplatsen på servern är:/var/log/mongodb/mongodb.log

Om loggfilen inte finns på den här platsen kan du kontrollera MongoDB-konfigurationsfilen. Du kan hitta MongoDB-konfigurationsfilen på någon av dessa två platser.

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

När du öppnar konfigurationsfilen, sök efter logpath-alternativet i den. logpath-alternativet talar om för MongoDB var alla meddelanden ska loggas.

Analysera ett enkelt loggmeddelande

Här är ett exempel på ett typiskt MongoDB-felmeddelande...

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

Tidsstämpel:2014-11-03T18:28:32.450-0500
Allvarlighetsgrad:I
Komponent:NÄTVERK
Kontext:[initandlisten]
Meddelande:väntar på anslutningar på port 27017

Den viktigaste delen av detta fel är meddelandedelen. I de flesta fall kan du ta reda på felet genom att titta på det här fältet. Ibland om meddelandet inte är tydligt för dig kan du gå till komponentdelen. För det här meddelandet är komponentens värde Nätverk, vilket betyder att loggmeddelandet är relaterat till ett nätverksproblem.

Om du inte kan lösa ditt fel kan du kontrollera allvaret i loggmeddelandet som säger att detta meddelande är i informationssyfte. Vidare kan du också kolla in andra delar av loggmeddelandet som tidsstämpel eller sammanhang för att hitta hela grundorsaken.

Avkoda vanliga felloggmeddelanden

1. Meddelande:

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

   Upplösning: Skapa adminanvändare i autentiseringsdatabasen

2. Meddelande:

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

   Upplösning: Ta bort tidsgränsen från markören eller öka markörens batchstorlek.

3. Meddelande:

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

   Upplösning: Brott mot unik nyckelbegränsning. Försök att infoga dokument med en annan nyckel.

4. Meddelande:

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

   Upplösning: Latensen mellan föraren och servern är för stor, föraren kan ge upp. Du kan ändra inställningen genom att lägga till alternativet ConnectionTimeout i anslutningssträngen.

5. Meddelande:

   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 }

   Upplösning: Ta bort duplicering av _id-fältvärde från motstridiga dokument.

6. Meddelande:

   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

   Upplösning: Antingen körs inte servern på port 27017 eller försök att starta om servern med rätt värd och port.

Verktyg för logghantering

MongoDB 3.0 har uppdaterat sina loggningsfunktioner för att ge bättre insikter för alla databasaktiviteter. Det finns många logghanteringsverktyg tillgängliga på marknaden som MongoDB Ops Manager, loggposter, mtools etc.

Slutsats

Loggning är lika viktigt som replikering eller sönderdelning för bra och korrekt databashantering. För bättre databashantering bör man enkelt kunna avkoda loggarna för att snabbt rätta till undantagen/felen. Jag hoppas att du efter att ha läst den här handledningen kommer att känna dig mer bekväm när du analyserar komplexa MongoDB-loggar.