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

[Matthew Khouzam]

Back at Ericsson. :)

On 12-01-31 06:19 PM, Mathieu Desnoyers wrote:
> * 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.
Ok, so I have a semi-clearer head.
0-6 is for loglevels, and this is called loglevel, I think it fits.
7-15 are tracing/debug level. Shouldn't they be in the domain? The issue
I'm really not comfortable with is that we're comparing apples to
durians here. We know a critical is more important than an info, but is
a class more important than a notice? you change units half way
through... if you wanted you could do something like a mask field so you
can encode it all together ( trace_process == (1 << 8 ) .... then
traceLevel = (TRACE_PROCESS | TRACE_CRITICAL). I still feel though that
the loglevels should be loglevels, and the localizations should be in
the domain.

>> 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
>>>
>>>