<div dir="ltr"><div><div><div><div><div>I implemented the ability for Juju's logs to go to MongoDB some time ago. This feature is available in 1.25 behind a feature flag and also gets enabled automatically if the "jes" feature flag is enabled (logging via rsyslog doesn't make much sense when using multiple environments in the one system). <br><br></div>There's also another separate feature flag which turns off rsyslog based logging.<br><br></div>The "jes" feature flag will be removed soon meaning that database logging will need to become default functionality. The question is do we then also remove logging to rsyslog functionality, or perhaps reverse the sense of the rsyslog feature flag so that it's off by default but can be enabled if people want it for some reason?<br><br></div>I'm confident that the logging to the database feature is solid. I spent of lot of time confirming that performance wouldn't be an issue. The code is well tested. Automatic log rotation is implemented.<br><br>The main issue I can see is that once rsyslog based logging is turned off we lose the all-machines.log file which some people and systems no doubt rely on. The logs for an environment can of course still be retrieved using the "juju debug-log" command.<br><br>If we really want something like all-machines.log, it wouldn't be /too/ hard to implement a worker which generates an all-machines.log style file in real-time from the database logs. All the pieces to implement that already exist, but I really don't have the bandwidth this cycle to do the work.<br><br></div>Thoughts?<br><br></div>- Menno<br><div><div><br><br><div><div><div><br><br></div></div></div></div></div></div>