Feature requests fürs Logging

Auflistung von gewünschten Features, Ausschreibung zur Umsetzung
Antworten
Benutzeravatar
mrinas
Beiträge: 2085
Registriert: Mi Jan 29, 2020 10:12 pm

Feature requests fürs Logging

Beitrag von mrinas »

Ich hätte da noch ein paar Ideen / Wünsche fürs Logging anzubieten. Sobald ich (hoffentlich) Zugriff auf Github Copilot Workspace bekomme kann ich das vielleicht selber hinfrickeln, bis dahin platziere ich das mal hier:

Redaction sensibler Inhalte während des Loggings
Problem: Gerade im SoC Log laden regelmässig alle möglichen Secrets. Secrets haben rein aus Prinzip nix im Log verloren.
Idee: Logfunktionen um maskierung sensibler Inhalte erweitern. Wird alles nicht 100% wasserdicht sein, aber hoffentlich deutlich besser als heute.
- Felder mit bekannt sensiblen Inhalt werden automatisch maskiert (z.b. password)
- weitere zu maskierende Felder können beim Aufruf des Loggings übergeben werden
- Tokens werden über regex erkannt und ebenfalls maskiert


Meldungen des letzten, und des letzten Durchlaufs mit Fehlermeldungen separat bereitstellen
Problem: Häufig wird das Log des eines (des letzten) vollständigen Regelzyklus benötigt. Dieser muss heute vergleichsweise mühsam im Log identifiziert, markiert und herauskopiert werden. Gehts um eine Situation mit sporadischer Fehlermeldung muss diese gesucht werden, der Zyklusbeginn gefunden und dann extrahiert werden.
Idee: Alle Meldungen des 1) letzten Regelzyklus und 2) letzten Regelzyklus mit Fehlermeldung werden separat bereitgestellt.
zu 1)
- Zu Beginn des Regeldurchlaufs wird ein Container (z.b. Datei in der Ramdisk) erstellt
- Alle Meldungen des laufenden Regelzyklus landen zustäzlich dort
- Bei Beendigung des Regelzyklus werden die gesammelten Meldungen in eine zweite Datei in der Ramdisk (o.ä.) geschrieben. Auf diese zweite Datei wird aus der UI zugegriffen. Das stellt sicher dass man auch während eines aktiven Durchlaufes einen vollständigen Logauszug bekommen kann.

zu 2)
- Wie oben
- Bei Beendigung des Regeldurchlaufs wird geprüft ob ein Fehler aufgetreten ist (Fehlerzähler)
- Ist das der Fall werden alle Meldungen zusätzlich in einem weiteren Container gesammelt, dieser wird - sofern vorhanden - überschrieben. Damit dort immer nur der letzte fehlerbehaftete Durchlauf zu finden ist

1+2 wird in der UI im Logging mit angezeigt. ggf. sogar als der prominente Einstiegspunkt für Logs & Meldungen, die bisherige Experience mit dem expandieren und Log laden ist weiterhin optional vorhanden wenn man mehr benötigt.
15,2kWp SMA (SB4000TL-21, SB3.0, STP6.0-SE + BYD HVS, EnergyMeter), openWB Standard+, openWB Pro, Smart #1 (ersetzt den e2008), Tesla Model Y LR.
rleidner
Beiträge: 898
Registriert: Mo Nov 02, 2020 9:50 am
Been thanked: 1 time

Re: Feature requests fürs Logging

Beitrag von rleidner »

Ich würde in diesem Kontext gerne einen weiteren Vorschlag machen.

Momentan gibt es genau eine Auswahlmöglichkeit für den Logging - Detaillierungsgrad in Einstellungen - System - Fehlersuche:
Warnungen und Fehler, Info, Details
Damit werden ALLE Logging-Ausgaben gleichermaßen geschaltet.
Wenn z.B. die Details für einen SOC-Modul benötigt werden, muss auf Details gesetzt werden und ALLES wird detailliert gelogged.

Das ist meiner Meinung nach nicht wirklich elegant und effizient.

Ich schlage vor, die Logging-Einstellungen für bestimmte Bereiche separat schaltbar zu machen, z.B.
- Regel-Logik
- Geräte/Komponenten
- Smarthome

Ich denke man könnte das auch an die einzelnen Log-Files oder an die vorhandenen Threads koppeln.
openWB-2 Standard+ | openWB EVU Kit v2 MID| 9,9kWp mit Kostal Plenticore 8.5 plus | VW ID.3, Kia EV6, Smart EQ forfour
Antworten