Project

General

Profile

Actions

Feature #273

closed

Get information from lttng command using a standard output format

Added by Philippe Proulx over 12 years ago. Updated over 9 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
06/19/2012
Due date:
% Done:

100%

Estimated time:

Description

Suggestion to add an option to some lttng commands to get the output in XML/JSON/other standard format for easier automated parsing.

Example:

# lttng list --json auto-20120619-131154
{
  kernel: {
    "channel0": {
      enabled: true,
      attributes: {
        overwriteMode: 0,
        subbuffers: {
          count: 4,
          size: 262144
        },
        switchTimerInterval: 0,
        readTimerInterval: 200,
        output: "splice()" 
      },
      events: {
        syscalls: {
          enabled: true
        },
        tracepoints: {
          "block_rq_remap": {
            logLevel: {
              name: "TRACE_EMERG",
              value: 0
            },
            enabled: true
          },
          "irq_handler_exit": {
            logLevel: {
              name: "TRACE_EMERG",
              value: 0
            },
            enabled: true
          },
          "timer_start": {
            logLevel: {
              name: "TRACE_EMERG",
              value: 0
            },
            enabled: false
          }
        }
      }
    }
  }
}

# lttng list --xml auto-20120619-131154
<?xml version="1.0" encoding="utf-8" ?>
<kernel>
  <channel name="channel0" enabled="true">
    <attributes>
      <attr name="overwriteMode" value="0" />
      <attr name="subbuffersCount" value="4" />
      <attr name="subbuffersSize" value="262144" />
      <attr name="switchTimerInterval" value="0" />
      <attr name="readTimerInterval" value="200" />
      <attr name="output" value="splice()" />
    </attributes>
    <events>
      <syscalls enabled="true" />
      <tracepoints>
        <event name="block_rq_remap" enabled="true">
          <loglevel name="TRACE_EMERG" value="0" />
        </event>
        <event name="irq_handler_exit" enabled="true">
          <loglevel name="TRACE_EMERG" value="0" />
        </event>
        <event name="timer_start" enabled="false">
          <loglevel name="TRACE_EMERG" value="0" />
        </event>
      </tracepoints>
    </events>
  </channel>
</kernel>

Related issues 1 (1 open0 closed)

Related to LTTng-tools - Feature #35: Remote administrationConfirmed02/11/2012

Actions
Actions #1

Updated by Anonymous over 12 years ago

We could get some inspiration from GDB's Machine Interface (GDB/MI).
This would also make remote control much easier.

Actions #2

Updated by Philippe Proulx over 12 years ago

Alexandre Montplaisir wrote:

We could get some inspiration from GDB's Machine Interface (GDB/MI).

Looks a lot like JSON: tuples between {}, arrays between [], entries as variable=value (JSON: variable:value).

This would also make remote control much easier.

Yes, this is probably the main purpose of this feature request. Creating any control GUI would also be much easier because all actions can be redirected to the lttng command and its output may be displayed in lists or trees if standardized.

Actions #3

Updated by Yannick Brosseau over 12 years ago

This would also make remote control much easier.

Yes, this is probably the main purpose of this feature request. Creating any control GUI would also be much easier because all actions can be redirected to the lttng command and its output may be displayed in lists or trees if standardized.

But for the control, don't forget that there is the lttng-ctl library
(soon with python binding...)

Actions #4

Updated by Philippe Proulx over 12 years ago

But for the control, don't forget that there is the lttng-ctl library
(soon with python binding...)

It's still possible that a remote embedded device has basic communication tools (Telnet, maybe SSH) and the lttng command, but not Python. Remote control is then possible by cooking lttng commands and sending them through Telnet/SSH, then getting information by reading its output.

Actions #5

Updated by Jonathan Rajotte about 10 years ago

This is solved by the merging of machine interface from commit c7e35b037773dbbfe10178c946ba44feefb226e1 and subsequent one.

Actions #6

Updated by Jonathan Rajotte Julien over 9 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF