From mboxrd@z Thu Jan  1 00:00:00 1970
From: matthew.khouzam@ericsson.com (Matthew Khouzam)
Date: Tue, 31 Jan 2012 17:58:50 -0500
Subject: [lttng-dev] [LTTng-UST RFC] Tracepoint Loglevels Specification
In-Reply-To: <20120131224119.GA16479@Krystal>
References: <20120131224119.GA16479@Krystal>
Message-ID: <4F28722A.4060206@ericsson.com>



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