InfluxData Blog - Scott Anderson

Query Distinct Tag Values in Under 30ms with the InfluxDB 3 Distinct Value Cache

Scott Anderson (InfluxData) — Mon, 27 Oct 2025 08:00:00 +0000

The Distinct Value Cache (DVC) available with InfluxDB 3 Core and InfluxDB 3 Enterprise lets you cache distinct values of specific columns and query those values in under 30ms.

The DVC is an in-memory cache that stores distinct values of one or more columns in a table. It is typically used to cache distinct tag values, but you can also cache distinct field values. When you create a DVC, you specify what columns’ distinct values to cache, the maximum number of distinct value combinations to cache, and how long to keep distinct values in the cache (TTL).

Why use a Distinct Value Cache?

The DVC provides a simple and performant way to query distinct column values in under 30ms. This type of query is commonly used to populate selectable options in web applications. For example, you can create a Grafana template variable that lets you select from a list of distinct tag values and modify a dashboard’s queries to display data specific to the selected values.

To return a list of distinct tag values without using the DVC, you would use a query similar to:

SELECT DISTINCT
  region
FROM
  system_monitor
WHERE
  time ">"= now() - INTERVAL '7 days'
  AND time ""= now()

This query requires time bounds to prevent the query engine from having to read all rows in the queried table. Without time bounds or when the queried time range is too large, the query could be very “heavy,” potentially requiring a resource-hungry full table scan. However, the downside of the time bounds is that the query won’t return distinct values outside of the queried time range.

To query distinct values from the DVC, the query would look similar to:

SELECT region FROM distinct_cache('system_monitor', 'region_cache')

This query doesn’t need to perform a full table scan to derive a list of distinct column values; it just queries the list of distinct values from the in-memory cache. Distinct value expiration is handled by the cache, ensuring the query returns all unexpired distinct values, regardless of time range. And it returns results in approximately 30 ms.

Set up a Distinct Value Cache

Each DVC is associated with a table, and a table can have multiple DVCs. You can add a DVC to an existing table, but for this example, we’ll create a new table to store the European Union (EU) wind sample dataset.

Use the influxdb3 create table command to create a new wind_data table. Because we know the schema of the sample data, we can pre-create the table with the necessary tag and field columns:

influxdb3 create table \
  --token INFLUXDB_TOKEN \
  --database EXAMPLE_DB \
  --tags country,county,city \
  --fields wind_direction:int64,wind_speed:float64 \
  wind_data

Replace the following:

INFLUXDB_TOKEN: Your InfluxDB admin token.
EXAMPLE_DB: The name of the target database.

Note: You can also use InfluxDB 3 Explorer to create and manage DVCs.

Use the influxdb3 create distinct_cache command to create a new DVC associated with the wind_data table. You can provide the following:

Table (--table): (Required) The name of the table to associate the DVC with.
Cache name: A unique name for the cache. If you don’t provide one, InfluxDB automatically generates a cache name for you.
Columns (--columns): Specify which columns to include in the cache. The cached columns will only include the distinct values from that column. Columns that benefit from a DVC are typically tags, but you can cache any string-typed column, including fields.

Tip: The DVC structures columns in the order you provide them when creating the cache. Column order determines how rows in the cache are sorted and can affect query performance. If column values are hierarchical—meaning one column is a subset of another column—list the columns highest in hierarchical order first.

In this example, we’ll create a DVC named wind_locations associated with the wind_data table. We’ll cache distinct values from the country, county, and city columns:

influxdb3 create distinct_cache \
  --token INFLUXDB_TOKEN \
  --database EXAMPLE_DB \
  --table wind_data \
  --columns country,county,city \
  wind_locations

Replace the following:

INFLUXDB_TOKEN: Your InfluxDB admin token.
EXAMPLE_DB: The name of the target database.

Write data to the table associated with the cache. For this example, write the EU wind sample data (the link provides other write methods and commands).

influxdb3 write \
  --token INFLUXDB_TOKEN \
  --database EXAMPLE_DB \
  "$(curl --request GET https://docs.influxdata.com/downloads/eu-wind-data.lp)"

Replace the following:

INFLUXDB_TOKEN: Your InfluxDB token with write access to the target database.
EXAMPLE_DB: The name of the target database.

Optimize Cache Size

DVCs provide options to help optimize the size and memory footprint of the cache. Use the following options to ensure your cache doesn’t grow too large:

