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

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

[Mathieu Desnoyers]

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

TRACE_ALERT    1
action must be taken immediately

TRACE_CRIT     2
critical conditions

TRACE_ERR      3
error conditions

TRACE_WARNING  4
warning conditions

TRACE_NOTICE   5
normal, but significant, condition

TRACE_INFO     6
informational message

TRACE_SYSTEM   7
information has system-level scope

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

Thoughts ?

Thanks,

Mathieu


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

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

[Matthew Khouzam]

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?
>
> TRACE_CRIT     2
> critical conditions
Differentiate from alert please? to me critical sounds more critical. ;)
>
> TRACE_ERR      3
> error conditions
>
> TRACE_WARNING  4
> warning conditions
classic combo
> TRACE_NOTICE   5
> normal, but significant, condition
>
> TRACE_INFO     6
> informational message
>
> 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?
>
> 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? 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.

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

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

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

[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