[lttng-dev] [lttng-ust] [babeltrace] use case question - field names in event classes

[staffan@eternaltraveller.com (Staffan Tjernstrom)]

We have a situation where we have a significant number (1000's) of
log-style trace messages generated by a large group of (sometime
offsite) developers.

Unfortunately the tracepoint definitions are maintained by a small
group of central developers.

So we have a need for generic tracepoint definitions, without loosing
the ability to tailor the output from individual log messages.

One approach we've come up with involves including the labels as part
of the parameter pack:

TRACEPOINT_EVENT(
    my_app,
    two_ints_and_string,
    TP_ARGS(
        // some pre-amble fields removed for clarity
        char const *, label1_arg,
        int, value1_arg,
        char const *, label2_arg,
        int, value2_arg,
        char const *, label3_arg,
        char const *, value3_arg
    ),
    TP_FIELDS(
        // pre-amble removed for clarity
        ctf_string( label1, label1_arg )
        ctf_integer(int, value1, value1_arg)
        ctf_string( label2, label2_arg )
        ctf_integer(int, value2, value2_arg)
    )
)

and we can then call this from multiple locations in our general
code-base using:

tracepoint(my_app, two_ints_and_string, "widget_height", 19,
"widget_width", 23, "widget_name", widget_name_as_cstring);

tracepoint(my_app, two_ints_and_string, "x_coordinate", x,
"y_coordinate", y, "point_type", "star");


The issue with this is that the output obviously treats the field
names and their values as individual items, so we get output like

label1 = "widget_height", value1 = 19, label2 = "widget_width", value2
=- 23, label3 = "widget_name", value3 = "topper"
label1 = "x_coordinate", value1 = -23, label2 = "y_coordinate", value2
= 25532, label3 = "point_type", value3 = "star"

But of course we need to mechanically scrape / inspect the output, so
what we'd really like would be output something more like:

widget_height = 19, widget_width = 23, widget_name = "topper"
x_coordinate = -23, y_coordinate = 25532, point_type = "star"

Post-processing of the babeltrace output is of course one option
(using -n none), but it feels like the wrong choice (adding more steps
to the tracing chain).

Does anyone out there have any better ideas how to achieve having our
cake ( a small number of generic tracepoints ), and eating it (
user-defined field names )?