Access component parts of probe name

[ajor]

Is your feature request related to a problem? Please describe.

When aggregating data from tracepoint probes, it is only currently possible to distinguish the data from each tracepoint by using the probe builtin:

tracepoint:syscalls:sys_enter_*
{
  @syscalls[probe] = count();
}

@syscalls[tracepoint:syscalls:sys_enter_close]: 35883
@syscalls[tracepoint:syscalls:sys_enter_openat]: 37641
@syscalls[tracepoint:syscalls:sys_enter_read]: 49833
@syscalls[tracepoint:syscalls:sys_enter_newfstatat]: 78194

It would be nice to have a way to access only part of the attach point's definition, so that we could generate output like this:

@syscalls[sys_enter_close]: 35883
@syscalls[sys_enter_openat]: 37641
@syscalls[sys_enter_read]: 49833
@syscalls[sys_enter_newfstatat]: 78194

Describe the solution you'd like

Provide a way to access component parts of a probe's definition. probe will still return the full probe name, but individual pieces could be accessed as if it was an array:

probe;    // tracepoint:syscalls:sys_enter_read
probe[0]; // tracepoint
probe[1]; // syscalls
probe[2]; // sys_enter_read

Or tuple style:

probe.0; // tracepoint
probe.1; // syscalls
probe.2; // sys_enter_read

Describe alternative solutions or features you've considered

func is an alternative for some use-cases (e.g. kprobes), but it doesn't work for all probe types (e.g. tracepoints) and its semantics are still not fully defined when tracing inlined functions.

Problems

• I suppose this could only work if all attachment points of a probe were of the same type, i.e. all tracepoints or all USDTs. A mixture would lead to strange behaviour.
• What do we do about probes types which take a variable number of parameters? e.g. kfunc:foo vs kfunc:module:foo

[viktormalik]

It would be nice to have a way to access only part of the attach point's definition, so that we could generate output like this:

@syscalls[sys_enter_close]: 35883
@syscalls[sys_enter_openat]: 37641
@syscalls[sys_enter_read]: 49833
@syscalls[sys_enter_newfstatat]: 78194

Yeah, this is nice and useful. I can see use-cases for other probe types, too, e.g. grouping by kernel module for kfuncs.

• What do we do about probes types which take a variable number of parameters? e.g. kfunc:foo vs kfunc:module:foo

This one will be tricky. Almost all probes have an optional part these days (kfuncs and kprobes have module, USDTs have namespace, uprobes has language, etc.) so using numerical indices may be quite confusing for users.

An alternative would be to introduce names for the individual parts but those would probably have to be different across various probe types. For example:

• tracepoints: probe.type, probe.category, probe.event
• kprobes/kfuncs: probe.type, probe.module, probe.function
• uprobes: probe.type, probe.binary, probe.function, probe.offset
• and so on...

The advantage is that we could go as far as interpret the probe part on the same "index" differently based on the field name - i.e. for uprobe, probe.function would return a string while probe.offset would return a number even though they are both the last part of the probe spec.

The disadvantage is that we'd have different part names for different probes (but since we wouldn't allow these for probes with attachpoints of mixed types, it wouldn't be that much of a problem). We could respect the naming from the manual so that it'd be clear to users what name to use.