sql >> Database teknologi >  >> NoSQL >> MongoDB

Afkodning af MongoDB fejllogfiler

Nogle gange kan det være vanskeligt at afkode MongoDB fejllogfiler og kan forbruge store bidder af din værdifulde tid. I denne artikel vil vi lære, hvordan man undersøger MongoDB fejllogfilerne ved at dissekere hver del af logmeddelelserne.

Fælles format for MongoDB-loglinjer

Her er loglinjemønsteret for version 3.0 og nyere...

[]

Loglinjemønster for tidligere versioner af MongoDB inkluderet kun:

[]

Lad os se på hvert tag.

Tidsstempler

Tidsstempelfeltet for logmeddelelsen gemmer det nøjagtige tidspunkt, hvor en logmeddelelse blev indsat i logfilen. Der er 4 typer tidsstempler understøttet af MongoDB. Standardformatet er:iso8601-local. Du kan ændre det ved at bruge parameteren --timeStampFormat.

Tidsstempelformatnavn Eksempel
iso8601-local 1969-12-31T19:00:00.000+0500
iso8601-utc 1970-01-01T00:00:00.000Z
ctime Ons 31. december 19:00:00.000
ctime-no-ms Ons 31. december 19:00:00

Sværhedsgrad

Følgende tabel beskriver betydningen af ​​alle mulige sværhedsgrader.

Sværhedsgrad Beskrivelse
F Fatal- Databasefejlen har medført, at databasen ikke længere er tilgængelig
E Fejl - Databasefejl, som vil stoppe DB-udførelse.
W Advarsel - Databasemeddelelser, der forklarer DB's potentielt skadelige adfærd.
I Informativ - Beskeder kun til informationsformål, såsom "En ny forbindelse accepteret".
D Fejlfinding - Mest nyttigt til fejlretning af DB-fejlene

Komponent

Efter version 3.0 indeholder logmeddelelser nu "komponent" for at give en funktionel kategorisering af meddelelserne. Dette giver dig mulighed for nemt at indsnævre din søgning ved at se på de specifikke komponenter.

Komponent Fejlbeskrivelse
Adgang Relateret til adgangskontrol
Kommando Relateret til databasekommandoer
Kontrol Relateret til kontrolaktiviteter
FTDC Relateret til diagnostiske dataindsamlingsaktiviteter
Geo Relateret til parsing af geospatiale former
Indeks Relateret til indekseringsoperationer
Netværk Relateret til netværksaktiviteter
Forespørgsel Relateret til forespørgsler
REPL Relateret til replikasæt
REPL_HB Relateret til replika sæt hjerteslag
Tilbage Relateret til rollback-db-handlinger
Sharding Relateret til sharding
Lagring Relateret til lageraktiviteter
Journal Relateret til journalaktiviteter
Skriv Relateret til db skriveoperationer

Kontekst

Kontekstdelen af ​​fejlmeddelelsen indeholder generelt tråden eller forbindelses-id'et. Andre værdier kan være initandlisten. Denne del er omgivet af firkantede parenteser. Logmeddelelser for enhver ny forbindelse til MongoDB vil have kontekstværdi som initandlisten, for alle andre logmeddelelser vil det enten være tråd-id eller forbindelses-id. For f.eks.

2018-05-29T19:06:29.731+0000 [initandlisten] forbindelse accepteret fra 127.0.0.1:27017 #1000 (13 forbindelser nu åbne)2018-05-29T19:06:31000070]+0 slutforbindelse 127.0.0.1:27017 (12 forbindelser nu åbne) 

Besked

Indeholder selve logmeddelelsen.

Logfilplacering

Standardplaceringen på serveren er:/var/log/mongodb/mongodb.log

Hvis logfilen ikke er til stede på denne placering, kan du tjekke MongoDB-konfigurationsfilen. Du kan finde MongoDB-konfigurationsfilen på en af ​​disse to steder.

/etc/mongod.conf eller /dinMongoDBpath/mongod.conf 

