Development:Anforderungen Logging

Vorwort

Ich beschreibe hier einen Sollzustand zur Diskussion, ohne den Istzustand zu berücksichtigen. Dass ggf. das ein oder andere schon umgesetzt wurde ist mir bewusst :-)

Überlegungen

• Realisierung als Singleton (Verfügbarkeit immer und überall auf geregelte Art)
• Trennung Model - View
• Realisierung unterschiedlicher Loggingstufen (Temporary, evtl. Debug_cyclic, Debug, Info, Warnung, Fehler, Fatal Error)
  • Temporary-Logging ist für temporär während der Entwicklung gedacht, die anschließend nicht mehr benötigt werden, und muss in produktiven Versionen ausgebaut sein (Performance-Gründe, Vermeidung von Überfüllung des Loggings)
• Realisierung unterschiedlicher Loggingarten:
  • Programmfehler
  • stwb/Scripting-Fehler (gemeldet durch das PRogramm)
  • Ausgaben durch Logging-Funktion im Script
• Implementierung eines Filters im View, der nach Loggingstufen und Loggingarten filtert.
• Standardmäßig werden Debug-Ausgaben im Model entweder nicht erfasst oder mengenmäßig limitiert (Performance). Das lässt sich umschalten.

Performance, Verhinderung von Logfluten

Das Fluten des Logs muss vermieden werden. Zyklische Nachrichten dürfen nur mit Logstufe Temporary ausgegeben werden.

Auf Debug-Level muss Loggen zyklischer Nachrichten wahrscheinlich weitgehend vermieden werden. Hier ist zu untersuchen, ob es eine Möglichkeit gibt, bei abgeschaltetem Debug-Logging das Erstellen des zu loggenden Strings zu verhindern. Ist die Abfrage, ob geloggt werden soll, erst in der Logging-Funktion selbst, dürfte zuerst das String-objekt erstellt, und dann erst entschieden werden, dass der String nicht genutzt wird. Das ist bisher allerdings eine Vermutung und noch nicht verifiziert.

Sollte es möglich sein, das Erstellen des String-Objekts zu verhindern, kann über eine weitere Debug-Stufe (Debug_cyclic) nachgedacht werden.

Erfasste Daten

Jede Lognachricht wird in einer eigenen Klasse erfasst. Dabei wird erfasst:

• Uhrzeit
• Logart
• Logstufe
• Lognachricht
• Ggf. Ort des Auftretens (z.B. Quelltextdatei/Zeile)

Wichtig: Performance (Speicher, Rechenzeit) beachten!

Anbindung Views

Beobachter-Pattern ist aus Performance-Grunden nicht geeignet.

Der Logger bietet eine Möglichkeit für Views:

• Daten abzurufen (ggf. vorgefiltert)
• Daten zu abonnieren (ggf. mit Filter)

Neu eintreffende Daten werden dann automatisch an die Views weitergegeben.

Views

Benötigte Views:

• Weiterleitung auf Konsole
• Grafische filterbare Liste
• Export in eine Datei/Upload auf Server/Versand per E-Mail

Nett zu haben

Schafft man es im Fall von Programmabstürzen Daten sowie das Log dazu zu sammeln?