Log Level

[Borewa]

Guten Tag,
ich hoffe das passt hier einigermaßen in das Themenbereich.

Für ein kleines Projekt unterteile ich meine Loglevel wie folgt:
0 debug
1 info
2 notice
3 warn
4 error
5 crit

Als Crit Stufe ich alles ein was, was die weiterbearbeitung der Funktion unmöglich macht.

Mein Problem liegt in der Unterscheidung von Warning und Error.
Ich Definiere das zwar alles selber für mich, aber diese LogLevel habe ich so in der Reihenfolge im Internet gefunden und da haben sich ja leute schon ihre Gedanken gemacht, wieso weshalb warum.

Mein Projekt hat viel mit Kunden und Objekten zutun und wie würde man folgende Fehler einstufen:

1. Ein bestimmter Kunde wurde nicht gefunden
2. Keine Gültige PLZ
3. Login inkoreckt
4. Alle Titel (für ein Dropdown) konnten nicht aus der Datenbank geladen
5. es würde kein Titel für den Kunden ausgewählt
6. Benutzername schon vorhanden

Sind nur einige Beispiele und wäre mir nicht sicher ob man da etwas von als Warning einstufen kann, bzw was man überhaupt als Warning einstufen kann.

Zusätzlich stellt sich mir die Frage ob man Daten die aus einem Formular kommen und ein Warning erzeugt haben trotzdem in eine Datenbank schreiben kann oder auch auf eine verbessung warten muss.

Oder kann man auf Warning komplett verzichten und alles zu error machen und wenn z.B. etwas optionales auftritt "Anrede nicht gewählt" dann einfach ein notice erzeugt. Auf eine Anrede bei einem Kunden könnte man noch verzichten, die Angabe wäre aber bzgl. Rechnungen trotzdem nützlich.

Wie gesagt könnte man sagen mach wie du es für richtig hälst, da du es ja selbst definiert, aber andere Menschen haben sich ja schon gedanken über solche Dinge gemacht und dann könnte man diese Gedankengänge und Erkenntnisse nutzen.

[pgoetz]

Servus,

[...]
Für ein kleines Projekt unterteile ich meine Loglevel wie folgt:
0 debug
1 info
2 notice
3 warn
4 error
5 crit

Das ist schon mal eine recht gängige Einteilung, auch wenn ich "notice" und "crit" noch nicht verwendet habe und mit dem Rest (evtl. plus "trace" vor "debug") auskomme.

[...]
Mein Projekt hat viel mit Kunden und Objekten zutun und wie würde man folgende Fehler einstufen:

1. Ein bestimmter Kunde wurde nicht gefunden
2. Keine Gültige PLZ
3. Login inkoreckt
4. Alle Titel (für ein Dropdown) konnten nicht aus der Datenbank geladen
5. es würde kein Titel für den Kunden ausgewählt
6. Benutzername schon vorhanden

Hier kommt es immer auf den Kontext an. Ein fehlender Titel beim Kunden kann bei der einen Anwendung (Anwendungsfall) ein Fehler sein, bei der nächsten ist es nicht mal des debug-Logs wert. Ein Fehler ist etwas, was wirklich schief gegangen ist. Warnings gebe ich in meinen Anwendungen aus, wenn eine Situation eingetreten ist, die später zu einem Fehler werden kann. Dann kann ich über eine vorhandene Warnung den Grund eingrenzen.
Allerdings ist das Logging und die Loglevel eine Wissenschaft für sich. Die einen machen es aus dem Bauch raus, bei den anderen verläuft es nach einem strengen, schriftlich fixierten Konzept.

In meinen Projekten versuche ich, es nicht zu dogmatisch zu sehen, aber eine prinzipielle Ordnung der Level und des Loggings allgemein zu erhalten. Das ist allerdings bei mir wieder Bauchgefühl. :)

Schöne Grüße,

Peter

[Der Martin]

Hallo,

Für ein kleines Projekt unterteile ich meine Loglevel wie folgt:
0 debug
1 info
2 notice
3 warn
4 error
5 crit

sieht nicht schlecht aus, obwohl mir die Einteilung übertrieben fein vorkommt.

Als Crit Stufe ich alles ein was, was die weiterbearbeitung der Funktion unmöglich macht.

Sinnvoll.

Mein Problem liegt in der Unterscheidung von Warning und Error.

Verstehe ich in etwa so:
Error: Das Programm läuft zwar noch kontrollierbar, die Ergebnisse können aber falsch oder unsinnig sein, ohne dass man es ihnen direkt ansieht.
Beispiel: Eine Datei kann wegen Zugriffsbeschränkungen nicht angelegt werden.
Warning: Eine sinnvolle, aber nicht zwingend notwendige Bedingung ist nicht erfüllt, das Programm korrigiert aber selbständig so, dass das Ergebnis immer noch verwertbar ist.
Beispiel: fehlende Eingabe, das Programm verwendet einen Defaultwert.

