Documentation

Transform data with aggregator and processor plugins

In addition to input plugins and output plugins, Telegraf includes aggregator and processor plugins, which are used to aggregate and process metrics as they pass through Telegraf.

graph TD Process[Process
- transform
- decorate
- filter] Aggregate[Aggregate
- transform
- decorate
- filter] CPU --> Process Memory --> Process MySQL --> Process SNMP --> Process Docker --> Process Process --> Aggregate Aggregate --> InfluxDB Aggregate --> File Aggregate --> Kafka style Process text-align:left style Aggregate text-align:left

Processor plugins process metrics as they pass through and immediately emit results based on the values they process. For example, this could be printing all metrics or adding a tag to all metrics that pass through. For a list of processor plugins and links to their detailed configuration options, see processor plugins.

Aggregator plugins, on the other hand, are a bit more complicated. Aggregators are typically for emitting new aggregate metrics, such as a running mean, minimum, maximum, quantiles, or standard deviation. For this reason, all aggregator plugins are configured with a period. The period is the size of the window of metrics that each aggregate represents. In other words, the emitted aggregate metric will be the aggregated value of the past period seconds. Since many users will only care about their aggregates and not every single metric gathered, there is also a drop_original argument, which tells Telegraf to only emit the aggregates and not the original metrics. For a list of aggregator plugins and links to their detailed configuration options, see aggregator plugins.

Behavior of processors and aggregators when used together

When using both aggregator and processor plugins in Telegraf v1.17, processor plugins process data and then pass it to aggregator plugins. After aggregator plugins aggregate the data, they pass it back to processor plugins. This can have unintended consequences, such as executing mathematical operations twice. See influxdata/telegraf#7993.

If using custom processor scripts, they must be idempotent (repeatable, without side-effects). For custom processes that are not idempotent, use namepass or namedrop to avoid issues when aggregated data is processed a second time.


Was this page helpful?

Thank you for your feedback!


Introducing InfluxDB Clustered

A highly available InfluxDB 3.0 cluster on your own infrastructure.

InfluxDB Clustered is a highly available InfluxDB 3.0 cluster built for high write and query workloads on your own infrastructure.

InfluxDB Clustered is currently in limited availability and is only available to a limited group of InfluxData customers. If interested in being part of the limited access group, please contact the InfluxData Sales team.

Learn more
Contact InfluxData Sales

The future of Flux

Flux is going into maintenance mode. You can continue using it as you currently are without any changes to your code.

Flux is going into maintenance mode and will not be supported in InfluxDB 3.0. This was a decision based on the broad demand for SQL and the continued growth and adoption of InfluxQL. We are continuing to support Flux for users in 1.x and 2.x so you can continue using it with no changes to your code. If you are interested in transitioning to InfluxDB 3.0 and want to future-proof your code, we suggest using InfluxQL.

For information about the future of Flux, see the following: