Logging changes coming with juju 1.15
Kapil Thangavelu
kapil.thangavelu at canonical.com
Thu Sep 26 22:26:46 UTC 2013
I don't think the log collection is the issue though this is still useful
to help mitigate perhaps some of the log accumulation on disk (despite
rotation archival). The problem is the primitive log display which amounts
to tail aggregated syslog. As an end user, i don't care about framework
internals, i care about seeing the provider mutations (create, destroy, sec
group maybe), hook execution, and errors. With juju-core there isn't any
ability to filter the log from the client on a given channel/hierarchy or
level, and currently any usage of log basically fills up with ping api
traffic obscuring actual content.
-k
On Thu, Sep 26, 2013 at 6:03 PM, Tim Penhey <tim.penhey at canonical.com>wrote:
> Hi All,
>
> Last night I was pointed at a bug where one of the main problems was
> poor communication on my part as to changes, so here is the
> comprehensive details.
>
> For a long time (all of juju-core up to now), all the machine agents
> logged everything at debug. Logging at the debug level is used
> primarily by developers. Warnings and errors are of more interest to
> the users, and sometimes the informational messages. Some time back, a
> new hierarchical logging facility was added. This allows logging to be
> grouped and potentially have different groups of log messages output at
> different severity levels. These groups are dotted names that should be
> familiar to people that have used log4j, python logging or many other
> logging frameworks. We call these logical groups "modules". Modules
> have parents, being those the next level up, and there is a <root> which
> is the parent of all first level modules.
>
> For example:
> juju.agent is the parent of juju.agent.tools
> juju is the parent of juju.agent
> <root> is the parent of juju
>
> The default logging configuration is:
> <root>=WARNING
>
> This means that only warnings and above (error and critical) are logged
> by default.
>
> On the command line, there are two ways to change this. You can specify
> an environment variable "JUJU_LOGGING_CONFIG", or you can specify
> --log-config on the command line. The default for --log-config is the
> JUJU_LOGGING_CONFIG environment variable, so if you specify --log-config
> you override what the environment has set.
>
> The environment variable gives developers a simple way to have the
> default logging set to what they are currently working on. For example,
> if I cared about the provisioner and the azure provider, I could do the
> following:
> export
> JUJU_LOGGING_CONFIG=juju.provider.azure=DEBUG;juju.worker.provisioner=DEBUG
>
> This would get combined with the default of <root>=WARNING.
>
> NOTE: setting --log-config doesn't show the log file on the command
> line, but does propagate the logging configuration into the environment,
> so all agents that start up get that logging config.
>
> To show the log on the command line, now use --show-log. The --debug
> has been kept to be short-hand for "--log-config=<root>=DEBUG
> --show-log", and --verbose has been deprecated with its current meaning
> (we intend to have --verbose mean 'show me more output for the command I
> am running', as logging and command output have different audiences
> almost all the time).
>
> If you are looking at the agent log files, or the debug-log command, you
> will notice that the agents all start logging at the DEBUG level, but
> once the internal workers are up and running, you'll see a line like this:
>
> 2013-09-23 15:56:21 DEBUG juju.worker.logger logger.go:45 reconfiguring
> logging from "<root>=DEBUG" to "<root>=WARNING"
>
> Every agent now has a worker that allows the logging configuration to be
> changed on a running environment. The "<root>=WARNING" that the
> configuration is being changed to is the default log-config specified at
> environment bootstrap time, and if one isn't specified, it defaults to
> warnings.
>
> To change the logging config of a running environment, you can use the
> existing "set-environment" (or "set-env") command.
>
> juju set-env 'logging-config=<root>=INFO;juju.provider=DEBUG'
>
> and this is then propagated through to all the running agents. Note
> that this is NOT additive. So if the existing logging config was
> "juju.provider.azure=DEBUG", and it was changed to "juju.agent=DEBUG",
> the juju.provider.azure would default back to the parent's level, which
> would be WARNING.
>
> You only need to specify the root logger if you want to change it from
> WARNING to something else, as by default it is set to WARNING.
>
> Tim
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20130926/05189351/attachment-0001.html>
More information about the Juju-dev
mailing list