https://wiki.stellsi.de/index.php?action=history&feed=atom&title=Development%3AAnforderungen_Logging 2026-04-06T08:49:16Z Versionsgeschichte dieser Seite in StellSi-Hilfewiki MediaWiki 1.39.1 https://wiki.stellsi.de/index.php?title=Development:Anforderungen_Logging&diff=199&oldid=prev 2015-08-15T08:13:18Z

<p>Die Seite wurde neu angelegt: „= Vorwort = Ich beschreibe hier einen Sollzustand zur Diskussion, ohne den Istzustand zu berücksichtigen. Dass ggf. das ein oder andere schon umgesetzt wurde…“</p> <p><b>Neue Seite</b></p><div>= Vorwort =<br /> 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 :-)<br /> = Überlegungen =<br /> * Realisierung als Singleton (Verfügbarkeit immer und überall auf geregelte Art)<br /> * Trennung Model - View<br /> * Realisierung unterschiedlicher Loggingstufen (Temporary, evtl. Debug_cyclic, Debug, Info, Warnung, Fehler, Fatal Error)<br /> ** 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)<br /> * Realisierung unterschiedlicher Loggingarten:<br /> ** Programmfehler<br /> ** stwb/Scripting-Fehler (gemeldet durch das PRogramm)<br /> ** Ausgaben durch Logging-Funktion im Script<br /> * Implementierung eines Filters im View, der nach Loggingstufen und Loggingarten filtert. <br /> * Standardmäßig werden Debug-Ausgaben im Model entweder nicht erfasst oder mengenmäßig limitiert (Performance). Das lässt sich umschalten.<br /> <br /> = Performance, Verhinderung von Logfluten =<br /> Das Fluten des Logs muss vermieden werden. Zyklische Nachrichten dürfen nur mit Logstufe Temporary ausgegeben werden. <br /> <br /> 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.<br /> <br /> Sollte es möglich sein, das Erstellen des String-Objekts zu verhindern, kann über eine weitere Debug-Stufe (Debug_cyclic) nachgedacht werden.<br /> <br /> = Erfasste Daten =<br /> Jede Lognachricht wird in einer eigenen Klasse erfasst. Dabei wird erfasst:<br /> * Uhrzeit<br /> * Logart<br /> * Logstufe<br /> * Lognachricht<br /> * Ggf. Ort des Auftretens (z.B. Quelltextdatei/Zeile)<br /> <br /> Wichtig: Performance (Speicher, Rechenzeit) beachten!<br /> <br /> = Anbindung Views =<br /> Beobachter-Pattern ist aus Performance-Grunden nicht geeignet. <br /> <br /> Der Logger bietet eine Möglichkeit für Views:<br /> * Daten abzurufen (ggf. vorgefiltert)<br /> * Daten zu abonnieren (ggf. mit Filter)<br /> <br /> Neu eintreffende Daten werden dann automatisch an die Views weitergegeben.<br /> <br /> = Views =<br /> Benötigte Views:<br /> * Weiterleitung auf Konsole<br /> * Grafische filterbare Liste<br /> * Export in eine Datei/Upload auf Server/Versand per E-Mail<br /> <br /> = Nett zu haben =<br /> Schafft man es im Fall von Programmabstürzen Daten sowie das Log dazu zu sammeln? <br /> <br /> [[Kategorie:Anforderungen]]<br /> [[Kategorie:Umbauplanung_Boris]]</div>

BorisM