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.pen...@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@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
