Как расшифровать лог MongoDB и понять причину ошибки

Чтобы расшифровать лог MongoDB, начните с последних строк рядом с моментом ошибки. В современных логах часто встречаются поля t, s, c, msg и attr: время, уровень сообщения, компонент, текст сообщения и дополнительные детали. Самая полезная часть для человека обычно в msg и attr

Пример строки:

{
  "t": { "$date": "2026-06-02T10:15:00.000+03:00" },
  "s": "E",
  "c": "NETWORK",
  "msg": "Error accepting new connection",
  "attr": { "error": "Connection reset by peer" }
}

Здесь видно: ошибка уровня E, компонент NETWORK, проблема связана с подключением

Где смотреть логи

На Linux часто удобно:

sudo journalctl -u mongod -n 100

Или файл лога, если он указан в конфигурации MongoDB:

sudo tail -n 100 /var/log/mongodb/mongod.log

В mongosh можно посмотреть лог командой:

db.adminCommand({ getLog: "global" })

Что означают основные поля

t — время события

s — уровень сообщения. Часто встречаются I для информации, W для предупреждения, E для ошибки

c — компонент: сеть, хранение данных, запросы, репликация и другие части MongoDB

msg — основное сообщение

attr — детали: порт, адрес, код ошибки, параметры запроса, длительность

Как читать лог по шагам

Сначала найдите время, когда возникла проблема. Если вы перезапускали MongoDB в 10:15, смотрите строки около 10:15

Затем ищите уровни E и W. Информационные строки тоже полезны, но начинать лучше с ошибок и предупреждений

После этого смотрите msg и attr. Часто там прямо написано, что не так: занят порт, нет прав на папку, не найден файл, отказ подключения

Примеры симптомов

Если MongoDB не стартует, ищите строки про путь к данным, права доступа, порт 27017 и конфигурационный файл

Если приложение не подключается, ищите сетевые ошибки, connection, authentication, not authorized

Если база работает медленно, ищите slow query и длительность операции. Такие строки помогают понять, какой запрос тормозит

Частые ошибки при чтении логов

Смотреть слишком большой кусок

Если открыть весь лог за месяц, легко утонуть. Начинайте с последних 50-100 строк или с конкретного времени

Игнорировать attr

В msg часто общий текст, а настоящая причина лежит в attr

Лечить симптом, не проверив причину

Если лог говорит про отказ авторизации, перезапуск службы не исправит логин и пароль

Не сохранять лог перед изменениями

Перед правками конфигурации сохраните важные строки. Потом будет проще понять, что именно изменилось

Короткий чек-лист

1. Найдите время ошибки.
2. Посмотрите последние строки лога.
3. Найдите уровни E и W.
4. Прочитайте msg.
5. Разберите attr.
6. Проверьте подключение, права, порт, путь к данным или запрос.

Что почитать дальше по MongoDB

Если нужен общий маршрут по теме, откройте рубрику MongoDB. Для соседних задач пригодятся эти разборы:

• Как понять причину поведения выборки в MongoDB
• Как перезапустить MongoDB безопасно: команды, проверка и ошибки
• Discord bot на Python и MongoDB: как задать проверку
• Failed to start MongoDB database server: что проверить

Как проверить результат на практике

Для MongoDB-материала полезно делать три проверки: сначала выполнить команду на маленьком наборе тестовых документов, затем посмотреть результат через find() или MongoDB Compass, а после этого повторить действие на копии реальной структуры данных. Если запрос меняет документы, сначала запускайте его с фильтром на один документ и только потом расширяйте условие

Еще одна хорошая привычка — записывать исходное состояние и ожидаемый результат. Например: было три документа, после обновления изменился только один; был массив из пяти элементов, после операции остался нужный элемент; индекс появился в getIndexes(). Такая проверка быстро показывает, что вы исправили именно задачу, а не просто получили команду без ошибки