Wann werden die verschiedenen Protokollebenen verwendet?

Es gibt verschiedene Möglichkeiten, Nachrichten in der Reihenfolge ihres Todes zu protokollieren:

1. FATAL

2. ERROR

3. WARN

4. INFO

5. DEBUG

6. TRACE

Wie entscheide ich, wann ich welche verwenden soll?

Was ist eine gute Heuristik?

Ich unterschreibe im Allgemeinen die folgende Konvention:

• Trace - Nur wenn ich den Code "verfolgen" und versuchen würde, einen Teil einer Funktion spezifisch zu finden.
• Debug - Informationen, die nicht nur für Entwickler (IT, Systemadministratoren usw.) diagnostisch hilfreich sind.
• Info - Allgemein nützliche Informationen zum Protokollieren (Start / Stopp des Dienstes, Konfigurationsannahmen usw.). Info Ich möchte immer verfügbar sein, kümmere mich aber normalerweise nicht um normale Umstände. Dies ist meine sofort einsatzbereite Konfigurationsstufe.
• Warnen - Alles, was möglicherweise zu Anwendungsfehlern führen kann, für das ich mich jedoch automatisch erholt habe. (B. Wechsel von einem primären zu einem Sicherungsserver, Wiederholung eines Vorgangs, fehlende sekundäre Daten usw.)
• Fehler - Jeder Fehler, der für den Vorgang schwerwiegend ist , jedoch nicht für den Dienst oder die Anwendung (eine erforderliche Datei, fehlende Daten usw. können nicht geöffnet werden). Diese Fehler erzwingen Eingriffe des Benutzers (Administrator oder direkter Benutzer). Diese sind normalerweise (in meinen Apps) für falsche Verbindungszeichenfolgen, fehlende Dienste usw. reserviert.
• Schwerwiegend - Jeder Fehler, der das Herunterfahren des Dienstes oder der Anwendung erzwingt, um Datenverlust (oder weiteren Datenverlust) zu verhindern. Ich behalte mir diese nur für die abscheulichsten Fehler und Situationen vor, in denen garantiert Daten beschädigt oder verloren gegangen sind.

Möchten Sie, dass die Nachricht einen Systemadministrator mitten in der Nacht aus dem Bett bringt?

• ja -> fehler
• nein -> warnen

Ich finde es hilfreicher, über Schweregrade aus der Perspektive der Anzeige der Protokolldatei nachzudenken.

Schwerwiegend / kritisch : Gesamtanwendung oder Systemfehler, die sofort untersucht werden sollten. Ja, wecken Sie den SysAdmin auf. Da wir unseren SysAdmins-Alarm bevorzugen und ausgeruht sind, sollte dieser Schweregrad sehr selten verwendet werden. Wenn es täglich passiert und das kein BFD ist, hat es seine Bedeutung verloren. In der Regel tritt ein schwerwiegender Fehler nur einmal in der Prozesslebensdauer auf. Wenn die Protokolldatei an den Prozess gebunden ist, ist dies normalerweise die letzte Meldung im Protokoll.

Fehler : Auf jeden Fall ein Problem, das untersucht werden sollte. SysAdmin sollte automatisch benachrichtigt werden, muss aber nicht aus dem Bett gezogen werden. Durch Filtern eines Protokolls nach Fehlern und höher erhalten Sie einen Überblick über die Fehlerhäufigkeit und können schnell den auslösenden Fehler identifizieren, der möglicherweise zu einer Kaskade zusätzlicher Fehler geführt hat. Das Verfolgen von Fehlerraten im Vergleich zur Anwendungsnutzung kann nützliche Qualitätsmetriken wie MTBF ergeben, anhand derer die Gesamtqualität bewertet werden kann. Diese Metrik kann beispielsweise dazu beitragen, Entscheidungen darüber zu treffen, ob vor einer Veröffentlichung ein weiterer Beta-Testzyklus erforderlich ist oder nicht.

Warnung : Dies könnte ein Problem sein oder auch nicht. Beispielsweise sollten erwartete vorübergehende Umgebungsbedingungen wie ein kurzer Verlust der Netzwerk- oder Datenbankkonnektivität als Warnungen und nicht als Fehler protokolliert werden. Das Anzeigen eines Protokolls, das so gefiltert wird, dass nur Warnungen und Fehler angezeigt werden, gibt möglicherweise einen schnellen Einblick in frühe Hinweise auf die Grundursache eines nachfolgenden Fehlers. Warnungen sollten sparsam verwendet werden, damit sie nicht bedeutungslos werden. Der Verlust des Netzwerkzugriffs sollte beispielsweise eine Warnung oder sogar ein Fehler in einer Serveranwendung sein, kann jedoch nur eine Information in einer Desktop-App sein, die für gelegentlich getrennte Laptop-Benutzer entwickelt wurde.

