it-swarm.com.de

Wann sind die verschiedenen Protokollebenen zu verwenden?

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?

440
raoulsson

Ich stimme im Allgemeinen der folgenden Konvention zu:

  • Trace - Nur wenn ich den Code "verfolgen" und versuchen würde, einen Teil einer bestimmten Funktion zu finden.
  • Debug - Informationen, die nicht nur Entwicklern (IT, Systemadministratoren usw.) diagnostisch hilfreich sind.
  • Info - Allgemein nützliche Informationen zum Protokollieren (Dienststart/-stopp, Konfigurationsannahmen usw.). Informationen, die ich immer zur Verfügung haben möchte, die mir aber normalerweise egal sind. Dies ist meine Out-of-the-Box-Konfigurationsebene.
  • Warnen - Alles, was möglicherweise zu Unregelmäßigkeiten bei der Anwendung führen kann, für das ich mich jedoch automatisch erholt habe. (Z. B. Wechsel von einem primären zu einem Sicherungsserver, Wiederholen eines Vorgangs, Fehlen von sekundären Daten usw.)
  • Fehler - Jeder Fehler, der für Vorgang schwerwiegend ist, jedoch nicht für den Dienst oder die Anwendung (erforderliche Datei, fehlende Daten usw. können nicht geöffnet werden). Diese Fehler erzwingen einen Benutzereingriff (Administrator oder direkter Benutzer). Diese sind normalerweise (in meinen Apps) für falsche Verbindungszeichenfolgen, fehlende Dienste usw. reserviert.
  • Fatal - Ein 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 Datenverfälschungen oder Datenverluste garantiert sind.
640
GrayWizardx

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

  • ja -> fehler
  • nein -> warnen
285
pm100

Ich finde es hilfreicher, beim Anzeigen der Protokolldatei über Schweregrade nachzudenken.

Fatal/Critical: Allgemeiner Anwendungs- oder Systemfehler, der sofort untersucht werden sollte. Ja, wach den SysAdmin auf. Da wir unsere SysAdmins als wachsam und ausgeruht bevorzugen, sollte dieser Schweregrad sehr selten verwendet werden. Wenn es täglich passiert und das kein BFD ist, hat es keine Bedeutung mehr. In der Regel tritt ein schwerwiegender Fehler nur einmal in der Prozesslebensdauer auf. Wenn die Protokolldatei an den Prozess gebunden ist, ist dies in der Regel 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. Die Verfolgung der Fehlerraten im Vergleich zur Anwendungsnutzung kann nützliche Qualitätsmetriken wie MTBF zur Beurteilung der Gesamtqualität liefern. Diese Metrik kann beispielsweise hilfreich sein, um Entscheidungen darüber zu treffen, ob ein weiterer Betatestzyklus durchgeführt wird oder nicht wird vor einer Veröffentlichung benötigt.

Warnung: Dies KANN 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 gefiltert ist, um nur Warnungen und Fehler anzuzeigen, kann einen schnellen Einblick in frühe Hinweise auf die Grundursache eines nachfolgenden Fehlers geben. 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 Info in einer Desktop-App sein, die für gelegentlich nicht verbundene Laptop-Benutzer konzipiert ist.

Info: Dies sind wichtige Informationen, die unter normalen Bedingungen protokolliert werden sollten, z. B. erfolgreiche Initialisierung, Starten und Beenden 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 auch auftretende Warnungen oder Fehler zu verstehen. Haben Sie nicht zu viele Info-Nachrichten. Wir haben in der Regel <5% Info-Nachrichten in Bezug auf Trace.

Trace: Trace ist mit Abstand 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 mit der Zeit ändern kann, wenn sich Programme weiterentwickeln. Der beste Weg, dies zu erreichen, besteht darin, das Entwicklerteam daran zu gewöhnen, regelmäßig Protokolle zu überprüfen, um von Kunden gemeldete Probleme zu beheben. Ermutigen Sie das Team, Trace-Nachrichten zu entfernen, die keinen nützlichen Kontext mehr bieten, und gegebenenfalls Nachrichten hinzuzufügen, um den Kontext nachfolgender Nachrichten zu verstehen. Beispielsweise ist es häufig hilfreich, Benutzereingaben wie das Ändern von Anzeigen oder Registerkarten zu protokollieren.

