Dekodowanie dzienników błędów MongoDB

Czasami dekodowanie dzienników błędów MongoDB może być trudne i pochłaniać duże części cennego czasu. W tym artykule dowiemy się, jak badać dzienniki błędów MongoDB, analizując każdą część komunikatów dziennika.

Wspólny format wierszy dziennika MongoDB

Oto wzorzec linii dziennika dla wersji 3.0 i nowszych...

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

Uwzględniono tylko wzór linii dziennika dla poprzednich wersji MongoDB:

<timestamp> [<context>] <message>

Przyjrzyjmy się każdemu tagowi.

sygnatury czasowe

Pole sygnatury czasowej komunikatu dziennika przechowuje dokładny czas wstawienia komunikatu dziennika do pliku dziennika. MongoDB obsługuje 4 typy znaczników czasu. Domyślny format to:iso8601-local. Możesz to zmienić za pomocą parametru --timeStampFormat.

Istotność

Poniższa tabela opisuje znaczenie wszystkich możliwych poziomów ważności.

Komponent

Po wersji 3.0 komunikaty dziennika zawierają teraz „komponent”, aby zapewnić funkcjonalną kategoryzację komunikatów. Pozwala to łatwo zawęzić wyszukiwanie, patrząc na określone komponenty.

Kontekst

Część kontekstowa komunikatu o błędzie zazwyczaj zawiera identyfikator wątku lub połączenia. Inne wartości mogą być initandlisten. Ta część jest otoczona nawiasami kwadratowymi. Komunikaty dziennika każdego nowego połączenia z MongoDB będą miały wartość kontekstu jako initandlisten, dla wszystkich innych komunikatów dziennika będzie to identyfikator wątku lub identyfikator połączenia. Na przykład

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)

Wiadomość

Zawiera aktualny komunikat dziennika.

Lokalizacja pliku dziennika

Domyślna lokalizacja na serwerze to:/var/log/mongodb/mongodb.log

Jeśli plik dziennika nie jest obecny w tej lokalizacji, możesz sprawdzić plik konfiguracyjny MongoDB. Możesz znaleźć plik konfiguracyjny MongoDB w jednej z tych dwóch lokalizacji.

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

Po otwarciu pliku konfiguracyjnego wyszukaj w nim opcję logpath. Opcja logpath mówi MongoDB, gdzie ma rejestrować wszystkie wiadomości.

Analiza prostego komunikatu dziennika

Oto przykład typowego komunikatu o błędzie MongoDB...

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

Znacznik czasu:2014-11-03T18:28:32.450-0500
Istotność:I
Komponent:SIEĆ
Kontekst:[initandlisten]
Wiadomość:oczekiwanie na połączenia na porcie 27017

Najważniejszą częścią tego błędu jest część wiadomości. W większości przypadków błąd można znaleźć, patrząc na to pole. Czasami, jeśli wiadomość nie jest dla ciebie jasna, możesz wybrać część składową. W przypadku tej wiadomości wartością składnika jest Sieć, co oznacza, że ​​komunikat dziennika dotyczy problemu z siecią.

Jeśli nie jesteś w stanie rozwiązać problemu, możesz sprawdzić wagę komunikatu dziennika, który mówi, że ten komunikat ma charakter informacyjny. Ponadto możesz również sprawdzić inne części komunikatu dziennika, takie jak znacznik czasu lub kontekst, aby znaleźć pełną przyczynę.

Dekodowanie typowych komunikatów dziennika błędów

1. Wiadomość:

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

   Rozdzielczość: Utwórz administratora w bazie danych uwierzytelniania

2. Wiadomość:

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

   Rozdzielczość: Usuń limit czasu z kursora lub zwiększ rozmiar wsadu kursora.

3. Wiadomość:

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

   Rozdzielczość: Naruszenie unikalnego ograniczenia klucza. Spróbuj wstawić dokument z innym kluczem.

4. Wiadomość:

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

   Rozdzielczość: Opóźnienie między kierowcą a serwerem jest zbyt duże, kierowca może się poddać. Możesz zmienić ustawienie, dodając opcję connectionTimeout w ciągu połączenia.

5. Wiadomość:

   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 }

   Rozdzielczość: Usuń duplikat wartości pola _id z dokumentów będących w konflikcie.

6. Wiadomość:

   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

   Rozdzielczość: Albo serwer nie działa na porcie 27017, albo spróbuj zrestartować serwer z prawidłowym hostem i portem.

Narzędzia do zarządzania dziennikami

MongoDB 3.0 zaktualizował swoje funkcje rejestrowania, aby zapewnić lepszy wgląd we wszystkie działania bazy danych. Na rynku dostępnych jest wiele narzędzi do zarządzania logami, takich jak MongoDB Ops Manager, wpisy logów, mtools itp.

Wniosek

Rejestrowanie jest tak samo ważne jak replikacja lub fragmentowanie dla dobrego i prawidłowego zarządzania bazą danych. W celu lepszego zarządzania bazą danych, należy być w stanie łatwo dekodować logi, aby szybko naprawić wyjątki/błędy. Mam nadzieję, że po przeczytaniu tego samouczka poczujesz się bardziej komfortowo podczas analizowania złożonych logów MongoDB.