frequently than log messages, often in the thousands per second range,
with very little execution overhead. Logging is more appropriate for
very high-level analysis of less frequent events: user accesses,
-exceptional conditions (e.g., errors, warnings), database
+exceptional conditions (errors and warnings, for example), database
transactions, instant messaging communications, etc. More formally,
logging is one of several use cases that can be accomplished with
tracing.
applications and the Linux kernel, how to control tracing sessions
using the `lttng` command line tool, and miscellaneous practical use
cases.
- 6. [Reference](#doc-reference) contains references of LTTng components,
- e.g., links to online manpages and to various APIs.
+ 6. [Reference](#doc-reference) contains references of LTTng components.
We recommend that you read the above chapters in this order, although
some of them may be skipped depending on your situation. You may skip
instances of `lttng-sessiond` may run simultaneously, each belonging
to a different user and each operating independently of the others.
Only `root`'s session daemon, however, may control LTTng kernel modules
-(i.e. the kernel tracer). With that in mind, if a user has no root
+(that is, the kernel tracer). With that in mind, if a user has no root
access on the target system, he cannot trace the system's kernel, but
should still be able to trace its own instrumented applications.
<p>
<span class="t">Note:</span>Because of a current limitation, all
channels must be <em>created</em> prior to beginning tracing in a
- given tracing session, i.e. before the first time you do
+ given tracing session, that is before the first time you do
<code>lttng start</code>.
</p>
<p>
</pre>
Then, choose a tracing session and start viewing events as they arrive
-using LTTng live, e.g.:
+using LTTng live:
<pre class="term">
babeltrace --input-format lttng-live net://localhost/host/hostname/my-session
</p>
<p>
In this case, make sure to set <code>LDFLAGS</code> to all the
- relevant 32-bit library paths, e.g.,
+ relevant 32-bit library paths, for example,
<code>LDFLAGS="-L/usr/lib32 -L/usr/lib/i386-linux-gnu"</code>.
</p>
</div>
<div class="tip">
<p>
<span class="t">Note:</span>You may add options to
- <code>./configure</code> if you need them, e.g., for
- Java and SystemTap support. Look at
+ <code>./configure</code> if you need them (for
+ Java and SystemTap support, for example). Look at
<code>./configure --help</code> for more information.
</p>
</div>
Regarding `TRACEPOINT_DEFINE` and `TRACEPOINT_PROBE_DYNAMIC_LINKAGE`,
the recommended practice is to use a separate C source file in your
-application to define them, and then include the tracepoint provider
-header files afterwards, e.g.:
+application to define them, then include the tracepoint provider
+header files afterwards. For example:
~~~ c
#define TRACEPOINT_DEFINE
<p>
For example, statically linking a tracepoint provider to a
shared object which is to be dynamically loaded by an application
- (e.g., a plugin) is not safe: the shared object, which contains the
- tracepoint provider, could be dynamically closed
+ (a plugin, for example) is not safe: the shared object, which
+ contains the tracepoint provider, could be dynamically closed
(<code>dlclose()</code>) at any time by the application.
</p>
gcc -o app tp.a other.o files.o of.o your.o app.o -llttng-ust <strong>-lc</strong>
</pre>
-The application can be started as usual, e.g.:
+The application can be started as usual, for example:
<pre class="term">
./app
by the LTTng-UST tracer. It must follow the tracepoint provider name
syntax: start with a letter and contain either letters, numbers or
underscores. Two tracepoints under the same provider cannot have the
-same name, i.e. you cannot overload a tracepoint like you would
-overload functions and methods in C++/Java.
+same name. In other words, you cannot overload a tracepoint like you
+would overload functions and methods in C++/Java.
<div class="tip">
<p><span class="t">Note:</span>The concatenation of the tracepoint
#include <lttng/tracef.h>
~~~
-Use `tracef()` like you would use `printf()` in your source code, e.g.:
+Use `tracef()` like you would use `printf()` in your source code, for
+example:
~~~ c
/* ... */
The tracepoint provider is a group of tracepoint definitions; its chosen
name should reflect this. A hierarchy like Java packages is recommended,
-using underscores instead of dots, e.g., `org_company_project_component`.
+using underscores instead of dots, for example,
+`org_company_project_component`.
Next is `TRACEPOINT_INCLUDE`:
in [Building/linking tracepoint providers and the user application](#doc-building-tracepoint-providers-and-user-application).
You could include other header files like `tp.h` here to create the probes
-of different tracepoint providers, e.g.:
+of different tracepoint providers, for example:
~~~ c
#define TRACEPOINT_CREATE_PROBES
The preferred, flexible way to include your module's mainline
tracepoint definition header is to put it in a specific directory
-relative to your module's root, e.g., `tracepoints`, and include it
+relative to your module's root (`tracepoints`, for example) and include it
relative to your module's root directory in the LTTng custom probe's
source:
skin, cardiac monitoring would be futile.
LTTng, as a tracer, is no different from the real life examples above.
-If you're about to trace a software system, i.e. record its history of
-execution, you better have probes in the subject you're
+If you're about to trace a software system or, put in other words, record its
+history of execution, you better have probes in the subject you're
tracing: the actual software. Various ways were developed to do this.
The most straightforward one is to manually place probes, called
_tracepoints_, in the software's source code. The Linux kernel tracing
LTTng-modules has supported system call tracing for a long time,
but until now, it was only possible to record either all of them,
or none of them. LTTng 2.6 allows the user to record specific
-system call events, e.g.:
+system call events, for example:
<pre class="term">
lttng enable-event --kernel --syscall open,fork,chdir,pipe
projects / lttng-docs.git / commitdiff
