[lttng-dev] LTTng event identification

[Philippe Proulx]

On Thu, Aug 13, 2020 at 9:52 AM Valentin Grigorev via lttng-dev
<lttng-dev at lists.lttng.org> wrote:
>
> Hello!
>
> I'm using LTTng live session and Babeltrace 2 C API to analyze events
> in online mode.
>
> I would like to route event processing statically (using IDs, without
> parsing strings). And currently, I don't understand if it is possible
> with LTTng.
>
> Babeltrace 2 C API provides bt_event_class_get_id function, but the
> only guarantee about IDs received from this function is "All the event
> classes of a given stream class have unique numeric IDs". And even
> more, it is mentioned further that stream class can automatically
> assign event class IDs in some cases (q.v.
> https://babeltrace.org/docs/v2.0/libbabeltrace2/group__api-tir-ev-cls.html).
> If I understand correctly, it means, that these IDs are assigned by
> Babeltrace library, not by LTTng itself or tracepoint provider, and as
> result, the same tracepoints can produce events with different event
> class IDs even within the same tracing session. Am I right?

In LTTng's case, which generates CTF traces, LTTng assigns the event
class IDs. A Babeltrace 2 `src.ctf.lttng-live` component simply uses
them as is to create event class objects. But LTTng assigns those event
class IDs dynamically, so, indeed, there's no guarantee that you'll
always get the same.

We generally use event class names to identify event classes.

>
> At the same time, in ETW (Event Tracing for Windows) event type is
> fully identified by 3 parameters: provider GUID, event id, event
> version. I would like to have something like this. At least I need to
> know that ID for the same tracepoint is constant, unique within a
> tracepoint provider, and not depends on a session configuration, other
> providers, etc.

It is very likely that CTF 2 will introduce a similar concept to
uniquely identify an event class without having to rely on its name
exclusively. Some namespace (based on a domain name and year, for
example; think XML/YAML/etc.) + a name + a version would be a good
start. For example:

    ns: lttng.org/ns/ctf/modules
    name: sched_switch
    version: 3

We could also merge all that into a single URI. I need to reflect on
this with other developers.

>
> Summarizing, I'm interested in the following questions:
>   * Do event class IDs depend on a session configuration (which events were enabled)?

Yes, in that LTTng assigns event class IDs sequentially, as needed,
without any relation to the tracepoints.

>   * If so, maybe there are some other IDs satisfying the above requirements in LTTng/Babeltrace?

No.

>   * Do any IDs for tracepoint providers exist in LTTng? Or parsing event name is the only way to identify it?

The usual strategy is for a Babeltrace 2 component to map event class
IDs to some private event class identifications somewhere (using a hash
table, for example). In LTTng live's case, it's possible that new event
classes appear later, so you need to take this into account.

Then when consuming an event message, the component first tries to find
its class's identification using its class's ID (hash table lookup, for
example). If the component cannot find the event class identification,
it uses its name to determine its identification and then maps its ID to
this identification.

Tell me if you want more details about this strategy.

Hope this helps,

Phil

>
> Best regards,
> Valentin Grigorev
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev