Yaml Profiles - Githubissues

This approach to profiles is simper but it comes with some limitations.

Profile syntax

(you can see more examples of profiles in test_data/profiles) This is an example profile:

version: 1.0.0
name: tcp
about: Collects information from the TCP stack
collect:
  - name: Relatively modern kernel
    when:
       - type: version
         version: ">6.2"
    args:
       collectors: skb
       probe:
         - tcp_v4_rcv
         - tcp_v6_rcv
         - tcp_whatever
       skb_sections: tcp
  - name: When ipv6 was just a dream
    when:
       - type: symbol
         name: tcp_v6_rcv
         exists: false
    args:
       collectors: skb
       probe:
         - tcp_v4_rcv
       skb_sections: tcp
- name: Default
    args:
       collectors: skb
       probe:
         - tcp_v4_rcv
         - tcp_v6_rcv
       skb_sections: tcp

When user specifies retis -p tcp collect, the profile is read and evaluated and printed back to the user: [INFO] Applying profile tcp: Relatively modern kernel

The actual set of collector arguments, let's call it "the profile's flavor", that are selected depends on currently available symbols and running kernel version. They are evaluated in order so the first one to match will be selected. It's up to the user to put the flavors in the right order and write sensible conditions.

Other features

Cli subcommand

There is a (to be improved) subcommand called profile that allows the user to list all installed profiles

Multiple profiles per file

Yaml conveniently supports defining multiple objects per file (separated with ---) and this PR supports that as well so multiple related profiles can be defined in a single file (see examples).

Combination

This PR changes some existing arguments so that profiles can be combined:

sudo ./target/debug/retis --log-level debug -p udp,ip collect -f "port 53"
[..]
10:53:54 [INFO] Applying profile udp: Default
10:53:54 [INFO] Applying profile ip: Default
10:53:54 [DEBUG] (1) retis::cli::cli: Resulting CLI arguments: ./target/debug/retis --log-level debug -p udp,ip collect -f port 53 --probe kprobe:udp_gro_receive --probe kprobe:udp_rcv --skb-sections udp --collectors skb --skb-sections l3,tcp --probe kprobe:ip_rcv --probe kprobe:ip_finish_output2 --probe kprobe:napi_gro_receive --probe kprobe:inet_gro_receive --collectors skb
10:53:59 [DEBUG] (1) retis::core::probe::manager: Attaching probe to kprobe:ip_finish_output2
10:53:59 [DEBUG] (1) retis::core::probe::manager: Attaching probe to kprobe:napi_gro_receive
10:53:59 [DEBUG] (1) retis::core::probe::manager: Attaching probe to kprobe:inet_gro_receive
10:53:59 [DEBUG] (1) retis::core::probe::manager: Attaching probe to kprobe:udp_gro_receive
10:53:59 [DEBUG] (1) retis::core::probe::manager: Attaching probe to kprobe:ip_rcv
10:53:59 [DEBUG] (1) retis::core::probe::manager: Attaching probe to kprobe:udp_rcv

Limitations

This yaml syntax is simple enough but the user might express things that are wrong (conditions in the wrong order or overlapping)
Right now arguments coming from the profile are "just" appended to the CLI.
- In order to establish some priority between arguments in the CLI and arguments in the profile we would have to do some non-trivial raw-argument management and I've not seen a good way of doing it without reinventing clap or breaking our distributed argument generation.
- Also, if a subcommand has further nested subcommands it'll be difficult to apply profiles
- I have not implemented conditions on presence of modules but symbol presence should also cover that case.

retis-org / retis