Inhalt dieses Guides
Gameserver Monitoring sinnvoll aufbauen: Prozess, Port, Query/API, echter Join, Ressourcen, Speicherplatz, Backupalter und Latenz als abgestufte Healthchecks.
Server-Arbeitsmodus
Arbeite den Guide kontrolliert ab und ändere immer nur eine Variable. Dein Fortschritt bleibt nur in diesem Browser gespeichert.
Wo hängt dein Server gerade?
Netzwerkdiagnose bringt nichts, solange der Server lokal nicht sauber startet oder lauscht.
Wenn localhost/LAN funktioniert, liegt der nächste Prüfbereich bei Host-Firewall, Router, öffentlicher Adresse und NAT.
Bei Lag, Abstürzen oder Update-Problemen sind Logs, Ressourcen, Mods und ein sauberer Rollbackpfad wichtiger als weitere Portregeln.
Ein laufender Prozess kann trotzdem einen kaputten Gameserver darstellen. Der Prozess kann hängen, keine Ports mehr beantworten, Saves nicht schreiben oder alle Clients beim Join verlieren. Gute Healthchecks werden deshalb in Stufen aufgebaut.
Stufe 1: Prozess
Prüfe, ob der erwartete Dienst existiert und nicht ständig neu startet. Ein Systemd-Service oder Windows-Dienst kann „active“ anzeigen, obwohl die Anwendung intern Fehler produziert; Prozessstatus ist nur die erste Ebene.
Stufe 2: Port und Protokoll
Teste lokal, ob der konfigurierte Port gebunden ist. Bei TCP kann eine Verbindung geprüft werden, bei UDP sind anwendungsspezifische Querys aussagekräftiger als ein generischer Portcheck.
Stufe 3: Anwendungsantwort
Nutze vorhandene Serverquerys, APIs oder Metadatenendpunkte. FiveM bietet beispielsweise info.json. Andere Spiele besitzen Query-Protokolle oder Serverbrowser-Daten.
Stufe 4: echter Join / Smoke-Test
Für kritische Community-Server ist ein periodischer manueller oder automatisierter Smoke-Test sinnvoll. Nach Updates sollte mindestens ein echter Client joinen und eine persistente Aktion testen.
Ressourcen überwachen
CPU, RAM, Disk I/O und freier Speicher sind nicht nur Performancewerte. Eine volle SSD kann Save- oder Logfehler auslösen. Beobachte Trends, nicht nur starre Momentwerte.
Backup-Alter als Monitoring-Metrik
Ein Backupjob kann ohne Alarm wochenlang fehlschlagen. Prüfe daher Zeitstempel, Größe und letzten erfolgreichen Offsite-Upload. Kritische Abweichungen sollten einen Alert erzeugen.
Alerts so gestalten, dass sie ernst genommen werden
Ein Alarm für jede kurzzeitige CPU-Spitze erzeugt Alarmmüdigkeit. Nutze Dauer, Schwellen und mehrere Signale. Beispiel: „Serverport 5 Minuten nicht erreichbar“ ist meist hilfreicher als „CPU einmal 95 %“.
Monitoring schützt nicht vor fehlendem Restore
Verfügbarkeit und Wiederherstellbarkeit sind getrennte Ziele. Kombiniere Monitoring deshalb mit regelmäßigen Restore-Tests.
Extern und intern messen
Ein interner Check auf localhost erkennt keinen Ausfall von Router, Provider-Firewall oder öffentlicher Route. Ergänze daher mindestens einen externen Verfügbarkeitscheck. Umgekehrt hilft internes Monitoring, wenn nur die öffentliche Strecke gestört ist.
Speichere Metriken lange genug, um Muster zu erkennen: RAM wächst jede Nacht? Latenz steigt nach einem bestimmten Modupdate? Storage wird während Backups gesättigt? Trends liefern oft mehr Wert als einzelne Alarmereignisse.