Konvention für Logfile-Namen?

[starwarsfan]

Hallo miteinander,

aus gegebenem Anlass würde ich gern darüber diskutieren, ob wir eine Art Konvention für das Naming der Logdateien der LBS einführen sollten. Anlass dazu ist für mich die Verwendung von Spaces in den Dateinamen der Logs, wie das in den Bausteinen von jonofe der Fall ist. Grundsätzlich ist das Leerzeichen in Dateinamen unter Linux ja kein Problem, nur sollte man es dennoch so gut es geht vermeiden. Ich habe bspw. beim escapen in URLs ("%20") schon die schrägsten Dinge erlebt...

Mein Vorschlag wäre eine Erweiterung der Funktion writeToCustomLog(...), welche den ersten Parameter als Ergänzung zum Dateinamen des Logs verwendet und somit auch leer gelassen werden kann. Den Namen des Logfiles generiert die Funktion jedoch selbst und entfernt dabei selbständig Spaces aus dem ersten Parameter der Funktion. Damit entsteht ein Dateiname in der Art

[I]<LBS-ID>_<Baustein-ID>[_<1st-parameter>[/I]]

und der Aufruf von

writeToCustomLog("foo", 0, "some text...");

aus dem Baustein 19004711 mit der ID 42 führt zu einem Logfile mit dem Namen LBS19004711_42_foo.log. Damit wären die Logs vernünftig sortierbar und einheitlich. Gerade dann, wenn man mehrere/viele Bausteine eines Typs hat, macht sich das bezahlt.

Das Dumme dabei ist aber, dass die Funktion writeToCustomLog(...) nicht weiss, aus welchem LBS heraus sie aufgerufen wurde bzw. wird es wohl doch recht Performance kosten, das via debug_backtrace() jeweils zu ermitteln.

Von daher wäre es wirklich eine Konvention und Bitte an alle LBS-Entwickler, sich hier auf eine Konvention zu einigen, diese in die Edomi-Doku einfliesen zu lassen und sie dann natürlich auch zu verwenden. Nach obigem Vorschlag wäre der Aufruf dann also wie folgt:

writeToCustomLog("LBSLBSID_${id}", ...

Was meint ihr dazu?

Kind regards,
Yves

[wintermute]

Hi Yves,

ich persoenlich finde es nicht empfehlenswert die ID pauschal im Logfilenamen zu fuehren. Mal als Beispiel einen Zeitumrechnungs-LBS gedacht, den man evtl sehr haeufig im Projekt hat und bei dem man das Log wirklich nur zum Debuggen braucht, da ist die ID im Filenamen eher im Weg. Fuer solche Bausteine erstelle ich normal nur ein Logfile und schreibe die ID in Klammern vor den Logeintrag, also konkret so:

writeToCustomLog("LBSLBSID",$l,"(ID$id) ".$a[$l].": ".$s); 

(Wobei $a[$l] der ausgeschriebene LogLevel ist und $s die eigentliche Meldung).

Bei anderen Bausteinen macht es allerdings sehr wohl Sinn die ID im Filenamen zu fuehren, spontan fallen mir dazu beispielsweise mein Squeeze-Client LBS oder deine Beschattungssteuerung ein. Ich wuerde also - je nach LBS Typ - eine von beiden Varianten nutzen wollen/werden/tuen.

gruesse :: Michael

[saegefisch]

Hi Yves,

ich sehe Szenarien, in denen mehrere unterschiedliche LBS zum selben Sachverhalt (da modularisiert, z.B. wegen einem generischen Regler-LBS) in das selbe Log schreiben. Das wäre meines Erachtens nicht so glücklich.

Daher würde ich eher vorschlagen, in den V-Variablen ganz oben als Konstante oder auch immer per E (wo es sinnvoll ist) einen Lognamen übergeben zu können, der verwendet wird. Bei meinen mache ich ich das bereits (teilweise) so (z.B: 19000117). Die anderen LBS von mir ziehe ich noch entsprechend nach, wenn ich Ende Januar wieder Zeit für LBS habe. So ist man wunderbar flexibel und doch strukturiert nach Sachverhalt. Ich gehe noch einen weiter: Ich mag bei mir Log und ein Prefix festlegen - genau für diese Szenarien mit mehreren Gleichen oder unterschiedlichen LBS in einem Log zu einem Thema.

Anders gesagt: Ich mag mir zu den Logs gar nicht so recht was vor -Konventionieren lassen... - sorry. Was ich hingen super finde, wenn alle LBS eine einheitliche Mechanik/Festlegung ermöglichen, damit man sich _seine_ Logs so machen, kann, wie man es selber möchte - ohne im Coding herum suchen oder ändern zu müssen. am besten mit Log-Name und Prefix. Dazu eine Konvention oder noch besser in edomi besonders behandelte Eingang, die automatisch immer ganz unten stehen für Verwaltungszwecke (X1 = Loglevel | X2 = Logname oder <leer> für Trace-Log | X3 = Themengruppe im Log | X4 = Prefix eines Eintrags | X5-X9 für weitere spätere übergreifende Zwecke der Zukunft) und X immer unter E im verwendeten LBS und ggf. optisch anders dargestellt)

Beispiel für meine Grunddaten in der DEF - ich lege die Defaults als Entwickler fest und überschreibe je nach Bedarf und Belegung im LBS noch E-Werte zu. Dort lege ich z.B. auch die Wartezeit für deley/usleep zentral und immer an gleicher Stelle fest:

E...
V...
// Grunddaten
[v#100 = 0.1 ]              // Version
[v#101 = 19000117 ]         // LBS
[v#102 = Astro ]            // eigens Log-File oder leer für TraceLog
[v#103 = 2 ]                // LogLevel    
[v#104 =   ]                // PreFix für FehlerLog
[v#105 = Offset  ]          // MainTag für FehlerLog        
[v#106 = 1000 ]             // Wartezeit(ms):Delay(statefull) oder usleep(EXEC) // dieser LBS weder statefull noch EXEC
###[/DEF]###
...
...
            logic_setVar($id,102,$E[<deinE>]['value']);            // LogFile
            logic_setVar($id,103,$E[<deinE>)]['value']);            // LogLevel
            logic_setVar($id,104,$E[<deinE>]['value']);            // LogPreFix
...

Wenn alles immer an gleicher Stelle wäre, wäre mir persönlich das Konvention genug zum Thema Log.

VG,
Carsten

[starwarsfan]

Hallo miteinander,

vielen Dank für die bisherigen Antworten und Meinungen.

Anders gesagt: Ich mag mir zu den Logs gar nicht so recht was vor -Konventionieren lassen...

Das ist auch ganz und gar nicht die Idee hinter dieser Diskussion. Eine Konvention ist ja auch immer irgendwie dehnbar und nicht wirklich eine Vorschrift.

Mir geht's eher drum, nach Möglichkeit (!) eine für alle brauchbare, einheitliche Vorgehensweise zu finden, welche es für den Edomi-User bzw. Edomi-Admin möglichst einfach macht, sich in den Logs zurecht zu finden. Von daher bin ich da völlig schmerzfrei und freue mich über jeden Input sowie die Gedanken hinter der gewählten Vorgehensweise. Mich stören hauptsächlich Spaces in Dateinamen, da es immer wieder irgendwelche Scripte oder dergleichen gibt, die damit auf die Nase fallen. Von daher versuche ich diese selbstgelegten Stolpersteine von vorn herein zu vermeiden und die low hanging fruits einfach mitzunehmen.

Und wenn dabei auch nichts konkretes heraus kommt, so haben doch alle Mitleser zumindest neue/andere Ideen und Gedanken mitgenommen.

[wintermute]

Mich stören hauptsächlich Spaces in Dateinamen, da es immer wieder irgendwelche Scripte oder dergleichen gibt, die damit auf die Nase fallen.

Jo, richtig. Ausserdem wirds immer irgendwie unhandlich wenn man das haendisch tippen muss...
Allerdings betrifft das nicht nur Whitespace, sondern auch so Sachen wie Backslashes, Doppelpunkte, Ampersands, Ausrufezeichen, Fragezeichen, Sterne usw usf... Ich faend es ratsam nur Buchstaben (ASCII), Zahlen, Unterstrich und - zu verwenden, vielleicht uU noch den Punkt. Also alles was in der Shell escaped werden muss und/oder ausserhalb von ASCII liegt sollte noch Moeglichkeit vermieden werden.

[jonofe]

Leerzeichen waren für mich bislang nie ein Problem, da ich die Logfile bislang immer nur im Browser angeschaut habe.
Sie zu entfernen ist aber kein Problem, zwei kleine Änderungen in der logging Funktion. Grundsätzlich würde ich aber bei einem Dateinamen bestehend aus LBS Namen und LBS Nummer bleiben wollen. Selektiv dann bei bestimmten LBS, verschiedene Logfiles für verschiedene Instanzen oder aber auch ein gemeinsames Logfile, je nach dem ob es Sinn macht oder nicht.

Ob man nun den Log Filename mit LBS Nummer oder LBS Namen beginnt ist mir eigentlich egal. Die LBS Nummer hätte den Vorteil der Sortierung nach dieser Nummer. Allerdings suche ich in der Logfile Liste eher nach dem Namen, weil ich die Nummern gar nicht im Kopf habe.

Ich werde allerdings jetzt nicht alle LBS updaten, sondern dies jeweils bei den nächsten Updates machen.

[saegefisch]

Hinsichtlich Space und Sonderzeichen bin ich 100% bei Euch - muss alles nicht sein und vermeidet tatsächlich hier und da Probleme. Das wäre eine gute Konvention. Ansonsten bin ich nicht unzufrieden - zugegeben nutze ich allerdings auch nicht wirklich viele "fremde" LBS - zumindest noch nicht. Geplant sind da noch ein paar...

[starwarsfan]

Hallo miteinander

Ob man nun den Log Filename mit LBS Nummer oder LBS Namen beginnt ist mir eigentlich egal. Die LBS Nummer hätte den Vorteil der Sortierung nach dieser Nummer. Allerdings suche ich in der Logfile Liste eher nach dem Namen, weil ich die Nummern gar nicht im Kopf habe.

Der Gedanke ist nicht von der Hand zu weisen.

Ich werde allerdings jetzt nicht alle LBS updaten, sondern dies jeweils bei den nächsten Updates machen.

Super, danke!

Hinsichtlich Space und Sonderzeichen bin ich 100% bei Euch - muss alles nicht sein und vermeidet tatsächlich hier und da Probleme. Das wäre eine gute Konvention.

Wenn ich es richtig verstehe, zeichnen sich also die folgenden beiden Empfehlungen ab:

1. Sammel-Log für mehrere Bausteine: <Bausteinname>_<LBSLBSID>
   Beispiel: ZeitpunktAlsText_LBS19000399
2. Log je Baustein: <Bausteinname>_<LBSLBSID>_<id>
   Beispiel: Beschattungssteuerung_LBS19000141_42

Somit also Aufruf in folgender Art:

writeToCustomLog("ZeitpunktAlsText_LBSLBSID", "${loglevel}", "${message}");
writeToCustomLog("Beschattungssteuerung_LBSLBSID_${id}", "${loglevel}", "${message}");

Soweit nachvollziehbar?

[coliflower]

Ist es eigentlich möglich, in einem einzigen Log-File eine komplette Log-Seite zu loggen (ich meine alle darin enthaltenen LBSs) ?

[starwarsfan]

Ist es eigentlich möglich, in einem einzigen Log-File eine komplette Log-Seite zu loggen (ich meine alle darin enthaltenen LBSs) ?

Verstehe ich nicht. Was genau meinst Du?

[coliflower]

Anstatt pro LBS je ein Log-File zu erstellen, für alle LBS die auf einer Logikseite eingefügt sind, nur ein Log-File erstellen … Quasi alle Log-Einträge aller LBS zusammengefasst ...

[starwarsfan]

N'abend

Anstatt pro LBS je ein Log-File zu erstellen, für alle LBS die auf einer Logikseite eingefügt sind, nur ein Log-File erstellen … Quasi alle Log-Einträge aller LBS zusammengefasst ...

Hm, eine interessante Idee. Seitens der LBS geht das mit Sicherheit nicht ootb, das müsste wohl vom Backend angeboten werden.