Info : Dies sind wichtige Informationen, die unter normalen Bedingungen protokolliert werden sollten, z. B. erfolgreiche Initialisierung, Starten und Stoppen von Diensten oder erfolgreicher Abschluss wichtiger Transaktionen. Das Anzeigen eines Protokolls mit Informationen und höher sollte einen schnellen Überblick über wichtige Statusänderungen im Prozess geben und einen Kontext auf oberster Ebene bieten, um eventuell auftretende Warnungen oder Fehler zu verstehen. Haben Sie nicht zu viele Info-Nachrichten. Wir haben normalerweise <5% Info-Nachrichten in Bezug auf Trace.

Trace : Trace ist bei weitem der am häufigsten verwendete Schweregrad und sollte einen Kontext bieten, um die Schritte zu verstehen, die zu Fehlern und Warnungen führen. Die richtige Dichte an Trace-Nachrichten macht Software viel wartbarer, erfordert jedoch einige Sorgfalt, da sich der Wert einzelner Trace-Anweisungen im Laufe der Zeit ändern kann, wenn sich Programme weiterentwickeln. Der beste Weg, dies zu erreichen, besteht darin, das Entwicklerteam daran zu gewöhnen, Protokolle regelmäßig zu überprüfen, um die vom Kunden gemeldeten Probleme zu beheben. Ermutigen Sie das Team, Trace-Nachrichten zu entfernen, die keinen nützlichen Kontext mehr bieten, und bei Bedarf Nachrichten hinzuzufügen, um den Kontext nachfolgender Nachrichten zu verstehen. Beispielsweise ist es häufig hilfreich, Benutzereingaben zu protokollieren, z. B. das Ändern von Anzeigen oder Registerkarten.

Debug : Wir betrachten Debug <Trace. Der Unterschied besteht darin, dass Debug-Nachrichten aus Release-Builds kompiliert werden. Wir raten jedoch von der Verwendung von Debug-Nachrichten ab. Das Zulassen von Debug-Nachrichten führt dazu, dass immer mehr Debug-Nachrichten hinzugefügt und keine jemals entfernt werden. Mit der Zeit werden Protokolldateien dadurch fast unbrauchbar, da es zu schwierig ist, Signale von Rauschen zu filtern. Dies führt dazu, dass Entwickler die Protokolle nicht verwenden, was die Todesspirale fortsetzt. Im Gegensatz dazu ermutigt das ständige Beschneiden von Trace-Nachrichten Entwickler, diese zu verwenden, was zu einer tugendhaften Spirale führt. Dadurch wird auch die Möglichkeit von Fehlern ausgeschlossen, die aufgrund der erforderlichen Nebenwirkungen im Debug-Code auftreten, die nicht im Release-Build enthalten sind. Ja, ich weiß, dass das in gutem Code nicht passieren sollte, aber besser sicher als leid.

Hier ist eine Liste der "Logger".

Apache log4j: §1 , §2

1. FATAL::

   [ v1.2 : ..] sehr schwerwiegende Fehlerereignisse, die vermutlich zum Abbruch der Anwendung führen.

   [ v2.0 : ..] schwerwiegender Fehler, der die Fortsetzung der Anwendung verhindert.

2. ERROR::

   [ v1.2 : ..] Fehlerereignisse, bei denen die Anwendung möglicherweise weiterhin ausgeführt werden kann.

   [ v2.0 : ..] Fehler in der Anwendung, möglicherweise behebbar.

3. WARN::

   [ v1.2 : ..] potenziell schädliche Situationen.

   [ V2.0 : ..] Fall , dass Macht möglich [ sic ] zu einem Fehler führen.

4. INFO::

   [ v1.2 : ..] Informationsmeldungen, die den Fortschritt der Anwendung auf grobkörniger Ebene hervorheben.

   [ v2.0 : ..] Ereignis zu Informationszwecken.

5. DEBUG::

   [ v1.2 : ..] feinkörnige Informationsereignisse, die zum Debuggen einer Anwendung am nützlichsten sind.

   [ v2.0 : ..] allgemeines Debugging-Ereignis.

