Ob die Änderungen im Spring Boot Admin persistent / versioniert sind hängt in erster Linie davon ab, wie der Client dahinter die Operation implementiert.
Nimmt man den Default von Spring Boot / Spring Cloud so sind die Änderungen am Loglevel bzw. den Properties weder versioniert noch dauerhaft geändert... sondern nach einem Neustart verloren.
Ich sehe es so wie Bene, dass man die Konfig-Änderungen im Sinne von Infrastructure as Code
vorzugsweise in der Deployment-Konfiguration/Config-DB/etcd/whatever persistent ändern sollte, wenn diese von Dauer sein sollen und auch den nächsten Restart überleben sollen.
Die Möglichkeiten den Loglevel zur Laufzeit (kurzfristig) ändern zu können hilft natürlich enorm bei der Fehlersuche. Andere Funktionen, die ich typischerweise zur Laufzeit benötige, sind Cache-Invalidierungen, Session-Terminierungen...
Ob die Änderungen im Spring Boot Admin persistent / versioniert sind hängt in erster Linie davon ab, wie der Client dahinter die Operation implementiert. Nimmt man den Default von Spring Boot / Spring Cloud so sind die Änderungen am Loglevel bzw. den Properties weder versioniert noch dauerhaft geändert... sondern nach einem Neustart verloren.
Ich sehe es so wie Bene, dass man die Konfig-Änderungen im Sinne von Infrastructure as Code vorzugsweise in der Deployment-Konfiguration/Config-DB/etcd/whatever persistent ändern sollte, wenn diese von Dauer sein sollen und auch den nächsten Restart überleben sollen.
Die Möglichkeiten den Loglevel zur Laufzeit (kurzfristig) ändern zu können hilft natürlich enorm bei der Fehlersuche. Andere Funktionen, die ich typischerweise zur Laufzeit benötige, sind Cache-Invalidierungen, Session-Terminierungen...