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 halte mich im Allgemeinen an die folgende Konvention:

• Spurensuche - Nur wenn ich den Code "zurückverfolgen" und versuchen würde, einen zu finden Teil einer bestimmten Funktion.
• Debuggen - Informationen, die nicht nur für Entwickler (IT, Systemadministratoren usw.) diagnostisch hilfreich sind.
• Infos - Allgemein nützliche Informationen zur Protokollierung (Start/Stopp des Dienstes, Konfigurationsannahmen usw.). Informationen, die ich immer verfügbar haben möchte, die mir aber unter normalen Umständen egal sind. Dies ist meine Standardkonfigurationsebene.
• Warnung - Alles, was möglicherweise zu Anwendungsproblemen führen kann, für die ich aber automatisch gerüstet bin. (z. B. Wechsel von einem Primär- zu einem Backup-Server, erneuter Versuch eines Vorgangs, fehlende Sekundärdaten usw.)
• Fehler - Jeder Fehler, der für das Programm fatal ist Betrieb aber nicht der Dienst oder die Anwendung (kann eine erforderliche Datei nicht öffnen, es fehlen Daten usw.). Diese Fehler zwingen den Benutzer (Administrator oder direkter Benutzer) zum Eingreifen. Sie sind normalerweise (in meinen Anwendungen) für falsche Verbindungszeichenfolgen, fehlende Dienste usw. reserviert.
• Tödlich - Jeder Fehler, der ein Herunterfahren des Dienstes oder der Anwendung erzwingt, um Datenverlust (oder weiteren Datenverlust) zu verhindern. Ich behalte mir dies nur für die schwerwiegendsten Fehler und Situationen vor, in denen es garantiert zu einer Datenbeschädigung oder einem Datenverlust gekommen ist.

Answer 2

Würden Sie wollen, dass die Nachricht einen Systemadministrator mitten in der Nacht aus dem Bett holt?

• ja -> Fehler
• nein -> warnen

Answer 3

Es ist ein altes Thema, aber immer noch aktuell. Diese Woche habe ich einen kleinen Artikel darüber geschrieben, für meine Kollegen. Zu diesem Zweck habe ich auch diesen Spickzettel erstellt, weil ich online keinen finden konnte.

Answer 4

Ich finde es hilfreicher, den Schweregrad aus der Perspektive der Protokolldatei zu betrachten.

Tödlich/Kritisch : Ein allgemeiner Anwendungs- oder Systemfehler, der sofort untersucht werden sollte. Ja, wecken Sie den SysAdmin. Da wir es vorziehen, dass unsere SysAdmins wach und ausgeruht sind, sollte dieser Schweregrad nur sehr selten verwendet werden. Wenn der Fehler täglich auftritt und es sich nicht um einen BFD handelt, hat er seine Bedeutung verloren. Normalerweise tritt ein Fatal-Fehler nur einmal während der Lebensdauer eines Prozesses auf. Wenn also die Protokolldatei an den Prozess gebunden ist, ist dies normalerweise die letzte Meldung im Protokoll.

Fehler : Ein Problem, das auf jeden Fall untersucht werden sollte. Der SysAdmin sollte automatisch benachrichtigt werden, muss aber nicht aus dem Bett geholt werden. Wenn Sie ein Protokoll nach Fehlern und darüber hinaus filtern, erhalten Sie einen Überblick über die Fehlerhäufigkeit und können den auslösenden Fehler, der zu einer Kaskade weiterer Fehler geführt haben könnte, schnell identifizieren. Die Verfolgung der Fehlerhäufigkeit im Vergleich zur Anwendungsnutzung kann nützliche Qualitätsmetriken wie die MTBF ergeben, die zur Bewertung der Gesamtqualität herangezogen werden können. Diese Metrik kann beispielsweise bei der Entscheidung helfen, ob vor einer Veröffentlichung ein weiterer Beta-Testzyklus erforderlich ist oder nicht.

