Query InfluxDB with Flux

See the equivalent InfluxDB v2 documentation: Query InfluxDB with Flux.

This guide walks through the basics of using Flux to query data from InfluxDB. If you haven’t already, make sure to install InfluxDB v1.8+, enable Flux, and choose a tool for writing Flux queries.

The following queries can be executed using any of the methods described in Execute Flux queries. Be sure to provide your InfluxDB Enterprise authorization credentials with each method.

Every Flux query needs the following:

  1. A data source
  2. A time range
  3. Data filters

1. Define your data source

Flux’s from() function defines an InfluxDB data source. It requires a bucket parameter. For this example, use telegraf/autogen, a combination of the default database and retention policy provided by the TICK stack.


2. Specify a time range

Flux requires a time range when querying time series data. “Unbounded” queries are very resource-intensive and as a protective measure, Flux will not query the database without a specified range.

Use the pipe-forward operator (|>) to pipe data from your data source into the range() function, which specifies a time range for your query. It accepts two properties: start and stop. Ranges can be relative using negative durations or absolute using timestamps.

Example relative time ranges
// Relative time range with start only. Stop defaults to now.
    |> range(start: -1h)

// Relative time range with start and stop
    |> range(start: -1h, stop: -10m)

Relative ranges are relative to “now.”

Example absolute time range
    |> range(start: 2018-11-05T23:30:00Z, stop: 2018-11-06T00:00:00Z)

Use the following:

For this guide, use the relative time range, -15m, to limit query results to data from the last 15 minutes:

    |> range(start: -15m)

3. Filter your data

Pass your ranged data into the filter() function to narrow results based on data attributes or columns. The filter() function has one parameter, fn, which expects an anonymous function with logic that filters data based on columns or attributes.

Flux’s anonymous function syntax is very similar to JavaScript’s. Records or rows are passed into the filter() function as a record (r). The anonymous function takes the record and evaluates it to see if it matches the defined filters. Use the AND relational operator to chain multiple filters.

// Pattern
(r) => (r.recordProperty comparisonOperator comparisonExpression)

// Example with single filter
(r) => (r._measurement == "cpu")

// Example with multiple filters
(r) => (r._measurement == "cpu") and (r._field != "usage_system" )

Use the following:

For this example, filter by the cpu measurement, the usage_system field, and the cpu-total tag value:

from(bucket: "telegraf/autogen")
    |> range(start: -15m)
    |> filter(fn: (r) => r._measurement == "cpu" and r._field == "usage_system" and r.cpu == "cpu-total")

4. Yield your queried data

Use Flux’s yield() function to output the filtered tables as the result of the query.

from(bucket: "telegraf/autogen")
    |> range(start: -15m)
    |> filter(fn: (r) => r._measurement == "cpu" and r._field == "usage_system" and r.cpu == "cpu-total")
    |> yield()

Chronograf and the influx CLI automatically assume a yield() function at the end of each script in order to output and visualize the data. Best practice is to include a yield() function, but it is not always necessary.


You have now queried data from InfluxDB using Flux.

The query shown here is a barebones example. Flux queries can be extended in many ways to form powerful scripts.

Was this page helpful?

Thank you for your feedback!

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: