Wann die verschiedenen Protokollebenen zu verwenden sind

Question

Es gibt verschiedene Möglichkeiten, Meldungen zu protokollieren, und zwar in der Reihenfolge ihres Auftretens:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

Wie entscheide ich, wann ich was verwende?

Was ist eine gute Heuristik, die man verwenden kann?

Answer 1

Ich stimme den anderen vollkommen zu und denke, dass GrayWizardx es am besten gesagt hat.

Ich kann nur hinzufügen, dass diese Stufen im Allgemeinen den Definitionen im Wörterbuch entsprechen, es kann also nicht so schwer sein. Im Zweifelsfall sollten Sie es wie ein Puzzle behandeln. Überlegen Sie sich für Ihr Projekt alles, was Sie protokollieren möchten.

Können Sie nun herausfinden, was tödlich sein könnte? Du weißt, was tödlich bedeutet, oder? Also, welche Punkte auf deiner Liste sind tödlich.

Ok, das ist tödlich, jetzt schauen wir uns die Fehler an ... spülen und wiederholen.

Unter "Fatal" oder vielleicht "Error" würde ich sagen, dass mehr Informationen immer besser sind als weniger, also "nach oben" gehen. Sie sind sich nicht sicher, ob es sich um eine Info oder eine Warnung handelt? Dann machen Sie es zu einer Warnung.

Ich denke, dass Fatal und Error für uns alle klar sein sollten. Die anderen sind vielleicht etwas undeutlicher, aber es ist wohl weniger wichtig, sie richtig zu verstehen.

Hier sind einige Beispiele:

Tödlich - kann keinen Speicher, keine Datenbank usw. zuweisen - kann nicht fortfahren.

Fehler - keine Antwort auf die Nachricht, Transaktion abgebrochen, Datei kann nicht gespeichert werden, usw.

Warnung - Die Ressourcenzuweisung erreicht X % (z. B. 80 %) - das ist ein Zeichen dafür, dass Sie Ihr Projekt möglicherweise neu dimensionieren sollten.

Infos - Benutzer angemeldet/abgemeldet, neue Transaktion, Datei erstellt, neues DBB-Feld oder Feld gelöscht.

Debuggen - Dump der internen Datenstruktur, Anything Trace Level mit Dateiname und Zeilennummer.
Trace - Aktion erfolgreich/gescheitert, d/b aktualisiert.

Answer 2

Wie bereits gesagt wurde, sind Fehler Probleme; Warnungen sind potenzielle Probleme.

In der Entwicklung verwende ich häufig Warnungen, in denen ich das Äquivalent eines Assertion-Fehlers einfüge, die Anwendung aber weiterarbeiten kann; so kann ich herausfinden, ob dieser Fall tatsächlich eintritt oder ob es sich um meine Einbildung handelt.

Aber ja, es kommt auf die Aspekte der Wiederherstellbarkeit und der Aktualität an. Wenn es wiederhergestellt werden kann, handelt es sich wahrscheinlich um eine Warnung; wenn es dazu führt, dass etwas tatsächlich fehlschlägt, ist es ein Fehler.

Answer 3

Ich denke, dass die SYSLOG-Stufen NOTICE und ALERT/EMERGENCY für die Protokollierung auf Anwendungsebene weitgehend überflüssig sind - während CRITICAL/ALERT/EMERGENCY für einen Operator nützliche Warnstufen sein können, die verschiedene Aktionen und Benachrichtigungen auslösen können, ist es für einen Anwendungsadministrator dasselbe wie FATAL. Und ich kann einfach nicht ausreichend zwischen einer Benachrichtigung und einer Information unterscheiden. Wenn die Information nicht erwähnenswert ist, ist sie nicht wirklich eine Information :)

Mir gefällt Jay Cincottas Interpretation am besten - die Verfolgung der Codeausführung ist etwas sehr Nützliches für den technischen Support, und die großzügige Einfügung von Trace-Anweisungen in den Code sollte gefördert werden - insbesondere in Kombination mit einem dynamischen Filtermechanismus für die Protokollierung der Trace-Meldungen von bestimmten Anwendungskomponenten. Der DEBUG-Level zeigt mir jedoch, dass wir noch dabei sind, herauszufinden, was vor sich geht - ich sehe die DEBUG-Level-Ausgabe als eine Option, die nur für die Entwicklung gedacht ist, und nicht als etwas, das jemals in einem Produktionsprotokoll auftauchen sollte.

