trace-cmd-record - record a trace from the Ftrace Linux internal tracer
trace-cmd record [OPTIONS] [command]
The trace-cmd(1) record command will set up the Ftrace Linux kernel tracer to record the specified plugins or events that happen while the command executes. If no command is given, then it will record until the user hits Ctrl-C.
The record command of trace-cmd will set up the Ftrace tracer to start tracing the various events or plugins that are given on the command line. It will then create a number of tracing processes (one per CPU) that will start recording from the kernel ring buffer straight into temporary files. When the command is complete (or Ctrl-C is hit) all the files will be combined into a trace.dat file that can later be read (see trace-cmd-report(1)).
Specify a trace plugin. Plugins are special Ftrace tracers that usually do more than just trace an event. Common plugins are
wakeup. A plugin must be supported by the running kernel. To see a list of available plugins, see trace-cmd-list(1).
Specify an event to trace. Various static trace points have been added to the Linux kernel. They are grouped by subsystem where you can enable all events of a given subsystem or specify specific events to be enabled. The
is of the format "subsystem:event-name". You can also just specify the subsystem without the
or the event-name without the "subsystem:". Using "-e sched_switch" will enable the "sched_switch" event where as, "-e sched" will enable all events under the "sched" subsystem.
The 'event' can also contain glob expressions. That is, "*stat*" will
select all events (or subsystems) that have the characters "stat" in their
The keyword 'all' can be used to enable all events.
Specify a filter for the previous event. This must come after a
-e. This will filter what events get recorded based on the content of the event. Filtering is passed to the kernel directly so what filtering is allowed may depend on what version of the kernel you have. Basically, it will let you use C notation to check if an event should be processed or not.
==, >=, <=, >, <, &, |, && and ||
The above are usually safe to use to compare fields.
This will cause all events specified after it on the command line to not be traced. This is useful for selecting a subsystem to be traced but to leave out various events. For Example: "-e sched -v -e "*stat\*"" will enable all events in the sched subsystem except those that have "stat" in their names.
Note: the *-v* option was taken from the way grep(1) inverts the following
This will filter only the executable that is given on the command line. If no command is given, then it will filter itself (pretty pointless). Using
will let you trace only events that are caused by the given command.
but lets you specify a process ID to trace.
By default, trace-cmd report will create a
file. You can specify a different file to write to with the
This will limit the
tracers to only trace the given function name. More than one
may be specified on the command line to trace more than one function. The limited use of glob expressions are also allowed. These are
to only filter functions that start with
to only filter functions that end with
to only filter on functions that contain
This option is for the function_graph plugin. It will graph the given function. That is, it will only trace the function and all functions that it calls. You can have more than one
on the command line.
This has the opposite effect of
-l. The function given with the
option will not be traced. This takes precedence, that is, if you include the same function for both
-l, it will not be traced.
Some tracer plugins enable the function tracer by default. Like the latency tracers. This option prevents the function tracer from being enabled at start up.
Ftrace has various options that can be enabled or disabled. This allows you to set them. Appending the text
to an option disables it. For example: "-O nograph-time" will disable the "graph-time" Ftrace option.
The processes that trace-cmd creates to record from the ring buffer need to wake up to do the recording. Setting the
to zero will cause the processes to wakeup every time new data is written into the buffer. But since Ftrace is recording kernel activity, the act of this processes going back to sleep may cause new events into the ring buffer which will wake the process back up. This will needlessly add extra data into the ring buffer.
The 'interval' metric is microseconds. The default is set to 1000 (1 ms).
This is the time each recording process will sleep before waking up to
record any new data that was written to the ring buffer.
The priority to run the capture threads at. In a busy system the trace capturing threads may be staved and events can be lost. This increases the priority of those threads to the real time (FIFO) priority. But use this option with care, it can also change the behaviour of the system being traced.
This sets the ring buffer size to
kilobytes. Because the Ftrace ring buffer is per CPU, this size is the size of each per CPU ring buffer inside the kernel. Using "-b 10000" on a machine with 4 CPUs will make Ftrace have a total buffer size of 40 Megs.
If another machine is running "trace-cmd listen", this option is used to have the data sent to that machine with UDP packets. Instead of writing to an output file, the data is sent off to a remote box. This is ideal for embedded machines with little storage, or having a single machine that will keep all the data in a single repository.
Note: This option is not supported with latency tracer plugins:
wakeup, wakeup_rt, irqsoff, preemptoff and preemptirqsoff
This option is used with
-N, when there's a need to send the live data with TCP packets instead of UDP. Although TCP is not nearly as fast as sending the UDP packets, but it may be needed if the network is not that reliable, the amount of data is not that intensive, and a guarantee is needed that all traced information is transfered successfully.