[Featurewunsch] Log je LBS

[starwarsfan]

Hallo Christian,

da ich gerade mit (m)einem LBS kämpfe, vermisse ich ein sicherlich auch für andere (Entwickler) praktisches Feature: Es wäre super, wenn man irgendwie LBS-spezifisch loggen könnte. Das alleinige Tracelog hilft mir nicht so recht weiter, da das einfach zu gross wird. Innerhalb eines Tages kommen da an die 25M zusammen und das lässt sich dann nicht mehr wirklich vernünftig verwenden.

Vielleicht ist es ja möglich, ein Option in der Art "logPerLBS=true|false" einzuführen, mit welcher es zusätzliche Tracelogs je LBS gibt, wenn in das Tracelog geschrieben wird!?

Und wenn ich grad dabei bin: Desweiteren wäre es ebenfalls sehr praktisch, wenn man die Logs auch im Browser in Echtzeit sehen könnte. Jenkins macht das bspw. auch, so dass man sich live den Output der Buildjobs ansehen kann, ohne ständig den Browser refreshen zu müssen.

[Stoxn]

Haha, da ich auch gerade kämpfe: Kann man das Trace Log löschen?

[vento66]

Ja, die Tracelog.htm im Ordner /usr/local/edomi/www/data/log löschen.

[Stoxn]

Das war einfach - bedankt!

[gaert]

Man kann sich auch totloggen Ich sach' ma so: Meine Logs sind im Prinzip leer. Sobald z.B. ein neuer LBS hinreichend getestet ist, nehme ich das Logging komplett raus - es werden höchstens noch schwere Fehler geloggt (die es ja nicht gibt...).

[coliflower]

Ja, die Tracelog.htm im Ordner /usr/local/edomi/www/data/log löschen.

Oder Edomi neu starten ...

[starwarsfan]

Hallo Christian

Man kann sich auch totloggen

OK, ein Smiley an dieser Stelle...

Ich sach' ma so: Meine Logs sind im Prinzip leer. Sobald z.B. ein neuer LBS hinreichend getestet ist, nehme ich das Logging komplett raus - es werden höchstens noch schwere Fehler geloggt (die es ja nicht gibt...).

Also wenn ich sowas lese, dann stellen sich mir als Softwareentwickler sämtliche Nackenhaare auf! Ich komme nicht umhin, das als eine php-Schwäche zu sehen, denn warum um alles in der Welt sollte man das Logging wieder entfernen, nachdem eine Software getestet wurde? Gibt es in php kein brauchbares Log-Framework? Wenn ich soetwas machen würde, würde man mich achtkantig vom Hof jagen! Die Software ist danach schlicht und einfach nicht mehr getestet, da der Code verändert wurde. Da kann man tausendmal sagen, dass da "nur" die Log-Statements entfernt wurden.

Ich habe schon Pferde kotzen sehen, direkt vor der Apotheke... Bitte nicht persönlich nehmen, mich regt das nur gerade mächtig auf...

Die eigentliche Frage ist jedoch eine andere: Hast Du überhaupt gelesen, worum es mir mit dem Feature-Request ging? Wie Du das handhabst ist ja interessant, nur ist das im beschriebenen Problemfall irrelevant! Es ist einfach mühsam, wenn man sich als Entwickler durch Megabytes an Logfiles wühlen muss, welche sich zudem als Plaintext ebenfalls sehr mühsam lesen lassen, da sie ja nunmal puren html-Code enthalten. Im Moment muss ich entweder ständig den Browser refreshen, was bedingt durch die Log-Grösse sehr lange dauert oder auf der Commandline mit dem html-Content leben. Beides ist nicht wirklich brauchbar, wenn man effizient arbeiten will und das ist gerade in der immer knapp bemessenen Freizeit ein sehr wichtiger Punkt.

Ich würde mich freuen, wenn Du Dir das nochmal durch den Kopf gehen lassen würdest, denn nach wie vor ist das Projekt sensationell und ich möchte es nicht mehr missen.

[gaert]

Ich als Softwareentwickler sehe dies ein wenig anders... Sobald meine Software (hier: LBS) funktioniert, brauche ich kein (Fehler)Log mehr - es sei denn, es tritt ein Fehler auf Ziel meiner Strategie bei der Softwareentwicklung ist es jedoch, dass keine Fehler auftreten... Ergo wird i.d.R. auch nichts geloggt. Es sei denn, es tritt ein Fehler auf - GOTO 1

Ich frage mich, wie man ein 25MB Logfile erzeugt - bzw. warum?! Während der Entwicklung ist dies natürlich vollkommen in Ordnung, aber sobald ein LBS produktiv eingesetzt wird, darf das Log m.E. absolut leer bleiben (außer im Fehlerfall natürlich).