Debug: Wir betrachten Debug <Trace. Der Unterschied besteht darin, dass Debug-Meldungen aus Release-Builds kompiliert werden. Wir raten jedoch von der Verwendung von Debug-Meldungen ab. Das Zulassen von Debug-Nachrichten führt dazu, dass immer mehr Debug-Nachrichten hinzugefügt und nie mehr entfernt werden. Dies macht Protokolldateien mit der Zeit fast unbrauchbar, da es zu schwierig ist, das Signal aus dem Rauschen herauszufiltern. Das 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, sie 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, der nicht im Release-Build enthalten ist, auftreten können. Ja, ich weiß, dass das in gutem Code nicht passieren sollte, aber sicherer als leid.

118
Jay Cincotta

Hier ist eine Liste der "Logger".


Apache log4j: §1 , §2

  1. FATAL:

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

    [ v2.0: ..] schwerer Fehler, der verhindert, dass die Anwendung fortgesetzt wird.

  2. ERROR:

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

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

  3. WARN:

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

    [ v2.0: ..] Ereignis, das möglich sein könnte [ sic] zu einem Fehler führen.

  4. INFO:

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

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

  5. DEBUG:

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

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

  6. TRACE:

    [ v1.2: ..] feinere Informationsereignisse als das DEBUG.

    [ v2.0: ..] fein abgestimmte Debug-Meldung, die normalerweise den Fluss durch die Anwendung aufzeichnet.


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

  1. emerg :

    Notfälle - System ist unbrauchbar.

  2. alert :

    Es muss sofort etwas unternommen werden [aber das System ist noch verwendbar].

  3. crit :

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

    • " Socket: Socket konnte nicht abgerufen werden, Kind wird beendet"
  4. Fehler :

    Fehlerzustände [aber nicht kritisch].

    • " Vorzeitiges Ende der Skript-Header"
  5. warn :

    Warnbedingungen. [fast ein Fehler, aber kein Fehler]

  6. Hinweis :

    Normaler, aber signifikanter [ bemerkenswert ] Zustand.

    • " httpd: caught SIGBUS, versucht, den Kern in ..."
  7. info :

    Informativ [und nicht notierbar].

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

    Nachrichten auf Debug-Ebene [ d. H. Nachrichten, die zum Zwecke des De-Bugging)] protokolliert wurden.

    • " Konfigurationsdatei öffnen ..."
  9. trace1 trace6 :

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

    • " Proxy: FTP: Kontrollverbindung abgeschlossen"
    • " proxy: CONNECT: Sendet die CONNECT-Anfrage an den Remote-Proxy"
    • " openssl: Handshake: start"
    • " Aus gepufferter SSL-Brigade lesen, Modus 0, 17 Bytes"
    • " Map Lookup fehlgeschlagen: map=rewritemapkey=keyname "
    • " Cache-Suche fehlgeschlagen, neue Kartensuche erzwungen"
  10. trace7 trace8 :

    Verfolgen Sie Nachrichten und speichern 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 :

    Schwerwiegende Fehler, die zu einer vorzeitigen Beendigung führen. Erwarten Sie, dass diese sofort auf einer Statuskonsole angezeigt werden.

  2. Fehler :

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

  3. warn :

    Verwendung veralteter APIs, schlechte API-Nutzung, "Fast" -Fehler, andere unerwünschte oder unerwartete Laufzeitsituationen, die jedoch nicht unbedingt "falsch" sind. Erwarten Sie, dass diese sofort auf einer Statuskonsole angezeigt werden.

  4. info :

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

  5. Debug :

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

  6. trace :

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

Apache Commons-Logging "Best Practices" für die Verwendung in Unternehmen unterscheidet zwischen Debug und Info basierend auf welche Art von Grenzen sie überschreiten.

Grenzen umfassen:

  • Außengrenzen - Erwartete Ausnahmen.

  • Außengrenzen - unerwartete Ausnahmen.

  • Interne Grenzen.

  • Bedeutende innere Grenzen.

(Siehe Commons-Logging-Anleitung für weitere Informationen dazu.)

25
Pacerier

