In a recent thread I highlighted the upcoming change in Juju's logging where logs from machine and unit agents will be streamed over Juju's API instead of via rsyslogd. Two things came out of that discussion:
1. a desire for juju debug-logs to support a "non-tailing" mode (as per bug 1390585 <https://bugs.launchpad.net/juju-core/+bug/1390585>) 2. a desire for a tool to dump the logs out of the database in the case of Juju being unavailable for some reason. I'm happy to report that #1 is being worked by right now as part of wider changes to remove the "jes" and "db-log" feature flags, and #2 is done as of today. Under 1.26, machine agents will install a /usr/bin/juju-dumplogs command which can be run on any state server to generate complete dumps of all stored logs (one file per environment). There are some things to be aware of for when existing environments are upgraded to 1.26.0 or later: - The existing all-machines.log will stop receiving updates very soon after the state server upgrades to the new Juju version. - all-machines.log will be left behind, but will be compressed. - Some text will be appended to the bottom of all-machines.log explaining that the file is no longer used with some pointers to relevant documentation. - There will be a small window where the state servers have upgraded to the new Juju version but some agents haven't. Those agents will continue trying to log to rsyslogd but it will no longer be running. Logs sent during that period will not be recorded in all-machines.log or in the new logs database. They will still appear in the machine or unit's local log file however. - We do not plan to pre-seed the logs database with existing logs from all-machines.log. As always, questions and comments welcome. - Menno
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