6. TRACE::

   [ v1.2 : ..] feinkörnigere Informationsereignisse als die DEBUG.

   [ v2.0 : ..] feinkörnige Debug-Nachricht, die normalerweise den Fluss durch die Anwendung erfasst.

Apache Httpd (wie immer) macht gerne den Overkill: §

1. emerg :

   Notfälle - System ist unbrauchbar.

2. Warnung :

   Es müssen sofort Maßnahmen ergriffen werden [das System ist jedoch weiterhin verwendbar].

3. krit :

   Kritische Bedingungen [aber es müssen nicht sofort Maßnahmen ergriffen werden].

   • " Socket: Fehler beim Abrufen eines Sockets beim Verlassen des Kindes "

4. Fehler :

   Fehlerbedingungen [aber nicht kritisch].

   • " Vorzeitiges Ende der Skript-Header "

5. warnen :

   Warnbedingungen. [nah am Fehler, aber kein Fehler]

6. Hinweis :

   Normaler, aber signifikanter [ bemerkenswerter ] Zustand.

   • " httpd: gefangen SIGBUS, versucht den Kern in ... "

7. info :

   Informativ [und nicht kommentierbar].

   • [" Server läuft seit x Stunden. "]

8. Debug :

   Nachrichten auf Debug-Ebene [dh Nachrichten, die zum Zwecke der Fehlerbehebung protokolliert wurden ]].

   • " Konfigurationsdatei öffnen ... "

9. trace1 → trace6 :

   Nachrichten verfolgen [dh Nachrichten, die zum Zwecke der Verfolgung protokolliert wurden ].

   • " Proxy: FTP: Steuerverbindung abgeschlossen "
   • " Proxy: CONNECT: Senden der CONNECT-Anforderung an den Remote-Proxy "
   • " openssl: Handshake: start "
   • " Lesen von gepufferter SSL-Brigade, Modus 0, 17 Bytes "
   • " Kartensuche fehlgeschlagen:map=rewritemap key=keyname "
   • " Cache-Suche fehlgeschlagen, erzwingt neue Kartensuche "

10. trace7 → trace8 :

    Verfolgen Sie Nachrichten und sichern Sie große Datenmengen

    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"
    • " | 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"

Apache Commons-Logging: §

1. tödlich :

   Schwere Fehler, die zu einer vorzeitigen Beendigung führen. Erwarten Sie, dass diese auf einer Statuskonsole sofort sichtbar sind.

2. Fehler :

   Andere Laufzeitfehler oder unerwartete Bedingungen. Erwarten Sie, dass diese auf einer Statuskonsole sofort sichtbar sind.

3. warnen :

   Verwendung veralteter APIs, schlechte Verwendung der API, "fast" Fehler, andere Laufzeitsituationen, die unerwünscht oder unerwartet sind, aber nicht unbedingt "falsch". Erwarten Sie, dass diese auf einer Statuskonsole sofort sichtbar sind.

4. info :

   Interessante Laufzeitereignisse (Start / Herunterfahren). Erwarten Sie, dass diese auf einer Konsole sofort sichtbar sind. Seien Sie also konservativ und halten Sie sich auf ein Minimum.

5. Debug :

   detaillierte Informationen zum Durchfluss durch das System. Erwarten Sie, dass diese nur in Protokolle geschrieben werden.

6. Spur :

   detailliertere Informationen. Erwarten Sie, dass diese nur in Protokolle geschrieben werden.

Apache Commons-Logging "Best Practices" für den Unternehmensgebrauch unterscheidet zwischen Debug und Informationen basierend darauf, welche Art von Grenzen sie überschreiten.

Grenzen umfassen:

• Externe Grenzen - Erwartete Ausnahmen.

• Externe Grenzen - Unerwartete Ausnahmen.

• Interne Grenzen.

• Wichtige interne Grenzen.

( Weitere Informationen hierzu finden Sie im Commons-Logging-Handbuch .)

Wenn Sie das Problem beheben können, ist dies eine Warnung. Wenn dies die weitere Ausführung verhindert, liegt ein Fehler vor.

Ich würde empfehlen, Syslog-Schweregrade zu übernehmen : DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, EMERGENCY.
Siehe http://en.wikipedia.org/wiki/Syslog#Severity_levels

Sie sollten für die meisten Anwendungsfälle genügend feinkörnige Schweregrade bereitstellen und werden von vorhandenen Protokollparsern erkannt. Sie haben natürlich die Freiheit, nur eine Teilmenge zu implementieren, z. B. DEBUG, ERROR, EMERGENCYabhängig von den Anforderungen Ihrer App.