Warnung : Das KANN ein Problem sein, muss es aber nicht. So sollten z. B. erwartete vorübergehende Umgebungsbedingungen, wie ein kurzzeitiger Verlust der Netzwerk- oder Datenbankkonnektivität, als Warnungen und nicht als Fehler protokolliert werden. Die Ansicht eines Protokolls, das nur Warnungen und Fehler anzeigt, kann einen schnellen Einblick in die Ursache eines späteren Fehlers geben. Warnungen sollten sparsam verwendet werden, damit sie nicht bedeutungslos werden. So sollte beispielsweise der Verlust des Netzwerkzugriffs in einer Serveranwendung eine Warnung oder sogar ein Fehler sein, während er in einer Desktop-Anwendung, die für gelegentlich nicht verbundene Laptop-Benutzer gedacht ist, nur eine Info sein kann.

Infos : Dies sind wichtige Informationen, die unter normalen Bedingungen protokolliert werden sollten, z. B. bei erfolgreicher Initialisierung, beim Starten und Stoppen von Diensten oder beim erfolgreichen Abschluss wichtiger Transaktionen. Die Anzeige eines Protokolls mit der Bezeichnung "Info" und höher sollte einen schnellen Überblick über die wichtigsten Zustandsänderungen des Prozesses geben und einen Top-Level-Kontext für das Verständnis von Warnungen oder Fehlern liefern, die ebenfalls auftreten. Es sollten nicht zu viele Info-Meldungen auftreten. In der Regel haben wir < 5% Info-Meldungen im Verhältnis zu Trace.

Spurensuche : Trace ist bei weitem der am häufigsten verwendete Schweregrad und sollte den Kontext liefern, um die Schritte zu verstehen, die zu Fehlern und Warnungen führen. Die richtige Dichte von Trace-Meldungen macht Software viel wartungsfreundlicher, erfordert aber eine gewisse Sorgfalt, da sich der Wert einzelner Trace-Anweisungen im Laufe der Zeit ändern kann, wenn sich Programme weiterentwickeln. Dies lässt sich am besten dadurch erreichen, dass sich das Entwicklerteam angewöhnt, die Protokolle regelmäßig zu überprüfen, da dies ein Standardbestandteil der Fehlerbehebung bei von Kunden gemeldeten Problemen ist. Ermuntern Sie das Team, Trace-Meldungen zu entfernen, die keinen nützlichen Kontext mehr liefern, und Meldungen hinzuzufügen, wenn dies zum Verständnis des Kontexts nachfolgender Meldungen erforderlich ist. So ist es zum Beispiel oft hilfreich, Benutzereingaben wie das Wechseln von Anzeigen oder Registerkarten zu protokollieren.

Debuggen : Wir betrachten Debug < Trace. Der Unterschied besteht darin, dass Debug-Meldungen aus den Release-Builds herauskompiliert werden. Dennoch raten wir von der Verwendung von Debug-Meldungen ab. Wenn man Debug-Meldungen zulässt, führt das dazu, dass immer mehr Debug-Meldungen hinzugefügt werden und keine einzige entfernt wird. Mit der Zeit werden die Protokolldateien dadurch fast nutzlos, weil es zu schwierig ist, das Signal vom Rauschen zu trennen. Das führt dazu, dass Entwickler die Protokolle nicht verwenden, was die Todesspirale weiter antreibt. Im Gegensatz dazu ermutigt das ständige Beschneiden von Trace-Meldungen die Entwickler, diese zu verwenden, was zu einer positiven Spirale führt. Außerdem wird so die Möglichkeit ausgeschlossen, dass Bugs aufgrund notwendiger Nebeneffekte in Debug-Code eingeführt werden, der nicht im Release-Build enthalten ist. Ja, ich weiß, dass das bei gutem Code nicht passieren sollte, aber Vorsicht ist besser als Nachsicht.

Answer 5

Hier ist eine Liste dessen, was "die Holzfäller" haben.

---

Apache log4j: §1 , §2

