<div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Hi !<br><br>The
term "loglevel" do not seems relevant for me, nor the implementation of
LTTng in that way. I think tracing is not used to "log", but to monitor
a specific part of the system, without any hierarchy between the events
since one can not consider that in any given situation a group of
events will be more important than another: there could be a situation
when these "more important events" will be less important than others.</div>
<div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
We often use the analiogy between logging and tracing to explain what is
tracing, but I believe that it's just an analogy. I don't think the
usage of both system share the same goal. </div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
I don't see the interest of using the tracing system to do logging... There is already logging systems for that.<br></div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br>
</div><div style="font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
However, what I find interesting is the idea to build "groups" of events
that can be activated easily together (for example by targeting a
certain part of the kernel, a little like those you had started to do,
but without the hierarchy idea).<br><br>Raphaël<br><br clear="all">--<br>Raphaël
Beamonte.<br><i>M.Sc.A Laboratoire DORSAL - <a href="http://www.dorsal.polymtl.ca/" target="_blank">http://www.dorsal.polymtl.ca/</a><br>Ecole Polytechnique, Montréal (Québec)</i><br><i>(+1) (438) 938-6879 - <a href="mailto:raphael.beamonte@polymtl.ca" target="_blank">raphael.beamonte@polymtl.ca</a></i>
<br></div><br><br><div class="gmail_quote">2012/2/3 Mathieu Desnoyers <span dir="ltr"><<a href="mailto:mathieu.desnoyers@efficios.com">mathieu.desnoyers@efficios.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div class="h5">* Aaron Spear (<a href="mailto:aspear@vmware.com">aspear@vmware.com</a>) wrote:<br>
> Hi guys,<br>
><br>
> > > > TRACE_SYSTEM 7<br>
> > > > information has system-level scope<br>
> > > ><br>
> > > > TRACE_PROCESS 8<br>
> > > > information has process-level scope<br>
> > > ><br>
> > > > TRACE_MODULE 9<br>
> > > > information has module (executable/library) scope<br>
> > > ><br>
> > > > TRACE_UNIT 10<br>
> > > > information has compilation unit scope<br>
> > > ><br>
> > > > TRACE_CLASS 11<br>
> > > > information has class-level scope<br>
> > > ><br>
> > > > TRACE_OBJECT 12<br>
> > > > information has object-level scope<br>
> > > ><br>
> > > > TRACE_FUNCTION 13<br>
> > > > information has function-level scope<br>
> > > ><br>
> > > First thought: I don't think that these levels (7-13) correspond to<br>
> > > levels.<br>
> > > These divisions sounds more like a part of the namespacing of the<br>
> > > event<br>
> > > and not level.<br>
><br>
> I think that I agree with what Yannick said above and didn't see what<br>
> I interpreted as a direct answer to the question. It does seem to me<br>
> that TRACE_SYSTEM, TRACE_MODULE, etc really are related to<br>
> domain/scope and not related to levels. It seems conceivable that I<br>
> am only interested in seeing TRACE_INFO from the process level scope<br>
> as opposed to the system level and would like to be able to filter<br>
> using the domain additionally. What am I missing?<br>
<br>
</div></div>Hi Aaron,<br>
<br>
I guess I need to detail my explanation then. Sorry for yesterday, being<br>
on a slow 2G cell phone link did not allow me to type a detailed<br>
explanation. First, before I dig into the explanation, here is the<br>
mapping I currently fixed for LTTng-UST loglevels:<br>
<br>
TRACE_EMERG = 0,<br>
TRACE_ALERT = 1,<br>
TRACE_CRIT = 2,<br>
TRACE_ERR = 3,<br>
TRACE_WARNING = 4,<br>
TRACE_NOTICE = 5,<br>
TRACE_INFO = 6,<br>
TRACE_SYSTEM = 7,<br>
TRACE_PROGRAM = 8,<br>
TRACE_PROCESS = 9,<br>
TRACE_MODULE = 10,<br>
TRACE_UNIT = 11,<br>
TRACE_FUNCTION = 12,<br>
TRACE_DEFAULT = 13,<br>
TRACE_VERBOSE = 14,<br>
TRACE_DEBUG = 15,<br>
<br>
In this example, I will mainly discuss the use the the loglevel 7<br>
through 15, which seems to be non-trivial. I assume there is no problem<br>
with loglevels 0 through 6, since they simply map to syslog loglevels.<br>
<br>
Let's use an example. Let's define a use-case with 4 applications:<br>
<br>
Apache web server<br>
Xorg<br>
MariaDB<br>
OpenSSH<br>
<br>
Each of those applications could have "high-level" events, like<br>
"application starting" / "application exiting" (this would be<br>
TRACE_PROGRAM level), mid-level events like "a new communication session<br>
with a remote computed has started" (could be TRACE_MODULE, since this<br>
information would tell what the communication module is being used to<br>
initiate a new session), and very detailed events like "incoming packet"<br>
(TRACE_UNIT), because those are somewhat frequent.<br>
<br>
Now let's say that we experience a problem on this system. The first<br>
step would be to enable a wildcard that almost traces the entire world,<br>
e.g.:<br>
<br>
lttng enable-event -u "*"<br>
( trace everything in userspace! )<br>
<br>
Obviously, this might generate too much data because it selects _every_<br>
tracepoint in the system, due to some of them generating high-throughput<br>
trace data. This is where the loglevels come into play. Instead of doing<br>
the enable-event above, we should do:<br>
<br>
lttng enable-event -u "*" --loglevel TRACE_SYSTEM<br>
<br>
So we are going to select tracepoints for _all_ applications which<br>
provide information allowing the person analysing the trace to figure<br>
out where in the system seems to come the problematic behavior (first<br>
pass to narrow down the problem). If we find some interesting bit of<br>
information that lets us think that, for instance, Xorg might be the<br>
cause of the problem, then we start tracing again, but this time with a<br>
different scope (wildcard) and a different loglevel (more detailed). We<br>
can afford an higher-throughput loglevel because we are restricting the<br>
scope of the wildcard, so only Xorg will produce data:<br>
<br>
lttng enable-event -u "xorg_*" --loglevel TRACE_PROGRAM<br>
<br>
and eventually do another go with:<br>
<br>
lttng enable-event -u "xorg_somelib_*" --loglevel TRACE_MODULE<br>
<br>
and so on until we end up choosing a very restrictive wildcard scope,<br>
and at the same time we select a very verbose loglevel.<br>
<br>
The combination of wildcard and loglevel is actually a new to LTTng and,<br>
in my opinion, is a very powerful way to select the scope of tracepoints<br>
to activate to really help in the process of narrowing down a problem.<br>
<br>
It's actually on purpose that I used names that match with the<br>
tracepoint naming scheme hierarchy, because those are used together: as<br>
we restrict the scope of the wildcard, we can select a more verbose<br>
loglevel.<br>
<br>
Thoughts ?<br>
<br>
Thanks,<br>
<div class="im"><br>
Mathieu<br>
<br>
--<br>
Mathieu Desnoyers<br>
Operating System Efficiency R&D Consultant<br>
EfficiOS Inc.<br>
<a href="http://www.efficios.com" target="_blank">http://www.efficios.com</a><br>
<br>
</div><div><div></div><div class="h5">_______________________________________________<br>
lttng-dev mailing list<br>
<a href="mailto:lttng-dev@lists.lttng.org">lttng-dev@lists.lttng.org</a><br>
<a href="http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev" target="_blank">http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev</a><br>
</div></div></blockquote></div><br>