Logging changes coming with juju 1.15

[Kapil Thangavelu]

Hi David,

Its great that this feature exists at all, its definitely better than
nothing, which was a serious possibility at that time with the current
implementation being the only one that got consensus support as i recall
and even then had a rocky road to getting merged. No one's playing the
blame game. Our focus collectively should be on the present and the future,
and how to make juju rock for users. What i posited here was my experience
as a user, and suggestions on future work to make debug-log even better. In
terms of low-hanging fruit, getting the api pings out of the logs (and
really any repetitive output) would be a big usability step forward.

thanks,

Kapil


On Thu, Sep 26, 2013 at 7:39 PM, David Cheney <david.cheney at canonical.com>wrote:

> I take blame for the 'primitive log system', this was my idea. But in
> my defense, debug-log wasn't even on the table 6 weeks before 13.04
> and the 'shove it all through syslog' was accepted as a solution that
> would get _a_ debug-log in the hands of users.
>
> Should it be replaced ? Absolutely, but please keep in mind it was
> born of pragmatism, not incompetence.
>
> On Fri, Sep 27, 2013 at 8:46 AM, Kapil Thangavelu
> <kapil.thangavelu at canonical.com> wrote:
> > 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
> >
> >
> >
> > --
> > 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/20130927/9eeb744d/attachment.html>