Thema: Logging Strategie
Das Thema Loggin hat viele Dimensionen. Folgende Punkte wurden diskutiert:
- Logging in Applikationen vs. Logging in Libraries: Libraries sollten nicht selbst bis zur Oberflaeche loggen, sondern ihr Logging an die Host-Applikation delegieren (callback, delegate).
- Tracing: zusaetzlich zum Logging braucht man manchmal Tracing, d.h. jede Methode meldet Einsprung und Aussprung.
- Multithread-save Logging
- Loglevel: wir verwenden folgende Loglevel: Fatal, Error, Warning, Debug, Info, Verbose, Trace, VeryVerbose
- Bedeutung der Loglevel sollte ueber eine gesamte Applikation hinweg aehnlich sein.
- Channels; Logging braucht Channels damit Logging-Quellen getrennt (gefiltert) werden koennen. Man will zB nicht eine gesamte Applikation auf VeryVerbose schalten, sondern nur eine Klasse oder ein Modul. Der Klassen name als Channel ist ein guter Ansatz. Das muss dann manchmal verfeinert werden.
- Syslog/EventLog: Logging auf einen Systemdienst.
- TCP/MsgQ: Logging auf eine Netzwerkverbindung an einen Logserver.
Logging sollte immer mitgefuehrt werden, nicht erst, wenn es Probleme gibt oder gar nach dem Deployment. - Problem und Loesung von Logging in Libraries ist verwandt mit Konfiguration in Libraries.
- Daten fuer Verbose und VeryVerbose levels sollten nur dann erzeugt werden, wenn entsprechende Level aktiviert sind.
Loglevel-Bedeutungen bei bluehands:
- Fatal: wenn die Applikation beenden muss
- Error: Fehler, der zum Funktionsabbruch fuehrt
- Warning: Fehler oder schlechte Datenlage, die behoben werden kann
- Debug: temporaerer Level fuer printf-Debugging. (Auskommentieren, drin stehen lassen)
- Info: regelmaessige (wichtige) Systemzustaende und Aenderungen
- Verbose: Verarbeitungsverlauf, 10-100 Zeilen pro Sekunde
- VeryVerbose: 1000 Zeilen pro Sekunde
_happy_coding()
Keine Kommentare:
Kommentar veröffentlichen