Was ist ein gutes Layout für eine Standardfehlerprotokolldatei?

Question

Ich versuche, die Fehler- und Warnprotokolldatei für mein Desktop-Programm zu entwerfen.

Da mein Programm die Eingabedatei des Benutzers liest, kann es Syntaxfehler oder ungültige Daten irgendeiner Art finden. Sobald alles gelesen wurde und das Programm die Daten verarbeitet, können weitere Probleme auftreten.

Ich möchte Nachrichten über diese in eine einfache Textdatei schreiben. Ich möchte vielleicht auch Informationstexte hinzufügen, um den Fortschritt, die Zeit, den Speicherverbrauch usw. anzuzeigen. Ich möchte Zeilennummern und vielleicht sogar die eigentlichen Eingabezeilen einbeziehen, die die Fehler verursachen.

Dies ist eine Datei, die der Benutzer durchsuchen wird, also muss es offensichtlich gut angelegt und einfach zu bedienen sein.

Kennen Sie irgendwelche Styleguides, oder haben Sie eine Fehlerprotokolldatei gesehen, die Sie zu sich selbst gebracht hat: "Nun, das ist eine gut gestaltete Log-Datei!"

---

Followup:

Die ersten drei Antworten sind eigentlich eher für einen Server oder Ereignisprotokoll.

Ich bin wirklich auf der Suche nach einem Format für eine Protokolldatei für mein Desktop-Programm, um alle Probleme mit der Eingabedatei und den Erfolg (oder Misserfolg) der Verarbeitung davon zu finden.

Ich bin sicher, es gibt einige Desktop-Anwendungen, die Sie verwenden, die solche Protokolldateien erstellen. Hast du irgendwelche guten gesehen?

Answer 1

syslog und log4j sind weit verbreitete Formate, mit denen Systemadministratoren vertraut sein können, und es gibt Tools für die Arbeit mit ihnen. Sie sollten sie zumindest anschauen, bevor Sie Ihr eigenes Format erstellen.

Für Windows ist es ziemlich immer das Application Event Log, das ich nicht so sehr wie eine Textdatei mag, aber es ist der richtige Weg. Ich habe ein paar Apps gesehen, die Textdateien in ihrem Programmverzeichnis oder so schreiben, aber es ist immer Ad-hoc, niemals Standard. McAfee VirusScan protokolliert beispielsweise Dateien in C: \ Dokumente und Einstellungen \ All Users \ Anwendungsdaten \ McAfee \ DesktopProtection. Mein Computer verfügt über zahlreiche Installationsprotokolle unter C: \ Dokumente und Einstellungen \ Benutzername \ Lokale Einstellungen \ temp * .log und C: \ WINDOWS \ temp * .log. Aber wieder sind sie alle unterschiedlich und ad hoc und nicht merklich gut gestaltet

Answer 2

Ich schreibe Protokolle in CSV-Dateien und finde es sehr bequem (Sie können sie als Datenbank verwenden oder sie mit einer Tabellenkalkulationssoftware für anspruchsvolle Analyse öffnen). Die Beispielprotokolldatei ist:

Date;Time;Severity;TID;Module;This;Source;Message 
2010/01/21;08:47:05:205;DEBUG;4936;MAIN;0x00000000;DllMain@36;DLL_PROCESS_ATTACH 
2010/01/21;08:47:05:205;DEBUG;4936;MAIN;0x00000000;DllMain@40;DLL_PROCESS_DETACH 

Ich bin nicht sicher, ob es Ihren Bedürfnissen entspricht, aber ich glaube, Sie die Hauptidee haben. Viel Glück!

Answer 3

Es gibt nur wenige Protokolldateien, die mich wirklich beeindruckt haben - eigentlich fällt mir schwer, an etwas zu denken (und finde es nicht). Meiner Erfahrung nach kommen die auftretenden Probleme zum Teil daher, dass die Logs für einen Insider (Programmierer) formatiert sind, um sie zu verstehen, anstatt sie entweder für ein anderes Programm oder einen Außenstehenden (Nicht-Programmierer) zu verstehen.

Wichtige Informationen werden oft weggelassen; manchmal sogar Datum und Uhrzeit Informationen. Ich würde empfehlen, diese leicht zu analysieren; Ich würde eine ISO-8601-Notation wie "2010-01-22T10: 23: 21-08: 00" (einschließlich der Zeitzone, Notiz) verwenden. Ich würde Prozess- (und Thread-) ID einschließen; Ich würde in Erwägung ziehen, Programmname, Argumente (z. B. Dateiname) aufzunehmen; Ich würde die Benutzer-ID auch in irgendeiner Form hinzufügen. Einige davon werden möglicherweise nur einmal pro Lauf benötigt, für jede Nachricht sind jedoch möglicherweise andere Bits erforderlich. Es hängt zum Teil davon ab, ob die Protokolldatei für jeden Lauf eindeutig ist oder für alle freigegeben ist und ob eine einzelne Datei von mehreren Benutzern/Prozessen verwendet werden kann.

Sie müssen dann entscheiden, wie Sie den Nachrichteninhalt identifizieren - und das Ende des Nachrichteninhalts. Insbesondere für maschinelles Parsen (aber auch für menschliches Parsen) ist es hilfreich, wenn der Inhalt eindeutig formatiert ist und das Ende erkannt werden kann. Sie müssen den Inhalt möglicherweise maskieren (dies ist der Schritt, der am häufigsten rückgängig gemacht wird. Wenn also die Fehlermeldung eine fehlerhafte Fehlermeldung enthält, ist es sehr schwer zu sagen, welche Daten aus der Datei stammen und welche neue Fehlermeldung vorliegt in der Datei).In einem Multithread-Programm - oder wenn die Protokolldatei zwischen Prozessen geteilt wird - müssen Sie überlegen, wie die Schreiboperationen ebenfalls gepuffert werden, besonders wenn Sie mit langen Zeilen arbeiten müssen. Sie möchten, dass jede Nachricht in der Protokolldatei einzeln getrennt ist. Dies ist nicht unbedingt trivial - Sie müssen möglicherweise sogar mit einem Sperrprotokoll umgehen, um einen kontrollierten Zugriff zu gewährleisten.

Überlegen Sie, ob Sie einen hübschen Drucker für das Protokoll bereitstellen müssen.

Überlegen Sie, ob ein XML-basiertes Format (mit Start- und Ende-Tags) hilfreich wäre. Ich bin kein großer Fan von XML, aber es hat einige Vorteile für die maschinelle Verarbeitung.