Hi all,
Here's an idea to improve first impression of lttng and hopefully help the UX of the toolchain: tl;dr; I propose to make lttng-analyses part of lttng-tools to provide some basic recording/analysis facilities and make them the blessed way of getting started with lttng, so that end users can quickly obtain meaningful results after installing lttng. Here follows my argumentation. I'll focus on kernel tracing. Facts: * People don't read documentation, at least not from the beginning. * First impressions stick * Potential users trying to evaluate a tool will typically spend a few minutes/hours getting that first impression by reading an as minimalistic as possible readme file. Right now, with lttng, the first thing people are invited to do for kernel tracing, is to enable all the events (-a -k), which results in a number of lost events and a lot of noise when trying to analyze the results, and then 'lttng view' to display the babeltrace output! (see the Usage section in the lttng-modules readme page here: https://github.com/lttng/lttng-modules) That is not imho a good first impressions. Other tracers like ftrace or perf have a more per-event approach to tracing, their beginner's documentation showing how to enable 1 or 2 tracepoints. But to get interesting results, we usually need more than that and listing them individually can be cumbersome. Looking at my outbox, I sent my lttng script to enable events to get the critical path to at least 15 people in the last years... It would be easy to have a predefined script for that purpose. Or many scripts (or profiles?) to enable events for various interesting analyses types. By comparison, take another kernel tracing tool: ebpf / bcc (https://github.com/iovisor/bcc). Installation is easy, then the readme points to a number of tools and example scripts of all kind. Running them after installation is easy and gives instant results. That makes one happy and feel good about bcc! Because having to write an ebpf script would have many users run for their sanity! ;-) But since many use cases are already covered by easily available scripts, people adopt the tool, then a few months later, when they need more, some may get to actually read the script, modify it, make them own. lttng should aim for that kind of ease of use for beginners, have them reach that good feeling in a few minutes trial. And lttng-analyses already provides such scripts to record and analyze traces, and it should really be put forward and improved to give the user a more seamless first experience. I'd suggest to include it with lttng-tools, in a tools/ directory, as it would be one less repo to fork or one less package to install and it's a clear sign that it goes together with lttng. Keeping it as a separate project makes it appear as a side-dish, while it should be the center-plate! What do you think? Regards, Geneviève _______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
