Logging changes coming with juju 1.15

[Kapil Thangavelu]

Re different channels for user, perhaps.. at the moment its unclear in some
cases where one begins and one ends. Some of the information that a user
wants to see is currently tied up in framework. ie. events around execution
of potentially non existant hooks (config-changed would have been called,
start, rel-joined, etc). The ability to filter gives the user the option to
find what they care about in any given context.

Re filtering also the ability to filter specifically to specific units is
critical, in terms of finding a specific error, else you end up grepping
the whole class (with -n to pull history). the context of the current log
level & channel lacks identity outside of machine ip.. ideally we'd see
things like machine id:1  and unit_id which would also be filterable items.

fwiw as context to a filtering impl, previous debug-log help was

usage: juju debug-log [-h] [-e ENVIRONMENT] [-r] [-i INCLUDE] [-x EXCLUDE]
                      [-l {DEBUG,INFO,WARNING,ERROR,CRITICAL}] [-n LIMIT]
                      [-o OUTPUT]

Enables a distributed log for all agents in the environment, and displays
all
log entries that have not been seen yet.

optional arguments:
  -h, --help            show this help message and exit
  -e ENVIRONMENT, --environment ENVIRONMENT
                        juju environment to operate in.
  -r, --replay          Display all existing logs first.
  -i INCLUDE, --include INCLUDE
                        Filter log messages to only show these log channels
or
                        agents/units. Multiple values can be specified,
also supports
                        unix globbing.
  -x EXCLUDE, --exclude EXCLUDE
                        Filter log messages to exclude these log channels or
                        agents/units. Multiple values can be specified,
also supports
                        unix globbing.
  -l {DEBUG,INFO,WARNING,ERROR,CRITICAL}, --level
{DEBUG,INFO,WARNING,ERROR,CRITICAL}
                        Log level to show
  -n LIMIT, --limit LIMIT
                        Show n log messages and exit.
  -o OUTPUT, --output OUTPUT
                        File to log to, defaults to stdout



On Thu, Sep 26, 2013 at 6:40 PM, Tim Penhey <tim.penhey at canonical.com>wrote:

> On 27/09/13 10:26, Kapil Thangavelu wrote:
> > 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.
>
> I agree entirely.  Although I feel that this is a step in the right
> direction.
>
> What we could do, and I was thinking about this after I wrote the last,
> is to have the hook logs, and the hook log command, go through a
> particular module, and make sure that is always logged out.
>
> Ideally I want a different channel of information for user information,
> as opposed to developer information.  This is still work in thought (not
> even progress yet).
>
> Tim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20130926/a67f6a55/attachment.html>