</pre>
Make sure the path you provide is the directory containing actual trace
-files (`channel0_0`, `metadata`, etc.): the `babeltrace` utility recurses
-directories, but the Python binding does not.
+files (`channel0_0`, `metadata`, and the rest): the `babeltrace` utility
+recurses directories, but the Python binding does not.
Here's an example of output:
with very little execution overhead. Logging is more appropriate for
very high-level analysis of less frequent events: user accesses,
exceptional conditions (errors and warnings, for example), database
-transactions, instant messaging communications, etc. More formally,
+transactions, instant messaging communications, and such. More formally,
logging is one of several use cases that can be accomplished with
tracing.
This chapter presents various references for LTTng packages such as links
to online manpages, tables needed by the rest of the text, descriptions
-of library functions, etc.
+of library functions, and more.
<li>
<code class="arg">t</code> integer C type
(<code>int</code>, <code>unsigned char</code>,
- <code>size_t</code>, etc.)
+ <code>size_t</code>, ...)
</li>
<li><code class="arg">n</code> field name</li>
</ul>
<li>
<code class="arg"><strong>t</strong></code> integer C type
(<code>int</code>, <code>long</code>,
- <code>size_t</code>, etc.)
+ <code>size_t</code>, ...)
</li>
<li><code class="arg"><strong>n</strong></code> field name</li>
<li><code class="arg"><strong>e</strong></code> argument expression</li>
* a name
* the channel state (enabled or disabled)
* its parameters (event loss mode, sub-buffers size and count,
- timer periods, output type, trace files size and count, etc.)
+ timer periods, output type, trace files size and count, and the rest)
* a list of added context information
* a list of [events](#doc-event)
* for each event:
* its state (enabled or disabled)
* a list of instrumentation points (tracepoints, system calls,
- dynamic probes, etc.)
+ dynamic probes, other types of probes)
* associated log levels
* a filter expression
The session daemon is responsible for managing tracing sessions and
what they logically contain (channel properties, enabled/disabled
-events, etc.). By communicating locally with instrumented applications
-(using LTTng-UST) and with the LTTng Linux kernel modules
+events, and the rest). By communicating locally with instrumented
+applications (using LTTng-UST) and with the LTTng Linux kernel modules
(LTTng-modules), it oversees all tracing activities.
One of the many things that `lttng-sessiond` does is to keep
so that they are initialized, enable/disable specific probes based on
enabled/disabled events by the user, send event filters information to
LTTng tracers so that filtering actually happens at the tracer site,
-start/stop tracing a specific application or the Linux kernel, etc.
+start/stop tracing a specific application or the Linux kernel, and more.
The session daemon is not useful without some user controlling it,
because it's only a sophisticated control interchange and thus
* scheduling priority (niceness)
* thread identifier (TID)
* the **hostname** of the system on which the event occurred
- * plenty of **performance counters** using perf:
- * CPU cycles, stalled cycles, idle cycles, etc.
+ * plenty of **performance counters** using perf, for example:
+ * CPU cycles, stalled cycles, idle cycles, and the other cycle types
* cache misses
- * branch instructions, misses, loads, etc.
+ * branch instructions, misses, loads
* CPU faults
- * etc.
The full list is available in the output of `lttng add-context --help`.
Some of them are reserved for a specific domain (kernel or
events are contained in a specific channel, itself contained in a
specific tracing session. A channel is a group of events with
tunable parameters (event loss mode, sub-buffer size, number of
-sub-buffers, trace file sizes and count, etc.). A given channel may
-only be responsible for enabled events belonging to one domain: either
-kernel or user space.
+sub-buffers, trace file sizes and count, to name a few). A given channel
+may only be responsible for enabled events belonging to one domain:
+either kernel or user space.
If you only used the `create`, `enable-event` and `start`/`stop`
commands of the `lttng` tool so far, one or two channels were
(required).
2. One or many **instrumentation points** in source code or binary
program (tracepoint name, address, symbol name, function name,
- logger name, etc.) to be executed (required).
+ logger name, amongst other types of probes) to be executed (required).
3. A **log level** (each instrumentation point declares its own log
level) or log level range to match (optional; only valid for user
space domain).
Configuring a tracing session may be long: creating and enabling
channels with specific parameters, enabling kernel and user space
-domain events with specific log levels and filters, adding context
-to some channels, etc. If you're going to use LTTng to solve real
+domain events with specific log levels and filters, and adding context
+to some channels are just a few of the many possible operations using
+the `lttng` command line tool. If you're going to use LTTng to solve real
world problems, chances are you're going to have to record events using
the same tracing session setup over and over, modifying a few variables
each time in your instrumented program or environment. To avoid
Since C and C++ are the base languages of virtually all other
programming languages
-(Java virtual machine, Python, Perl, PHP and Node.js interpreters, etc.),
-implementing user space tracing for an unsupported language is just a
-matter of using the LTTng-UST C API at the right places.
+(Java virtual machine, Python, Perl, PHP and Node.js interpreters, to
+name a few), implementing user space tracing for an unsupported language
+is just a matter of using the LTTng-UST C API at the right places.
The usual work flow to instrument a user space C application with
LTTng-UST is:
into some source code. It can be done manually, by writing tracepoint
calls at specific locations in the source code of the program to trace,
or more automatically using dynamic probes (address in assembled code,
-symbol name, function entry/return, etc.).
+symbol name, function entry/return, and others).
It has to be noted that, as an LTTng user, you may not have to worry
about the instrumentation process. Indeed, you may want to trace a
that can be done by the LTTng session daemon, which is controlled using
`liblttng-ctl` or its command line utility, `lttng`: creating tracing
sessions, listing tracing sessions and events, enabling/disabling
-events, starting/stopping the tracers, taking snapshots, etc.
+events, starting/stopping the tracers, taking snapshots, amongst many
+other commands.
This chapter is a complete user guide of both activities,
with common use cases of LTTng exposed throughout the text. It is
projects / lttng-docs.git / commitdiff