EDIT:
Wenn Du unbedingt zusätzliche Logs brauchst: Warum implementierst Du dies nicht einfach selbst?! Was spricht dagegen einfach irgendwelche Logs z.B. in /data/log anzulegen?

[Stoxn]

...bin kein Entwickler, baue aber auch gerade einen LBS in einer VM. Während der Entwicklung bombe ich natürlich das Log File zu, weiß aber jetzt, wie ich es vor dem nächsten Aktivieren wieder lösche.

Debug-Logs können am LBS Eingang ein- und ausgeschaltet werden. Sollte ich das Teil jemals fertigstellen , würde ich den Log in der Produktivumgebung ebenfalls abschalten (leeres Log = alles Tutti).
Fehler werden natürlich immer ausgegeben, sonst bekomme ich ja nicht mit, wenn was schief steht. Muss ja nicht am eigenen Quelltext liegen, sondern an nicht erreichbarem Service, einer geänderten API etc. Je nach Szenario kannst Du Fehler ja auch auf einen Ausgang legen und Dir in ein Meldungsarchiv schreiben, per Telegram schicken, ...

Vorschlag: Nutze doch einen Log-Level (ein/aus, 0-5 etc.) und schreibe Deine Logs abhängig davon. Rausschmeißen würde ich die Meldungen im Übrigen auch nicht.

[starwarsfan]

Hallo

Ich als Softwareentwickler sehe dies ein wenig anders... Sobald meine Software (hier: LBS) funktioniert, brauche ich kein (Fehler)Log mehr - es sei denn, es tritt ein Fehler auf

Ja klar, dann änderst Du den Code nochmals und gehst davon aus, dass das korrekt ist? Ich kann's nicht glauben. Hast Du schonmal mit CI oder gar CD gearbeitet?

Ziel meiner Strategie bei der Softwareentwicklung ist es jedoch, dass keine Fehler auftreten... Ergo wird i.d.R. auch nichts geloggt. Es sei denn, es tritt ein Fehler auf - GOTO 1

Und genau dafür braucht es vernünftiges Logging resp. ein brauchbares Framework denn wenn es ein Problem gibt, dann schaltet man das Loggin einfach ein und ändert nicht den Code!

Ich frage mich, wie man ein 25MB Logfile erzeugt - bzw. warum?!

Das frage ich mich auch! Mich interessieren nur die Meldungen meines LBS, darum ja auch der Feature-Request. Das Tracelog besteht aber zu 99% nur aus irgendwelchen anderen Meldungen, welche ich eben in diesem Zusammenhang nicht sehen will.

Während der Entwicklung ist dies natürlich vollkommen in Ordnung, aber sobald ein LBS produktiv eingesetzt wird, darf das Log m.E. absolut leer bleiben (außer im Fehlerfall natürlich).

Genau darum geht es, um Logs je nach Anwendungsfall und das ist hier die Entwicklung!

EDIT:
Wenn Du unbedingt zusätzliche Logs brauchst: Warum implementierst Du dies nicht einfach selbst?! Was spricht dagegen einfach irgendwelche Logs z.B. in /data/log anzulegen?

So wird's wohl werden, nur wäre das eine Notlösung. Mir geht es eigentlich darum, es auch für andere Entwickler einfacher zu machen.

Aber mir soll's recht sein, dann programmiere ich eben um die Basisanwendung drumrum...

[gaert]

Ich verstehe Dein Problem nicht... Das TraceLog ist dazu da während der Entwicklung(!) temporär etwas zu tracen - mangels Möglichkeit der Ausgabe auf der Konsole. Das FehlerLog soll nur Fehler enthalten, dies natürlich auch im produktiven Einsatz.

Sobald die Entwicklung abgeschlossen ist, sollte das tracen vermieden werden - denn sonst wird das TraceLog beim Endanwender zugemüllt und dieser ist wohl kaum an internen Debugmeldungen interessiert.

Was Du während der Entwickung loggst ist Dir überlassen. Aber sobald der LBS öffentlich wird, muss das Logging deaktiviert werden - mit Ausnahme von Fehlern, die für den Nutzer von Bedeutung sind.

So ist das Design, basta! Ich sag's auch gerne nochmal: EDOMI ist keine Entwicklungsumgebung... Dafür gibt's andere Tools.

EDOMI ist als Endkundenprodukt zu verstehen, so wie Word... Oder loggt Word irgendwelche internen Fehler?!

[starwarsfan]