Oder kann man auf Warning komplett verzichten und alles zu error machen und wenn z.B. etwas optionales auftritt "Anrede nicht gewählt" dann einfach ein notice erzeugt.

Die Unterscheidung zwischen Warning und Notice halte ich auch für sehr schwierig, spitzfindig oder willkürlich.

Wie gesagt könnte man sagen mach wie du es für richtig hälst, da du es ja selbst definiert, aber andere Menschen haben sich ja schon gedanken über solche Dinge gemacht und dann könnte man diese Gedankengänge und Erkenntnisse nutzen.

Schon richtig, aber du musst trotzdem das, was andere sich ausgedacht haben, auf DEIN konkretes Projekt anwenden und anpassen. Dazu gehört genau die Überlegung, die du hier anstellst; und eventuell auch die Erkenntnis, dass nicht alle Stufen in deinem Fall wirklich sinnvoll sind.

So long,
 Martin

[Borewa]

Habe folgendes gefunden:

Error -> Andere Fehlerbedingung
Warning -> Warnmeldung
Notice -> Untersuchungswürdige Ereignisse

[..]
Während der Unterschied zwischen notice und warning (und zwischen warning und error) klar sein dürfte, [..]

Quelle: Linux Administrationsbandbuch

Gerade den unterschied Notice -> Warning finde ich sehr schwer. Und die Kurzbeschreibungen machen es nicht einfacher. Sie definieren den Begriff recht gut, aber so aus der Hand herraus kann ich keinen unterschied zwischen Warnmeldung und Untersuchungswürdige Ereignisse nennen.

Würde sogar sagen das eine Warnmeldung ein untersuchungswürdiges Ereignis ist. Eine Warnung kommt ja nicht ohne Grund ...

Die definition das ein Warning später zu einem Fehler führen könnte finde ich auch nicht schlecht, aber in der Unterteilung Warning / Notice auch nicht hilfreich.

Der schnellste Weg wäre wohl sich entweder oder für Notice oder Warning zu entscheiden.

Als Beispiel wäre ein Crit dann wenn z.B. die Datenbankverbindung nicht hergestellt werden konnte, diese aber unbedingt für den Rest der Funktion genötigt wird.

Ein Error wäre dann ein "normaler" Fehler, womit die Funktion noch ausgeführt werden könnte, z.B. Benutzerdaten stimmten im Login nicht, Kundenname (Pflichtfeld) wurde nicht angegeben, Kundenname ist zu lange oder zu kurz.

Das Warning/Notice wäre dann einfach Schönheitsverbessungen oder Dinge die später zu Fehlern führen KÖNNTEN, z.B. der Titel wurde nicht angegeben (kein Pflichtfeld, aber in Briefen/Rechnungen sieht es ohne Titel komisch aus).

Info würde ich streichen, da es eher Informationen sind Richtung welcher Charset verwendet wird.

Und Debug ist ja so ziemlich alles(vieles) um Fehler zu finden.

Leider stellt sich bei der Einteilung die Frage ob wenn jemand etwas ungültiges eingegeben hat, z.B. zulangen Kundenname oder Buchstaben in der Telefonnummer wirklich ein Error im Log stehen sollte. So wichtig wäre diese Information nicht, aber die Funktion muss "gestoppt" werden, da der Datensatz in diesem Fall nicht in die Datenbank geschrieben werden könnte und vorher vom Benutzer erst korrigiert werden müsste.
Trotzdem muss der Benutzer eine Meldung erhalten was an seinen eingegebenen Daten nicht stimmt.

[ChrisB]

Hi,

Leider stellt sich bei der Einteilung die Frage ob wenn jemand etwas ungültiges eingegeben hat, z.B. zulangen Kundenname oder Buchstaben in der Telefonnummer wirklich ein Error im Log stehen sollte.

Nein.

So wichtig wäre diese Information nicht, aber die Funktion muss "gestoppt" werden, da der Datensatz in diesem Fall nicht in die Datenbank geschrieben werden könnte und vorher vom Benutzer erst korrigiert werden müsste.

„Gestoppt werden“ ist in diesem Zusammenhang eine unglückliche Wortwahl.

Trotzdem muss der Benutzer eine Meldung erhalten was an seinen eingegebenen Daten nicht stimmt.

Das gehört zum definierten und erforderlichen Verhalten der Applikation - natürlich hat sie dem Benutzer zu melden, wenn die eingegebenen Daten ungültig sind und einer Überarbeitung bedürfen.
Es stellt aber keinen *Fehler* der Applikation dar - in dem sie dem Benutzer auf die fehlerhaften Daten hinweist, macht sie exakt ihren Job.

Unterscheide zwischen Fehlern auf Applikationsebene, und schlichten Datenfehlern bei der Plausibilisierung.

MfG ChrisB