Logy herních serverů: kde je najdeš a co v nich hledat

Každý herní server píše dva druhy záznamů: výstup konzole, který vidíš běžet v panelu, a jeden či více logovacích souborů na disku, které přežijí restart. Když se něco pokazí, chceš soubor, protože konzole obsahuje jen to, co se stalo od posledního startu. Kde soubor leží, závisí hlavně na enginu, na kterém je hra postavená - servery Minecraftu a další servery v Javě píšou logs/latest.log, hry na Unreal Engine píšou do <Project>/Saved/Logs/, hry na Source nepíšou vůbec nic, dokud logování nezapneš, a hry na Unity píšou tam, kam ukazuje -logFile. Jakmile soubor znáš, hledání je krátké: první ERROR nebo Exception po úvodním banneru startu a hrstka konkrétních řetězců, z nichž každý znamená jedinou věc.

Tento článek je mapa: kde který běžný titul drží své logy, na kterých souborech záleží a co hledat. Jak dlouho je uchovávat a jak je rotovat, je samostatné rozhodnutí popsané v článku logy, které stojí za uchování, a umění číst stack trace, až ho najdeš, je v článku jak číst konzoli serveru.

Konzole a logovací soubor nejsou totéž#

V panelu typu Pterodactyl je konzole, kterou vidíš v prohlížeči, standardní výstup herního procesu přenášený živě. Je to nejrychlejší pohled na to, co se děje právě teď, a má dvě omezení:

• Při každém bootu začíná znovu. Po pádu a restartu zmizí výstup pádu ze živého pohledu a nahradí ho nový start.
• Nemusí obsahovat všechno. Mnoho her píše některé řádky jen do souboru - podrobné chyby, chat, akce adminů - a do konzole vypíše shrnutí, nebo nic.

Logovací soubor na disku je trvalý záznam. Většina her při každém bootu založí nový a ten předchozí si ponechá pod jiným názvem, takže soubor, který po pádu potřebuješ, obvykle není aktuální, ale ten před ním. Jen tento detail vysvětluje velkou část hlášení „v logu nic není“: dotyčný otevřel log zdravého restartu, ne log pádu.

Na RE:NODE konzole ukazuje nefiltrovaný živý výstup s příkazovou řádkou a historií a ke každému logovacímu souboru se dostaneš přes správce souborů nebo SFTP. Pokud potřebuješ prohledat velký soubor, je často rychlejší ho stáhnout a hledat lokálně, než listovat v prohlížeči.

Kde logy jsou, podle enginu#

Většina her zdědí logování od enginu, na kterém je postavená, takže umístění je předvídatelné, jakmile engine znáš.

Java: Minecraft a jeho proxy

Paper, Purpur, Velocity, BungeeCord, Forge, NeoForge i Fabric se drží tohoto uspořádání. Pluginy často vedou vlastní logy v plugins/<Name>/ a CoreProtect drží historii bloků v databázi, ne v logu. Crash report je v Minecraftu nejužitečnější jediný soubor - jmenuje vlákno, výjimku a obvykle i mód nebo plugin.

Engine Source: CS2, TF2, Garry's Mod, CS 1.6

Servery na Source si na disk ukládají ve výchozím stavu velmi málo. Změní to dva přepínače:

• log on v server.cfg (nebo v konzoli) zapisuje události - připojení, chat, zabití, kola - do složky logs/ ve složce hry, jeden soubor na každou změnu mapy pojmenovaný L<MMDD><NNN>.log.
• -condebug na spouštěcím řádku kopíruje veškerý výstup konzole do console.log ve složce hry. Užitečné při honění pádu, jako trvalé nastavení příliš hlučné.

SourceMod přidává vlastní logy v addons/sourcemod/logs/: errors_<date>.log pro chyby pluginů, což je první soubor k otevření na zlobícím modovaném serveru, a L<date>.log pro akce adminů. AMX Mod X na CS 1.6 dělá totéž v addons/amxmodx/logs/. Metamod a CounterStrikeSharp na CS2 logují do konzole a do vlastních složek pod addons/.

Unreal Engine: Palworld, Satisfactory, The Isle, Abiotic Factor

Servery na Unreal píšou do <Project>/Saved/Logs/<Project>.log a při startu přejmenují předchozí běh na <Project>-backup-<timestamp>.log. Palworld ho má v Pal/Saved/Logs/, Satisfactory v FactoryGame/Saved/Logs/FactoryGame.log. Fatální pády také zanechají složku v <Project>/Saved/Crashes/ s minidumpem a kopií logu. Řádky logu Unrealu jsou označené kategorií, například LogNet, LogWorld nebo LogOnline, což je nejlepší způsob, jak zúžit hledání.