Also egal was ich vorschlage, bei Dir fahre ich mit nahezu 100%iger Sicherheit gegen einen Baum. Ist hier nicht das erste Mal, seltsam... Wir sollten unbedingt mal ein Bier zusammen trinken, irgendwo klemmt da noch was...

Anyway, dann hole ich mal noch etwas weiter aus:

Wenn ich das Tracelog aktiviere, dann wird alles dort rein geschrieben, was da eben so als Trace-Meldung kommt. Genau das ballert mir aber das Log bis zum Exzess voll, obwohl mein Setup ansonsten super funktioniert (oder ich habe noch nicht gefunden, was nicht funktioniert). Genau aus dieser Überlegung heraus entstand mein Vorschlag, eine einfache Möglichkeit zu haben, Logs je LBS zu schreiben. Da das Ganze schlussendlich über die writeToTracelog-Funktion geht, wäre das auch nur dann aktiv, wenn das Tracelog aktiviert ist. Damit wäre das LogPerLBS eine Art Zusatzfunktion zum aktivierten Tracelog, nicht mehr, nicht weniger.

In vielen (Community-)LBS ist es so, dass das Logging via separatem Eingang ("Debug") aktiviert werden kann und ich habe das bei meinen LBS'en auch so implementiert. Gerade wenn man bspw. auf Input anderer Anwender zurückgreifen möchte, kann man damit sagen "Schalt doch mal den Debug-Modus ein und schick mir das Log".

Ist das für Dich so abwegig?

[gaert]

Ist das so?! Empfinde ich ehrlich gesagt nicht so... Ich bin für jeden Vorschlag offen!

In diesem Fall sehe ich nur wenig Sinn in einer Umsetzung Deiner Idee. Nicht, dass dies grundsätzlich eine schlechte Idee wäre - das Problem ist eher folgendes: Das Logging soll so sparsam wie möglich sein, schließlich soll EDOMI dauerhaft die Hüdde steuern und nicht als Testumgebung für irgendwelche LBS dienen. Nur im Notfall (Fehler) oder zu temporären Debuggingzwecken (MonitorLog) soll geloggt werden.

Beispiel: Ein LBS, der irgendwelche Webdienste abfragt. Nun ist der Webdienst nicht erreichbar - muss das unbedingt mit 100 Einträgen geloggt werden? Wäre da nicht ein Ausgang "Webdienst nicht erreichbar 0/1" sinnvoller? Ich meine eindeutig: Ja!

Und genau aus diesen Gründen möchte ich das Logging nicht "zu komfortabel" machen, denn sonst ist der Reiz zu groß, die Logs mit sinnlosen Meldungen zu fluten.

Während(!) der Entwicklung ist das natürlich etwas anderes - logisch. Ich schreibe meine Trace-Infos z.B. einfach in eine Textdatei in /tmp (also ausserhalb vom EDOMI-Universum). Wenn der LBS dann fertig ist, wird dieses ganze Tracing entfernt, denn der LBS soll den User nicht mit irgendwelchen Meldungen belästigen sondern einfach funktionieren Oder eben wie erwähnt seinen Fehlerausgang setzen - so wie es jede moderne Software macht... (für Endanwender)

Also:
Wenn Du Wert auf's Logging legst, dann kannst Du doch einfach ein eigenes Log erstellen - sind doch nur 3 Zeilen Code. Wenn Du die Datei in data/tmp ablegst, wird diese bei jedem Start von EDOMI gelöscht. Wenn Du sie in data/log ablegst, bleibt die Datei für immer erhalten und muss manuell gelöscht werden.

[heckmannju]

Hi,
reden wir von logging oder tracing? Wenn zuviel im Tracing landet sollte man das vielleicht abstellen, nicht Lösschen oder Auskommentieren weil das könnte man ja noch mal brauchen sondern weg konfigurieren. Beim Logging macht es für mich schon sinn das u.u in einem seperaten File zu halten. Z.b. man hat ein LBS welches den Fenster Status auswertet. In diese schreibt man rein wann ein Fenster auf und zu gemacht wird mit Zeitstempel das will ich jetzt natürlich nicht in einem Monsterlog sondern in einen eigenen. Das kann man sich jetzt jeder selber basteln oder auf was vom System zurückgreifen.
VG
Jürgen

[gaert]

Und was soll das bringen (Fenster-Log)?! Dafür gibt es doch Datenarchive, Meldungsarchive oder das MonitorLog (zum Debuggen). So ein Log ist eine Einbahnstraße...

Warum schreibt Ihr nicht einfach einen Log-LBS - ist ja nicht so kompliziert E1=Message, E2=Filename, etc...