---

   lttng-enable-channel    ( 1 )

---

Описание (Description)

The lttng enable-channel command can create a new channel, or enable one or more existing and disabled ones.

A channel is the owner of sub-buffers holding recorded events. Event, rules, when created using lttng-enable-event(1), are always assigned to a channel. When creating a new channel, many parameters related to those sub-buffers can be fine-tuned. They are described in the subsections below.

When CHANNEL does not name an existing channel, a channel named CHANNEL is created. Otherwise, the disabled channel named CHANNEL is enabled.

Note that the lttng-enable-event(1) command can automatically create default channels when no channel exist.

A channel is always contained in a tracing session (see lttng-create(1) for creating a tracing session). The session in which a channel is created using lttng enable-channel can be specified using the --session option. If the --session option is omitted, the current tracing session is targeted.

Existing enabled channels can be disabled using lttng-disable-channel(1). Channels of a given session can be listed using lttng-list(1).

See the LIMITATIONS section below for a list of limitations of this command to consider.

Event loss modes LTTng tracers are non-blocking by default: when no empty sub-buffer exists, losing events is acceptable when the alternative would be to cause substantial delays in the instrumented application's execution.

LTTng privileges performance over integrity, aiming at perturbing the traced system as little as possible in order to make tracing of subtle race conditions and rare interrupt cascades possible.

You can allow the user space tracer to block with a --blocking- timeout option set to a positive value or to inf, and with an application which is instrumented with LTTng-UST started with a set LTTNG_UST_ALLOW_BLOCKING environment variable. See lttng-ust(3) for more details.

When it comes to losing events because no empty sub-buffer is available, the channel's event loss mode, specified by one of the --discard and --overwrite options, determines what to do amongst:

Discard Drop the newest events until a sub-buffer is released.

Overwrite Clear the sub-buffer containing the oldest recorded events and start recording the newest events there. This mode is sometimes called flight recorder mode because it behaves like a flight recorder: always keep a fixed amount of the latest data.

Which mechanism to choose depends on the context: prioritize the newest or the oldest events in the ring buffer?

Beware that, in overwrite mode (--overwrite option), a whole sub-buffer is abandoned as soon as a new event doesn't find an empty sub-buffer, whereas in discard mode (--discard option), only the event that doesn't fit is discarded.

Also note that a count of lost events is incremented and saved in the trace itself when an event is lost in discard mode, whereas no information is kept when a sub-buffer gets overwritten before being committed.

The probability of losing events, if it is experience in a given context, can be reduced by fine-tuning the sub-buffers count and size (see next subsection).

Sub-buffers count and size The --num-subbuf and --subbuf-size options respectively set the number of sub-buffers and their individual size when creating a new channel.

Note that there is a noticeable tracer's CPU overhead introduced when switching sub-buffers (marking a full one as consumable and switching to an empty one for the following events to be recorded). Knowing this, the following list presents a few practical situations along with how to configure sub-buffers for them when creating a channel in overwrite mode (--overwrite option):

High event throughput In general, prefer bigger sub-buffers to lower the risk of losing events. Having bigger sub-buffers also ensures a lower sub-buffer switching frequency. The number of sub-buffers is only meaningful if the channel is enabled in overwrite mode: in this case, if a sub-buffer overwrite happens, the other sub-buffers are left unaltered.

Low event throughput In general, prefer smaller sub-buffers since the risk of losing events is already low. Since events happen less frequently, the sub-buffer switching frequency should remain low and thus the tracer's overhead should not be a problem.

Low memory system If the target system has a low memory limit, prefer fewer first, then smaller sub-buffers. Even if the system is limited in memory, it is recommended to keep the sub-buffers as big as possible to avoid a high sub-buffer switching frequency.

In discard mode (--discard option), the sub-buffers count parameter is pointless: using two sub-buffers and setting their size according to the requirements of the context is fine.

Switch timer When a channel's switch timer fires, a sub-buffer switch happens. This timer may be used to ensure that event data is consumed and committed to trace files periodically in case of a low event throughput.

It's also convenient when big sub-buffers are used to cope with sporadic high event throughput, even if the throughput is normally lower.

Use the --switch-timer option to control the switch timer's period of the channel to create.

Read timer By default, an internal notification mechanism is used to signal a full sub-buffer so that it can be consumed. When such notifications must be avoided, for example in real-time applications, the channel's read timer can be used instead. When the read timer fires, sub-buffers are checked for consumption when they are full.

Use the --read-timer option to control the read timer's period of the channel to create.

Monitor timer When a channel's monitor timer fires, its registered trigger conditions are evaluated using the current values of its properties (for example, the current usage of its sub-buffers). When a trigger condition is true, LTTng executes its associated action. The only type of action currently supported is to notify one or more user applications.

See the installed C/C++ headers in lttng/action, lttng/condition, lttng/notification, and lttng/trigger to learn more about application notifications and triggers.

Use the --monitor-timer option to control the monitor timer's period of the channel to create.

Buffering scheme In the user space tracing domain, two buffering schemes are available when creating a channel:

Per-process buffering (--buffers-pid option) Keep one ring buffer per process.

Per-user buffering (--buffers-uid option) Keep one ring buffer for all the processes of a single user.

The per-process buffering scheme consumes more memory than the per-user option if more than one process is instrumented for LTTng-UST. However, per-process buffering ensures that one process having a high event throughput won't fill all the shared sub-buffers, only its own.

The Linux kernel tracing domain only has one available buffering scheme which is to use a single ring buffer for the whole system (--buffers-global option).

Trace files limit and size By default, trace files can grow as large as needed. The maximum size of each trace file written by a channel can be set on creation using the --tracefile-size option. When such a trace file's size reaches the channel's fixed maximum size, another trace file is created to hold the next recorded events. A file count is appended to each trace file name in this case.

If the --tracefile-size option is used, the maximum number of created trace files is unlimited. To limit them, the --tracefile- count option can be used. This option is always used in conjunction with the --tracefile-size option.

For example, consider this command:

$ lttng enable-channel --kernel --tracefile-size=4096 \ --tracefile-count=32 my-channel

Here, for each stream, the maximum size of each trace file is 4 kiB and there can be a maximum of 32 different files. When there is no space left in the last file, trace file rotation happens: the first file is cleared and new sub-buffers containing events are written there.

LTTng does not guarantee that you can view the trace of an active tracing session (before you run the lttng-stop(1) command), even with multiple trace files, because LTTng could overwrite them at any moment, or some of them could be incomplete. You can archive a tracing session's current trace chunk while the tracing session is active to obtain an unmanaged and self-contained LTTng trace: see lttng-rotate(1) and lttng-enable-rotation(1).