1. FATAL :

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

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

2. ERROR :

   [ v1.2 : ] Fehlerereignisse, die eine Fortsetzung der Anwendung ermöglichen könnten.

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

3. WARN :

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

   [ v2.0 : ] Ereignis, das möglicherweise [ sic ] führen zu einem Fehler.

4. INFO :

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

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

5. DEBUG :

   [ v1.2 : ] feinkörnige Informationsereignisse, die für die Fehlersuche in einer Anwendung sehr nützlich sind.

   [ v2.0 : ] allgemeines Debugging-Ereignis.

6. TRACE :

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

   [ v2.0 : ] feinkörnige Debug-Meldung, die typischerweise den Fluss durch die Anwendung aufzeichnet.

---

Apache Httpd geht (wie üblich) gerne über die Stränge: §

1. Notruf :

   Notfälle - System ist unbrauchbar.

2. Alarm :

   Es müssen sofort Maßnahmen ergriffen werden [aber das System ist noch benutzbar].

3. Kritik :

   Kritische Bedingungen [aber es muss nicht sofort gehandelt werden].

   • " Steckdose: Konnte keinen Socket erhalten, Kind wird beendet "

4. Fehler :

   Fehlerbedingungen [aber nicht kritisch].

   • " Vorzeitiges Ende von Skript-Kopfzeilen "

5. warnen :

   Warnbedingungen. [nahe am Fehler, aber kein Fehler]

6. Hinweis :

   Normal, aber signifikant [ Bemerkenswert Zustand.

   • " httpd: gefangen SIGBUS bei dem Versuch, den Kern in ... "

7. Infos :

   Informativ [und unauffällig].

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

8. Fehlersuche :

   Meldungen auf Debug-Ebene [, d. h. Meldungen, die zu Zwecken der Entstörung )].

   • " Öffnen der Konfigurationsdatei ... "

9. Spur1 → Spur6 :

   Trace-Meldungen [, d. h. Meldungen, die zu Zwecken der Rückverfolgung ].

   • " Vollmacht: FTP: Kontrollverbindung vollständig "
   • " Proxy: CONNECT: Senden der CONNECT-Anfrage an den entfernten Proxy "
   • " openssl: Handshake: Start "
   • " Lesen von gepufferter SSL-Brigade, Modus 0, 17 Bytes "
   • " map lookup FAILED: map=rewritemap key=keyname "
   • " Cache-Lookup FAILED, erzwingt neuen Map-Lookup "

10. Spur7 → Spur8 :

    Trace-Nachrichten, Dumping großer 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-Protokollierung: §

1. tödlich :

   Schwere Fehler, die zu einem vorzeitigen Abbruch führen. Diese sollten sofort auf einer Statuskonsole sichtbar sein.

2. Fehler :

   Andere Laufzeitfehler oder unerwartete Bedingungen. Erwarten Sie, dass diese sofort auf einer Statuskonsole angezeigt werden.

3. warnen :

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

4. Infos :

   Interessante Laufzeitereignisse (Starten/Herunterfahren). Erwarten Sie, dass diese sofort auf einer Konsole sichtbar sind, also seien Sie vorsichtig und beschränken Sie sich auf ein Minimum.

5. Fehlersuche :

   detaillierte Informationen über den Fluss durch das System. Diese sollten nur in Protokolle geschrieben werden.

6. Spur :

   ausführlichere Informationen. Diese werden voraussichtlich nur in Protokolle geschrieben.

Die Apache-Commons-Logging-"Best Practices" für den Unternehmenseinsatz unterscheiden zwischen Fehlersuche y Infos je nachdem, welche Grenzen sie überschreiten.

Die Grenzen umfassen:

• Externe Grenzen - erwartete Ausnahmen.

• Externe Grenzen - Unerwartete Ausnahmen.

• Interne Grenzen.

• Signifikante interne Grenzen.

(Siehe commons-logging-leitfaden für weitere Informationen dazu).