Lassen Sie uns auf etwas standardisieren, das es schon seit Ewigkeiten gibt, anstatt für jede andere App, die wir erstellen, einen eigenen Standard zu entwickeln. Sobald Sie mit dem Aggregieren von Protokollen beginnen und versuchen, Muster über verschiedene hinweg zu erkennen, hilft dies wirklich.

Warnungen, von denen Sie sich erholen können. Fehler, die Sie nicht können. Das ist meine Heuristik, andere haben vielleicht andere Ideen.

Angenommen, Sie geben den Namen "Angela Müller"in Ihre Anwendung ein / importieren ihn (beachten Sie den Umlaut über u). Ihr Code / Ihre Datenbank ist möglicherweise nur englisch (obwohl dies heutzutage wahrscheinlich nicht mehr der Fall sein sollte ) und könnte daher warnen, dass alle "ungewöhnlichen" Zeichen in reguläre englische Zeichen konvertiert wurden.

Vergleichen Sie dies mit dem Versuch, diese Informationen in die Datenbank zu schreiben und 60 Sekunden lang eine Nachricht über einen Netzwerkausfall zu erhalten. Das ist eher ein Fehler als eine Warnung.

Wie andere gesagt haben, sind Fehler Probleme; Warnungen sind mögliche Probleme.

In der Entwicklung verwende ich häufig Warnungen, bei denen ich möglicherweise das Äquivalent eines Assertionsfehlers setze, die Anwendung jedoch weiterarbeiten kann. Auf diese Weise kann ich herausfinden, ob dieser Fall jemals tatsächlich eintritt oder ob es meine Vorstellungskraft ist.

Aber ja, es kommt auf die Aspekte der Wiederherstellbarkeit und Aktualität an. Wenn Sie sich erholen können, ist dies wahrscheinlich eine Warnung. Wenn dadurch tatsächlich etwas fehlschlägt, liegt ein Fehler vor.

Ich denke, dass die SYSLOG-Ebenen NOTICE und ALERT / EMERGENCY für die Protokollierung auf Anwendungsebene weitgehend überflüssig sind - während CRITICAL / ALERT / EMERGENCY nützliche Warnstufen für einen Bediener sein können, der unterschiedliche Aktionen und Benachrichtigungen auslösen kann TÖDLICH. Und ich kann einfach nicht ausreichend zwischen einer Kündigung oder einer Information unterscheiden. Wenn die Informationen nicht bemerkenswert sind, sind es nicht wirklich Informationen :)

Die Interpretation von Jay Cincotta gefällt mir am besten - das Nachverfolgen der Ausführung Ihres Codes ist im technischen Support sehr nützlich, und das großzügige Einfügen von Trace-Anweisungen in den Code sollte empfohlen werden - insbesondere in Kombination mit einem dynamischen Filtermechanismus zum Protokollieren der Trace-Nachrichten von bestimmten Anwendungskomponenten. Die DEBUG-Ebene bedeutet für mich jedoch, dass wir noch dabei sind, herauszufinden, was los ist. Ich sehe die Ausgabe der DEBUG-Ebene als reine Entwicklungsoption und nicht als etwas, das jemals in einem Produktionsprotokoll angezeigt werden sollte.

Es gibt jedoch eine Protokollierungsstufe, die ich gerne in meinen Fehlerprotokollen sehe, wenn ich den Hut eines Systemadministrators trage, genauso wie den des technischen Supports oder sogar des Entwicklers: OPER für OPERATIONAL-Nachrichten. Dies verwende ich zum Protokollieren eines Zeitstempels, der Art der aufgerufenen Operation, der angegebenen Argumente, möglicherweise einer (eindeutigen) Aufgabenkennung und der Aufgabenerfüllung. Es wird verwendet, wenn z. B. eine eigenständige Aufgabe ausgelöst wird. Dies ist ein echter Aufruf innerhalb der größeren App mit langer Laufzeit. Es ist die Art von Dingen, die ich immer protokollieren möchte, egal ob etwas schief geht oder nicht. Daher halte ich den OPER-Level für höher als FATAL, sodass Sie ihn nur ausschalten können, indem Sie in den völlig stillen Modus wechseln. Und es ist viel mehr als nur INFO-Protokolldaten - eine Protokollebene, die häufig zum Spammen von Protokollen mit geringfügigen Betriebsmeldungen ohne historischen Wert missbraucht wird.

Wie es der Fall vorschreibt, können diese Informationen an ein separates Aufrufprotokoll weitergeleitet oder durch Herausfiltern aus einem großen Protokoll, in dem weitere Informationen aufgezeichnet werden, abgerufen werden. Als historische Information muss man jedoch immer wissen, was getan wurde - ohne auf die Ebene von AUDIT abzusteigen, eine andere völlig separate Protokollebene, die nichts mit Fehlfunktionen oder Systembetrieb zu tun hat, passt nicht wirklich in die oben genannten Ebenen ( da es einen eigenen Steuerschalter benötigt, keine Schweregradklassifizierung) und definitiv eine eigene separate Protokolldatei benötigt.

Ab RFC 5424 das Syslog-Protokoll (IETF) - Seite 10:

Jede Nachrichtenpriorität hat auch eine dezimale Schweregradanzeige. Diese werden in der folgenden Tabelle zusammen mit ihren numerischen Werten beschrieben. Schweregrade MÜSSEN im Bereich von 0 bis einschließlich 7 liegen.

       Numerical         Severity
         Code

          0       Emergency: system is unusable
          1       Alert: action must be taken immediately
          2       Critical: critical conditions
          3       Error: error conditions
          4       Warning: warning conditions
          5       Notice: normal but significant condition
          6       Informational: informational messages
          7       Debug: debug-level messages

          Table 2. Syslog Message Severities

Tag auch,

Als Folge dieser Frage teilen Sie Ihre Interpretationen der Protokollebenen mit und stellen Sie sicher, dass alle Personen in einem Projekt in ihrer Interpretation der Ebenen ausgerichtet sind.

Es ist schmerzhaft, eine Vielzahl von Protokollnachrichten zu sehen, bei denen die Schweregrade und die ausgewählten Protokollstufen inkonsistent sind.

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

HTH

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

Alles, was ich hinzufügen kann, ist, dass diese Ebenen im Allgemeinen ihren Wörterbuchdefinitionen entsprechen, also kann es nicht so schwer sein. Wenn Sie Zweifel haben, behandeln Sie es wie ein Puzzle. Denken Sie für Ihr spezielles Projekt an alles, was Sie protokollieren möchten.

Können Sie jetzt herausfinden, was tödlich sein könnte? Sie wissen, was tödlich bedeutet, nicht wahr? Also, welche Elemente auf Ihrer Liste sind fatal.

Ok, das ist fatal behandelt, jetzt schauen wir uns die Fehler an ... spülen und wiederholen.

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

Ich denke, dass Fatal und Irrtum uns allen klar sein sollten. Die anderen mögen unschärfer sein, aber es ist wohl weniger wichtig, sie richtig zu machen.

Hier sind einige Beispiele:

Schwerwiegend - Speicher, Datenbank usw. können nicht zugeordnet werden - kann nicht fortgesetzt werden.

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

Warnung - Die Ressourcenzuweisung erreicht X% (z. B. 80%). Dies ist ein Zeichen dafür, dass Sie Ihre Ressourcen möglicherweise neu dimensionieren möchten.

Info - Benutzer angemeldet / abgemeldet, neue Transaktion, Datei erstellt, neues D / B-Feld oder Feld gelöscht.

Debug - Speicherauszug der internen Datenstruktur, Anything Trace-Ebene mit Dateiname und Zeilennummer.
Trace - Aktion erfolgreich / fehlgeschlagen, d / b aktualisiert.

Ein Fehler ist etwas, das falsch ist, einfach falsch, kein Weg daran vorbei, er muss behoben werden.

Eine Warnung ist ein Zeichen für ein Muster, das möglicherweise falsch ist, aber auch nicht.

Trotzdem kann ich kein gutes Beispiel für eine Warnung finden, die nicht auch ein Fehler ist. Damit meine ich, dass Sie das zugrunde liegende Problem genauso gut beheben können, wenn Sie sich die Mühe machen, eine Warnung zu protokollieren.

Dinge wie "SQL-Ausführung dauert zu lange" können jedoch eine Warnung sein, während "SQL-Ausführungs-Deadlocks" ein Fehler sind, sodass es vielleicht doch einige Fälle gibt.

Ich habe immer darüber nachgedacht, die erste Protokollebene zu warnen, was sicher bedeutet, dass ein Problem vorliegt (z. B. ist eine Konfigurationsdatei möglicherweise nicht dort, wo sie sein sollte, und wir müssen sie mit den Standardeinstellungen ausführen). Ein Fehler bedeutet für mich, dass das Hauptziel der Software jetzt unmöglich ist und wir versuchen werden, das System sauber herunterzufahren.