Wenn Sie das Problem beheben können, handelt es sich um eine Warnung. Wenn dies die Fortsetzung der Ausführung verhindert, liegt ein Fehler vor.

Ich würde empfehlen, die 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 ausreichend differenzierte Schweregrade bereitstellen und werden von vorhandenen Protokollparsern erkannt. Während Sie natürlich die Freiheit haben, nur eine Teilmenge zu implementieren, z. DEBUG, ERROR, EMERGENCY abhängig von den Anforderungen Ihrer App.

Lassen Sie uns auf etwas standardisieren, das es schon seit Ewigkeiten gibt, anstatt für jede App, die wir erstellen, unseren eigenen Standard zu entwickeln. Sobald Sie mit dem Aggregieren von Protokollen begonnen haben und versuchen, Muster in verschiedenen Protokollen zu erkennen, hilft dies wirklich.

22
kvz

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

Nehmen wir zum Beispiel an, Sie geben den Namen "Angela Müller" In Ihre Anwendung ein/importieren ihn (beachten Sie den Umlaut über dem u). Ihr Code/Ihre Datenbank ist möglicherweise nur in Englisch (obwohl es wahrscheinlich sollte nicht heutzutage sein) und könnte daher warnen, dass alle "ungewöhnlichen" Zeichen in normale englische Zeichen konvertiert wurden.

Vergleichen Sie dies mit dem Versuch, diese Informationen in die Datenbank zu schreiben und 60 Sekunden lang eine Netzwerkausfallnachricht abzurufen. Das ist eher ein Fehler als eine Warnung.

16
paxdiablo

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

In der Entwicklung verwende ich häufig Warnungen, bei denen ich das Äquivalent eines Assertionsfehlers angeben kann, die Anwendung jedoch weiterarbeiten kann. Auf diese Weise kann ich herausfinden, ob dieser Fall tatsächlich eintritt oder ob ich es mir eingebildet habe.

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

5

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 für einen Bediener, der möglicherweise verschiedene Aktionen und Benachrichtigungen auslöst, nützliche Warnebenen sein können, ist es für einen Anwendungsadministrator dasselbe TÖDLICH. Und ich kann einfach nicht genug unterscheiden, ob ich eine Kündigung oder eine Information bekomme. Wenn die Information nicht bemerkenswert ist, ist sie nicht wirklich eine Information :)

Jay Cincottas Interpretation gefällt mir am besten: Die Nachverfolgung der Ausführung Ihres Codes ist für den technischen Support sehr nützlich, und das großzügige Einfügen von Trace-Anweisungen in den Code sollte gefördert werden - insbesondere in Kombination mit einem dynamischen Filtermechanismus zum Protokollieren der Trace-Nachrichten von bestimmten Anwendungskomponenten. Allerdings zeigt mir die DEBUG-Stufe, dass wir immer noch dabei sind, herauszufinden, was vor sich geht. Ich sehe die Ausgabe auf DEBUG-Stufe als reine Entwicklungsoption und nicht als etwas, das jemals in einem Produktionsprotokoll auftauchen sollte.

Es gibt jedoch eine Protokollierungsstufe, die ich in meinen Fehlerprotokollen sehen möchte, wenn ich den Hut eines Systemadministrators ebenso trage 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) Aufgaben-ID und der Aufgabenerfüllung. Es wird verwendet, wenn z.B. Eine eigenständige Aufgabe wird ausgelöst. Dies ist eine echte Aufforderung aus der größeren, lang laufenden App heraus. Es ist die Art von Dingen, die ich immer protokollieren möchte, egal ob etwas schief geht oder nicht, daher betrachte ich die Stufe von OPER als höher als FATAL, sodass Sie sie nur ausschalten können, indem Sie in den Modus "Total Silent" wechseln. Dabei handelt es sich um weit mehr als nur INFO-Protokolldaten - eine Protokollstufe, die häufig zum Versenden von Spam-Protokollen mit geringfügigen Betriebsmeldungen ohne historischen Wert missbraucht wird.