Unity: Valheim, Rust, 7 Days to Die, Unturned, SCP: Secret Laboratory

Servery na Unity píšou tam, kam ukazuje argument -logFile, nebo na standardní výstup, když chybí či je nastaven na - (chování se mezi verzemi Unity lišilo). Bez obojího je výchozí umístění na Linuxu ~/.config/unity3d/<Company>/<Product>/Player.log. V praxi:

• Valheim vypisuje do konzole ve výchozím stavu; přidej -logFile, chceš-li uchovat soubor.
• Rust se běžně spouští s -logfile určujícím soubor a Oxide nebo Carbon přidávají oxide/logs/ nebo carbon/logs/ s chybami pluginů.
• Výchozí spouštěcí skript 7 Days to Die předává -logfile s datovaným názvem, takže každý běh dostane vlastní soubor output_log ve složce dat serveru. Hromadí se - viz místo na disku.

Logy Unity jsou upovídané a na headless serveru často plné neškodných varování o shaderech a assetech. Užitečné řádky obsahují Exception a nejužitečnější částí výjimky je první řádek stack trace, který jmenuje něco jiného než UnityEngine.

Bohemia: DayZ a Arma 3

DayZ a Arma 3 píšou do složky profilů zadané přes -profiles=. Soubory, na kterých záleží:

Nový .RPT vzniká při každém spuštění a nikdo je nemaže, takže složka profilů je častým důvodem, proč se u DayZ zaplní disk. -nologs vypne výstup RPT úplně; užitečné jen tehdy, když jsi si jistý, že ho nikdy nebudeš potřebovat, což u DayZ nenastane. Co čte soubor .ADM, popisuje administrátorské nástroje DayZ a BattlEye RCON.

Hry s vlastním uspořádáním

Složka Logs/ v Project Zomboid je mimořádně dobrá: samostatné soubory pro chat, příkazy adminů, připojení hráčů, události s předměty a PvP, takže je to nejlépe vybavená hra z uvedených pro řešení sporů.

Co hledat jako první#

Log o 40 000 řádcích nečteš, prohledáváš ho. Postup, který funguje skoro vždy:

1. Úvodní banner startu. Najdi poslední start serveru - v Minecraftu Starting minecraft server version, v Unrealu první řádky LogInit, u Source číslo buildu. Všechno nad ním je předchozí běh.
2. První chyba po něm. Hledej ERROR, Exception, FATAL nebo Error: a vezmi první shodu po banneru, ne poslední shodu v souboru.
3. Poslední řádky před koncem. Pokud soubor končí náhle bez zprávy o vypnutí, proces byl zabit zvenčí - pamětí, tlačítkem kill nebo hostingem - a log to nevysvětlí.

Pak konkrétní řetězce, které mají větší cenu než jakékoli obecné hledání, protože každý má jediný význam:

Ke každému z nich je někde na tomto blogu sekce, ale jde o to, že log jako celek málokdy potřebuješ chápat - stačí poznat jeden řádek.

Hledání v lozích s shellem i bez něj#

S shellem - na vlastním stroji, na VDS nebo ve stažené kopii logů - odvede práci grep:

# first errors in the current Minecraft log, with line numbers$ grep -n -E "ERROR|Exception" logs/latest.log | head -20# the same across every compressed older log$ zgrep -l "OutOfMemoryError" logs/*.log.gz# five lines of context around each match$ grep -n -C 5 "Segmentation fault" console.log# follow a log as it is written$ tail -f Pal/Saved/Logs/Pal.log

zgrep čte soubory .gz přímo, takže týdenní logy Minecraftu nemusíš rozbalovat, abys v nich hledal. -l vypíše jen názvy souborů, které odpovídají, což je nejrychlejší způsob, jak zjistit, který den něco začalo.

Bez shellu - což je v panelu běžný případ - zbývá správce souborů a SFTP. Malý log otevři v editoru správce souborů a použij hledání v prohlížeči; cokoli velkého nebo komprimovaného stáhni přes SFTP a hledej na vlastním stroji. Každý slušný textový editor prohledá soubor o 100 MB a většina umí otevřít soubory .gz nebo je po rozbalení otevře. Připojení popisuje SFTP a správce souborů.

Logy, které nejsou logy: chat, admin a auditní záznamy#

