Декодиране на регистрационните файлове за грешки в MongoDB

Понякога декодирането на регистрационни файлове за грешки в MongoDB може да бъде сложно и може да отнеме големи парчета от вашето ценно време. В тази статия ще научим как да изследваме регистрационните файлове за грешки на MongoDB, като разчленим всяка част от съобщенията в журнала.

Общ формат за MongoDB регистрационни линии

Ето модела на регистрационния ред за версия 3.0 и по-нова...

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

Моделът на регистрационния ред за предишни версии на MongoDB включва само:

<timestamp> [<context>] <message>

Нека разгледаме всеки маркер.

Чети за време

Полето за клеймо на регистрационния файл съхранява точното време, когато регистрационното съобщение е било вмъкнато в регистрационния файл. Има 4 типа времеви печати, поддържани от MongoDB. Форматът по подразбиране е:iso8601-local. Можете да го промените с помощта на параметъра --timeStampFormat.

Тежест

Следната таблица описва значението на всички възможни нива на сериозност.

Компонент

След версия 3.0, регистрационните съобщения вече включват „компонент“, за да осигурят функционална категоризация на съобщенията. Това ви позволява лесно да стесните търсенето си, като разгледате конкретните компоненти.

Контекст

Контекстната част на съобщението за грешка обикновено съдържа нишката или идентификатора на връзката. Други стойности могат да бъдат initandlisten. Тази част е заобиколена от квадратни скоби. Регистрационните съобщения за всяка нова връзка към MongoDB ще имат стойност на контекста като initandlisten, за всички други съобщения в дневника, това ще бъде или идентификатор на нишка, или идентификатор на връзката. Например

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)

Съобщение

Съдържа действителното съобщение в дневника.

Местоположение на регистрационния файл

Местоположението по подразбиране на сървъра е:/var/log/mongodb/mongodb.log

Ако регистрационният файл не присъства на това място, тогава можете да проверите в конфигурационния файл на MongoDB. Можете да намерите конфигурационния файл на MongoDB на всяко от тези две места.

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

След като отворите конфигурационния файл, потърсете опция за logpath в него. Опцията logpath казва на MongoDB къде да регистрира всички съобщения.

Анализиране на просто съобщение в дневника

Ето пример за типично съобщение за грешка в MongoDB...

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

Печат за време:2014-11-03T18:28:32.450-0500
Сережест:I
Компонент:МРЕЖА
Контекст:[initandlisten]
Съобщение:чакат се връзки на порт 27017

Най-важната част от тази грешка е частта от съобщението. В повечето случаи можете да разберете грешката, като погледнете това поле. Понякога, ако съобщението не ви е ясно, тогава можете да отидете на компонентната част. За това съобщение стойността на компонента е Мрежа, което означава, че съобщението в журнала е свързано с проблем с мрежата.

Ако не сте в състояние да разрешите грешката си, можете да проверите сериозността на съобщението в дневника, което казва, че това съобщение е с информационна цел. Освен това можете да проверите и други части от съобщението в регистрационния файл, като времева марка или контекст, за да намерите пълната основна причина.

Декодиране на съобщения в регистъра за често срещани грешки

1. Съобщение:

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

   Резолюция: Създайте администратор на потребител в базата данни за удостоверяване

2. Съобщение:

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

   Резолюция: Премахнете времето за изчакване от курсора или увеличете размера на пакета на курсора.

3. Съобщение:

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

   Резолюция: Нарушаване на ограничение за уникален ключ. Опитайте да вмъкнете документ с различен ключ.

4. Съобщение:

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

   Резолюция: Закъснението между драйвера и сървъра е твърде голямо, драйверът може да се откаже. Можете да промените настройката, като добавите опция connectionTimeout в низа за връзка.

5. Съобщение:

   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 }

   Резолюция: Премахнете дублирането на стойността на полето _id от конфликтни документи.

6. Съобщение:

   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

   Резолюция: Или сървърът не работи на порт 27017, или се опитайте да рестартирате сървъра с правилен хост и порт.

Инструменти за управление на регистрационни файлове

MongoDB 3.0 актуализира своите функции за регистриране, за да предостави по-добра информация за всички дейности на базата данни. На пазара има много инструменти за управление на регистрационни файлове като MongoDB Ops Manager, записи в регистрационни файлове, mtools и др.

Заключение

Регистрирането е толкова важно, колкото репликацията или разделянето за доброто и правилно управление на базата данни. За по-добро управление на базата данни човек трябва да може лесно да декодира регистрационните файлове, за да коригира бързо изключенията/грешките. Надявам се, че след като прочетете този урок, ще се почувствате по-комфортно, докато анализирате сложни регистрационни файлове на MongoDB.