Wir alle, die wir mit DSM arbeiten, sind sicherlich regelmäßige "Leser" der DSM Logfiles, von denen es ja jede Menge gibt. Die Schwierigkeit für Anfänger (und durchaus auch manchmal noch für Fortgeschrittene) beim Ergünden einer Problemursache besteht meistens nicht darin, das Problem im Logfile zu finden, sondern das richtige Logfile zu identifizieren, indem das (vermutete) Fehlverhalten protokolliert ist.

Obwohl ich doch jetzt schon ein paar Jahre DSM-Erfahrung auf dem Buckel habe, hat mir ein Kunde letztens ein paar Fragen zu Logfiles gestellt, die ich so aus dem Stehgreif auch nicht beantworten konnte. Der Support hat mir super-schnell und kompetent auf die Fragen geantwortet, aber da ich denke, dass diese Infos vielleicht auch bei anderen DSM-Anwendern nicht so bekannt sind, dachte ich, ich schreibe einen mehr oder weniger kurzen Blog-Artikel dazu.

Die Fragen des Kunden waren:

• Wann werden eigentlich alte Logfiles gelöscht und werden immer die ältesten gelöscht (hier hatte ich noch Infos aus NetInstall 5.x Zeiten, war mir aber nicht sicher, ob diese Mechanismen heute noch gültig sind)?
• Wieviele Logfiles werden eigentlich vorgehalten und lässt sich die Anzahl konfigurieren?
• Manche Logs werden ja in einem ZIP-Unterverzeichnis archiviert. Kann man das beeinflussen oder konfigurieren?

Tatsächlich ist es so, dass die Antwort auf die erste Frage mittlerweile in der Online-Hilfe zu finden ist - wenn man denn richtig danach sucht. Wie "früher" ist es auch heute noch so, dass Logfiles gelöscht werden, wenn entweder die maximale Speicherplatzgröße für die Protokolldateien eines Typs oder die maximale Anzahl der Protokolldateien einer Instanz erreicht ist.

Es werden dann aber nicht einfach so, wie allgemein angenommen, dass die ältesten Logs gelöscht werden. Legt eine DSM Komponente eine neue Instanz einer Protokolldatei an und der maximale Speicherplatz oder die maximale Protokolldatei-Anzahl ist erreicht, dann löscht DSM diejenige Protokolldatei mit der geringsten Signifikanz.

Wie auch in der Online-Hilfe im Abschnitt "Anhang › Hilfe bei der Fehlersuche › Protokolldateien › Statistik einer Protokolldatei" nachzulesen, hängt die Signifikanz einer Protokolldatei unter anderem davon ab, wieviele Aktionen in der Datei mitprotokolliert wurden, wieviele Warnungen und Fehler aufgetreten sind aber auch wie alt das Logfile mittlerweile ist.

Für jeden Eintrag wird ein festgelegter Wert zur Signifikanz addiert:

• GPF (General Protection Failure) = 32 
• Error = 5 
• Warning = 2 
• Signifikante Aktion = 1 (z.B. InstallFileList) 
• Erstelldatum = Pro Tag wird die Signifikanz um den Wert 1 verringert.

Diese endgültige Signifikanz wird bei jeder Analyse neu berechnet und nicht in die Protokolldatei geschrieben. Gelöscht werden also immer die Logs mit der geringsten Signifikanz, was – wenn keine Fehler aufgetreten sind – in aller Regel auch die ältesten Logfiles sein werden. Es kann aber durchaus auch passieren, dass Protokolle neueren Datums gelöscht werden, wenn viele Fehler aufgetreten sind oder besonders viele Aktionen ausgeführt und protokolliert wurden.

Die nächste Frage war, wieviele Logs eigentlich vorgehalten werden? Viele DSM-Anwender sind der Meinung, dass die Einstellung "Maximale Anzahl von Sicherungen" im Abschnitt "Installation" der Konfigurationstabelle festlegt, wieviele Generationen Protokolldateien vorgehalten werden. Dies ist aber nicht richtig – diese Einstellung gilt nur für die Anzahl der Backups einer Datei, wenn sie von DSM ersetzt wird. Dies kann entweder die NCP-Datei sein, wenn Konfigurationseinstellungen geändert werden oder es handelt sich um Dateien, die vom DSM-Client geändert oder ersetzt werden. Grundsätzlich werden die Dateien dann mit der Endung ".BA1" bis "BAn" gesichert.

Andere Anwender, und ich muss gestehen, dass ich bis vor kurzem auch dazu gehörte, sind der Meinung, dass die Anzahl der Logfiles nicht konfigurierbar wäre. Schließlich findet sich im entsprechenden Abschnitt der Konfigurationstabelle keine passende Einstellung:

Wenn man sich aber in der – mittlerweile doch sehr umfangreichen und sehr empfehlenswerten – Knowledgebase im HEAT Self Service Portal (erreichbar unter https://support.heatsoftware.com) auf die Suche begibt, sich findet sich ein Artikel, der beschreibt, dass DSM standardmäßig sechzehn Generationen Logfiles für jede Hauptkomponente wie DSM Konsole, Runtime Service, DSM Agent etc. und sechs Generationen für Unterkomponenten wie z.B. den Client State Manager oder den Location Check vorhält.

Sollte es aus irgendeinem Grund erforderlich sein, die Anzahl der Hauptkomponenten-Logs zu erhöhen, so ist dies dadurch möglich, dass im Registry-Schlüssel "HKEY_LOCAL_MACHINE\SOFTWARE\<SysWow6432Node>\NetSupport\NetInstall\LogFileSettings" ein neuer DWORD-Wert namens "MaxLogFiles" angelegt und in diesem die Anzahl der zu behaltenden Log-Generationen angegeben wird. Diese Einstellung ist zwar nicht vom Support unterstützt und man sollte natürlich vorsichtig sein, was man hier einträgt, da der Platzbedarf der NiLogs natürlich recht groß werden kann, wenn man hier zu große Werte einträgt, aber es ist immerhin gut zu wissen, dass es auch möglich ist, Logs über einen längeren Zeitraum zu behalten, weil das für Troubleshooting-Zwecke manchmal recht hilfreich sein kann.

Die letzte offene Frage war, wie es sich denn mit den ZIP-Archiven verhält, die in den "zip"-Unterverzeichnissen des NiLogs-Verzeichnisses angelegt werden? Dort werden ältere "wichtige" Protokolldateien archiviert und stehen auch später noch zur Auswertung zur Verfügung. Der Kunde wollte wissen, ob diese Archive manuell gelöscht werden müssen oder ob sie irgendwann automatisch gelöscht werden und falls ja, wann und ob das konfigurierbar wäre.

Auch hier liefert die Knowledgebase (im Artikel 12735) Auskunft: standardmäßig werden die hier erstellten Archive nach einem Jahr, also nach 365 Tagen, gelöscht. Sollte der Platzbedarf jedoch so groß oder der freie Speicherplatz so gering sein, dass diese Sicherungen früher gelöscht werden müssen, so lässt sich das maximale Alter ebenfalls über einen Registry-Wert konfigurieren. Dazu ist im Schlüssel "HKEY_LOCAL_MACHINE\SOFTWARE\<Wow6432Node>\NetSupport\LogProviders\filelog" ein neuer DWORD-Wert namens "ZipMaxAgeDays" anzulegen und dort das maximale Alter in Anzahl Tagen einzutragen. Protokoll-Archive die älter als der hier konfigurierte Wert sind, werden dann automatisch gelöscht.