Ich habe vorher Systeme gebaut, die Folgendes verwenden:

1. FEHLER - bedeutet, dass etwas ernsthaft falsch ist und dass ein bestimmter Thread / Prozess / eine bestimmte Sequenz nicht fortgesetzt werden kann. Einige Benutzer- / Administratorinterventionen sind erforderlich
2. WARNUNG - etwas stimmt nicht, aber der Prozess kann wie zuvor fortgesetzt werden (z. B. ist ein Job in einem Satz von 100 fehlgeschlagen, der Rest kann jedoch verarbeitet werden).

In den Systemen, die ich erstellt habe, wurden Administratoren angewiesen, auf FEHLER zu reagieren. Auf der anderen Seite würden wir nach WARNHINWEISEN suchen und für jeden Fall feststellen, ob Systemänderungen, Neukonfigurationen usw. erforderlich waren.

Übrigens bin ich ein großer Fan davon, alles zu erfassen und die Informationen später zu filtern.

Was würde passieren, wenn Sie auf Warnungsebene erfassen und Debug-Informationen zur Warnung wünschen, die Warnung jedoch nicht neu erstellen konnten?

Erfassen Sie alles und filtern Sie später!

Dies gilt auch für eingebettete Software, es sei denn, Sie stellen fest, dass Ihr Prozessor nicht mithalten kann. In diesem Fall möchten Sie möglicherweise Ihre Ablaufverfolgung neu gestalten, um sie effizienter zu gestalten, oder die Ablaufverfolgung beeinträchtigt das Timing ( möglicherweise) Debugging durchführen ein leistungsfähigerer Prozessor, aber das eröffnet eine ganze Reihe weiterer Würmer).

Erfassen Sie alles und später filtern !!

(Übrigens: Alles erfassen ist auch gut, weil Sie damit Tools entwickeln können, die mehr als nur die Debug-Ablaufverfolgung anzeigen (ich zeichne Nachrichtensequenzdiagramme aus meinen und Histogramme der Speichernutzung. Sie bieten Ihnen auch eine Vergleichsbasis, wenn etwas schief geht Zukunft (behalten Sie alle Protokolle, ob bestanden oder nicht bestanden, und stellen Sie sicher, dass die Build-Nummer in der Protokolldatei enthalten ist)).

Meine zwei Cent ungefähr FATALund TRACEFehlerprotokollstufen.

ERROR ist, wenn ein Fehler (Ausnahme) auftritt.

FATAL ist eigentlich DOUBLE FAULT: Wenn während der Behandlung der Ausnahme eine Ausnahme auftritt.

Für den Webdienst ist es leicht zu verstehen.

1. Anfrage kommen. Ereignis wird als protokolliertINFO
2. Das System erkennt einen geringen Speicherplatz. Ereignis wird als protokolliertWARN
3. Einige Funktionen werden aufgerufen, um die Anforderung zu verarbeiten. Während der Verarbeitung erfolgt eine Division durch Null. Ereignis wird als protokolliertERROR
4. Der Ausnahmebehandler des Webdienstes wird aufgerufen, um die Division durch Null zu behandeln. Der Webdienst / das Framework sendet E-Mails, kann dies jedoch nicht, da der Mailingdienst jetzt offline ist. Diese zweite Ausnahme kann nicht normal behandelt werden, da der Ausnahmehandler des Webdienstes keine Ausnahme verarbeiten kann.
5. Anderer Ausnahmebehandler aufgerufen. Ereignis wird als protokolliertFATAL

TRACEDies ist der Zeitpunkt, an dem wir den Ein- / Ausgang von Funktionen verfolgen können. Hier geht es nicht um die Protokollierung, da diese Nachricht von einem Debugger generiert werden kann und Ihr Code überhaupt nicht aufgerufen hat log. Nachrichten, die nicht aus Ihrer Anwendung stammen, werden also wie folgt markiertTRACE Ebene . Zum Beispiel führen Sie Ihre Anwendung mit ausstrace

So im Allgemeinen in Ihrem Programm tun Sie DEBUG, INFOund WARNProtokollierung. Und nur wenn Sie einen Webdienst / ein Framework schreiben, werden Sie es verwenden FATAL. Und wenn Sie eine Anwendung debuggen, erhalten Sie eine TRACEProtokollierung von dieser Art von Software.

Ich schlage vor, nur drei Ebenen zu verwenden

1. Tödlich - Was die Anwendung beschädigen würde.
2. Info - Info
3. Debug - Weniger wichtige Informationen