Når du åbner konfigurationsfilen, skal du søge efter logpath-indstillingen i den. logpath-indstillingen fortæller MongoDB, hvor alle meddelelserne skal logges.

Analyse af en simpel logmeddelelse

Her er et eksempel på en typisk MongoDB fejlmeddelelse...

2014-11-03T18:28:32.450-0500 I NETVÆRK [initandlisten] venter på forbindelser på port 27017 

Tidsstempel:2014-11-03T18:28:32.450-0500
Sværhedsgrad:I
Komponent:NETVÆRK
Kontekst:[initandlisten]
Besked:venter på forbindelser på port 27017

Den vigtigste del af denne fejl er meddelelsesdelen. I de fleste tilfælde kan du finde ud af fejlen ved at se på dette felt. Nogle gange, hvis meddelelsen ikke er klar for dig, kan du gå efter komponentdelen. For denne meddelelse er Komponentens værdi Netværk, hvilket betyder, at logmeddelelsen er relateret til et netværksproblem.

Hvis du ikke er i stand til at løse din fejl, kan du kontrollere alvoren af ​​logmeddelelsen, som siger, at denne meddelelse er til informationsformål. Yderligere kan du også tjekke andre dele af logmeddelelsen, såsom tidsstempel eller kontekst, for at finde den komplette årsag.

Afkodning af almindelige fejllogmeddelelser

  1. Besked:

    2018-05-10T21:19:46.942 I CONTROL [initandlisten] ** ADVARSEL:Adgangskontrol er ikke aktiveret for databasen. 

    Opløsning: Opret admin-bruger i godkendelsesdatabasen

  2. Besked:

    2018-05-10T21:19:46.942 E COMMAND [initandlisten] ** FEJL:kommandoen getMore mislykkedes. Markøren blev ikke fundet 

    Opløsning: Fjern timeout fra markøren, eller øg markørens batchstørrelse.

  3. Besked:

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

    Opløsning: Overtrædelse af unik nøglebegrænsning. Prøv at indsætte dokument med en anden nøgle.

  4. Besked:

    2018-05-10T21:19:46.942 E NETVÆRK [initandlisten] ** FEJL:Timeout for forbindelsen til localhost:27017. 

    Opløsning: Latency mellem driveren og serveren er for stor, føreren kan give op. Du kan ændre indstillingen ved at tilføje forbindelsesTimeout-indstillingen i forbindelsesstrengen.

  5. Besked:

    2018-05-10T21:19:46.942 E SKRIV [initandlisten] ** FEJL:En skrivehandling resulterede i en fejl. E11000 duplicate key error index:test.people.$_id_ dup key:{ :0 } 

    Opløsning: Fjern duplikering af _id-feltværdi fra modstridende dokumenter.

  6. Besked:

    2018-05-10T21:19:46.942 E NETVÆRK [initandlisten] ** FEJL:Der kunne ikke oprettes forbindelse, fordi målmaskinen aktivt nægtede det 127.0.0.1:27017 på System.Net.Sockets.Socket. EndConnect 

    Opløsning: Enten af ​​serverne kører ikke på port 27017, eller prøv at genstarte serveren med korrekt vært og port.

Logstyringsværktøjer

MongoDB 3.0 har opdateret sine logfunktioner for at give bedre indsigt i alle databaseaktiviteter. Der er mange logstyringsværktøjer tilgængelige på markedet som MongoDB Ops Manager, logindtastninger, mtools osv.

Konklusion

Logning er lige så vigtig som Replikering eller Sharding for god og korrekt databasestyring. For bedre databasestyring bør man være i stand til nemt at afkode logfilerne for hurtigt at rette op på undtagelserne/fejlene. Jeg håber, at du efter at have læst denne vejledning vil føle dig mere komfortabel, mens du analyserer komplekse MongoDB-logfiler.


  1. Forbind NodeJS til MongoDB Droplet

  2. Visuel statistik til din MongoDB-server

  3. MongoDB indlejret opslag med 3 niveauer

  4. Docker-compose - Redis ved 0.0.0.0 i stedet for 127.0.0.1