Minecraft Server-Logs lesen und analysieren

Der Server ist um 3 Uhr nachts abgestuerzt. Spieler schreiben: "Alles hat gefreezed und dann wurden wir gekickt." Am naechsten Morgen loggt ihr euch ein, und der Server laeuft - der Watchdog hat ihn neugestartet. Was ist passiert? Ohne Logs werdet ihr es nie erfahren.

Logs sind die einzige zuverlaessige Informationsquelle darueber, was auf eurem Server passiert. Nicht "ich glaube," nicht "vielleicht ist das Plugin kaputt," sondern konkrete Eintraege mit exaktem Zeitstempel, Schweregrad und Problembeschreibung. Wenn ihr einen Minecraft Server betreibt und keine Logs lesen koennt - arbeitet ihr blind.

In diesem Artikel behandeln wir alles: wo Logs gespeichert werden, wie Eintraege formatiert sind, was Log-Level bedeuten, wie man typische Probleme erkennt und wie man die Analyse automatisiert.

Wo Logs gespeichert werden

latest.log

Die Hauptdatei ist logs/latest.log im Server-Stammverzeichnis. Alles seit dem letzten Start wird hier geschrieben. Bei jedem Neustart wird die vorherige latest.log komprimiert und archiviert.

server/
├── logs/
│   ├── latest.log              <-- aktuelle Sitzung
│   ├── 2026-03-25-1.log.gz     <-- gestriges Log (komprimiert)
│   ├── 2026-03-24-1.log.gz
│   ├── 2026-03-24-2.log.gz     <-- falls Server zweimal neugestartet wurde
│   └── ...
├── crash-reports/
│   └── crash-2026-03-25-server.txt
└── ...

Archive werden als gzip gespeichert. Um ein altes Log zu lesen:

# Komprimiertes Log anzeigen
zcat logs/2026-03-25-1.log.gz | less

# In komprimiertem Log suchen
zgrep "ERROR" logs/2026-03-25-1.log.gz

crash-reports/

Wenn der Server mit einem fatalen Fehler abstuerzt, erstellt er eine Datei in crash-reports/. Das ist nicht dasselbe wie ein normales Log - ein Crash-Report enthaelt einen detaillierten Snapshot des Serverzustands zum Zeitpunkt des Absturzes: Stack Trace, geladene Plugins, Systeminfos, Speicherzustand.

Dateinamen enthalten Datum und Uhrzeit: crash-2026-03-25-151432-server.txt.

debug/

Auf Paper-Servern gibt es ein debug/-Verzeichnis, in das Thread Dumps und andere Diagnosedaten geschrieben werden. Dazu weiter unten mehr.

Format eines Log-Eintrags

Jede Zeile im Log folgt einem Standardformat:

[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

Aufgeschluesselt:

• [15:42:01] - Zeitstempel (HH:MM:SS)
• [Server thread/INFO] - Thread-Name und Log-Level
• Text nach : - die eigentliche Nachricht

Der Thread ist wichtig. Server thread ist der Haupt-Tick-Thread, der die gesamte Spiellogik ausfuehrt. Wenn ein Fehler in Async Chat Thread oder Netty Epoll Server IO auftritt, ist das eine andere Geschichte mit anderen Ursachen.

Log-Level

INFO

Normale Informationsmeldungen. Spielerverbindungen, Plugin-Laden, Welt-Speichern. Das macht 95% eures Logs aus.

[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"

INFO-Meldungen koennen bei der Fehlersuche meist ignoriert werden. Aber manchmal verstecken sich nuetzliche Infos genau hier - zum Beispiel koennen Plugin-Ladezeiten zeigen, welches den Start verlangsamt.

WARN

Warnungen. Der Server ist auf etwas Unerwuenschtes gestossen, laeuft aber weiter.

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

Die beruehmteste Minecraft-Warnung. Sie bedeutet, dass der Server Ticks nicht rechtzeitig verarbeiten kann. Gelegentliches Auftreten ist okay. Alle paar Sekunden bedeutet ein ernstes Performance-Problem.

Andere haeufige WARNs:

[WARN]: Ambiguity between arguments [...]  -- Kommando-Mehrdeutigkeit, harmlos
[WARN]: UUID of player X is ...             -- UUID-Probleme, oft bei offline-mode
[WARN]: Connection throttled: 192.168.1.50  -- zu viele Verbindungen von einer IP

ERROR

Fehler. Etwas ist kaputtgegangen. Ein Plugin ist abgestuerzt, eine Welt konnte nicht geladen werden, eine Config ist ungueltig.

[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)

Das erfordert Aufmerksamkeit. ERROR braucht immer Untersuchung. Nach der ERROR-Zeile folgt normalerweise ein Stack Trace - die Aufrufkette, die zum Fehler gefuehrt hat. Wie man ihn liest, behandeln wir weiter unten.

FATAL

Kritischer Fehler, der den Server normalerweise stoppt. Selten, aber wenn ihr FATAL seht, ist es ernst.

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

Speichermangel, beschaedigte Weltdaten, Bugs im Server-Core - all das kann FATAL ausloesen.

Stack Traces lesen

Ein Stack Trace ist die Kette von Methodenaufrufen, die zum Fehler gefuehrt hat. Man liest ihn von oben nach unten, aber die Ursache sucht man von unten nach oben.

[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)

So liest man ihn:

1. Erste Zeile - was passiert ist: "Could not pass event PlayerInteractEvent to ShopPlugin." Problem liegt im ShopPlugin bei der Verarbeitung eines Spielerklicks.

2. "Caused by" - die tatsaechliche Ursache. NullPointerException: Cannot invoke "getType()" because "item" is null. Das Plugin versucht den Item-Typ zu bekommen, aber das Item ist null.

3. Die Zeile mit eurem Plugin - ShopListener.java:78. Das ist Zeile 78 in ShopListener.java. Wenn es euer Plugin ist, geht diese Zeile fixen. Wenn es von jemand anderem ist, erstellt ein Issue auf GitHub oder sucht nach einem Update.

Zeilen von org.bukkit, net.minecraft, java.lang und sun.reflect sind Server- und Java-Interna. Sie sind normalerweise nicht die Ursache - sie zeigen nur den Ausfuehrungspfad.

Typische Fehler und was man tut

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

Bereits oben erwaehnt. Der Server faellt hinter die normalen 20 Ticks pro Sekunde zurueck. Ursachen:

• Zu viele Entities
• Schweres Plugin im Hauptthread
• Zu wenig RAM und haeufige GC-Pausen
• Langsame Festplatte (SSD ist Pflicht fuer Server)

Detaillierte Lag-Diagnose in unserem Server-Lag-Guide.

"Connection throttled"

[WARN]: Connection throttled: 185.220.101.34

Jemand verbindet sich zu haeufig. Kann ein Bot sein, kann eine DDoS-Attacke auf Anwendungsebene sein. Wenn ihr eine IP mit Hunderten von Throttles seht, blockiert sie ueber eure Firewall.

"Disconnect: Outdated client/server"

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

Spieler versucht mit falscher Version beizutreten. Wenn viele solcher Eintraege von einer IP kommen, ist es wahrscheinlich ein Scanner, der Protokollversionen durchprobiert.

OutOfMemoryError

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

Speicher voll. Prueft eure Startflags - wie viel Speicher ueber -Xmx zugewiesen ist. Nutzt richtige JVM-Flags. Kann auch ein Memory Leak in einem Plugin sein - das Plugin erstellt Objekte und gibt sie nie frei.

"IOException: Connection reset by peer"

[WARN]: IOException: Connection reset by peer

Client hat die Verbindung abgebrochen. Normalerweise harmlos - Spieler abgestuerzt oder Spiel geschlossen. Aber wenn es massenhaft passiert, koennte es eine Attacke sein. Prueft, von welchen IPs diese Verbindungsabbrueche kommen.

"Moved too quickly!"

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

Spieler hat sich schneller bewegt als erwartet. Entweder Lag oder ein Cheater mit Speed-Hack. Einzelfaelle sind normal (Lag). Wenn ein Spieler das dauerhaft ausloest, sollte man nachschauen.

Crash-Reports

Crash-Reports enthalten mehr Details als normale Logs. Oeffnet eine Datei aus crash-reports/ - sie ist in Abschnitte gegliedert:

---- 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

Worauf ihr achten muesst:

1. Description - kurze Zusammenfassung der Absturzursache
2. Stack Trace - wo genau der Fehler aufgetreten ist
3. Memory - wie viel verwendet vs verfuegbar. Wenn die Nutzung nahe am Maximum liegt - OOM
4. Entities - wenn die Zahl riesig ist (10000+), koennte das die Ursache sein
5. Plugins - Liste geladener Plugins. Wenn der Stack Trace eines erwaehnt, ist das der Hauptverdaechtige

Thread Dumps

Ein Thread Dump ist ein Snapshot aller Server-Threads zu einem bestimmten Zeitpunkt. Nuetzlich wenn der Server "haengt" - nicht abstuerzt, aber auch nicht reagiert.

Auf Paper-Servern:

/paper dump threads

Oder ueber kill-Signal:

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

Im Thread Dump sucht ihr nach Threads im Zustand BLOCKED oder WAITING. Wenn Server thread blockiert ist, haengt der Server. Schaut euch an, bei welchem Aufruf er feststeckt:

"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)

Hier sieht man, dass der Hauptthread bei einer Datenbankabfrage in irgendeinem Plugin blockiert ist. Das Plugin macht einen synchronen Datenbankaufruf im Hauptthread - ein klassischer Fehler, der den gesamten Server aufhaengt.

Hack-Versuche in Logs erkennen

Logs sind euer Sicherheitssystem. Wenn jemand versucht den Server zu kompromittieren, bleiben Spuren zurueck. Hier ist, wonach ihr suchen muesst:

Verdaechtige Befehle

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

Findet heraus, wer Admin-Befehle ausgefuehrt hat. Wenn ein Spieler, der kein Operator sein sollte, ploetzlich /op oder /gamemode ausfuehrt, ist das ein Einbruch.

Exploit-Versuche

# Nach verdaechtig langen Nachrichten suchen (moeglicher Book-Exploit)
grep "AsyncChat" logs/latest.log | awk '{if(length($0) > 500) print}'

# Nach Versuchen suchen, serverseitige Selektoren ueber den Chat zu verwenden
grep -i "selector\|@a\|@e\|@r\|@p" logs/latest.log

Massenverbindungen

# Wer hat sich am haeufigsten verbunden
grep "logged in with entity" logs/latest.log | awk -F'[/:]' '{print $2}' | sort | uniq -c | sort -rn | head 20

Wenn ein Nick oder eine IP sich hunderte Male einloggt, ist es ein Bot oder eine Attacke. Richtet Rate Limiting ein.

Ungewoehnliche Nachtaktivitaet

# Was ist zwischen 3:00 und 5:00 Uhr passiert
grep "^\[0[3-4]:" logs/latest.log | grep -v "INFO.*save\|INFO.*Saving"

Wenn nachts, wenn niemand spielt, etwas Ungewoehnliches passiert, solltet ihr dem nachgehen.

Mehr zur Sicherheit: Minecraft Server Sicherheits-Checkliste und Angriffs-Monitoring.

Nuetzliche grep-Befehle

Grep ist euer bester Freund bei der Log-Analyse. Hier sind die Befehle, die ich staendig verwende:

# Alle Fehler der aktuellen Sitzung
grep "ERROR\|FATAL" logs/latest.log

# Fehler eines bestimmten Plugins
grep "PluginName" logs/latest.log | grep -i "error\|exception\|warn"

# Anzahl jedes Log-Levels zaehlen
grep -c "INFO\]" logs/latest.log
grep -c "WARN\]" logs/latest.log
grep -c "ERROR\]" logs/latest.log

# Wer hat sich auf dem Server eingeloggt
grep "joined the game\|left the game" logs/latest.log

# Alle Befehle, die Spieler ausgefuehrt haben
grep "issued server command" logs/latest.log

# Fehler in archivierten Logs
zgrep "ERROR" logs/2026-03-*.log.gz

# Letzte 50 Fehler mit Kontext (3 Zeilen davor und danach)
grep -n "ERROR" logs/latest.log | tail -50
grep -B3 -A3 "ERROR" logs/latest.log | tail -100

# Finden, welche archivierten Logs OOM-Fehler enthalten
zgrep -l "OutOfMemoryError" logs/*.log.gz

Echtzeit-Monitoring

# Log live verfolgen
tail -f logs/latest.log

# Nur Fehler in Echtzeit
tail -f logs/latest.log | grep --line-buffered "ERROR\|WARN\|FATAL"

# Mit Farbhervorhebung (wenn ccze installiert ist)
tail -f logs/latest.log | ccze -A

Timings und spark-Reports

Fuer Performance-Analyse reichen Logs allein nicht. Timings (veraltet) und spark (modern) geben ein detailliertes Bild davon, was der Server bei jedem Tick macht.

Ein spark-Report zeigt:

• Wie viel Zeit jedes Plugin beansprucht
• Wo CPU-Ressourcen verbraucht werden
• Speicherzustand und GC-Pausen
• Konkrete Methoden, die bremsen

/spark profiler start
# 3-5 Minuten warten
/spark profiler stop

spark generiert einen Link zu einem Web-Report. Oeffnet ihn und sucht nach den schwersten Aesten. Mehr zum Profiling in unserem Lag-Diagnose-Artikel.

Log-Rotation und Speicherung

Standardmaessig speichert Minecraft alle archivierten Logs fuer immer. Auf einem lang laufenden Server sind das Gigabytes. Richtet Rotation ein:

# Skript zum Loeschen alter Logs (aelter als 30 Tage)
find /path/to/server/logs -name "*.log.gz" -mtime +30 -delete

In cron eintragen:

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

Aber loescht Logs nicht zu frueh - ihr koenntet sie fuer die Untersuchung von Vorfaellen brauchen. 30 Tage sind ein vernuenftiges Minimum. Wenn der Speicherplatz es erlaubt, behaltet 90 Tage.

Analyse automatisieren

Statt jeden Tag manuell Logs zu parsen, koennt ihr ein einfaches Skript schreiben:

#!/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

Morgens ausfuehren - in unter einer Minute seht ihr das Bild der Nacht.

Fuer ernsthafteres Monitoring nutzt dedizierte Tools. Wie man vollstaendiges Monitoring einrichtet, lest ihr in unserem Artikel zum Server-Monitoring.

Zusammenfassung

Logs sind nicht einfach Textdateien, die Speicherplatz fressen. Sie sind eure Black Box, euer Detektiv, eure Quelle der Wahrheit.

Das Minimum, das jeder Admin tun sollte:

1. Logs nach jedem Neustart pruefen - schaut nach Fehlern
2. ERROR und FATAL monitoren - das braucht immer Aufmerksamkeit
3. Crash-Reports analysieren - sie enthalten alles fuer die Diagnose
4. Logs regelmaessig auf Sicherheit pruefen - sucht nach verdaechtigen Befehlen und Massenverbindungen
5. Rotation einrichten - damit die Festplatte nicht volllaeuft
6. Grundlegende grep-Befehle lernen - das spart Stunden

Wartet nicht, bis Spieler sich beschweren. Lest eure Logs proaktiv - die meisten Probleme hinterlassen Spuren, lange bevor sie kritisch werden.