docs/concepts/config.md - third_party/perfetto - Git at Google

 # Trace configuration

 Unlike many always-on logging systems (e.g. Linux's rsyslog, Android's logcat),
 in Perfetto all tracing data sources are idle by default and record data only
 when instructed to do so.

 Data sources record data only when one (or more) tracing sessions are active.
 A tracing session is started by invoking the `perfetto` cmdline client and
 passing a config (see QuickStart guide for
 [Android](/docs/quickstart/android-tracing.md) or
 [Linux](/docs/quickstart/linux-tracing.md)).

 A simple trace config looks like this:

 ```protobuf
 duration_ms: 10000

 buffers {
   size_kb: 65536
   fill_policy: RING_BUFFER
 }

 data_sources {
   config {
     name: "linux.ftrace"
     target_buffer: 0
     ftrace_config {
       ftrace_events: "sched_switch"
       ftrace_events: "sched_wakeup"
     }
   }
 }

 ````

 And is used as follows:

 ```bash
 perfetto --txt -c config.pbtx -o trace_file.pftrace
 ```

 TIP: Some more complete examples of trace configs can be found in the repo in
 [`/test/configs/`](/test/configs/).

 ## TraceConfig

 The TraceConfig is a protobuf message
 ([reference docs](/docs/reference/trace-config-proto.autogen)) that defines:

 1. The general behavior of the whole tracing system, e.g.:
     * The max duration of the trace.
     * The number of in-memory buffers and their size.
     * The max size of the output trace file.

 2. Which data sources to enable and their configuration, e.g.:
     * For the [kernel tracing data source](/docs/data-sources/cpu-scheduling.md)
     , which ftrace events to enable.
     * For the [heap profiler](/docs/data-sources/native-heap-profiler.md), the
     target process name and sampling rate.

     See the _data sources_ section of the docs for details on how to
     configure the data sources bundled with Perfetto.

 3. The `{data source} x {buffer}` mappings: which buffer each data
     source should write into (see [buffers section](#buffers) below).

 The tracing service (`traced`) acts as a configuration dispatcher: it receives
 a config from the `perfetto` cmdline client (or any other
 [Consumer](/docs/concepts/service-model.md#consumer)) and forwards parts of the
 config to the various [Producers](/docs/concepts/service-model.md#producer)
 connected.

 When a tracing session is started by a consumer, the tracing service will:

 * Read the outer section of the TraceConfig (e.g. `duration_ms`, `buffers`) and
   use that to determine its own behavior.
 * Read the list of data sources in the `data_sources` section. For each data
   source listed in the config, if a corresponding name (`"linux.ftrace"` in the
   example below) was registered, the service will ask the producer process to
   start that data source, passing it the raw bytes of the
   [`DataSourceConfig` subsection][dss] verbatim to the data source (See
   backward/forward compat section below).

 ![TraceConfig diagram](/docs/images/trace_config.png)

 [dss]: /docs/reference/trace-config-proto.autogen#DataSourceConfig

 ## Buffers

 The buffer sections define the number, size and policy of the in-memory buffers
 owned by the tracing service. It looks as follows:

 ```protobuf
 // Buffer #0
 buffers {
   size_kb: 4096
   fill_policy: RING_BUFFER
 }

 // Buffer #1
 buffers {
   size_kb: 8192
   fill_policy: DISCARD
 }
 ```

 Each buffer has a fill policy which is either:

 * RING_BUFFER (default): the buffer behaves like a ring buffer and writes when
   full will wrap over and replace the oldest trace data in the buffer.

 * DISCARD: the buffer stops accepting data once full. Further write attempts are
   dropped.

 WARNING: DISCARD can have unexpected side-effect with data sources that commit
 data at the end of the trace.

 A trace config must define at least one buffer to be valid. In the simplest case
 all data sources will write their trace data into the same buffer.

  While this is
 fine for most basic cases, it can be problematic in cases where different data
 sources write at significantly different rates.

 For instance, imagine a trace config that enables both:

 1. The kernel scheduler tracer. On a typical Android phone this records
    ~10000 events/second, writing ~1 MB/s of trace data into the buffer.

 2. Memory stat polling. This data source writes the contents of /proc/meminfo
    into the trace buffer and is configured to poll every 5 seconds, writing
    ~100 KB per poll interval.

 If both data sources are configured to write into the same buffer and such
 buffer is set to 4MB, most traces will contain only one memory snapshot. There
 are very good chances that most traces won't contain any memory snapshot at all,
 even if the 2nd data sources was working perfectly.
 This is because during the 5 s. polling interval, the scheduler data source can
 end up filling the whole buffer, pushing the memory snapshot data out of the
 buffer.

 ## Dynamic buffer mapping

 Data-source <> buffer mappings are dynamic in Perfetto.
 In the simplest case a tracing session can define only one buffer. By default,
 all data sources will record data into that one buffer.

 In cases like the example above, it might be preferable separating these data
 sources into different buffers.
 This can be achieved with the `target_buffer` field of the TraceConfig.

 ![Buffer mapping](/docs/images/trace_config_buffer_mapping.png)

 Can be achieved with:

 ```protobuf
 data_sources {
   config {
     name: "linux.ftrace"
     target_buffer: 0       // <-- This goes into buffer 0.
     ftrace_config { ... }
   }
 }

 data_sources: {
   config {
       name: "linux.sys_stats"
       target_buffer: 1     // <-- This goes into buffer 1.
       sys_stats_config { ... }
   }
 }

 data_sources: {
   config {
     name: "android.heapprofd"
     target_buffer: 1       // <-- This goes into buffer 1 as well.
     heapprofd_config { ... }
   }
 }
 ```

 ## PBTX vs binary format

 There are two ways to pass the trace config when using the `perfetto` cmdline
 client format:

 #### Text format

 It is the preferred format for human-driven workflows and exploration. It
 allows to pass directly the text file in the PBTX (ProtoBuf TeXtual
 representation) syntax, for the schema defined in the
 [trace_config.proto](/protos/perfetto/config/trace_config.proto)
 (see [reference docs](/docs/reference/trace-config-proto.autogen))

 When using this mode pass the `--txt` flag to `perfetto` to indicate the config
 should be interpreted as a PBTX file:

 ```bash
 perfetto -c /path/to/config.pbtx --txt -o trace_file.pftrace
 ```

 NOTE: The `--txt` option has been introduced only in Android 10 (Q). Older
 versions support only the binary format.

 WARNING: Do not use the text format for machine-to-machine interaction
 benchmark, scripts and tools) as it's more prone to breakages (e.g. if a field
 is renamed or an enum is turned into an integer)

 #### Binary format

 It is the preferred format for machine-to-machine (M2M) interaction. It involves
 passing the protobuf-encoded binary of the TraceConfig message.
 This can be obtained passing the PBTX in input to the protobuf's `protoc`
 compiler (which can be downloaded
 [here](https://github.com/protocolbuffers/protobuf/releases)).

 ```bash
 cd ~/code/perfetto  # external/perfetto in the Android tree.

 protoc --encode=perfetto.protos.TraceConfig \
         -I. protos/perfetto/config/perfetto_config.proto \
         < config.txpb \
         > config.bin
 ```

 and then passing it to perfetto as follows, without the `--txt` argument:

 ```bash
 perfetto -c config.bin -o trace_file.pftrace
 ```

 ## {#long-traces} Streaming long traces

 By default Perfetto keeps the full trace buffer(s) in memory and writes it into
 the destination file (the `-o` cmdline argument) only at the end of the tracing
 session. This is to reduce the perf-intrusiveness of the tracing system.
 This, however, limits the max size of the trace to the physical memory size of
 the device, which is often too limiting.

 In some cases (e.g., benchmarks, hard to repro cases) it is desirable to capture
 traces that are way larger than that, at the cost of extra I/O overhead.

 To achieve that, Perfetto allows to periodically write the trace buffers into
 the target file (or stdout) using the following TraceConfig fields:

 * `write_into_file (bool)`:
 When true periodically drains the trace buffers into the output
 file. When this option is enabled, the userspace buffers need to be just
 big enough to hold tracing data between two write periods.
 The buffer sizing depends on the activity of the device.
 The data rate of a typical trace is ~1-4 MB/s. So a 16MB in-memory buffer can
 hold for up write periods of ~4 seconds before starting to lose data.

 * `file_write_period_ms (uint32)`:
 Overrides the default drain period (5s). Shorter periods require a smaller
 userspace buffer but increase the performance intrusiveness of tracing. If
 the period given is less than 100ms, the tracing service will use a period
 of 100ms.

 * `max_file_size_bytes (uint64)`:
 If set, stops the tracing session after N bytes have been written. Used to
 cap the size of the trace.

 For a complete example of a working trace config in long-tracing mode see
 [`/test/configs/long_trace.cfg`](/test/configs/long_trace.cfg).

 Summary: to capture a long trace just set `write_into_file:true`, set a long
          `duration_ms` and use an in-memory buffer size of 32MB or more.

 ## Data-source specific config

 Alongside the trace-wide configuration parameters, the trace config also defines
 data-source-specific behaviors. At the proto schema level, this is defined in
 the `DataSourceConfig` section of `TraceConfig`:

 From [data_source_config.proto](/protos/perfetto/config/data_source_config.proto):

 ```protobuf
 message TraceConfig {
   ...
   repeated DataSource data_sources = 2;  // See below.
 }

 message DataSource {
   optional protos.DataSourceConfig config = 1;  // See below.
   ...
 }

 message DataSourceConfig {
   optional string name = 1;
   ...
   optional FtraceConfig ftrace_config = 100 [lazy = true];
   ...
   optional AndroidPowerConfig android_power_config = 106 [lazy = true];
 }
 ```

 Fields like `ftrace_config`, `android_power_config` are examples of data-source
 specific configs. The tracing service will completely ignore the contents of
 those fields and route the whole DataSourceConfig object to any data source
 registered with the same name.

 The `[lazy=true]` marker has a special implication in the
 [protozero](/docs/design-docs/protozero.md) code generator. Unlike standard
 nested messages, it generates raw accessors (e.g.,
 `const std::string& ftrace_config_raw()` instead of
 `const protos::FtraceConfig& ftrace_config()`). This is to avoid injecting too
 many `#include` dependencies and avoiding binary size bloat in the code that
 implements data sources.

 #### A note on backwards/forward compatibility
 The tracing service will route the raw binary blob of the `DataSourceConfig`
 message to the data sources with a matching name, without attempting to decode
 and re-encode it. If the `DataSourceConfig` section of the trace config contains
 a new field that didn't exist at the time when the service was built, the
 service will still pass the `DataSourceConfig` through to the data source.
 This allows to introduced new data sources without needing the service to
 know anything about them upfront.

 TODO: we are aware of the fact that today extending the `DataSourceConfig` with
 a custom proto requires changing the `data_source_config.proto` in the Perfetto
 repo, which is unideal for external projects. The long-term plan is to reserve
 a range of fields for non-upstream extensions and provide generic templated
 accessors for client code. Until then, we accept patches upstream to introduce
 ad-hoc configurations for your own data sources.

 ## Multi-process data sources

 Some data sources are singletons. E.g., in the case of scheduler tracing that
 Perfetto ships on Android, there is only data source for the whole system,
 owned by the `traced_probes` service.

 However, in the general case multiple processes can advertise the same data
 source. This is the case, for instance, when using the
 [Perfetto SDK](/docs/instrumentation/tracing-sdk.md) for userspace
 instrumentation.

 If this happens, when starting a tracing session that specifies that data
 source in the trace config, Perfetto by default will ask all processes that
 advertise that data source to start it.

 In some cases it might be desirable to further limit the enabling of the data
 source to a specific process (or set of processes). That is possible through the
 `producer_name_filter` and `producer_name_regex_filter`.

 NOTE: the typical Perfetto run-time model is: one process == one Perfetto
       Producer; one Producer typically hosts multiple data sources.

 When those filters are set, the Perfetto tracing service will activate the data
 source only in the subset of producers matching the filter.

 Example:

 ```protobuf
 buffers {
   size_kb: 4096
 }

 data_sources {
   config {
     name: "track_event"

     # Enable the data source only on Chrome and Chrome canary.
     producer_name_filter: "com.android.chrome"
     producer_name_filter: "com.google.chrome.canary"
   }
 }
 ```

 ## Triggers

 In nominal conditions, a tracing session has a lifecycle that simply matches the
 invocation of the `perfetto` cmdline client: trace data recording starts when
 the TraceConfig is passed to `perfetto` and ends when either the
 `TraceConfig.duration_ms` has elapsed, or when the cmdline client terminates.

 Perfetto supports an alternative mode of either starting or stopping the trace
 which is based on triggers. The overall idea is to declare in the trace config
 itself:

 * A set of triggers, which are just free-form strings.
 * Whether a given trigger should cause the trace to be started or stopped, and
   the start/stop delay.

 Why using triggers? Why can't one just start perfetto or kill(SIGTERM) it when
 needed? The rationale of all this is the security model: in most Perfetto
 deployments (e.g., on Android) only privileged entities (e.g., adb shell) can
 configure/start/stop tracing. Apps are unprivileged in this sense and they
 cannot control tracing.

 Triggers offer a way to unprivileged apps to control, in a limited fashion, the
 lifecycle of a tracing session. The conceptual model is:

 * The privileged Consumer (see
   [_Service model_](/docs/concepts/service-model.md)), i.e. the entity
   that is normally authorized to start tracing (e.g., adb shell in Android),
   declares upfront what are the possible trigger names for the trace and what
   they will do.
 * Unprivileged entities (any random app process) can activate those triggers.
   Unprivileged entities don't get a say on what the triggers will do, they only
   communicate that an event happened.

 Triggers can be signaled via the cmdline util

 ```bash
 /system/bin/trigger_perfetto "trigger_name"
 ```

 (or also by starting an independent trace session which uses only the
 `activate_triggers: "trigger_name"` field in the config)

 There are two types of triggers:

 #### Start triggers

 Start triggers allow activating a tracing session only after some significant
 event has happened. Passing a trace config that has `START_TRACING` trigger
 causes the tracing session to stay idle (i.e. not recording any data) until either
 the trigger is hit or the `duration_ms` timeout is hit.

 Example config:
 ```protobuf
 // If no trigger is hit, the trace will end without having recorded any data
 // after 30s.
 duration_ms: 30000

 // If the "myapp_is_slow" is hit, the trace starts recording data and will be
 // stopped after 5s.
 trigger_config {
   trigger_mode: START_TRACING
   triggers {
     name: "myapp_is_slow"
     stop_delay_ms: 5000
   }
 }

 // The rest of the config is as usual.
 buffers { ... }
 data_sources { ... }
 ```

 #### Stop triggers

 STOP_TRACING triggers allow to prematurely finalize a trace when the trigger is
 hit. In this mode the trace starts immediately when the `perfetto` client is
 invoked (like in nominal cases). The trigger acts as a premature finalization
 signal.

 This can be used to use perfetto in flight-recorder mode. By starting a trace
 with buffers configured in `RING_BUFFER` mode and `STOP_TRACING` triggers,
 the trace will be recorded in a loop and finalized when the culprit event is
 detected. This is key for events where the root cause is in the recent past
 (e.g., the app detects a slow scroll or a missing frame).

 Example config:
 ```protobuf
 // If no trigger is hit, the trace will end after 30s.
 duration_ms: 30000

 // If the "missed_frame" is hit, the trace is stopped after 1s.
 trigger_config {
   trigger_mode: STOP_TRACING
   triggers {
     name: "missed_frame"
     stop_delay_ms: 1000
   }
 }

 // The rest of the config is as usual.
 buffers { ... }
 data_sources { ... }
 ```

 ## Other resources

 * [TraceConfig Reference](/docs/reference/trace-config-proto.autogen)
 * [Buffers and dataflow](/docs/concepts/buffers.md)
	# Trace configuration

	Unlike many always-on logging systems (e.g. Linux's rsyslog, Android's logcat),
	in Perfetto all tracing data sources are idle by default and record data only
	when instructed to do so.

	Data sources record data only when one (or more) tracing sessions are active.
	A tracing session is started by invoking the `perfetto` cmdline client and
	passing a config (see QuickStart guide for
	[Android](/docs/quickstart/android-tracing.md) or
	[Linux](/docs/quickstart/linux-tracing.md)).

	A simple trace config looks like this:

	```protobuf
	duration_ms: 10000

	buffers {
	size_kb: 65536
	fill_policy: RING_BUFFER
	}

	data_sources {
	config {
	name: "linux.ftrace"
	target_buffer: 0
	ftrace_config {
	ftrace_events: "sched_switch"
	ftrace_events: "sched_wakeup"
	}
	}
	}

	````

	And is used as follows:

	```bash
	perfetto --txt -c config.pbtx -o trace_file.pftrace
	```

	TIP: Some more complete examples of trace configs can be found in the repo in
	[`/test/configs/`](/test/configs/).

	## TraceConfig

	The TraceConfig is a protobuf message
	([reference docs](/docs/reference/trace-config-proto.autogen)) that defines:

	1. The general behavior of the whole tracing system, e.g.:
	* The max duration of the trace.
	* The number of in-memory buffers and their size.
	* The max size of the output trace file.

	2. Which data sources to enable and their configuration, e.g.:
	* For the [kernel tracing data source](/docs/data-sources/cpu-scheduling.md)
	, which ftrace events to enable.
	* For the [heap profiler](/docs/data-sources/native-heap-profiler.md), the
	target process name and sampling rate.

	See the _data sources_ section of the docs for details on how to
	configure the data sources bundled with Perfetto.

	3. The `{data source} x {buffer}` mappings: which buffer each data
	source should write into (see [buffers section](#buffers) below).

	The tracing service (`traced`) acts as a configuration dispatcher: it receives
	a config from the `perfetto` cmdline client (or any other
	[Consumer](/docs/concepts/service-model.md#consumer)) and forwards parts of the
	config to the various [Producers](/docs/concepts/service-model.md#producer)
	connected.

	When a tracing session is started by a consumer, the tracing service will:

	* Read the outer section of the TraceConfig (e.g. `duration_ms`, `buffers`) and
	use that to determine its own behavior.
	* Read the list of data sources in the `data_sources` section. For each data
	source listed in the config, if a corresponding name (`"linux.ftrace"` in the
	example below) was registered, the service will ask the producer process to
	start that data source, passing it the raw bytes of the
	[`DataSourceConfig` subsection][dss] verbatim to the data source (See
	backward/forward compat section below).

	![TraceConfig diagram](/docs/images/trace_config.png)

	[dss]: /docs/reference/trace-config-proto.autogen#DataSourceConfig

	## Buffers

	The buffer sections define the number, size and policy of the in-memory buffers
	owned by the tracing service. It looks as follows:

	```protobuf
	// Buffer #0
	buffers {
	size_kb: 4096
	fill_policy: RING_BUFFER
	}

	// Buffer #1
	buffers {
	size_kb: 8192
	fill_policy: DISCARD
	}
	```

	Each buffer has a fill policy which is either:

	* RING_BUFFER (default): the buffer behaves like a ring buffer and writes when
	full will wrap over and replace the oldest trace data in the buffer.

	* DISCARD: the buffer stops accepting data once full. Further write attempts are
	dropped.

	WARNING: DISCARD can have unexpected side-effect with data sources that commit
	data at the end of the trace.

	A trace config must define at least one buffer to be valid. In the simplest case
	all data sources will write their trace data into the same buffer.

	While this is
	fine for most basic cases, it can be problematic in cases where different data
	sources write at significantly different rates.

	For instance, imagine a trace config that enables both:

	1. The kernel scheduler tracer. On a typical Android phone this records
	~10000 events/second, writing ~1 MB/s of trace data into the buffer.

	2. Memory stat polling. This data source writes the contents of /proc/meminfo
	into the trace buffer and is configured to poll every 5 seconds, writing
	~100 KB per poll interval.

	If both data sources are configured to write into the same buffer and such
	buffer is set to 4MB, most traces will contain only one memory snapshot. There
	are very good chances that most traces won't contain any memory snapshot at all,
	even if the 2nd data sources was working perfectly.
	This is because during the 5 s. polling interval, the scheduler data source can
	end up filling the whole buffer, pushing the memory snapshot data out of the
	buffer.

	## Dynamic buffer mapping

	Data-source <> buffer mappings are dynamic in Perfetto.
	In the simplest case a tracing session can define only one buffer. By default,
	all data sources will record data into that one buffer.

	In cases like the example above, it might be preferable separating these data
	sources into different buffers.
	This can be achieved with the `target_buffer` field of the TraceConfig.

	![Buffer mapping](/docs/images/trace_config_buffer_mapping.png)

	Can be achieved with:

	```protobuf
	data_sources {
	config {
	name: "linux.ftrace"
	target_buffer: 0 // <-- This goes into buffer 0.
	ftrace_config { ... }
	}
	}

	data_sources: {
	config {
	name: "linux.sys_stats"
	target_buffer: 1 // <-- This goes into buffer 1.
	sys_stats_config { ... }
	}
	}

	data_sources: {
	config {
	name: "android.heapprofd"
	target_buffer: 1 // <-- This goes into buffer 1 as well.
	heapprofd_config { ... }
	}
	}
	```

	## PBTX vs binary format

	There are two ways to pass the trace config when using the `perfetto` cmdline
	client format:

	#### Text format

	It is the preferred format for human-driven workflows and exploration. It
	allows to pass directly the text file in the PBTX (ProtoBuf TeXtual
	representation) syntax, for the schema defined in the
	[trace_config.proto](/protos/perfetto/config/trace_config.proto)
	(see [reference docs](/docs/reference/trace-config-proto.autogen))

	When using this mode pass the `--txt` flag to `perfetto` to indicate the config
	should be interpreted as a PBTX file:

	```bash
	perfetto -c /path/to/config.pbtx --txt -o trace_file.pftrace
	```

	NOTE: The `--txt` option has been introduced only in Android 10 (Q). Older
	versions support only the binary format.

	WARNING: Do not use the text format for machine-to-machine interaction
	benchmark, scripts and tools) as it's more prone to breakages (e.g. if a field
	is renamed or an enum is turned into an integer)

	#### Binary format

	It is the preferred format for machine-to-machine (M2M) interaction. It involves
	passing the protobuf-encoded binary of the TraceConfig message.
	This can be obtained passing the PBTX in input to the protobuf's `protoc`
	compiler (which can be downloaded
	[here](https://github.com/protocolbuffers/protobuf/releases)).

	```bash
	cd ~/code/perfetto # external/perfetto in the Android tree.

	protoc --encode=perfetto.protos.TraceConfig \
	-I. protos/perfetto/config/perfetto_config.proto \
	< config.txpb \
	> config.bin
	```

	and then passing it to perfetto as follows, without the `--txt` argument:

	```bash
	perfetto -c config.bin -o trace_file.pftrace
	```

	## {#long-traces} Streaming long traces

	By default Perfetto keeps the full trace buffer(s) in memory and writes it into
	the destination file (the `-o` cmdline argument) only at the end of the tracing
	session. This is to reduce the perf-intrusiveness of the tracing system.
	This, however, limits the max size of the trace to the physical memory size of
	the device, which is often too limiting.

	In some cases (e.g., benchmarks, hard to repro cases) it is desirable to capture
	traces that are way larger than that, at the cost of extra I/O overhead.

	To achieve that, Perfetto allows to periodically write the trace buffers into
	the target file (or stdout) using the following TraceConfig fields:

	* `write_into_file (bool)`:
	When true periodically drains the trace buffers into the output
	file. When this option is enabled, the userspace buffers need to be just
	big enough to hold tracing data between two write periods.
	The buffer sizing depends on the activity of the device.
	The data rate of a typical trace is ~1-4 MB/s. So a 16MB in-memory buffer can
	hold for up write periods of ~4 seconds before starting to lose data.

	* `file_write_period_ms (uint32)`:
	Overrides the default drain period (5s). Shorter periods require a smaller
	userspace buffer but increase the performance intrusiveness of tracing. If
	the period given is less than 100ms, the tracing service will use a period
	of 100ms.

	* `max_file_size_bytes (uint64)`:
	If set, stops the tracing session after N bytes have been written. Used to
	cap the size of the trace.

	For a complete example of a working trace config in long-tracing mode see
	[`/test/configs/long_trace.cfg`](/test/configs/long_trace.cfg).

	Summary: to capture a long trace just set `write_into_file:true`, set a long
	`duration_ms` and use an in-memory buffer size of 32MB or more.

	## Data-source specific config

	Alongside the trace-wide configuration parameters, the trace config also defines
	data-source-specific behaviors. At the proto schema level, this is defined in
	the `DataSourceConfig` section of `TraceConfig`:

	From [data_source_config.proto](/protos/perfetto/config/data_source_config.proto):

	```protobuf
	message TraceConfig {
	...
	repeated DataSource data_sources = 2; // See below.
	}

	message DataSource {
	optional protos.DataSourceConfig config = 1; // See below.
	...
	}

	message DataSourceConfig {
	optional string name = 1;
	...
	optional FtraceConfig ftrace_config = 100 [lazy = true];
	...
	optional AndroidPowerConfig android_power_config = 106 [lazy = true];
	}
	```

	Fields like `ftrace_config`, `android_power_config` are examples of data-source
	specific configs. The tracing service will completely ignore the contents of
	those fields and route the whole DataSourceConfig object to any data source
	registered with the same name.

	The `[lazy=true]` marker has a special implication in the
	[protozero](/docs/design-docs/protozero.md) code generator. Unlike standard
	nested messages, it generates raw accessors (e.g.,
	`const std::string& ftrace_config_raw()` instead of
	`const protos::FtraceConfig& ftrace_config()`). This is to avoid injecting too
	many `#include` dependencies and avoiding binary size bloat in the code that
	implements data sources.

	#### A note on backwards/forward compatibility
	The tracing service will route the raw binary blob of the `DataSourceConfig`
	message to the data sources with a matching name, without attempting to decode
	and re-encode it. If the `DataSourceConfig` section of the trace config contains
	a new field that didn't exist at the time when the service was built, the
	service will still pass the `DataSourceConfig` through to the data source.
	This allows to introduced new data sources without needing the service to
	know anything about them upfront.

	TODO: we are aware of the fact that today extending the `DataSourceConfig` with
	a custom proto requires changing the `data_source_config.proto` in the Perfetto
	repo, which is unideal for external projects. The long-term plan is to reserve
	a range of fields for non-upstream extensions and provide generic templated
	accessors for client code. Until then, we accept patches upstream to introduce
	ad-hoc configurations for your own data sources.

	## Multi-process data sources

	Some data sources are singletons. E.g., in the case of scheduler tracing that
	Perfetto ships on Android, there is only data source for the whole system,
	owned by the `traced_probes` service.

	However, in the general case multiple processes can advertise the same data
	source. This is the case, for instance, when using the
	[Perfetto SDK](/docs/instrumentation/tracing-sdk.md) for userspace
	instrumentation.

	If this happens, when starting a tracing session that specifies that data
	source in the trace config, Perfetto by default will ask all processes that
	advertise that data source to start it.

	In some cases it might be desirable to further limit the enabling of the data
	source to a specific process (or set of processes). That is possible through the
	`producer_name_filter` and `producer_name_regex_filter`.

	NOTE: the typical Perfetto run-time model is: one process == one Perfetto
	Producer; one Producer typically hosts multiple data sources.

	When those filters are set, the Perfetto tracing service will activate the data
	source only in the subset of producers matching the filter.

	Example:

	```protobuf
	buffers {
	size_kb: 4096
	}

	data_sources {
	config {
	name: "track_event"

	# Enable the data source only on Chrome and Chrome canary.
	producer_name_filter: "com.android.chrome"
	producer_name_filter: "com.google.chrome.canary"
	}
	}
	```

	## Triggers

	In nominal conditions, a tracing session has a lifecycle that simply matches the
	invocation of the `perfetto` cmdline client: trace data recording starts when
	the TraceConfig is passed to `perfetto` and ends when either the
	`TraceConfig.duration_ms` has elapsed, or when the cmdline client terminates.

	Perfetto supports an alternative mode of either starting or stopping the trace
	which is based on triggers. The overall idea is to declare in the trace config
	itself:

	* A set of triggers, which are just free-form strings.
	* Whether a given trigger should cause the trace to be started or stopped, and
	the start/stop delay.

	Why using triggers? Why can't one just start perfetto or kill(SIGTERM) it when
	needed? The rationale of all this is the security model: in most Perfetto
	deployments (e.g., on Android) only privileged entities (e.g., adb shell) can
	configure/start/stop tracing. Apps are unprivileged in this sense and they
	cannot control tracing.

	Triggers offer a way to unprivileged apps to control, in a limited fashion, the
	lifecycle of a tracing session. The conceptual model is:

	* The privileged Consumer (see
	[_Service model_](/docs/concepts/service-model.md)), i.e. the entity
	that is normally authorized to start tracing (e.g., adb shell in Android),
	declares upfront what are the possible trigger names for the trace and what
	they will do.
	* Unprivileged entities (any random app process) can activate those triggers.
	Unprivileged entities don't get a say on what the triggers will do, they only
	communicate that an event happened.

	Triggers can be signaled via the cmdline util

	```bash
	/system/bin/trigger_perfetto "trigger_name"
	```

	(or also by starting an independent trace session which uses only the
	`activate_triggers: "trigger_name"` field in the config)

	There are two types of triggers:

	#### Start triggers

	Start triggers allow activating a tracing session only after some significant
	event has happened. Passing a trace config that has `START_TRACING` trigger
	causes the tracing session to stay idle (i.e. not recording any data) until either
	the trigger is hit or the `duration_ms` timeout is hit.

	Example config:
	```protobuf
	// If no trigger is hit, the trace will end without having recorded any data
	// after 30s.
	duration_ms: 30000

	// If the "myapp_is_slow" is hit, the trace starts recording data and will be
	// stopped after 5s.
	trigger_config {
	trigger_mode: START_TRACING
	triggers {
	name: "myapp_is_slow"
	stop_delay_ms: 5000
	}
	}

	// The rest of the config is as usual.
	buffers { ... }
	data_sources { ... }
	```

	#### Stop triggers

	STOP_TRACING triggers allow to prematurely finalize a trace when the trigger is
	hit. In this mode the trace starts immediately when the `perfetto` client is
	invoked (like in nominal cases). The trigger acts as a premature finalization
	signal.

	This can be used to use perfetto in flight-recorder mode. By starting a trace
	with buffers configured in `RING_BUFFER` mode and `STOP_TRACING` triggers,
	the trace will be recorded in a loop and finalized when the culprit event is
	detected. This is key for events where the root cause is in the recent past
	(e.g., the app detects a slow scroll or a missing frame).

	Example config:
	```protobuf
	// If no trigger is hit, the trace will end after 30s.
	duration_ms: 30000

	// If the "missed_frame" is hit, the trace is stopped after 1s.
	trigger_config {
	trigger_mode: STOP_TRACING
	triggers {
	name: "missed_frame"
	stop_delay_ms: 1000
	}
	}

	// The rest of the config is as usual.
	buffers { ... }
	data_sources { ... }
	```

	## Other resources

	* [TraceConfig Reference](/docs/reference/trace-config-proto.autogen)
	* [Buffers and dataflow](/docs/concepts/buffers.md)