Feature requests fürs Logging
Verfasst: Di Jun 25, 2024 8:23 pm
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.
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.