Es gibt jedoch eine Protokollierungsebene, die ich in meinen Fehlerprotokollen gerne sehe, wenn ich den Hut eines Systemadministrators ebenso trage wie den des technischen Supports oder sogar des Entwicklers: OPER, für OPERATIONELLE Meldungen. Damit protokolliere ich einen Zeitstempel, die Art der aufgerufenen Operation, die übergebenen Argumente, möglicherweise eine (eindeutige) Aufgabenkennung und den Abschluss der Aufgabe. Sie wird verwendet, wenn z. B. eine eigenständige Aufgabe abgefeuert wird, etwas, das ein echter Aufruf innerhalb einer größeren, länger laufenden Anwendung ist. Das ist die Art von Dingen, von denen ich möchte, dass sie immer protokolliert werden, unabhängig davon, ob etwas schief geht oder nicht, daher halte ich die Stufe OPER für höher als FATAL, so dass man sie nur abschalten kann, indem man in den völlig stillen Modus geht. Und es geht um viel mehr als um bloße INFO-Protokolldaten - eine Protokollebene, die oft dazu missbraucht wird, die Protokolle mit unbedeutenden Betriebsmeldungen ohne jeglichen historischen Wert zu überladen.

Je nach Fall können diese Informationen in ein separates Aufrufprotokoll geleitet oder aus einem großen Protokoll herausgefiltert werden, das mehr Informationen enthält. Als historische Information wird sie jedoch immer benötigt, um zu wissen, was getan wurde - ohne auf die Ebene von AUDIT hinabzusteigen, einer weiteren, völlig separaten Protokollebene, die nichts mit Fehlfunktionen oder dem Systembetrieb zu tun hat, nicht wirklich in die oben genannten Ebenen passt (da sie einen eigenen Kontrollschalter und keine Schweregradklassifizierung benötigt) und die definitiv eine eigene Protokolldatei benötigt.

Answer 4

Guten Tag,

Als logische Konsequenz dieser Frage sollten Sie Ihre Interpretationen der Protokollebenen kommunizieren und sicherstellen, dass alle Projektmitarbeiter ihre Interpretationen der Ebenen aufeinander abstimmen.

Es ist schmerzhaft, eine Vielzahl von Protokollmeldungen zu sehen, bei denen die Schweregrade und die ausgewählten Protokollstufen nicht übereinstimmen.

Geben Sie nach Möglichkeit Beispiele für die verschiedenen Protokollierungsstufen an. Und seien Sie konsequent bei den Informationen, die in einer Meldung protokolliert werden sollen.

HTH

Answer 5

Meine Meinung zu FATAL y TRACE Fehlerprotokollebenen.

ERROR ist, wenn ein FAULT (Ausnahme) auftritt.

FATAL ist eigentlich DOUBLE FAULT: wenn bei der Behandlung von Ausnahmen Ausnahmen auftreten.

Für den Webdienst ist das leicht zu verstehen.

1. Bitte kommen. Ereignis wird protokolliert als INFO
2. Das System erkennt einen geringen Speicherplatz. Das Ereignis wird protokolliert als WARN
3. Eine Funktion wird aufgerufen, um die Anfrage zu bearbeiten. Während der Verarbeitung tritt eine Division durch Null auf. Das Ereignis wird protokolliert als ERROR
4. Der Exception-Handler des Webdienstes wird aufgerufen, um die Division durch Null zu behandeln. Der Webdienst/das Framework will eine E-Mail senden, kann dies aber nicht, da der Mailingdienst jetzt offline ist. Diese zweite Ausnahme kann nicht normal behandelt werden, weil der Exception-Handler des Webdienstes die Ausnahme nicht verarbeiten kann.
5. Anderer Exception-Handler aufgerufen. Ereignis wird protokolliert als FATAL

TRACE ist der Zeitpunkt, an dem wir den Ein- und Austritt einer Funktion verfolgen können. Hier geht es nicht um Logging, denn diese Meldung kann von einem Debugger erzeugt werden und Ihr Code hat keinen Aufruf an log überhaupt nicht. So werden Nachrichten, die nicht von Ihrer Anwendung stammen, wie folgt gekennzeichnet TRACE Niveau. Zum Beispiel führen Sie Ihre Anwendung mit strace

Im Allgemeinen machen Sie in Ihrem Programm also DEBUG , INFO y WARN Protokollierung. Und nur wenn Sie einen Webdienst/Framework schreiben, werden Sie die FATAL . Und wenn Sie die Anwendung debuggen, erhalten Sie TRACE Protokollierung durch diese Art von Software.