tracee cli UX

[AsafEitani]

Wanted to open a discussion regarding the user experience of tracee via cli.

At the moment we have a really complex cli interface - lots of flags, flags with different styles (--, :, =) and complicated help interface (can't get all the info in one place - ex. output help).

While we do have an open issue regarding file configuration (#467 ) I believe we should improve the cli interface as well.
Combining tracee-ebpf and rules to a single binary will help reduce some of the flags like --input-tracee and the output format.

The following are the issues as I see it:

• Hard to use - tracee is hard to use by a new user that isn't really familiar with the project. Even users that use tracee from time to time have a hard time remembering all the feature flags.
• Lots of flags - while tracee present a great customization with lots of options, this can sometime be confusing for the averaged user.
• Flags format - specifying --output option:parse-arguments for example is too long (especially when you cannot name multiple options together)

There might be other issues I skipped - you are welcomed to add some of your own.

I believe we need to improve the UX so that more users will want to use tracee - not only as a detection tool but as a monitoring tool as well.

Adding high level events for common actions (process creation, file writing, etc) will help the common user to understand the output better.
Renaming sets to be more user friendly could also aid in creating a "mode" of tracee with suits different users.

I encourage you to share your thoughts and add concerns and solutions of your own.

[NDStrahilevitz]

I think a good start would be defining subcommands for tracee.

For example in the context of a single binary we could have:

1. tracee trace ... - Would work like tracee-ebpf and could have a similar flag layout we have today. We could also have subcommands for trace which would work like a predefined tracee-ebpf settings (for example a container focused setting).
2. tracee detect ... - Would work like a combined tracee-rules tracee-ebpf, this would have less flags from tracee-ebpf since they would be configured according to the engine needs, so option:parse-arguments wouldn't be needed anymore for example.

Additionally, if we go down the route of a single binary, we could streamline the event streaming flow, and use a direct channel between the two components, this would increase event throughput and possibly reduce a lot of the flags we have that exist to create communication between tracee-ebpf and tracee-rules currently (a lot of the output flags).

[yanivagman]

Once we'll prioritize #1288, we should definitely discuss how we want the command line to look like.
One of the things that I would like to change is the "flags hierarchy" we currently have. I think that some of the flags can be flattened to avoid having long commands and confuse the user with extra help screens for each flag.
For example, we might want to remove the --trace flag, and just have filters with their own flags, e.g.:
--pid, --container, --event, etc.
Same for the capture flag:
--capture-exec, --capture-write, --capture-net, etc.