TeaHostКогда сервер падает, лагает или плагин молча не работает, логи сервера Minecraft — единственный источник правды. Всё остальное будет гаданием. Проблема в том, что в latest.log за сутки набегает десятки тысяч строк, и без понимания структуры там утонуть проще, чем найти причину.
Держите короткий справочник: какие файлы есть, что в них искать и как отсеять шум.
Где лежат логи сервера Minecraft
Все файлы — в корне сервера:
logs/
latest.log — текущая сессия, обнуляется при рестарте
2026-04-17-1.log.gz — архив предыдущих запусков
debug.log — расширенный лог, если включён
crash-reports/
crash-2026-04-18_03.14.22-server.txt
hs_err_pid12345.log — падение самой JVM, в корнеЛогика простая: при каждом старте сервера текущий latest.log сжимается в .gz с датой и номером запуска. Если сервер за сутки перезапускался четыре раза, будет 2026-04-18-1.log.gz ... -4.log.gz.
Отдельно смотрите crash-reports. Туда попадают именно креши процесса — с полным стектрейсом, списком модов и состоянием тредов. А hs_err_pid*.log появляется, когда падает не сервер, а сама виртуальная машина Java: обычно это нехватка памяти на уровне контейнера или сбойный нативный код.
Скачивать удобнее по SFTP — подключение разбирали отдельно. В панели логи тоже видно, но искать в веб-консоли по десяткам тысяч строк неудобно.
Структура строки
[03:14:22 INFO]: [LuckPerms] Loaded 14 groups
[03:14:23 WARN]: Can't keep up! Is the server overloaded? Running 4213ms behind
[03:14:25 ERROR]: Could not pass event PlayerJoinEvent to EssentialsX v2.20.1Три уровня, которые встречаются в 99% случаев:
- INFO — обычные события: старт, подключения, загрузка плагинов. Нужен для контекста.
- WARN — что-то не так, но сервер продолжает работать. Пропущенные конфиги, отставание тика, устаревшие API-вызовы.
- ERROR — исключение. Дальше почти всегда идёт стектрейс.
Есть ещё имя треда в квадратных скобках у Paper при включённом debug — по нему видно, произошло что-то в главном потоке или в асинхронной задаче плагина.
Как читать стектрейс
Типичная простыня выглядит устрашающе, но полезной информации в ней три строки:
[19:02:11 ERROR]: Could not pass event BlockBreakEvent to MyShop v1.4
java.lang.NullPointerException: Cannot invoke "org.bukkit.entity.Player.getName()" because "p" is null
at ru.example.myshop.ShopListener.onBreak(ShopListener.java:88)
at com.destroystokyo.paper.event.executor.MethodHandleEventExecutor.execute(...)
...
Caused by: java.lang.IllegalStateException: Database connection closed
at ru.example.myshop.Storage.query(Storage.java:41)Что смотреть:
- Первая строка — какой плагин и на каком событии сломался. Здесь MyShop на BlockBreakEvent, значит проблема воспроизводится при ломании блока.
- Тип исключения — NullPointerException означает баг в плагине, а не в вашем конфиге. ClassNotFoundException или NoSuchMethodError — плагин собран под другую версию API.
- Самая нижняя строка
Caused by:— настоящая причина. В примере это оборванное соединение с базой, а не сам NPE.
Правило, которое экономит часы: читайте стектрейс снизу вверх и ищите последний Caused by. Всё, что выше, — только цепочка вызовов.
Поиск по логам через grep
Веб-консоль хороша для просмотра в реальном времени, а разбор удобнее делать в шелле:
tail -f logs/latest.log
grep -n "ERROR" logs/latest.log | tail -50
grep -c "Can't keep up" logs/latest.log
grep -A 20 "PlayerJoinEvent" logs/latest.log
zgrep "OutOfMemoryError" logs/*.log.gz-A 20 показывает двадцать строк после совпадения — как раз хватает на стектрейс. zgrep умеет читать сжатые архивы без распаковки, что удобно, когда надо проверить, повторялась ли ошибка неделю назад.
Поиск по конкретному игроку:
grep -i "Steve" logs/latest.logТак находятся входы, выходы, смены IP и команды, если у вас включено логирование команд.
Что означают частые сообщения
| Сообщение | Что значит | Что делать |
|---|---|---|
Can't keep up! Is the server overloaded? | Сервер не успел обработать тики | Единичное после генерации мира — норма; регулярное — запускайте профайлер Spark |
java.lang.OutOfMemoryError: Java heap space | Кончилась куча | Проверьте -Xmx и выделение памяти, потом ищите утечку в плагинах |
... moved too quickly! | Обычно ложное срабатывание проверки движения на лифтах или лодках | Параметр moved-too-quickly-multiplier в spigot.yml |
The server has stopped responding! | Watchdog: главный поток завис дольше timeout-time (по умолчанию 60 секунд) | Смотрите дамп стека ниже — часто виноват плагин, который синхронно лезет в базу |
Failed to check session lock, aborting | Мир занят другим процессом | Двойной запуск: старый процесс не завершился |
Как убрать спам
Половина объёма логов — бесполезные сообщения. Отфильтровать их можно через собственный log4j2.xml в корне сервера: туда добавляется RegexFilter с шаблоном вида .*(Ignoring unknown custom packet payload).* и действием DENY. Файл подключается флагом -Dlog4j.configurationFile=log4j2.xml в строке запуска.
Осторожнее с фильтрами: заглушив что-то «лишнее», можно потом полдня искать ошибку, которой в логе просто нет.
Отдельно проверьте verbose у плагинов. У WorldGuard, LuckPerms и античитов подробный режим по умолчанию бывает включён и генерирует мегабайты в час.
Ротация и хранение
Логи копятся бесконечно, и на сервере с частыми рестартами logs/ за месяц раздувается до гигабайта. Простое решение — крон-задача:
find /home/container/logs -name "*.log.gz" -mtime +14 -deleteДве недели истории покрывают почти любой разбор инцидента. Если у вас настроен автоперезапуск, добавьте очистку в тот же скрипт.
Итог
Алгоритм разбора любой проблемы: открыть latest.log, найти первый ERROR по времени инцидента, прочитать последний Caused by, определить плагин, проверить его версию под ваше ядро. Если ERROR нет, а есть только «Can't keep up» — это не ошибка, а нагрузка, и лечится профайлером и конфигами.
Для постоянного контроля состояния сервера пригодится мониторинг нагрузки. А если логи стабильно показывают нехватку памяти — вопрос решается не конфигом, а тарифом: посмотреть варианты.