Bei einer Störung explodiert die Logmenge, und Server, die Logs synchron weitergeben, werden durch das Logging noch langsamer.
Warum Fehler treten auf, das Volumen von Logs und Metriken schießt hoch → Folge Log-Collector kommt nicht nach, Server mit synchronem Versand warten → Auf dem Bildschirm Ruckeln und Freezes während der Störung werden durch das Logging verstärkt
Kapazität des Log-Collectors auf das Spitzenvolumen bei Störungen auslegen, Alarm bei Rückstau im Collector.
Im Graphen
Vereinzelte Spitzen ohne Muster · Logvolumen, Warteschlange des Log-Collectors
Wo nachsehen
Logzeilen und Bytes pro Sekunde auf dem Server sowie Warteschlange und verworfene Einträge des Log-Agents zusammen mit der Tick-Zeit auswerten. Bei hängenden Threads mit bcc offcputime -p prüfen, ob sie beim Schreiben oder Versenden von Logs warten
Spricht dafür
Zum Zeitpunkt der Tick-Spitze steigt die Logmenge um einen zweistelligen Faktor über den Normalwert, und die Wartezeit des Game-Threads konzentriert sich auf Call-Stacks des Log-Schreibens und -Versands
Spricht dagegen
Logmenge normal oder Game-Thread wartet nicht beim Logging: Die Log-Flut ist nur eine Folge der Störung, die Ursache des ersten Fehlers gesondert suchen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
Logging in C#Microsoft .NET-Logmethoden sind synchron. Bei langsamem Speicherziel wird empfohlen, zuerst in einen schnellen Speicher zu schreiben und später zu verschieben
Asynchronous loggersApache Software Foundation Asynchrones Logging fängt kurze Spitzen mit einer Queue ab. Bleibt die Ausgabe dauerhaft langsam, füllt sich die Queue, und das Tempo fällt auf das der langsamsten Ausgabe zurück, oder Logs werden je nach Richtlinie verworfen (Discard)