[ltt-dev] LTTng Agent

Bernd Hufmann Bernd.Hufmann at ericsson.com
Fri Apr 1 10:49:08 EDT 2011


Hello

we are currently integrating and enhancing the LTTng Trace Control 
plugin for Eclipse, that was originally provided as prototype by 
Polytechnique de Montreal.  Once all implementations are finished, the 
plugin will be made available at the Linuxtools project within the 
Eclipse foundation. This plugin connects as a client to a LTTng agent in 
order to control the tracing of kernel or user space applications using 
LTTng kernel or user space tracer. We have good progress but there are 
some features (commands) missing in the LTTng agent which I think are 
important for the user of the LTTng Trace Control. This email is to 
point out this missing features and to get some feedback about my 
suggestions.

My target node has the following versions installed:

- Ubuntu 10.10
- Instrumented kernel 2.6.35-24 installed from the PPA repository at 
https://launchpad.net/~lttng/+archive/ppa 
<https://launchpad.net/%7Elttng/+archive/ppa>
- manually upgraded UST 0.12
- manually upgraded lttng-agent from the git repository 
(git.dorsal.polymtl.ca/git/lttng-agent.git), master branch of 23 March 2011


The LTTng agent provides commands to configure traces, markers or 
channels. In some of the cases it's possible for the user to get that 
information back form the agent (e.g. getActiveTraceInfo). However, 
there are also many parameters which can't be retrieved. Generally 
spoken, each parameter that can be set, there should be a command to get 
that information back. See below for a list of missing commands and 
other issues. I split the list between kernel and UST. The commands are 
explained from the command line client point of view.

    * Kernel
          o There isn't any command to get the state of the tracing,
            that means it's not possible to find out if an existing
            trace is started or paused. As well as it's not possible to
            retrieve the transport type (e.g. relay). It's possible to
            retrieve all active traces (command: getActiveTraces) and
            their configuration (getActiveTraceInfo), but the state and
            transport is not available.
            I propose to extend the command getActiveTraceInfo should be
            extended to return the current state (started or paused).

            Command: getActiveTraceInfo provider target trace
            Output: {"target":"<target>","trace":"<trace>","destination":"<trace
            path>","numThread":<# threads>,"flight_only":<flight
            recorder>,"normal_only":<normal mode>,
            "transport":<transport>, "is_started":<state>}
            where:
            <target>: the target name
            <trace>: trace name
            <trace path>: the trace path trace is local to the agent or
            network when streaming
            <# threads>: the number of threads
            <flight recorder>: true for flight recorder mode else false
            <normal mode>: true for normal mode else false
            <transport> : the transport used
            <is_started>: true if trace is started or false if trace is
            paused

          o There is a possibility to set parameters for channels, but
            there is no way to retrieve this information. Here are the
            set commands: setChannelEnable, setChannelOverride,
            setChannelSubbufNum, setChannelSubbufSize and
            setChannelTimer. There should be a command to retrieve that
            information. To be consistent to the other get-commands I
            propose the following command:

            Command: getChannelInfo provider target trace channel
            Output: {"target":"<target>","trace":"<trace>","channel":"<channel>", "timer":<timer>, "is_enabled":<enable
            state>,"is_override":<override state>,"subbuf_num":<#
            subbuf>,"subbuf_size":<subbuf size>}
            where:
            <target>: the target name
            <trace>: trace name
            <channel>: the channel name
            <timer>: channel timer in milliseconds
            <enable state>: true if enabled
            <override state>: true if override mode else false
            <# subbuf>: number of sub buffers
            <subbuf size>: size of sub buffer

    * UST
          o Currently it's not possible to create a UST trace using the
            LTTng Trace control and LTTng agent. This needs to be
            addressed and is currently looked at.

          o For UST, there isn't a command to get the created traces for
            a given target. Neither command getTraces nor
            getActiveTraces is implemented as it is for kernel traces. I
            understand that for UST there is always only 1 trace
            possible per target (with name auto), but the user has to
            have the possibility to retrieve the information from the
            agent whether the trace has been created or not. I propose
            to implement the commands getTraces and getActiveTraces.

          o As for kernel traces, there should be the possibility to
            retrieve the information about configured trace parameters.
            I propose to implement getActiveTraceInfo which returns the
            same information as for kernel traces (as proposed above)

          o As for kernel traces, there should be the possibility to
            retrieve the information about the configured channel
            parameters. For UST, only the channel timer can be
            configured and  only one single timer is supported per
            provider. I propose to use the getChannelInfo command as
            proposed above for kernel traces (to be consistent).


Could you please give me some feedback about the above requested 
enhancements of the LTTng agent? What are the future plans for the LTTng 
agent? Is it possible to include these enhancements?

Best Regards
Bernd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20110401/832acf7e/attachment-0003.htm>


More information about the lttng-dev mailing list