--max-cardinality: Specify the maximum number of unique column value combinations in your cache. For example, using the hierarchical schema of the EU wind sample data, each unique combination of country, county, and city counts against the cardinality limit. The default maximum cardinality is 100000 (one-hundred thousand).
--max-age: Specify the maximum age or time to live (TTL) for values in the cache. The age of each value is reset each time that a distinct value is written to InfluxDB. The default maximum age is 24 hours.

Query data in the Distinct Value Cache

Use the distinct_cache() function in the FROM clause of a SQL SELECT statement to query data from the DVC. distinct_cache() supports the following arguments:

table_name: (Required) the name of the table the DVC is associated with, formatted as a string literal
cache_name: the name of the DVC to query from, formatted as a string literal (only required if there is more than one DVC associated with the table)

distinct_cache(table_name, cache_name)

To query the DVC for the written sample data, execute the following query:

SELECT * FROM distinct_cache('wind_data', 'wind_locations')

This is just a normal SQL query, so you can include other SQL clauses to modify query results. For example, if you only want cities in Spain, you can use the following query:

SELECT
  city
FROM
  distinct_cache('wind_data', 'wind_locations')
WHERE
  country = 'Spain'

Note: InfluxQL does not support the distinct_cache() function. You can only query data in a DVC using SQL.

The DVC in practice

The target use case for the DVC is to help build performant user experiences that display distinct column values for users. For example, creating a UI that lists all the unique values of a tag. Using the DVC will help you to quickly query and return that list.

Grafana Dashboard Variables

One common use case that greatly benefits from using the DVC is creating query-based variables for a Grafana dashboard. Let’s say you want to create a dashboard for the EU wind sample data that lets users select what country, county, and cities to include in the visualizations.

Note: Grafana 12.2.0 fixed a bug that prevented DVC queries from successfully returning results. If using an earlier version of Grafana, cast each column in your SELECT clause to a STRING type–for example: SELECT country::STRING ...

Return a list of distinct countries

Create a country variable and use the following query to return the variable values:

SELECT
  country
FROM
  distinct_cache('wind_data', 'wind_locations')

Return a list of distinct counties in the selected countries

Create a county variable and use the following query to return counties from the selected countries:

SELECT
  county
FROM
  distinct_cache('wind_data', 'wind_locations')
WHERE
  country IN (${country:singlequote})

Return a list of cities in the selected countries and counties

Create a city variable and return the list of cities from the selected countries and counties:

SELECT
  city
FROM
  distinct_cache('wind_data', 'wind_locations')
WHERE
  country IN (${country:singlequote})
  AND county IN (${county:singlequote})

Use the variable selections in your Grafana dashboard queries

In each of your dashboard queries, use the variables to filter on country, county, and city. The example below uses multi-select variables that return a list of values. It uses Grafana’s variable interpolation to structure the list of selected variable values as a SQL array. The variables also include an All option, and the query changes the behavior of the WHERE conditions if All is selected.

SELECT
  time,
  city,
  wind_direction
FROM
  wind_data
WHERE
  time ">"= $__timeFrom
  AND time ">"= $__timeTo
  AND country IN (${country:singlequote})
  AND CASE
        WHEN 'All' IN (${county:singlequote}) THEN TRUE
        ELSE county IN (${county:singlequote})
      END
  AND CASE
        WHEN 'All' IN (${city:singlequote}) THEN TRUE
        ELSE city IN (${city:singlequote})
      END
ORDER BY
  time,
  city

To see an example Grafana dashboard that visualizes the EU wind sample data and uses the InfluxDB DVC to populate dashboard variables, download and install the EU Wind Sample Data Grafana Dashboard.

What to know about the Distinct Value Cache

The InfluxDB 3 Distinct Value Cache is an incredibly powerful tool, but there are important things to know when using it.

High-Cardinality Distinct Value Combinations

DVCs are stored in memory, and the larger the cache, the more memory it requires to maintain the cache. It’s critical to balance the size of your DVCs with the amount of memory it takes to store them. The higher the cardinality of your distinct value combinations, the larger your cache. “Cardinality” refers to the number of unique column combinations in your cached data. As a best practice, only cache distinct values from columns that are important to your query workload. Caching distinct tag or field values unnecessarily results in higher cardinality and memory usage without any benefit.

Distinct Value Caches are flushed when the server stops

Because the DVC is an in-memory cache, any time the server stops, the cache is flushed. After a server restart, InfluxDB 3 Enterprise queries previously written data and populates the cache. However, InfluxDB 3 Core does not and only writes new values to the DVC when you write data.

The InfluxDB 3 Distinct Value Cache is a powerful device that lets you get the best performance on queries that need to return distinct column values. It’s another tool in your time series toolbelt that helps make sure your workload is as performant as possible.

Try the DVC and let us know what you think! Check out our Getting Started Guide for Core and Enterprise, and share your feedback with our development team on Slack in the #influxdb3_core channel, or on our Community Site.

Telegraf’s New Labels Feature Unlocks Smarter Plugin Control

Scott Anderson (InfluxData) — Wed, 22 Oct 2025 08:00:00 +0000

Telegraf 1.36 includes a powerful new feature that lets you add labels to plugins and enable or disable plugins dynamically at startup using labels. Telegraf labels and selectors offer new flexibility in how you configure and run your Telegraf agents—especially when you have many Telegraf instances sharing a set of configurations or want fine-grained control over which plugins run under specific conditions or in certain environments.

Let’s dive in.

What are Telegraf labels and selectors?

Labels and selectors let you attach metadata (labels) to plugin configurations and then choose which plugins are enabled using selectors (filter expressions).

This gives you a lot of expressive control over what Telegraf plugins to run. Want to run certain inputs only in staging environments? Label them env = "staging" and use a selector to enable them in staging and disable non-staging plugins. Want to temporarily disable a subset? Use selectors instead of entirely removing config blocks.

Add labels in your Telegraf configuration

To add labels to a plugin, include a labels subtable in your plugin configuration:

[[inputs.cpu]]
  percpu = true
  totalcpu = true

  [inputs.cpu.labels]
    env = "prod"
    region = "us-west"

[[inputs.mem]]
  [inputs.mem.labels]
    env = "prod"
    role = "monitoring"

[[outputs.influxdb_v2]]
  urls = ["http://localhost:8181"]
  token = "${INFLUX_TOKEN}"
  organization = ""
  bucket = "DATABASE_NAME"

  [outputs.influxdb_v2.labels]
    env = "prod"
    region = "us-west"

You can add labels to all plugin types (inputs, processors, aggregators, outputs).

Label Syntax & Examples

Each label is a key value pair associated with an equals sign (=). Keys and values support alphanumeric characters [A-Za-z0-9], dots (.), dashes (-), and underscores (_). The value must be formatted as a string literal.

env = "prod"
region = "us-west-1"

Use selectors to control plugin execution

Once labels are defined, use selectors to filter which plugins to run based on their labels. Use the --select flag when starting the Telegraf agent to apply one or more selectors. At startup, Telegraf parses the selector and eliminates any plugin instances that don’t match.

telegraf --select 'env=prod'

Selector Syntax & Examples

Selectors are predicate expressions that evaluate plugin labels and resolve to true or false. Telegraf selectors support the following operators:

Comparison Operators:
- = : Equal to
Logical operators:
- ;: (AND) Returns true if both operands are true, otherwise returns false
Wildcard operator:
- * : Placeholder for unknown or variable characters

To combine predicate expressions using “and” logic, separate each predicate with a semi-colon (;) in a single selector. To combine predicate expressions using “or” logic, pass each predicate as a separate selector.

Some examples:

Run plugins with an env label that is prod:

telegraf --select 'env=prod'

Run plugins with an env label that is prod AND a region label that is us-west-1:

telegraf --select 'env=prod;region=us-west-1'

Run plugins with an env label that is prod OR a always_run label that is true:

telegraf \
  --select 'env=prod' \
  --select 'always_run=true'

Run plugins with a region label that begins with us-:

telegraf --select 'region=us-*'

How this helps in deployment scenarios

Here are some interesting use cases that benefit from labels and selectors:

Environment-based filtering: Maintain a single canonical telegraf.conf, label plugins for env = "dev" / "staging" / "prod", and choose which run per deployment.
Multi-tenant setups / multi-instance agents: If you run multiple Telegraf agents with overlapping configs, you can better isolate which plugin instances run per agent.
Gradual rollout / feature gating: Enable a new input or output only for certain subsets of agents via labels and selectors.
Switching degree of metric details: Defining a plugin instance twice, one instance with more detailed metrics and the other with less, each with corresponding labels. Use a selector to identify which plugin to run and control the level of metric details reported.

Because the filtering occurs before plugin initialization, you reduce resource usage (no unnecessary plugin startup) and simplify operations.

Try it yourself

Upgrade to the version of Telegraf 1.36+.
Add labels to plugin configurations.
Run Telegraf with --select to filter instances.
Provide feedback and report any edge cases that may surface.

We’d love to hear from you—try it out, tell us your use cases, and let us know how well this feature helps your deployments.

Query the Latest Values in Under 10ms with the InfluxDB 3 Last Value Cache

Scott Anderson (InfluxData) — Mon, 10 Feb 2025 07:00:00 +0000

As part of the InfluxDB 3 Core and InfluxDB 3 Enterprise public alpha, the Last Value Cache (LVC) is available for testing. The LVC lets you cache the most recent values for specific fields in a table, improving the performance of queries that return the most recent value of a field for specific time series or the last N values of a field, typical of many monitoring workloads. With the LVC, these types of queries return in under 10ms.

The LVC is an in-memory cache that stores the last N number of values for specific fields of time series in a table. When you create an LVC, you can specify what fields to cache, what tags to include in the cache (which determines how many unique time series you store the last values of), and the number of values to cache for each unique tag set.

For example, let’s use a dataset with the following schema (similar to the home sensor sample dataset):

home (table)
- tags:
  - room
    - kitchen
    - living room
  - wall
    - north
    - east
    - south
- fields:
  - co (integer)
  - temp (float)
  - hum (float)

If you were to cache the last value for each field per room and wall, the LVC would look similar to this:

+-------------+-------+----+------+------+---------------------+
| room        | wall  | co | hum  | temp | time                |
+-------------+-------+----+------+------+---------------------+
| Kitchen     | east  | 26 | 36.5 | 22.7 | 2025-02-10T20:00:00 |
| Living Room | north | 17 | 36.4 | 22.2 | 2025-02-10T20:00:00 |
| Living Room | south | 16 | 36.3 | 22.1 | 2025-02-10T20:00:00 |
+-------------+-------+----+------+------+---------------------+

If you were to cache the last four values of each field per room and wall, the LVC would look similar to:

+-------------+-------+----+------+------+---------------------+
| room        | wall  | co | hum  | temp | time                |
+-------------+-------+----+------+------+---------------------+
| Kitchen     | east  | 26 | 36.5 | 22.7 | 2025-02-10T20:00:00 |
| Kitchen     | east  | 9  | 36.0 | 22.7 | 2025-02-10T17:00:00 |
| Kitchen     | east  | 3  | 36.2 | 22.7 | 2025-02-10T15:00:00 |
| Kitchen     | east  | 0  | 36.1 | 22.7 | 2025-02-10T10:00:00 |
| Living Room | north | 17 | 36.4 | 22.2 | 2025-02-10T20:00:00 |
| Living Room | north | 5  | 35.9 | 22.6 | 2025-02-10T17:00:00 |
| Living Room | north | 1  | 36.1 | 22.3 | 2025-02-10T15:00:00 |
| Living Room | north | 0  | 36.0 | 21.8 | 2025-02-10T10:00:00 |
| Living Room | south | 16 | 36.3 | 22.1 | 2025-02-10T20:00:00 |
| Living Room | south | 4  | 35.8 | 22.5 | 2025-02-10T17:00:00 |
| Living Room | south | 0  | 36.0 | 22.3 | 2025-02-10T15:00:00 |
| Living Room | south | 0  | 35.9 | 21.8 | 2025-02-10T10:00:00 |
+-------------+-------+----+------+------+---------------------+

Why use a Last Value Cache?

In short, the LVC provides last-value query responses in under 10ms, simplifying a common query type. Let’s say that you are building a monitoring dashboard and only need to know the last reported values for specific fields. Without using the LVC, you’d have to run a query similar to:

SELECT
  room,
  wall,
  selector_last(co, time)['value'] as co,
  selector_last(temp, time)['value'] as temp,
  selector_last(hum, time)['value'] as hum,
  selector_last(hum, time)['time'] AS time
FROM
  home
GROUP BY
  room,
  wall
WHERE
  time >= now() - INTERVAL '1 day'
  AND time <= now()

While this query will give you the last reported values, there are some things to note:

The time value in each row is specific to only the hum field. If field values are reported independently with sporadic timestamps, the time value may be inaccurate for the other fields.
The query includes a time range, which prevents the query engine from having to read all the data in the table to generate results. Without the time bounds, this query could potentially be very “heavy,” depending on the amount of data in the table. This also means that if the last reported value is outside the queried time range, it is not included in the results.

To query this same data from the LVC, the query would look similar to:

SELECT * FROM last_cache('home', 'homeSensorCache')

Time bounds aren’t necessary. All the returned timestamps are specific to the last reported value of each field. Results return in under 10ms, and the query is just simpler.

The LVC also unlocks some other functionalities, but we’ll discuss that in a future post.

