[lttng-dev] [LTTng-UST RFC] Tracepoint Loglevels Specification

[mathieu.desnoyers@efficios.com (Mathieu Desnoyers)]

* Matthew Khouzam (matthew.khouzam at ericsson.com) wrote:
> 
> 
> On 12-01-31 05:41 PM, Mathieu Desnoyers wrote:
> > Hi,
> >
> > Some early LTTng-UST adopters brought to my attention that the way
> > tracepoint loglevels are currently specified in LTTng-UST might be too
> > relax for its own good. If each application define their own loglevel
> > names/values, it will become difficult to use the loglevels to select
> > "trace verbosity" in a system-wide manner.
> >
> > Now that I come to think of it, it might make sense to pre-define a set
> > of supported loglevels, similarly to syslog(3). However, given that
> > tracing sometimes targets debug levels that are more fine-grained than
> > in the case of logs, I would propose to split the "debug" loglevel into
> > sub-categories. The following loglevel names are just ideas, and
> > feedback is very welcome.
> >
> > My current thought is to simply just allow these loglevels. I doubt that
> > letting application developers specify extra loglevels on top of this
> > would be that useful, and it would certainly be more confusing.
> >
> > In the list below, lower numbers means "low verbosity", higher numbers
> > means "high verbosity, debug-style information".
> >
> > based on syslog
> > http://linux.die.net/man/3/syslog
> >   SUSv2 and POSIX.1-2001. POSIX.1-2001
> >
> > TRACE_EMERG    0
> > system is unusable
> Good
> >
> > TRACE_ALERT    1
> > action must be taken immediately
> How immediately?

As immediately as defined by syslog ;) levels 0 to 6, and TRACE_DEBUG,
are directly inspired from syslog(3), and so are their associated text.

Having a too narrow description is probably not a good idea for
something as general as loglevels.

> >
> > TRACE_CRIT     2
> > critical conditions
> Differentiate from alert please? to me critical sounds more critical. ;)

Derived from syslog. I guess they mean that a critical condition has
occured, but the system can still live for a while without human
intervention.

> >
> > TRACE_ERR      3
> > error conditions
> >
> > TRACE_WARNING  4
> > warning conditions
> classic combo
> > TRACE_NOTICE   5
> > normal, but significant, condition
> >
> > TRACE_INFO     6
> > informational message
> >

Starting from below, this is really for "tracing", not "logging".

> > TRACE_SYSTEM   7
> > information has system-level scope
> Could you have a system level error? I don't know, your app breaks
> OpenGL or something?

This is really not specifically limited to errors. This TRACE_SYSTEM
means: activate tracing data that helps understand what happens at the
system-level.

> >
> > TRACE_PROCESS  8
> > information has process-level scope
> >
> > TRACE_MODULE   9
> > information has module (executable/library) scope
> >
> > TRACE_UNIT     10
> > information has compilation unit scope
> >
> > TRACE_CLASS    11
> > information has class-level scope
> >
> > TRACE_OBJECT   12
> > information has object-level scope
> >
> > TRACE_FUNCTION 13
> > information has function-level scope
> >
> > TRACE_PRINTF   14
> > tracepoint_printf message
> >
> > TRACE_DEBUG    15
> > debug-level message
> 
> Are the trace levels in order of increasing threat?

At the top (0 to 6), yes, because they are derived from syslog.

The rest are "tracing/debugging verbosity" levels.

> I can see a slider
> showing up to level 7, but after they don't seem to fit in the advisory
> systems I've seen elsewhere. How would we choose which ones to activate?
> I am imagining an account manager going, "lets see the critical issues"
> "now the severe issues" "now the info" but then we go into more
> architectural stuff that may just confuse and make the tech support
> either ignore it, or activate everything.

Some will want to use tracing to get "log messages", others will want to
use it to gather very detailed debugging data on the applications.
Levels 7 to 15 fit in the second category.

Basically, 7 to 15 are really the TRACE_DEBUG (last entry of syslog
loglevels) expanded to allow a much finer-grained selection of the trace
data.

> 
> Also, if I trace_printf something, couldn't it be a critical message?

I want the trace_printf statements to be kept for development-debugging
only, so I would rather prefer to make it the very last number, right
before the catch-all TRACE_DEBUG. 0 to 13, IMHO, only belong to
TRACEPOINT_EVENT declaration, not debug-style printf-alike ad-hoc
tracing.

> 
> I don't know, maybe I'm missing the point with the last ones.

Let me know if my explanation about the intent of expanding the DEBUG
level into multiple ones makes it clearer.

Thanks for the feedback!

Mathieu

> >
> > Thoughts ?
> >
> > Thanks,
> >
> > Mathieu
> >
> >

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com