Je nach Erfordernis können diese Informationen an ein separates Aufrufprotokoll weitergeleitet oder durch Herausfiltern aus einem großen Protokoll abgerufen werden, in dem weitere Informationen aufgezeichnet werden. Aber es ist immer notwendig, als historische Information zu 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 und nicht wirklich in die oben genannten Ebenen passt ( da es einen eigenen Kontrollschalter benötigt, keine Schweregradklassifizierung) und auf jeden Fall eine eigene separate Protokolldatei benötigt.

4
volkerk

Von Ietf - Seite 10

Each message Priority also has a decimal Severity level indicator.

Diese sind in der folgenden Tabelle mit ihren Zahlenwerten 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
3
ThangTD

Ein Fehler ist etwas, das falsch ist, einfach falsch, es muss behoben werden.

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

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

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

Ich stimme den anderen vollkommen 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, sodass es nicht so schwer sein kann. Im Zweifelsfall behandeln Sie es wie ein Puzzle. Denken Sie für Ihr bestimmtes Projekt an alles, was Sie protokollieren möchten.

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

Ok, das ist fatal, 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 irren Sie "nach oben". Nicht sicher, ob es Info oder Warnung ist? Dann mache es zu einer Warnung.

Ich denke, dass Fatal und Irrtum für uns alle klar sein sollten. Die anderen mögen unschärfer sein, aber es ist wohl weniger wichtig, sie richtig hinzubekommen.

Hier sind einige Beispiele:

Fatal - Speicher, Datenbank usw. können nicht zugewiesen 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%).

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

Debug - Dump der internen Datenstruktur, Anything Trace Level mit Dateiname & Zeilennummer.
Trace - Aktion erfolgreich/fehlgeschlagen, d/b aktualisiert.

3
Mawg

Ich habe immer darüber nachgedacht, die erste Protokollebene zu warnen, die auf jeden Fall ein Problem bedeutet (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 impliziert für mich, dass das Hauptziel der Software jetzt unmöglich ist und wir versuchen, sie sauber herunterzufahren.

3
dicroce

Tag auch,

Als Folge dieser Frage sollten Sie Ihre Interpretationen der Protokollebenen kommunizieren und sicherstellen, dass alle Personen in einem Projekt in ihrer Interpretation der Ebenen übereinstimmen.

Es ist schmerzhaft, eine Vielzahl von Protokollnachrichten zu sehen, bei denen der Schweregrad 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

2
Rob Wells

Ich habe Systeme gebaut, die folgendes verwenden:

  1. FEHLER - Bedeutet, dass etwas ernsthaft falsch ist und dass ein bestimmter Thread/Prozess/eine bestimmte Sequenz nicht weitermachen kann. Einige Benutzer/Administratoren-Eingriffe sind erforderlich
  2. WARNUNG - Es stimmt etwas nicht, aber der Vorgang kann fortgesetzt werden (z. B. ist ein Auftrag in einem Satz von 100 fehlgeschlagen, der Rest kann jedoch verarbeitet werden).

In den von mir erstellten Systemen wurden Administratoren angewiesen, auf FEHLER zu reagieren. Auf der anderen Seite würden wir nach WARNUNGEN Ausschau halten und für jeden Fall feststellen, ob Systemänderungen, Neukonfigurationen usw. erforderlich sind.

1
Brian Agnew

Ü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 einige Debug-Informationen zur Warnung wünschen, die Warnung jedoch nicht erneut erstellen können?

Capture alles und später filtern!

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 die Ablaufverfolgung möglicherweise neu gestalten, um sie effizienter zu gestalten, oder die Ablaufverfolgung beeinträchtigt das Timing (Sie könnte ein Debuggen auf einem leistungsstärkeren Prozessor in Betracht ziehen, aber das eröffnet eine ganze Reihe weiterer Würmer).

Capture alles und später filtern !!

(Übrigens, Capture Everything ist auch gut, weil Sie damit Tools entwickeln können, die mehr als nur Debug-Trace anzeigen Zukunft (Bewahren Sie alle Protokolle auf, ob bestanden oder nicht, und achten Sie darauf, die Build-Nummer in die Protokolldatei aufzunehmen).

1
Mawg

Ich schlage vor, nur drei Ebenen zu verwenden

  1. Fatal - Was die Anwendung stören würde.
  2. Info - Info
  3. Debuggen - Weniger wichtige Informationen
0
user1782556