Několik souborů výše se netýká ani tak chyb jako lidí. Výstup log on u Source, .ADM u DayZ, logy chatu a adminů v Zomboidu, admin log SourceModu a řádky chatu v latest.log Minecraftu jsou záznamem toho, kdo co udělal. Záleží na nich, když hráč tvrdí, že dostal nespravedlivý ban, když je zničená základna a nikdo se nepřiznává, nebo když admin účet použil někdo, kdo neměl.

Dvě praktické poznámky:

• Zapni je dřív, než je budeš potřebovat. -adminlog u DayZ a log on u her na Source jsou vypnuté, dokud o ně nepožádáš, a log zabití z minulého týdne po události nezrekonstruuješ.
• Obsahují osobní údaje. IP adresy, Steam ID a chat jsou podle GDPR osobní údaje. Uchovávej je tak dlouho, jak moderace potřebuje, ne navždy, a omez, kdo z týmu je smí číst. Na RE:NODE ti oprávnění subuserů umožní dát moderátorovi přístup ke konzoli bez přístupu k souborům, nebo k souborům bez fakturace.

Moderaci serveru postavenou na těchto lozích popisuje pravidla serveru, moderace a tým.

Přitvrzení logování a zase zpět#

Když je problém těžké určit, pomůže chvíli víc logování. Každý engine na to má způsob:

• Minecraft: pluginy mívají v konfiguraci možnost debug: true; Paper nahradil starý systém /timings pluginem spark, který novější buildy zahrnují - ale spark je profiler, ne log.
• Source: -condebug a log on jak je uvedeno výše; developer 1 vypisuje do konzole víc.
• Unreal: podrobnost logu podle kategorie, nastavená přes -LogCmds="LogNet Verbose" na příkazové řádce nebo v DefaultEngine.ini pod [Core.Log].
• Factorio: --console-log pro soubor s konzolí multiplayeru.
• BepInEx: BepInEx/config/BepInEx.cfg nastavuje úrovně logů zapisovaných do LogOutput.log a do konzole.

Potom je zase sniž. Podrobné logování na vytíženém serveru zapíše gigabajty týdně, zaplní disky a zpomalí server, který má diagnostikovat, protože zápis na disk není zadarmo na hlavním vlákně hry, která loguje synchronně.

Kde log nepomůže#

Některá selhání nezanechají stopu v žádném logu, který hra píše:

• Zastavení kvůli nedostatku paměti. Jádro ukončí proces zvenčí, takže hra nestihne napsat ani řádek. Log prostě skončí. Důkazem je graf paměti v panelu; jak vypadá jeho tvar, ukazuje čtení grafu zátěže serveru.
• Zabití z panelu nebo zastavení na úrovni hostingu. Stejný otisk: log končí uprostřed věty.
• Problémy sítě na straně hráče. Log serveru může ukázat timeout nebo důvod odpojení, ale ne proč jeho spojení spadlo.
• Lag. Pomalý server téměř nic nezapisuje, kromě Can't keep up v Minecraftu. Lag najde profiler, ne log - pro Minecraft viz profiler spark.

Když log končí bez chyby nebo zprávy o vypnutí, přestaň ho prohledávat a podívej se na grafy.

FAQ#

Kde je logovací soubor mého herního serveru?

Záleží na enginu. Servery v Javě používají logs/latest.log, servery na Unreal <Project>/Saved/Logs/, hry Bohemie složku profilů a hry na Unity to, co určuje -logFile. Hry na Source drží jen to, co zapneš přes log on nebo -condebug. Běžné hry vypisují tabulky výše.

Proč je log po pádu serveru prázdný?

Pravděpodobně čteš log restartu, který následoval po pádu. Hledej předchozí soubor: .gz v logs/ Minecraftu, soubor -backup- v Unrealu, starší datovaný soubor u Bohemie a 7 Days to Die. Pokud i ten končí bez chyby, proces byl zabit zvenčí.

Je bezpečné mazat staré logovací soubory?

Ano, při zastaveném serveru nebo u souborů, do kterých server právě nepíše. Logy hra ke svému běhu nikdy nepotřebuje. Poslední týden nebo dva si nech pro diagnostiku, a déle admin a chatové logy, pokud na nich stavíš moderaci.

Mohu si prohlížet logy z panelu bez stahování?

Ano, správce souborů otevře textové soubory v prohlížeči a konzole ukazuje živý výstup. U velkých nebo komprimovaných souborů je rychlejší stáhnout a hledat lokálně.

Proč se v mém logu objevují hesla?

Některé hry vypisují celý startovací řádek včetně hesel předaných jako argumenty a některé pluginy logují svůj connection string k databázi. Považuj logovací soubory za citlivé, před sdílením z nich odstraň tajné údaje a změň každé heslo, které se objevilo v logu zveřejněném veřejně.