Set up a Last Value Cache

An LVC is associated with a table, which can have multiple LVCs. You can add an LVC to an existing table, but for this example, we’ll create a new table to store the home sensor sample dataset.

Use the influxdb3 create table command to create a new home table. Because we know the schema of the sample data, we can pre-create the table with the necessary tag and field columns :

influxdb3 create table \
  --tags room \
  --fields co:int64 temp:float64 hum:float64 \
  --database example_db \
  home

Use the influxdb3 create last_cache command to create a new LVC associated with the home table. You can provide the following:

Table (--table): (Required) The name of the table to associate the LVC with.
Cache name: A unique name for the cache. If you don’t provide one, InfluxDB automatically generates a cache name for you.
Key columns (--key-columns): Specify which columns to include in the primary key of the cache. Rows in the LVC are uniquely identified by their timestamp and key columns, so include all the columns you need to identify each row. These are typically tags, but you can use any columns with the following types:
- String
- Integer
- Unsigned integer
- Boolean
Value columns (--value-columns): Specify which columns to cache as value columns. These are typically fields but can also be tags. By default, time and columns other than those specified as --key-columns are cached as value columns.
Count (--count): The number of values to cache per unique key column combination. The default count is 1.

In this example, we’ll create an LVC named homeLastCache associated with the home table. We’ll use the room tag as a key column, all the fields as value columns, and only cache the latest value for each field per room:

influxdb3 create last_cache \
  --database example-db \
  --table home \
  --key-columns room \
  homeLastCache

Write data to the table associated with the cache. For this example, write the home sensor sample data (Commands and data are provided in the link, and you can adjust the timestamps of the data).

Note: Values are cached on write. When you create a cache, it will not cache previously written points, only newly written points.

Query data in the Last Value Cache

Use the last_cache() function in the FROM clause of an SQL SELECT statement to query data from the LVC. last_cache() supports the following arguments:

table_name: (required) The name of the table the LVC is associated with, formatted as a string literal.
cache_name: The name of the LVC to query from, formatted as a string literal (only required if there is more than one LVC associated with the table).

last_cache(table_name, cache_name)

To query the LVC for the written sample data, execute the following query:

SELECT * FROM last_cache('home', 'homeCache')

This is just a simple SQL query, so you can include other SQL clauses to modify query results. For example, if you only want the last temperature value for the Kitchen, you can use the following query:

