[lttng-dev] Proposal: Make lttng-analyses part of lttng-tools

[Geneviève Bastien]

Hi Jonathan,


Thanks for your feedback, I'm happy we agree on the need to get to
analyses more easily. The unspoken bit of my email is that I am willing
to work on that right now and I can [help] maintain those scripts.

Our perspective at Poly is on the whole toolchain of trace collection,
visualization and analysis, of which lttng is an important part. So from
my point of view, the scripts could include all necessary tracing info
to get to view and analyze the traces with, say, Trace Compass, not just
Julien's lami scripts. I'll detail this idea below.

Also, to give more context, we are preparing a tutorial on trace
collection and visualization for the next LISA conference in October and
having simple one-liner scripts (that is available in a package) to get
traces would be much sexier than many big lines that people would need
to copy-paste manually.


On 2018-07-17 04:47 PM, Jonathan Rajotte-Julien wrote:
>
>> * First impressions stick
> Pretty sure some people still thinks that you need to recompile your kernel for
> kernel tracing to work. For those skimming, lttng-modules DOES NOT
> requires a kernel compilation.
Exactly what I was thinking of, even though you and I never knew that
era, it still sticks to the project! :p
>
>
>> 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
> The doc here seems to have a good basic primer indicating that the user could
> choose to enable all events if necessary and the different projects for
> analysis (Following section).
>
> https://lttng.org/docs/v2.10/#doc-tracing-the-linux-kernel
That is, when one actually reaches that part of the doc... which people
don't read remember ;-)
>
>> 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
> I'm not sure it is the responsibility of the tracer to define "pertinent" events.
> The critical analysis is mostly a Trace Compass thing. The Trace Compass project
> might want to have clearer event requirements (matching to lttng events name or
> other tracer if possible) for their analysis.
It's not the responsibility of the tracer at all. But it could be the
responsiblity of tracing helper script. Having it in Trace Compass means
the use case would be to start tracing with Trace Compass. But the use
case we have in mind here is flight-recorder mode + snapshots on various
server machines when something occurs, then gather traces and if
required, open them in Trace Compass and maybe look at the critical
path. So tracing would be controlled by helper scripts.

The profiles I was mentioning are also at the script level. For
instance, one would start recording
./lttng-record [-p <profile_name>]

where we could have predefined profiles, for instance

* 'kernel_base' which would include all kernel events necessary for
critical path
* 'kernel_sched' for sched_switches only (to get thread status, CPU
times, etc for another userspace (not just UST) trace)
* 'kernel_memory' for memory events and other required for memory analysis
* 'kernel_kvm' ....(which will eventually include userspace stuff for
statedumps, etc)

You see the point.

>
>> 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.
> Scripts could be done (lttng-analyses), not sure profiles at the tracer level make sense.
>
> I think lttng-analyses already provides the essential part of a possible
> solution. It would be a matter wrapping the lttng-analyses-record command and
> the analyses scripts.
I Agree, see above
>
>
> I would be more inclined to have it as a "recommended" package of
> lttng-modules (since only kernel analyses are provided)
for now
> packages for package manager supporting this kind of feature (e.g apt).
>
> Installing from source should not be the "go to" way of installing lttng for
> beginners or people with limited involvement in the development of the project.
You guys have any stats on the "go to" way of lttng users? Stats on
package downloads for different distros
>
>> 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!
> I agree on center-plate stuff, not so much on how :).
Maybe for now, we can keep it in a separate package, as long as it
becomes part of the new "go to" way for starters.
>
> I'm eager to get some feedback from Mathieu and Jérémie on all this.
So am I!

Cheers,
Geneviève