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 <[email protected]> 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 <[email protected]> > 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev > -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