SELECT
  room,
  temp`
FROM
  last_cache('home', 'homeCache')
WHERE
  room = 'Kitchen'

Note: InfluxQL does not support the last_cache() function, so you can only access the data in the LVC using SQL queries.

What to know about the Last Value Cache

The InfluxDB 3 Last Value Cache is an incredibly powerful tool, but there are important things to know when using it. LVCs are stored in memory; the larger the cache, the more memory it requires to maintain it. It’s essential to balance the size of your LVCs with the amount of memory it takes to store them. Things to consider:

High Cardinality Key Columns

“Cardinality” refers to the number of unique key column combinations in your cached data. While the InfluxDB 3 storage engine is not limited by cardinality, it does affect the LVC. Higher cardinality increases memory requirements for storing the LVC and can affect LVC query performance. We recommend the following:

Only use tags important to your query workload as key columns in the LVC. Caching tags or fields as key columns unnecessarily results in higher cardinality without any benefit.
Avoid including high cardinality key columns in your LVC.
Don’t include multiple high-cardinality key columns in your LVC

For a general idea of total key column cardinality in an LVC, you can use the following equation:

num_uniq_col_val_N [× num_uniq_col_val_N …] = key_column_cardinality

Value Count

By increasing the number of values to store in the LVC, you increase the number of rows stored in the cache and the amount of memory required to store them. Be judicious with the number of values to store. This count is per unique key column combination. If you include two tags as key columns, one with three unique values and the other with 10, you could have up to 30 unique key column combinations. If you want to keep the last 10 values, you could potentially have 300+ rows in the cache. In reality, this isn’t a huge cache, but it illustrates how key column cardinality and the number of values you want to cache can explode your cache size.

To get an idea of the number of rows required to cache the specified number of values, use the following equation:

key_column_cardinality × count = number_of_rows

Last Value Caches Are Flushed When the Server Stops

Because the LVC is an in-memory cache, the cache is flushed any time the server stops. After a server restart, InfluxDB only writes new values to the LVC when you write data, so there may be a period of time when some values are unavailable in the LVC.

Defining Value Columns

When creating an LVC, if you include the --value-columns options to specify which fields to cache as value columns, any new fields added in the future will not be added to the cache. However, if you omit the --value-columns option, all columns other than those specified as --key-columns are cached as value columns, including columns that are added later.

The InfluxDB 3 Last Value Cache is a powerful tool that lets you get the best performance on queries that need to return the latest reported values. It’s another tool in your time series toolbelt that helps make sure your workload is as performant as possible.

Try the LVC, and let us know what you think! Check out our Getting Started Guide for Core and Enterprise, and share your feedback with our development team on Discord in the #influxdb3_core channel, on Slack in the #influxdb3_core channel, or on our Community Site.

Product Update: Monitor Your InfluxDB Cloud Dedicated Cluster

Scott Anderson (InfluxData) — Mon, 24 Jun 2024 08:00:00 +0000

InfluxDB Cloud Dedicated provides fully-managed InfluxDB v3 clusters that power enterprise-grade workloads on a scalable infrastructure dedicated to your workload and your workload alone. As a fully-managed service, InfluxData takes the infrastructure hassle off your plate by monitoring and scaling your cluster when necessary.

Until recently, cluster health-related metrics were only available to internal InfluxData support staff. To provide you access to those same metrics, InfluxDB Cloud Dedicated now gives you access to an operational dashboard that visualizes data related to the performance and health of your dedicated cluster.

What’s in the operational dashboard?

The operational dashboard displays the same cluster health-related metrics that InfluxData support staff use to make adjustments to your cluster. As a user, this information can help you identify unintended workload changes, potential bottlenecks, optimization opportunities, and provide insight into how each component in your cluster is performing.

For information about the specific metrics available in the dashboard, see the documentation.

View your operational dashboard

The dashboard used to monitor your InfluxDB Cloud Dedicated cluster is a Grafana dashboard managed by InfluxData. By default, the operational dashboard is not enabled for all clusters. To view your cluster’s operational dashboard:

Contact InfluxData support to enable the operational dashboard on your dedicated cluster.
Copy your InfluxDB Cloud Dedicated cluster URL, paste it into a browser, and add /observability as the URL path. For example: https://cluster-id.a.influxdata.com/observability
Use the credentials provided by InfluxData support to log into the Grafana dashboard.

Once logged in, you can view the operational dashboard specific to your InfluxDB Cloud Dedicated cluster.

Request access to your InfluxDB Cloud Dedicated operational dashboard

The InfluxDB Cloud Dedicated operational dashboard and the metrics displayed are subject to change. If there is information that you feel would benefit your ability to monitor your dedicated cluster, let us know.

Product Update: SSO for InfluxDB Cloud Dedicated

Scott Anderson (InfluxData) — Mon, 10 Jun 2024 08:00:00 +0000

InfluxDB Cloud Dedicated is a fully-managed InfluxDB offering that lets you run enterprise-grade workloads on cloud infrastructure dedicated to your workload and your workload alone. A common request from those running enterprise-grade workloads on InfluxDB is the ability to use single sign-on (“SSO”) to authorize access to InfluxDB. SSO is now available as a paid option for InfluxDB Cloud Dedicated clusters.

What is SSO?

SSO is a delegated authentication system that allows team members to access multiple applications using a single set of credentials managed by a corporate Identity Provider (“IdP”). When a team member logs into an application using SSO, their corporate IdP validates their credentials, which authenticates access back to the application. In this way, SSO simplifies access for team members while also reducing administrative overhead. SSO has the following additional benefits:

Reduces username/password fatigue
Decreases risk of weak passwords and password reuse
Reduces friction accessing multiple systems
Reduces login issues and support requests
Simplifies administration and security enforcement

SSO is now offered on InfluxDB Cloud Dedicated so that you can enjoy these benefits with InfluxDB V3; your administrators can grant/revoke access to your cluster the same way that they would administer access to any of your other systems.

SSO with InfluxDB Cloud Dedicated

When using SSO with InfluxDB Cloud Dedicated, you connect your identity provider to the InfluxData-managed Auth0 service. When a user attempts to authorize using your InfluxDB Cloud Dedicated cluster, the following occurs:

InfluxDB sends an authentication request to the InfluxData-managed Auth0 service.
Auth0 sends the provided credentials to your identity provider.
Your identity provider grants or denies authorization based on the provided credentials and returns the appropriate response to Auth0.
Auth0 returns the authorization response to InfluxDB Cloud Dedicated which grants or denies access to the user.

Your identity provider manages access to your cluster. Once you grant a user access through your identity provider, they have administrative access to your InfluxDB Cloud Dedicated cluster.

Set up SSO for your cluster

Contact InfluxData sales to begin the process of enabling SSO on your dedicated cluster. They will gather the information necessary to start your SSO implementation.
If you haven’t already, set up your identity provider. For information about setting up your identity provider, refer to your identity provider’s documentation.
Note: To use SSO with InfluxDB Cloud Dedicated, you must use an identity provider supported by Auth0.
Create a new application or client in your identity provider to use with Auth0 and your InfluxDB Cloud Dedicated cluster. Refer to your identity provider’s documentation for more information.
Provide the necessary connection credentials to InfluxData support. What credentials are needed depends on your identity provider and your protocol. For example:

Protocol Required credentials

OIDC Client secret

SAML Identity provider certificate

InfluxData support will provide more information about the specific credentials required.
Add the InfluxData Auth0 connection URL as a valid callback URL to your identity provider application. This is also sometimes referred to as a “post-back” URL.

Protocol	Required credentials
OIDC	Client secret
SAML	Identity provider certificate

https://auth.influxdata.com/login/callback

With the callback URL in place, you can test the integration by attempting to authorize with your InfluxDB Cloud Dedicated cluster. The quickest way to authorize is to use any of the influxctl commands.

Once working, you can manage all access to your InfluxDB Cloud Dedicated cluster through your identity provider.

For more information about SSO with InfluxDB Cloud Dedicated, see the InfluxDB Cloud Dedicated SSO documentation.

Learn more about InfluxDB Cloud Dedicated.

InfluxDB and Elementary School Science Fairs

Scott Anderson (InfluxData) — Mon, 16 May 2022 07:00:49 -0700

I’m a proud father of an incredibly smart, talented, kind, and just all-around great 9 year-old daughter. Since she first learned to talk, she has been a “questioner,” curious about the world around her and how everything connects (you know, the kid who asks questions throughout an entire movie… yeah, that’s her). As she’s grown older, her love of questions and need for answers has led her to gravitate toward math and science, both of which she excels at.

Every year her elementary school does a science fair and, as usual, she was all in. After some brainstorming and research, she wanted to know, “does playing video games affect your blood pressure?” Her hypothesis was that, due to the excitement and/or stress of playing, your blood pressure increases while playing. To test her hypothesis, she did the following:

Gathered test subjects (luckily we had a family dinner that provided a pool of willing participants that varied in age).
Measured and recorded each test subject's blood pressure before playing.
Had each test subject play Mario Kart 8 for 7 minutes (approximately two races).
Measured and recorded each test subject's blood pressure after playing.
Recorded the age and sex of each test subject.

I should interject and say that my wife and I support our daughter in whatever she sets out to do, but the work is hers to do. We’re just there to help. My daughter came up with her hypothesis, designed the experiment, made a list of supplies she needed, and then conducted the experiment. She’s pretty awesome.

Once she collected the data, she knew what questions she wanted to answer, but wasn’t sure of the best way to find the answers. Enter data-nerd-dad (me):

“I think I can help with this.”

I get to work with InfluxDB everyday, so I knew this is the type of data that InfluxDB would be really good at processing. So here’s what we did:

Convert results to line protocol

We first converted my daughter’s handwritten results into line protocol. We stored the data in a bloodpressure measurement, included name and age tags, and included fields for systolic (sys) and diastolic (dia) pressures.

Each test had two lines of line protocol; one for the initial blood pressure reading and one for the final blood pressure reading. The timestamps were arbitrary, but we wanted all the tests to align, so we used the same initial and final timestamps for all tests. Here’s what a result from a single test looked like in line protocol:

bloodpressure,name=Bob,age=32,sex=m sys=132,dia=80 1651003231
bloodpressure,name=Bob,age=32,sex=m sys=120,dia=70 1651003221

Write queries to answer questions

As with any data analysis, you first need questions to answer to know how to query the data appropriately. Here are the questions my daughter wanted to answer:

What was the average change in blood pressure overall?
Does sex matter?
Does age matter?

So I began to build some queries and, while I was at it, a dashboard to visualize her results.

I built cells that displayed line graphs to show the change between the average starting and ending blood pressures as well as single stat cells to display the average numeric change of systolic and diastolic pressures. I did the same for sex segments and age segments. It took me about 20 minutes to build out the first version of the dashboard.

At this point, my daughter looked at the dashboard and said, “the change in numbers are hard to understand. Can we do a percentage change?”

Me, swelling with pride: “Absolutely.”

About 10 minutes later, all the single stat cells were updated to report the percentage change rather than just the mathematical difference. This is what our final dashboard looked like:

She asked if we could just use the dashboard on her project board, so we put the dashboard in presentation mode, toggled light mode (to save printer ink), printed the dashboard in tiles, taped them all together, and then glued them to her project board. Here was the result:

Her findings

While the sample size of the experiment wasn’t large enough to draw any concrete conclusions, there were some interesting results that my daughter observed:

Overall, blood pressure dropped by approximately 2% on average.
The drop in blood pressure was higher in males than it was in females. Females saw almost no change in systolic pressure, but a slight increase in diastolic pressure.
Test subjects under the age of 18 saw almost no change in blood pressure while subjects 19-30 years old saw the most significant change in blood pressure.

The result

It was a fun little experiment and my daughter got a taste of using InfluxDB to better understand the data she collected. AND she won her age group!

Blue ribbon or not, I’m incredibly proud of her. My daughter’s need to constantly ask questions and her love of learning are going to take her far in life. I’m excited to see where she goes and happy that I was able to introduce her to the powerful toolset I get to work with every day.

InfluxDB 2.0 Documentation is Now Open Source

Scott Anderson (InfluxData) — Mon, 14 Oct 2019 09:00:00 -0700

Special thanks to Kelly Seivert, Nora Mullen, and Will Pierce

Greetings, InfluxData community! ????

In January, we released InfluxDB 2.0 alpha with draft documentation. With each incremental alpha release, we’ve iteratively updated the docs. Most recently, we published content for InfluxDB Cloud 2.0. Since the initial 2.0 alpha release, the 2.0 documentation source code has been kept in a private GitHub repository. Behind the scenes, we’ve been hard at work: curating content to address common InfluxDB use cases, standardizing structure and style, and increasing the depth of content.

Today we’re open-sourcing the InfluxDB 2.0 documentation!

Optimize your time to awesome

To deliver useful, informative InfluxDB 2.0 documentation, we’re crafting content using a task-based approach. We’re organizing content by common tasks to perform, rather than by feature. We’ve separated conceptual and reference information from procedures.

Our goal: less time reading, more time building cool stuff with InfluxDB.

Our commitment to you

We believe when project maintainers and users collaborate, the end product is always better. Your viewpoint, insight, and use case may be one we haven’t considered or addressed. Share your goals with us. We’re committed to:

Our community
Open source
Better solutions

Our docs are “ever-evolving” – growing and changing to address your needs. Your contributions make a difference. Our hope in open sourcing the InfluxDB 2.0 documentation is to open the doors for community contributions and feedback. We want and need your help to create documentation that addresses the needs of our community and inspires new and interesting ways to use InfluxDB.

Ways to contribute

Find unclear or inaccurate information…a typo or a broken link? Missing content? Let us know! Submit an issue or a pull request on the InfluxDB 2.0 documentation repository. We welcome all contributions!

InfluxData Blog - Scott Anderson

Query Distinct Tag Values in Under 30ms with the InfluxDB 3 Distinct Value Cache

Why use a Distinct Value Cache?

Set up a Distinct Value Cache

Optimize Cache Size

Query data in the Distinct Value Cache

The DVC in practice

Grafana Dashboard Variables

What to know about the Distinct Value Cache

High-Cardinality Distinct Value Combinations

Share your feedback

Telegraf’s New Labels Feature Unlocks Smarter Plugin Control

What are Telegraf labels and selectors?

Add labels in your Telegraf configuration

Label Syntax & Examples

Use selectors to control plugin execution

Selector Syntax & Examples

How this helps in deployment scenarios

Try it yourself

Query the Latest Values in Under 10ms with the InfluxDB 3 Last Value Cache

Why use a Last Value Cache?

Set up a Last Value Cache

Query data in the Last Value Cache

What to know about the Last Value Cache

High Cardinality Key Columns

Value Count

Last Value Caches Are Flushed When the Server Stops

Defining Value Columns

Share your feedback

Product Update: Monitor Your InfluxDB Cloud Dedicated Cluster

What’s in the operational dashboard?

View your operational dashboard

Product Update: SSO for InfluxDB Cloud Dedicated

What is SSO?

SSO with InfluxDB Cloud Dedicated

Set up SSO for your cluster

InfluxDB and Elementary School Science Fairs

Convert results to line protocol

Write queries to answer questions

Her findings

The result

InfluxDB 2.0 Documentation is Now Open Source

Optimize your time to awesome

Our commitment to you

Ways to contribute