Every model has its own log collection. The logs for any particular model can be seen using the debug-log command. Logging levels are set on a model by model basis using the model-config value logging-config. All logs from machines and agents in the model are written to that model’s log collection.
A long standing issue has been around the workers that are run by the controller on behalf of models, and where those logs turn up. Prior to Juju 2.7 those logs ended up in the controller model’s log collection. This was somewhat problematic if you as a user didn’t have access to the controller model. Which, to be honest, is almost every non-test deployment.
In Juju 2.7, the log entries for the workers that the controller runs now show up in the model’s log collection for the model that the worker is working for. A good example of this is the provisioner worker. This is the worker that talks to the cloud provider to actually start up the machines for a model.
Now an individual model could increase the logging levels configured and see the more detailed logs for the tasks that the controller manages.
This did cause potential issues on the host machines log file for the controller. The /var/log/juju/machine-x.log file has all the logging for the controller’s machine agent. We really didn’t want another model with excessive trace logging to cause constant logfile rotation of the controller’s machine log. To this end the local file that is written to is model specific: /var/log/juju/models/<model-uuid>.log.
To do before 2.7.0 final
- change the model log file from
<model-uuid>.logto<short hash>-owner-name.log - finish the rest of the model worker log migration to the model’s log collection