Jak czytac i analizowac logi serwera Minecraft

Serwer padl w nocy. Gracze pisza, ze "wszystko lagowalo, potem wyrzucilo". Wchodzisz rano, serwer dziala - zrestartowal go watchdog. Co sie stalo? Bez logow nigdy sie nie dowiesz.

Logi to jedyne wiarygodne zrodlo informacji o tym, co dzieje sie na serwerze. Nie "wydaje mi sie", nie "pewnie plugin bugowal", a konkretne wpisy z dokladnym czasem, poziomem krytycznosci i opisem problemu. Jesli administrujesz serwer Minecraft i nie umiesz czytac logow - dzialasz na slepo.

W tym artykule omawiam wszystko: gdzie leza logi, jak zbudowany jest format wpisow, co oznaczaja poziomy, jak znajdowac typowe problemy i jak zautomatyzowac analize.

Gdzie sa przechowywane logi

latest.log

Glowny plik to logs/latest.log w katalogu serwera. Zapisuje sie tu wszystko od ostatniego startu. Przy kazdym restarcie serwera poprzedni latest.log jest archiwizowany.

server/
|-- logs/
|   |-- latest.log              <-- biezaca sesja
|   |-- 2026-03-25-1.log.gz     <-- wczorajszy log (skompresowany)
|   |-- 2026-03-24-1.log.gz
|   |-- 2026-03-24-2.log.gz     <-- jesli serwer restartowal sie dwa razy
|   `-- ...
|-- crash-reports/
|   `-- crash-2026-03-25-server.txt
`-- ...

Archiwa trzymane sa w formacie gzip. Zeby odczytac stary log:

# Podglad skompresowanego loga
zcat logs/2026-03-25-1.log.gz | less

# Szukanie w skompresowanym logu
zgrep "ERROR" logs/2026-03-25-1.log.gz

crash-reports/

Gdy serwer pada z fatalnym bledem, tworzy plik w folderze crash-reports/. To nie to samo co zwykly log - crash raport zawiera szczegolowy snapshot stanu serwera w momencie padu: stack trace, zaladowane pluginy, info o systemie, stan pamieci.

Nazwa pliku zawiera date i czas: crash-2026-03-25-151432-server.txt.

debug/

Na serwerach Paper jest folder debug/ - trafiaja tu thread dumpy i inne info diagnostyczne. O nich szerzej ponizej.

Format wpisu loga

Kazda linijka w logu ma standardowy format:

[15:42:01] [Server thread/INFO]: Player_Steve joined the game
[15:42:15] [Server thread/WARN]: Can't keep up! Is the server overloaded?
[15:43:02] [Server thread/ERROR]: Could not pass event PlayerMoveEvent

Rozbijmy na czesci:

• [15:42:01] - czas zdarzenia (HH:MM:SS)
• [Server thread/INFO] - watek (thread) i poziom logowania
• Tekst po : - sama wiadomosc

Watek jest wazny. Server thread to glowny watek tickow, na ktorym dziala cala logika gry. Jesli blad dzieje sie w Async Chat Thread albo Netty Epoll Server IO - to inna historia i inne przyczyny.

Poziomy logowania

INFO

Zwykle wiadomosci informacyjne. Polaczenia graczy, ladowanie pluginow, zapisywanie swiata. To 95% twojego loga.

[15:42:01] [Server thread/INFO]: Starting minecraft server version 1.20.4
[15:42:03] [Server thread/INFO]: Loading properties
[15:42:05] [Server thread/INFO]: Done (4.832s)! For help, type "help"

Wiadomosci INFO mozna zwykle ignorowac przy szukaniu problemow. Ale czasem przydatne info kryje sie wlasnie tu - np. czas ladowania pluginow moze pokazac, ktory z nich spowalnia start.

WARN

Ostrzezenia. Serwer napotkal cos niepozadanego, ale dziala dalej.

[15:42:15] [Server thread/WARN]: Can't keep up! Is the server overloaded?
    Running 5023ms or 100 ticks behind

To najslynniejsze ostrzezenie Minecrafta. Oznacza, ze serwer nie nadaza obslugiwac tickow na czas. Jesli pojawia sie sporadycznie - nic groznego. Jesli co kilka sekund - masz powazne problemy z wydajnoscia.

Inne czeste WARN:

[WARN]: Ambiguity between arguments [...]  -- niejednoznacznosc komend, nieszkodliwe
[WARN]: UUID of player X is ...             -- problemy z UUID, czesto przy offline-mode
[WARN]: Connection throttled: 192.168.1.50  -- za czeste polaczenia z jednego IP

ERROR

Bledy. Cos sie zepsulo. Plugin padl, nie udalo sie zaladowac swiata, blad w konfiguracji.

[15:43:02] [Server thread/ERROR]: Could not pass event PlayerMoveEvent to ExamplePlugin v1.0
org.bukkit.event.EventException: null
    at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:310)
    at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70)
    ...
Caused by: java.lang.NullPointerException
    at com.example.plugin.MoveListener.onPlayerMove(MoveListener.java:45)

To juz jest wazne. ERROR zawsze wymaga uwagi. Po ERROR zwykle idzie stack trace - lancuch wywolan, ktory doprowadzil do bledu. Jak go czytac - ponizej.

FATAL

Krytyczny blad, po ktorym serwer zwykle sie zatrzymuje. Rzadki, ale jesli widzisz FATAL - to powaznie.

[15:45:01] [Server thread/FATAL]: Encountered an unexpected exception
java.lang.OutOfMemoryError: Java heap space

Brak pamieci, uszkodzenie danych swiata, bug w rdzeniu serwera - wszystko to moze wywolac FATAL.

Jak czytac stack trace

Stack trace to lancuch wywolan metod, ktory doprowadzil do bledu. Czytac go trzeba z gory do dolu, ale szukac przyczyny - z dolu do gory.

[ERROR]: Could not pass event PlayerInteractEvent to ShopPlugin v2.1
org.bukkit.event.EventException: null
    at org.bukkit.plugin.java.JavaPluginLoader$1.execute(JavaPluginLoader.java:310)
    at org.bukkit.plugin.RegisteredListener.callEvent(RegisteredListener.java:70)
    at org.bukkit.plugin.SimplePluginManager.callEvent(SimplePluginManager.java:545)
    at org.bukkit.craftbukkit.event.CraftEventFactory.callPlayerInteractEvent(CraftEventFactory.java:540)
    at net.minecraft.server.level.ServerPlayerGameMode.useItemOn(ServerPlayerGameMode.java:532)
Caused by: java.lang.NullPointerException: Cannot invoke "org.bukkit.inventory.ItemStack.getType()" because "item" is null
    at com.example.shop.ShopListener.onInteract(ShopListener.java:78)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Algorytm czytania:

1. Pierwsza linijka - co sie stalo: "Could not pass event PlayerInteractEvent to ShopPlugin". Od razu jasne - problem w ShopPlugin przy obsludze klikniecia gracza.

2. "Caused by" - realna przyczyna. NullPointerException: Cannot invoke "getType()" because "item" is null. Plugin probuje pobrac typ przedmiotu, ale przedmiot jest null.

3. Linijka z twoim pluginem - ShopListener.java:78. To linijka 78 w pliku ShopListener.java. Jesli plugin jest twoj - idziesz naprawic te linijke. Jesli nie twoj - robisz issue na GitHubie albo szukasz aktualizacji.

Linie z org.bukkit, net.minecraft, java.lang i sun.reflect to wnetrznosci serwera i Javy. Zwykle nie sa przyczyna problemu, tylko pokazuja sciezke wykonania.

Typowe bledy i co z nimi robic

"Can't keep up! Is the server overloaded?"

Juz wspomnialem wyzej. Serwer zostaje w tyle za normalnymi 20 tickami na sekunde. Przyczyny:

• Za duzo encji
• Ciezki plugin w glownym watku
• Za malo RAM i czeste pauzy GC
• Wolny dysk (SSD obowiazkowy dla serwerow)

Szczegolowo o diagnostyce lagow czytaj w naszym poradniku o przyczynach lagow.

"Connection throttled"

[WARN]: Connection throttled: 185.220.101.34

Ktos laczy sie za czesto. Moze to byc bot, moze atak DDoS na poziomie aplikacji. Jesli widzisz jedno IP z setkami throttli - blokuj przez firewall.

"Disconnect: Outdated client/server"

[INFO]: Disconnect: com.mojang.authlib.GameProfile@... (Outdated client! Please use 1.20.4)

Gracz probuje wejsc na zlej wersji. Jesli takich wpisow jest duzo z jednego IP - to moze byc skaner przeczesujacy wersje protokolu.

OutOfMemoryError

[FATAL]: java.lang.OutOfMemoryError: Java heap space

Skonczyla sie pamiec. Sprawdz flagi startowe - ile pamieci przydzielono serwerowi przez -Xmx. Uzyj poprawnych flag JVM. Moze tez byc wyciek pamieci w pluginie - plugin tworzy obiekty i nie zwalnia ich.

"IOException: Connection reset by peer"

[WARN]: IOException: Connection reset by peer

Klient zerwal polaczenie. Zwykle nieszkodliwe - gracz wylecial albo zamknal gre. Ale jesli masowo - moze byc atak. Sprawdz, z jakich IP przychodza te zerwania.

"Moved too quickly!"

[WARN]: Player_Steve moved too quickly! (23.45, 0.0, 18.76)

Gracz przemiescil sie za szybko. Albo lag, albo cheater uzywa speed-hack. Pojedyncze przypadki - normalne (lagi). Jesli jeden gracz stale dostaje takie ostrzezenia - warto sprawdzic.

Crash reporty

Crash raporty sa bardziej informacyjne niz zwykle logi. Otworz plik z crash-reports/ - jest strukturyzowany na sekcje:

---- Minecraft Crash Report ----

Time: 2026-03-25 15:14:32
Description: Exception in server tick loop

java.lang.OutOfMemoryError: Java heap space
    at net.minecraft.nbt.CompoundTag.copy(CompoundTag.java:265)
    ...

-- System Details --
Minecraft Version: 1.20.4
Operating System: Linux (amd64) version 5.15.0
Java Version: 17.0.9
Memory: 234217728 bytes / 8589934592 bytes
Plugins:
  EssentialsX v2.20.1
  WorldGuard v7.0.9
  ShopPlugin v2.1
  ...

-- World Details --
Loaded chunks: 4521
Entities: 18432

Na co zwracac uwage:

1. Description - krotki opis przyczyny padu
2. Stack trace - gdzie dokladnie wystapil blad
3. Memory - ile pamieci uzyto vs dostepne. Jesli uzyto blisko maksimum - OOM
4. Entities - jesli liczba jest ogromna (10000+), mozliwe, ze to przyczyna
5. Plugins - lista zaladowanych pluginow. Jesli w stack trace wspomniany jest jeden z nich - to glowny podejrzany

Thread dumpy

Thread dump to snapshot wszystkich watkow serwera w konkretnym momencie. Przydatne, gdy serwer "zawisl" - nie pada, ale nie odpowiada.

Na serwerach Paper:

/paper dump threads

Albo przez sygnal kill:

kill -3 $(cat server.pid)
# lub
jstack $(cat server.pid) > thread_dump.txt

W thread dumpie szukaj watkow w stanie BLOCKED lub WAITING. Jesli Server thread jest zablokowany - serwer wisi. Patrz, na jakim wywolaniu zawisnal:

"Server thread" #1 prio=5 os_prio=0 tid=0x00007f... nid=0x1a23 waiting for monitor entry
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.example.plugin.Database.query(Database.java:156)
    - waiting to lock <0x000000076ab8c120>
    at com.example.plugin.Handler.onEvent(Handler.java:42)

Widac, ze glowny watek jest zablokowany na zapytaniu do DB w jakims pluginie. Plugin robi synchroniczne zapytanie do bazy danych w glownym watku - klasyczny blad, ktory wiesza caly serwer.

Szukanie sladow wlamania w logach

Logi to twoj system bezpieczenstwa. Jesli ktos probuje wlamac sie na serwer, slady zostaja. Oto co szukac:

Podejrzane komendy

grep -i "issued server command" logs/latest.log | grep -i "op\|deop\|ban\|perm\|gamemode\|give"

Szukamy, kto wykonywal komendy administracyjne. Jesli gracz, ktory nie powinien byc operatorem, nagle wykonuje /op albo /gamemode - to wlamanie.

Proby eksploitow

# Szukanie podejrzanie dlugich wiadomosci (mozliwy book exploit)
grep "AsyncChat" logs/latest.log | awk '{if(length($0) > 500) print}'

# Szukanie prob uzycia komend serwerowych przez czat
grep -i "selector\|@a\|@e\|@r\|@p" logs/latest.log

Masowe polaczenia

# Kto laczyl sie najczesciej
grep "logged in with entity" logs/latest.log | awk -F'[/:]' '{print $2}' | sort | uniq -c | sort -rn | head 20

Jesli jeden nick albo IP wchodzi setki razy - to bot albo atak. Warto skonfigurowac ochrone przed botami.

Niezwykla aktywnosc noca

# Co dzialo sie miedzy 3:00 a 5:00
grep "^\[0[3-4]:" logs/latest.log | grep -v "INFO.*save\|INFO.*Saving"

Jesli noca, gdy nikt nie gra, dzieje sie cos dziwnego - warto sprawdzic.

Wiecej o bezpieczenstwie: checklista bezpieczenstwa serwera Minecraft i monitoring atakow.

Przydatne komendy grep

Grep to twoj najlepszy przyjaciel przy analizie logow. Zestaw komend, ktorych uzywam stale:

# Wszystkie bledy z ostatniej sesji
grep "ERROR\|FATAL" logs/latest.log

# Bledy konkretnego plugina
grep "PluginName" logs/latest.log | grep -i "error\|exception\|warn"

# Ile razy kazdy poziom wystepuje
grep -c "INFO\]" logs/latest.log
grep -c "WARN\]" logs/latest.log
grep -c "ERROR\]" logs/latest.log

# Kto wchodzil na serwer
grep "joined the game\|left the game" logs/latest.log

# Wszystkie komendy wykonane przez graczy
grep "issued server command" logs/latest.log

# Bledy w archiwalnych logach
zgrep "ERROR" logs/2026-03-*.log.gz

# Ostatnie 50 bledow z kontekstem (3 linie przed i po)
grep -n "ERROR" logs/latest.log | tail -50
grep -B3 -A3 "ERROR" logs/latest.log | tail -100

# Szukanie w kilku plikach naraz
zgrep -l "OutOfMemoryError" logs/*.log.gz

Monitoring w czasie rzeczywistym

# Sledzenie loga na zywo
tail -f logs/latest.log

# Tylko bledy w czasie rzeczywistym
tail -f logs/latest.log | grep --line-buffered "ERROR\|WARN\|FATAL"

# Z podswietleniem (jesli masz ccze)
tail -f logs/latest.log | ccze -A

Timings i raporty spark

Do analizy wydajnosci same logi nie wystarcza. Timings (przestarzaly) i spark (nowoczesny) daja szczegolowy obraz tego, co serwer robi kazdy tick.

Raport spark pokazuje:

• Ktore pluginy ile czasu zajmuja
• Gdzie dokladnie idzie czas CPU
• Stan pamieci i pauzy GC
• Konkretne metody spowalniajace

/spark profiler start
# poczekaj 3-5 minut
/spark profiler stop

spark stworzy link do raportu www. Otworz i szukaj najciezszych galezi. Wiecej o profilowaniu w artykule o diagnostyce lagow.

Rotacja i przechowywanie logow

Domyslnie Minecraft trzyma archiwalne logi wiecznie. Na dlugo zyjacym serwerze to gigabajty. Skonfiguruj rotacje:

# Skrypt usuwania starych logow (starszych niz 30 dni)
find /path/to/server/logs -name "*.log.gz" -mtime +30 -delete

Dodaj do crona:

0 4 * * 0 find /path/to/server/logs -name "*.log.gz" -mtime +30 -delete

Ale nie kasuj logow za wczesnie - moga sie przydac do dochodzenia w sprawie incydentow. 30 dni to rozsadne minimum. Jesli miejsce pozwala - trzymaj 90 dni.

Automatyzacja analizy

Zamiast recznie parsowac co dzien mozna napisac prosty skrypt:

#!/bin/bash
LOG="logs/latest.log"

echo "=== Server Log Summary ==="
echo "Errors:   $(grep -c 'ERROR\]' $LOG)"
echo "Warnings: $(grep -c 'WARN\]' $LOG)"
echo "Fatals:   $(grep -c 'FATAL\]' $LOG)"
echo ""
echo "=== Top Errors ==="
grep 'ERROR\]' $LOG | sed 's/\[.*ERROR\]: //' | sort | uniq -c | sort -rn | head -10
echo ""
echo "=== Player Activity ==="
echo "Joins:  $(grep -c 'joined the game' $LOG)"
echo "Leaves: $(grep -c 'left the game' $LOG)"
echo ""
echo "=== Overload Warnings ==="
grep -c "Can't keep up" $LOG

Odpalaj rano - w minute zobaczysz obraz z nocy.

Do powazniejszego monitoringu uzywaj specjalizowanych narzedzi. O tym, jak skonfigurowac pelnoprawny monitoring, czytaj w naszym artykule o monitoringu serwera Minecraft.

Podsumowanie

Logi to nie tylko pliki tekstowe zjadajace miejsce na dysku. To twoja czarna skrzynka, twoj detektyw, twoje zrodlo prawdy.

Minimum, ktore powinien robic kazdy administrator:

1. Sprawdzac logi po kazdym restarcie - zobacz, czy nie ma bledow
2. Monitorowac ERROR i FATAL - zawsze wymaga uwagi
3. Analizowac crash raporty - zawieraja cale info do diagnostyki
4. Okresowo sprawdzac logi pod katem bezpieczenstwa - szukac podejrzanych komend i masowych polaczen
5. Skonfigurowac rotacje - zeby dysk sie nie przepelnil
6. Nauczyc sie podstawowych komend grep - to zaoszczedzi godziny czasu

Nie czekaj, az gracze przyjda z zazaleniami. Czytaj logi proaktywnie - wiekszosc problemow zostawia slady na dlugo przed tym, jak staja sie krytyczne.