InfluxData Blog - Developer

Telegraf 1.40 Release Notes

Sven Rebhan (InfluxData) — Tue, 15 Sep 2026 00:00:00 +0000

You can find the binaries for the latest Telegraf release on our Downloads page. Many thanks to all the open source community members who contributed to this effort!

New plugins

These are the newest plugins, first available in this version:

Databricks Zerobus output (outputs.zerobus)
- Streams metrics to a Unity Catalog Delta table using the Databricks Zerobus Ingest service over gRPC to directly commit into Delta
- Contributed by zlata-stefanovic-db
Fritzbox Smarthome input (inputs.fritzbox_smarthome)
- Reads metrics such as lamp state, energy consumption, etc., from Smarthome-capable FRITZ! routers using the AVM Home Automation interface.
- Contributed by hdecarne

Important changes

Here are some changes to highlight:

Cisco Model-Driven-Telemetry fixes
- Several fixes changed the metric format
- Configured aliases are now respected for microburst and RIB messages, which might result in changes to the metric name
- Spurious, invalid metrics with wrong tag-sets were removed or corrected
- Row numbers are now tagged correctly for table messages
Smart input fix for power-on-hours
- Power-on-hours are now reported correctly for raw values in 182h+39m+24.879s format
- Previously, those values resulted in the field containing the time in seconds
Removal of deprecated plugins
- inputs.aerospike
- inputs.sflow
- outputs.amon
Removal of deprecated plugin options
- inputs.kafka_consumer removal of connection_strategy
- inputs.openstack removal of server_diagnostics
- inputs.procstat removal of cmdline_tag, pid_tag, and supervisor_unit
- inputs.tail removal of from_beginning
- Use the telegraf config migrate command to migrate your configuration
Elasticsearch query input plugin migration to official library
- Migration to official and maintained libraries
- Additional support for Elasticsearch v7, v8 and v9

Downloads

Head to our Downloads page to get the latest Telegraf release. If you have issues or questions, please join our InfluxDB Community Slack or post them in our InfluxDB GitHub Repo or Community Site, and we will look into them.

InfluxDB University

Learn more about collecting data with Telegraf by taking the free InfluxDB University Data Collection with Telegraf course.

FAQ

What's new in Telegraf 1.40?

Telegraf 1.40 adds two new plugins: a Databricks Zerobus output plugin for streaming metrics directly into Unity Catalog Delta tables over gRPC, and a Fritzbox Smarthome input plugin for reading device metrics from AVM's FRITZ! routers. The release also fixes several Cisco Model-Driven-Telemetry issues, corrects a SMART input bug for power-on-hours reporting, and migrates the Elasticsearch query input plugin to an official, maintained library with added support for Elasticsearch v7, v8, and v9.

Which Telegraf plugins were removed in 1.40?

Three deprecated input/output plugins were removed: inputs.aerospike, inputs.sflow, and outputs.amon. If you're running configurations that use any of these, you'll need to migrate to an alternative plugin before upgrading.

What deprecated plugin options were removed in Telegraf 1.40?

Several plugin-specific options were dropped: connection_strategy from inputs.kafka_consumer, server_diagnostics from </code class="language-markup">inputs.openstack, and cmdline_tag, pid_tag, and supervisor_unit from inputs.procstat. The from_beginning option was also removed from inputs.tail. InfluxData recommends running telegraf config migrate to automatically update existing configuration files affected by these removals.

How do I download and get support for Telegraf 1.40?

Binaries are available on InfluxData's Downloads page. For questions or issues, join the InfluxDB Community Slack or post on the InfluxDB Community Site. InfluxData also offers a free "Data Collection with Telegraf" course through InfluxDB University for those new to the tool.

Building a Practical Time Series Data Layer for Automotive Manufacturing

Cole Bowden (InfluxData) — Wed, 09 Sep 2026 08:00:00 +0000

Automotive manufacturing generates data at several operating cadences. Sensors and controllers emit measurements continuously. Equipment and line states change as events. Production and quality systems add context at the part, batch, shift, and plant level. Together, these records describe how a manufacturing process behaves over time.

That data can support plant visibility, investigations, scrap reduction, condition monitoring, and longer-term comparison, but only if the storage and query layer can keep up with the workload. InfluxDB is a practical fit for these types of workloads because it is optimized for continuous, time-stamped data and can process, retain, and query it without requiring every system around it to be redesigned.

Why automotive data is a time series workload

A time series workload is, at its core, any data where you primarily store, query, and analyze it by looking at when it happened and how it progressed from one state to another.

A temperature measurement in a time series workload never exists in isolation. When a device overheats, you ask how long it took to heat up, whether it had opportunities to cool down, and what that looked like over the span of five, ten, or fifty minutes. The same principles can apply to vibration, torque, current, pressure, flow, cycle state, machine availability, inspection results, alarms, and many other signals generated during vehicle and component production.

Queries are written to understand what changed during a particular interval, whether a condition persisted, how one shift compared with another, or how several signals behaved around a production or quality event. Those queries tend to start with a filter on timestamps to the relevant window in which questions are being asked, narrow the data to the relevant equipment or process, and then aggregate, compare, or retrieve the latest values.

The write pattern of time series data is often distinctive, too. Sensors create readings at a regular cadence, so new data points arrive continuously, almost exclusively as appends to the database, with few or no updates or edits to historical rows.

The same data also has value at very different time scales. Recent, high-resolution telemetry can support detailed investigations. Longer-range summaries can support plant management, capacity planning, process comparison, forecasting, and cross-plant visibility. Keeping every full-resolution observation may be difficult to justify, but reducing everything to hourly averages at ingestion time throws away information before anyone knows whether it will matter.

This combination of continuous writes, time-bounded reads, multiple resolutions, and changing retention value is what makes automotive telemetry a time series workload.

Automotive systems also contain plenty of data that doesn’t fit this description. Bills of material, work orders, user accounts, inventory records, and transactional production data may belong in an MES, ERP system, or relational database. InfluxDB is designed to operationalize telemetry, and it’s part of a well-orchestrated tech stack.

Why use a time series database?

Any relational database (or even Excel) can store time-stamped measurements. The question is: how efficiently, effectively, and easily can they handle a time series workload, and can they scale? We already have a blog on this topic that explains the advantages of time series databases, and it’s a good place to start if you want to understand their key advantages.

To summarize for automotive telemetry: InfluxDB most efficiently handles high-volume ingestion and time-oriented querying, while database- and table-level retention lets you control how long each data type remains available. A high-volume raw table can have a shorter retention period than a cleaned or downsampled table in the same database, and because InfluxDB 3 is designed and built for low-cost object storage, data costs stay low. Even better, all tables are very efficiently compressed, minimizing the footprint in object storage and lowering costs.

The Last Value Cache addresses another common query pattern: retrieving the newest value, or last few values, for each series. That is useful for current-state views where repeatedly scanning recent history would be unnecessary work.

These features map directly to the shape of automotive manufacturing data workloads, which ingest continuously, query by time, keep recent detail, summarize older data, and serve current state efficiently. This makes a time-series database like InfluxDB the only cost-effective, performant, scalable choice for high-volume, time series workloads.

A reference architecture for automotive manufacturing

Rather than talking about it at a high level, it may be easier to show you how the architecture works in action.

The InfluxDB 3 automotive manufacturing reference architecture is a runnable example of an automotive time series pipeline. It uses Docker Compose, InfluxDB 3 Enterprise, Processing Engine plugins, and a small web UI:

git clone https://github.com/influxdata/influxdb3-ref-auto-manufacturing.git
cd influxdb3-ref-auto-manufacturing
make up

On first boot, the setup asks for an email address and sends an InfluxDB 3 Enterprise license-validation link. After validation, this stack begins generating and processing the simulated plant data, and you can see it by opening the UI at:

http://localhost:8080

The repository installs InfluxDB-approved plugins, creates tables and triggers, runs the processing chain, and exposes raw, processed, downsampled, and forecast data through the UI. It also demonstrates isolated station pipelines and a Last Value Cache for current-state views.

Make sure you read the production notes before using it as a deployment template. The demo is single-node, uses a file-backed object store, shares an admin token between services, and does not enable TLS inside the Compose network. Production requires scoped service tokens, TLS, durable object storage, monitoring, backup planning, and an appropriate multi-node topology. One easy-to-miss detail: create source tables before registering WAL triggers, or the triggers may never fire.

The repository’s most useful pattern is its separation of concerns. You can replace the signal generator with an OPC UA, historian, or gateway feed and keep the downstream stages. You can change the filter without rewriting the dashboard, or you can change retention without touching the PLC.

Building on the reference architecture

Obviously, this is a reference architecture, and it’s meant to be the first step towards building the architecture for your deployment. The most obvious first change to make is replacing the signal generator with an actual data source.

The repository is deliberately structured so that this happens at the input boundary. Telegraf’s OPC UA input can collect data from an OPC UA server and write it to InfluxDB. An industrial integration platform such as Litmus or HighByte can write line protocol through the InfluxDB write API. A historian or existing plant application can also become the source if it already exposes the required data. Downstream processing stages don’t need to know which route the points took to get there.

From there, the work becomes signal-specific.

A regular time grid may be necessary when several sensors need to be aligned or when an algorithm expects a stable sample rate. It may add little value for an event stream. Gap filling should be bounded and explicit, and ideally preserve enough metadata to distinguish observed values from generated ones. Some gaps should remain gaps because the absence of data is useful information, as it can indicate that certain systems were paused or sensors stopped generating readings.

Filtering requires similar care. A filter that cleans up a slowly changing booth-temperature signal may be inappropriate for current, vibration, pressure, or torque. Before filtering a production stream, test the filter against the events engineers actually need to preserve. Keep the raw signal long enough to compare the processed output against it.

Downsampling is another place to be deliberate. Whether you use an average, minimum, maximum, or median, downsampling necessarily entails losing some information. Fortunately, the Downsampler plugin can generate several calculations for the same source measurement. Useful output might include an average for long-term trends, a maximum for threshold analysis, and a count to show whether the interval contained the expected number of observations.

Retention follows the same logic. Raw telemetry can remain available for the period in which detailed investigations are likely. Intermediate processing tables may only need to exist long enough to support the next stage. Cleaned or downsampled data can remain available for longer-range analysis. InfluxDB’s table-level retention overrides make it possible to apply those policies within the same database, so that data can flow from maximal-resolution fresh tables into lower-resolution longer-term storage. This ensures all data is available when needed, without paying to store immense volumes of data that will only be used for sporadic historical analysis.

Finally, the local deployment needs ordinary production hardening. The repository’s architecture notes cover moving from local files to S3, Google Cloud Storage, or Azure Blob Storage; separating ingest, query, compaction, and processing roles; using scoped tokens for individual services; and enabling TLS across trust boundaries. Plugins should also have version control, automated tests, resource limits, and a repeatable deployment process. Running Python inside the database removes some infrastructure, but it’s still production code.

Augmenting an existing automotive data stack

Many automotive environments already have control systems, historians, manufacturing applications, quality systems, and enterprise analytics infrastructure. There’s no need to displace them before evaluating InfluxDB. Similarly, the justification for adding InfluxDB doesn’t depend on proving that the historian, warehouse, or relational database is bad. It depends on whether a specialized time series database can serve a particular workload more efficiently.

A useful entry point is to start bounded, picking a specific task or domain where InfluxDB may be worth leveraging. Mirror data from that domain into InfluxDB, but allow your existing systems to remain authoritative. Because InfluxDB 3 uses SQL, you can likely run the same queries across your existing system and InfluxDB at the same time, and just like that, you’re testing which system is more efficient. How fresh is the data? What’s the query latency, especially when you’re leveraging the Last Value Cache?

Once it’s running, you can see what else InfluxDB unlocks for you. Use the Processing Engine with ML plugins to detect anomalies and generate forecasts that help with predictive maintenance. Hook into the InfluxDB MCP server to power your AI agents with your data. The database is the backbone, and what you build on top of it is where you truly begin to derive value.

Measure sustained ingestion, storage consumption at each resolution, query latency for real investigation patterns, and operational overhead. Ask yourself how useful the resulting analysis, forecasts, and downstream tools you built are. A bounded evaluation with representative data gives you evidence from your own workload, which is what truly matters for your use case.

Bringing it all together

Automotive telemetry has the defining characteristics of a time series workload: continuous writes, time-bounded queries, value at multiple resolutions, and a useful lifetime that changes as the data ages.

InfluxDB provides a specialized solution for that workload. The automotive reference architecture makes the design concrete by showing how ingestion, resampling, gap filling, filtering, downsampling, forecasting, caching, and retention can fit together without becoming one inseparable pipeline. Once you’ve got the data flowing, you’ll unlock new capabilities to maximize the value you get from your data, driving efficiency and better data-driven results.

Get started with a free trial of InfluxDB 3 Enterprise, and try it out today.

Getting Started with InfluxDB 3 and Grafana Tutorial

Charles Mahler (InfluxData) — Wed, 02 Sep 2026 07:00:00 +0000

InfluxDB and Grafana are the most common pairing in time series monitoring, and division of labor between them is simple. InfluxDB stores and queries the data: high-volume, time-stamped readings from sensors, servers, meters, vehicles, and anything else that emits time series. Grafana visualizes the data: dashboards, time series panels, stat tiles, state timelines, and alerts. Neither tool replaces the other, and many production monitoring stacks run both.

Connecting them has gotten considerably simpler with InfluxDB 3. Grafana ships with a built-in InfluxDB datasource that speaks InfluxDB 3 SQL over Flight SQL, so there is no third-party plugin to install and no custom query language to learn.

This guide walks through that integration end-to-end using a realistic dataset you generate yourself. You will learn the following in this tutorial:

Getting data in - Writing line protocol and what tags, fields, and timestamps mean for how you will query later.
Transforming data as it arrives - Using an InfluxDB 3 Python Processing Engine plugin to turn raw readings into a derived table of decisions. This pattern keeps dashboard queries simple and your source data untouched.
Connecting Grafana securely - Read-only tokens and the datasource settings that actually matter.
Building a real dashboard - Template variables, chained variables, $__timeFilter, date_bin() for downsampling, and eight panels across stats, time series, state timelines, bar gauges, and tables.

What you will build with InfluxDB 3 and Grafana

To make all of that concrete, you will generate a week of smart-building data. The generator is deterministic, so your numbers will match the expected output at every step, and you can verify each stage rather than guessing.

The raw table, building_telemetry, preserves the original readings. The derived table, iaq_assessment, adds an indoor-air-quality risk score, a severity label, a recommended action, and a conservative estimate of energy used above an idle baseline. The finished dashboard answers four questions an operator actually asks:

Which occupied rooms experienced unhealthy air?
Where did CO₂ and PM2.5 spike?
How much energy was consumed while rooms were empty?
Which building zones should someone investigate first?

The dataset has four incidents deliberately built into it. A stuffy Tuesday conference room, a lab drawing power on an empty Wednesday evening, a Thursday ventilation problem in the design studio, and a building-wide Friday particulate event, so every panel has something real to show.

Buildings are just an example. The architecture in this tutorial applies unchanged to industrial equipment, fleet telemetry, energy metering, network devices, or application metrics. If you are evaluating InfluxDB and Grafana for any of those, this is a working template.

Prerequisites

This walk-through assumes:

A Debian- or Ubuntu-based Linux environment; Grafana also publishes installation instructions for RHEL, Fedora, and other supported systems.
Python 3.9 (or newer).
sudo access for installing Grafana.
An InfluxDB 3 Enterprise trial, at-home, or commercial license.

Why use Grafana’s built-in InfluxDB datasource?

Grafana includes an InfluxDB datasource that supports InfluxDB 3 SQL out of the box. There’s no need to install anything else, which makes getting started easy.

Other choices still have valid uses:

InfluxQL is supported by the plugin as well, and is useful when migrating existing InfluxDB 1.x queries or working through an HTTP/1.1-only proxy.
A separately hosted Grafana is useful for a shared observability platform, but its backend needs private, HTTP/2-capable access to the InfluxDB query node.
A custom API can add domain-specific authorization or reshape data, but it adds another service that a beginner tutorial does not need.

Create Your Project Directory

Create a folder anywhere convenient and open it in your text editor:

mkdir smart-building-demo
cd smart-building-demo
mkdir plugins influxdb-data

The tutorial uses only these local paths:

smart-building-demo/
├── generate.py
├── smart-building.lp
├── influxdb-data/
└── plugins/
    └── iaq_assessment.py

Keep the terminal in smart-building-demo for the remaining commands.

Install and Start InfluxDB 3 Enterprise

InfluxData provides a quick installer for Linux and macOS. Download the installer first so you can inspect it before running:

curl -o /tmp/install_influxdb3.sh \
  https://www.influxdata.com/d/install_influxdb3.sh

# Optional: inspect the downloaded script before running it.
less /tmp/install_influxdb3.sh

sh /tmp/install_influxdb3.sh enterprise

The installer tracks the latest InfluxDB 3 Enterprise release. For production, InfluxData recommends its DEB/RPM packages or a carefully secured container deployment; see the official installation guide.

Verify that the binary is available:

influxdb3 --version

If the command is not found, open a new terminal or follow the installer’s instructions for adding the binary to your PATH, then return to the demo directory.

Start the Database with the Processing Engine Enabled

Run InfluxDB in the first terminal and leave it running:

influxdb3 serve \
  --node-id smart-building-node \
  --cluster-id smart-building-cluster \
  --object-store file \
  --data-dir "$PWD/influxdb-data" \
  --plugin-dir "$PWD/plugins"

The --plugin-dir flag activates the Processing Engine and tells InfluxDB where to find the Python file you will create. The data directory persists the database between restarts. These options are documented in the Processing Engine guide.

On the first start, InfluxDB asks you to choose and activate a license. A trial provides full Enterprise features for 30 days; the at-home license is intended for eligible hobbyist use. Follow the prompts and email-verification step described in the license documentation. Do not include license files, license JWTs, or account details in screenshots or source code.

Create and Store the Administrator Token

Open a second terminal, return to smart-building-demo, and create the initial administrator token:

influxdb3 create token --admin

InfluxDB displays this token only once. Store it in a password manager. Then load it into the current terminal without placing it in shell history:

read -rsp "Paste the InfluxDB administrator token: " INFLUXDB_TOKEN
echo
export INFLUXDB3_AUTH_TOKEN="$INFLUXDB_TOKEN"
export INFLUXDB3_HOST_URL="http://127.0.0.1:8181"

Do not put the token in generate.py, the plugin, Grafana queries, screenshots, or a committed shell script. InfluxDB’s authorization setup guide recommends the INFLUXDB3_AUTH_TOKEN environment variable for CLI authentication.

Create a database for the demo:

export INFLUXDB_DATABASE="smart_building"
influxdb3 create database "$INFLUXDB_DATABASE"

Expected result: the command completes without an error. You can confirm the database exists with:

influxdb3 show databases

Generate a Demo Telemetry Data

A good tutorial dataset should be small, understandable, and repeatable. This generator creates six zones, sampled every five minutes for seven days.

In your editor, create generate.py in smart-building-demo and paste the following code:

#!/usr/bin/env python3
"""Generate deterministic smart-building telemetry as InfluxDB line protocol."""

from __future__ import annotations

from datetime import datetime, timedelta, timezone
import math
from pathlib import Path
import random

START = datetime(2026, 8, 10, tzinfo=timezone.utc)
INTERVAL = timedelta(minutes=5)
POINTS_PER_ZONE = 7 * 24 * 12

ZONES = [
    {"building": "hq", "floor": "1", "zone": "open_office", "sensor": "hq-1-open", "capacity": 40, "offset": 0.0},
    {"building": "hq", "floor": "1", "zone": "conference_a", "sensor": "hq-1-conf-a", "capacity": 12, "offset": 0.3},
    {"building": "hq", "floor": "1", "zone": "cafe", "sensor": "hq-1-cafe", "capacity": 50, "offset": 0.7},
    {"building": "hq", "floor": "2", "zone": "lab", "sensor": "hq-2-lab", "capacity": 20, "offset": 0.5},
    {"building": "annex", "floor": "1", "zone": "design_studio", "sensor": "annex-1-design", "capacity": 24, "offset": -0.2},
    {"building": "annex", "floor": "2", "zone": "meeting_room", "sensor": "annex-2-meeting", "capacity": 10, "offset": 0.1},
]

def occupancy_for(zone: dict[str, object], ts: datetime, rng: random.Random) -> int:
    hour = ts.hour + ts.minute / 60
    weekday = ts.weekday() " 5
    capacity = int(zone["capacity"])
    name = str(zone["zone"])

    if not weekday:
        base = 0
    elif 8 "= hour " 18:
        profile = {
            "open_office": 0.64,
            "conference_a": 0.34,
            "cafe": 0.18,
            "lab": 0.48,
            "design_studio": 0.70,
            "meeting_room": 0.28,
        }[name]
        curve = 0.82 + 0.18 * math.sin((hour - 8) * math.pi / 10)
        base = round(capacity * profile * curve)
    else:
        base = 0

    if weekday and name == "cafe" and 11.5 "= hour " 13.5:
        base = round(capacity * 0.88)
    if ts.weekday() == 1 and name == "conference_a" and 14 "= hour " 16:
        base = capacity
    if ts.weekday() == 3 and name == "design_studio" and 9 "= hour " 12:
        base = round(capacity * 0.92)

    return max(0, min(capacity, base + rng.randint(-1, 1)))

def values_for(zone: dict[str, object], ts: datetime, rng: random.Random):
    occupancy = occupancy_for(zone, ts, rng)
    capacity = int(zone["capacity"])
    hour = ts.hour + ts.minute / 60
    zone_name = str(zone["zone"])
    diurnal = math.sin((hour - 7) * math.pi / 12)
    load = occupancy / capacity if capacity else 0

    temperature = 21.3 + float(zone["offset"]) + 1.3 * diurnal + 1.1 * load + rng.uniform(-0.18, 0.18)
    humidity = 43.0 - 4.0 * diurnal + 3.0 * load + rng.uniform(-0.8, 0.8)
    co2 = round(430 + 530 * load + rng.uniform(-18, 18))
    pm25 = 5.2 + 2.8 * load + rng.uniform(-0.7, 0.7)
    power = 0.65 + 0.10 * occupancy + max(0.0, temperature - 23.0) * 0.42 + rng.uniform(-0.12, 0.12)

    # Deterministic incidents used by the dashboard.
    if ts.weekday() == 1 and zone_name == "conference_a" and 14 "= hour " 16:
        co2 += round(720 + 80 * math.sin((hour - 14) * math.pi / 2))
    if ts.weekday() == 3 and zone_name == "design_studio" and 9 "= hour " 12:
        co2 += round(560 + 70 * math.sin((hour - 9) * math.pi / 3))
    if ts.weekday() == 4 and 9 "= hour " 14:
        pm25 += 20 + 4 * math.sin((hour - 9) * math.pi / 5)
    if ts.weekday() == 2 and zone_name == "lab" and 19 "= hour " 22:
        power += 5.5

    return (
        occupancy,
        round(temperature, 2),
        round(humidity, 2),
        int(co2),
        round(pm25, 2),
        round(max(power, 0.1), 2),
    )

def main() -> None:
    output = Path("smart-building.lp")
    rng = random.Random(20260821)
    rows = 0

    with output.open("w", encoding="utf-8") as handle:
        for tick in range(POINTS_PER_ZONE):
            ts = START + tick * INTERVAL
            epoch_s = int(ts.timestamp())

        for zone in ZONES:
                occupancy, temperature, humidity, co2, pm25, power = values_for(zone, ts, rng)
                tags = (
                    f"building={zone['building']},floor={zone['floor']},"
                    f"zone={zone['zone']},sensor_id={zone['sensor']}"
                )
                fields = (
                    f"temperature_c={temperature:.2f},humidity_pct={humidity:.2f},"
                    f"co2_ppm={co2}i,pm25_ug_m3={pm25:.2f},power_kw={power:.2f},"
                    f"occupancy={occupancy}i,capacity={zone['capacity']}i"
                )
                handle.write(f"building_telemetry,{tags} {fields} {epoch_s}\n")
                rows += 1

    print(f"wrote {rows} deterministic rows to {output}")

if __name__ == "__main__":
    main()

Run the generator:

python3 generate.py
wc -l smart-building.lp

Expected output:

wrote 12096 deterministic rows to smart-building.lp
12096 smart-building.lp

You can open smart-building.lp in your editor to inspect the line protocol. Each line contains:

Tags: building, floor, zone, and sensor_id are low-cardinality dimensions used for filtering and grouping.
Fields: temperature, humidity, CO₂, PM2.5, power, occupancy, and capacity are values that change over time.
Timestamp: epoch seconds—the ingestion command will specify --precision s.

Add an InfluxDB Python Processing Engine Plugin

Raw sensor values are valuable, but operators usually want a smaller set of decisions: Is the room healthy? How urgent is the problem? What should someone check?

Create plugins/iaq_assessment.py in your editor and paste this code:

"""Create dashboard-ready indoor-air-quality assessments from raw telemetry.

InfluxDB 3 injects LineBuilder and influxdb3_local at runtime.
"""

def _classify(row):
    co2 = int(row["co2_ppm"])
    pm25 = float(row["pm25_ug_m3"])
    temperature = float(row["temperature_c"])
    humidity = float(row["humidity_pct"])
    occupancy = int(row["occupancy"])
    power_kw = float(row["power_kw"])

    co2_component = min(70, max(0, round((co2 - 800) / 8)))
    pm_component = min(30, max(0, round((pm25 - 8) * 2)))
    comfort_component = (
        10
        if temperature " 20
        or temperature > 25
        or humidity " 30
        or humidity > 60
        else 0
    )
    risk_score = min(100, co2_component + pm_component + comfort_component)

    if risk_score >= 70:
        severity = "critical"
    elif risk_score >= 45:
        severity = "high"
    elif risk_score >= 20:
        severity = "moderate"
    else:
        severity = "normal"

    if co2 > 1000 and occupancy > 0:
        recommendation = "increase_ventilation"
    elif pm25 > 25:
        recommendation = "check_filtration"
    elif comfort_component:
        recommendation = "balance_hvac"
    else:
        recommendation = "monitor"

    energy_waste_kw = max(0.0, power_kw - 1.5) if occupancy == 0 else 0.0
    return risk_score, severity, recommendation, energy_waste_kw

def process_writes(influxdb3_local, table_batches, args=None):
    processed = 0

    for table_batch in table_batches:
        if table_batch["table_name"] != "building_telemetry":
            continue

        for row in table_batch["rows"]:
            risk_score, severity, recommendation, energy_waste_kw = _classify(row)
            line = (
                LineBuilder("iaq_assessment")
                .tag("building", row["building"])
                .tag("floor", row["floor"])
                .tag("zone", row["zone"])
                .tag("severity", severity)
                .int64_field("risk_score", risk_score)
                .int64_field(
                    "co2_excess_ppm", max(0, int(row["co2_ppm"]) - 800)
                )
                .string_field("recommendation", recommendation)
                .float64_field("energy_waste_kw", energy_waste_kw)
                .bool_field("occupied", int(row["occupancy"]) > 0)
                .time_ns(int(row["time"]))
            )
            influxdb3_local.write(line)
            processed += 1

    influxdb3_local.info(
        f"iaq_assessment processed {processed} building_telemetry rows"
    )

The plugin deliberately uses only the API InfluxDB injects and the Python standard library, so you don’t have to install any packages.

Understanding the Risk Calculation

CO₂ component     = clamp(round((co2_ppm - 800) / 8), 0, 70)
PM2.5 component   = clamp(round((pm25_ug_m3 - 8) × 2), 0, 30)
comfort component = 10 outside 20–25 °C or 30–60% humidity
risk score        = min(100, all three components added together)

The score becomes one of four states:

Score	Severity
0–19	normal
20–44	moderate
45–69	high
70–100	critical

The rules are intentionally simple and transparent. They are tutorial logic, not a health, safety, or regulatory standard.

The plugin also calculates energy_waste_kw. When occupancy is zero, it counts only power above a conservative 1.5 kW idle baseline. This is different from counting all energy used while a room is empty, which is shown in the dashboards.

Raw and derived table schemas

The first write creates the raw building_telemetry table:

The plugin creates iaq_assessment:

Columns	Stored as
building, floor, zone, sensor_id	Tags
temperature_c, humidity_pct, pm25_ug_m3, power_kw	Float fields
co2_ppm, occupancy, capacity	Integer fields
time	Timestamp

Keeping the raw and derived data separate makes the model easy to audit. You can inspect the original readings without reverse-engineering a transformed table, while Grafana can query the already classified states.

Test the Plugin Before Connecting it to Writes

InfluxDB can run a WAL plugin against a sample row without committing its output. This is the quickest way to catch syntax errors or confirm the scoring logic. The Processing Engine testing guide describes this behavior.

Run:

influxdb3 test wal_plugin \
  --database "$INFLUXDB_DATABASE" \
  --lp "building_telemetry,building=test,floor=1,zone=test,sensor_id=test temperature_c=22.0,humidity_pct=45.0,co2_ppm=1200i,pm25_ug_m3=10.0,power_kw=2.0,occupancy=4i,capacity=10i 1786406400000000000" \
  iaq_assessment.py

Expected: one derived iaq_assessment line, no errors, risk score 54, severity high, and recommendation increase_ventilation.

The risk is 54 because CO₂ contributes 50 points, PM2.5 contributes 4, and temperature and humidity add zero.

Mistake to avoid: The final argument is relative to the server’s --plugin-dir, not your terminal’s current directory. Because the server started with plugins as its plugin directory, the correct value is iaq_assessment.py.

Create the Trigger and Ingest Sample Data

Create a WAL trigger that watches only the raw table:

export INFLUXDB_TRIGGER="smart_building_iaq_assessment"
influxdb3 create trigger \
  --database "$INFLUXDB_DATABASE" \
  --path iaq_assessment.py \
  --trigger-spec "table:building_telemetry" \
  --error-behavior disable \
  "$INFLUXDB_TRIGGER"

The table scope is important. The plugin writes to iaq_assessment; because the trigger watches only building_telemetry, those derived writes cannot invoke the plugin recursively. The code also ignores batches from other tables as a second guard.

Write all 12,096 source rows:

influxdb3 write \
  --database "$INFLUXDB_DATABASE" \
  --precision s \
  --file smart-building.lp

InfluxDB acknowledges the source write separately from completing asynchronous Processing Engine work. Poll the derived count for up to 60 seconds:

derived_rows=0
for attempt in $(seq 1 60); do
  derived_rows=$(
    influxdb3 query \
      --database "$INFLUXDB_DATABASE" \
      --format csv \
      "SELECT COUNT(*) AS derived_rows FROM iaq_assessment" |
      tail -n 1
  )

  if [[ "$derived_rows" == "12096" ]]; then
    break
  fi

  sleep 1
done

printf 'Derived rows: %s\n' "$derived_rows"

Expected:

Derived rows: 12096

If the count does not reach 12,096, do not continue to Grafana yet. Review the troubleshooting section and inspect the InfluxDB terminal for Processing Engine errors.

Disable the trigger after enrichment finishes:

influxdb3 disable trigger \
  --database "$INFLUXDB_DATABASE" \
  "$INFLUXDB_TRIGGER"

In a real streaming application, you would normally leave a healthy trigger enabled so future writes are enriched.

Query the Results with SQL

Start by validating the raw table:

influxdb3 query \
  --database "$INFLUXDB_DATABASE" \
  "SELECT
     COUNT(*) AS source_rows,
     COUNT(DISTINCT building) AS buildings,
     COUNT(DISTINCT zone) AS zones,
     MIN(time) AS first_time,
     MAX(time) AS last_time
   FROM building_telemetry"

Expected values:

source_rows: 12096
buildings: 2
zones: 6
first_time: 2026-08-10T00:00:00
last_time: 2026-08-16T23:55:00

Now summarize the derived table:

influxdb3 query \
  --database "$INFLUXDB_DATABASE" \
  "SELECT
     COUNT(*) AS derived_rows,
     MIN(risk_score) AS min_risk,
     MAX(risk_score) AS max_risk,
     SUM(
       CASE
         WHEN severity IN ('high', 'critical') AND occupied THEN 1
         ELSE 0
       END
     ) AS unhealthy_occupied_intervals,
     ROUND(SUM(energy_waste_kw) * 5.0 / 60.0, 2) AS avoidable_kwh
   FROM iaq_assessment"

Expected values:

derived_rows: 12096
min_risk: 0
max_risk: 71
unhealthy_occupied_intervals: 62
avoidable_kwh: 9.29

Finally, find the CO₂ hotspots and empty-zone consumption:

influxdb3 query \
  --database "$INFLUXDB_DATABASE" \
  "SELECT
     building,
     zone,
     MAX(co2_ppm) AS peak_co2_ppm,
     ROUND(AVG(pm25_ug_m3), 2) AS avg_pm25_ug_m3

The first two rows should be hq/conference_a at 1,770 ppm and annex/design_studio at 1,572 ppm. The hq/lab row should have the largest raw empty-zone consumption at 61.22 kWh.

Installing Grafana

Install Grafana OSS from Grafana Labs’ signed APT repository:

sudo apt-get install -y apt-transport-https wget gnupg

sudo mkdir -p /etc/apt/keyrings
sudo wget -O /etc/apt/keyrings/grafana.asc \
  https://apt.grafana.com/gpg-full.key
sudo chmod 644 /etc/apt/keyrings/grafana.asc

echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" |
  sudo tee /etc/apt/sources.list.d/grafana.list

sudo apt-get update
sudo apt-get install -y grafana

Start Grafana and enable it at boot:

sudo systemctl daemon-reload
sudo systemctl enable --now grafana-server.service
sudo systemctl status --no-pager grafana-server.service

Open http://localhost:3000 in your browser. On a new installation, the default username and password are both admin; Grafana immediately prompts you to choose a new password.

Use a unique local password supplied as $GRAFANA_ADMIN_PASSWORD. Never reuse the InfluxDB token as a Grafana password.

Create a Read-Only Token for Grafana

Grafana only needs to query this one database. It should not receive the administrator token used for setup.

In the terminal where INFLUXDB3_AUTH_TOKEN is still set, run:

influxdb3 create token \ –permission “db:smart_building:read” \ –name “Grafana read-only access to smart_building”

Store the returned value in your password manager as $INFLUXDB_GRAFANA_TOKEN. InfluxDB’s resource-token documentation explains the db:"database":read permission format.

Do not paste this token into a text file or include it in a screenshot. Enter it once in Grafana’s secure token field.

Connect Grafana to InfluxDB 3

In Grafana:

Open Connections → datasources.
Click Add new datasource.
Select InfluxDB. This is the built-in datasource; do not install another plugin.
Enter InfluxDB 3 Smart Building as the name.
Configure the connection:

Setting	Value
URL	http://127.0.0.1:8181
Query language	SQL
Database	smart_building
Token	The securely stored $INFLUXDB_GRAFANA_TOKEN value
Insecure Connection	Enabled

Click Save & test.

SQL uses Flight SQL over gRPC. Because both programs are on the same machine and the URL uses local HTTP without TLS, Insecure Connection is required. This setting disables gRPC TLS; it is not a recommendation for traffic crossing an untrusted network.

The URL is interpreted by the Grafana server, not by your browser. 127.0.0.1 works here because Grafana and InfluxDB run on the same machine. If you later move either service into a container or another machine, update the URL to an address reachable from the Grafana backend while keeping the connection private.

Create the Grafana Dashboard and Variables

Create the dashboard first:

Open Dashboards.
Click New → New Dashboard.
Save it as Smart Building Operations.
Set the dashboard timezone to UTC.
Set the absolute time range from 2026-08-10 00:00:00 through 2026-08-17 00:00:00.

The fixed range matters because this is historical data generated in a specific time range. A relative range such as “Last 7 days” will not include it.

Add the Building Variable

While editing the dashboard, click Add → Variable and configure:

Option	Value
Variable type	Query
Name	`building`
Label	Building
datasource	InfluxDB 3 Smart Building
Multi-value	Enabled
Include All	Enabled

Use this SQL query:

SELECT DISTINCT
  building AS __text,
  building AS __value
FROM building_telemetry
ORDER BY building

The preview should show annex and hq. Save the variable.

Add the Zone Variable

Add another query variable:

Option	Value
Name	`zone`
Label	Zone
datasource	InfluxDB 3 Smart Building
Multi-value	Enabled
Include All	Enabled

Use:

SELECT DISTINCT
  zone AS __text,
  zone AS __value
FROM building_telemetry
WHERE building IN (${building:sqlstring})
ORDER BY zone

This is a chained variable: changing Building refreshes the relevant Zone choices. For multi-value SQL variables, use IN and ${variable:sqlstring}. Grafana supplies correctly quoted SQL strings; do not add another pair of quotes around the variable. See InfluxDB template variables for more examples.

Set both variables to All before creating the panels.

Building the Grafana dashboard panels

For each panel, click Add → Visualization, select InfluxDB 3 Smart Building, switch the query editor to SQL code mode if necessary, paste the query, choose the indicated format and visualization, then apply the panel.

Every query uses two Grafana features:

$__timeFilter(time) expands to the dashboard’s active time range.
${building:sqlstring} and ${zone:sqlstring} expand the multi-select variables into quoted SQL values.

Grafana documents the available SQL macros in its InfluxDB query editor reference.

Peak CO₂ Dashboard

This stat answers, “What was the highest CO₂ reading in the selected scope?”

SELECT MAX(co2_ppm) AS "Peak CO₂ ppm"
FROM building_telemetry
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})

Configure:

Visualization: Stat
Format: Table
Unit: ppm
Title: Peak CO₂

With all buildings and zones selected, expect 1,770 ppm.

Keep the color neutral unless you have documented, context-appropriate CO₂ thresholds. A peak value alone does not describe duration, sensor accuracy, or local health policy.

Unhealthy Occupied Intervals Dashboard

This panel counts five-minute zone intervals that the plugin classified as high or critical while someone was present:

SELECT COUNT(*) AS "Unhealthy occupied intervals"
FROM iaq_assessment
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
  AND severity IN ('high', 'critical')
  AND occupied = true

Configure:

Visualization: Stat
Format: Table
Unit: short
Title: Unhealthy occupied intervals

Expected result: 62. This means 62 five-minute zone records, not 62 separate incidents.

Energy While Empty Dashboard

The source cadence is five minutes, so kWh for one row is power_kw × 5/60. This query integrates every interval with zero occupancy:

SELECT ROUND(
  SUM(
    CASE
      WHEN occupancy = 0 THEN power_kw * 5.0 / 60.0
      ELSE 0
    END
  ),
  2
) AS "Empty-zone kWh"
FROM building_telemetry
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})

Configure:

Visualization: Stat
Format: Table
Unit: kWh
Title: Energy while empty

CO₂ by Zone Dashboard

A raw five-minute series is readable, but a 15-minute average makes the incident shape easier to compare across zones:

SELECT
  date_bin(
    INTERVAL '15 minutes',
    time,
    TIMESTAMP '1970-01-01T00:00:00Z'
  ) AS time,
  zone,
  AVG(co2_ppm) AS "CO₂ ppm"
FROM building_telemetry
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
GROUP BY 1, 2
ORDER BY 1

Configure:

Visualization: Time series
Format: Time series
Unit: ppm
Legend: table, with maximum displayed
Title: CO₂ by zone

The result contains 672 series rows: 112 quarter-hour bins × six zones. A time series query must return a timestamp column; naming it time keeps the Grafana mapping straightforward.

Indoor Air Quality State Dashboard

SELECT time, zone, severity
FROM iaq_assessment
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
ORDER BY time

Configure:

Visualization: State timeline
Format: Time series
Title: Indoor-air-quality state

Add value mappings:

Value	Label	Suggested color
`normal`	Normal	Green
`moderate`	Moderate	Yellow
`high`	High	Orange
`critical`	Critical	Red

Wasted Energy Dashboard

The plugin’s energy signal shows how much power exceeded the 1.5 kW baseline while the zone was empty.

SELECT
  date_bin(
    INTERVAL '15 minutes',
    time,
    TIMESTAMP '1970-01-01T00:00:00Z'
  ) AS time,
  zone,
  AVG(energy_waste_kw) AS "Excess kW wasted"
FROM iaq_assessment
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
GROUP BY 1, 2
ORDER BY 1

Configure:

Visualization: Time series
Format: Time series
Draw style: bars
Stacking: normal
Unit: kW
Title: Energy wasted

The derived weekly total is 9.29 kWh, concentrated in the lab’s Wednesday evening event. Panel 3’s 316.04 kWh and this 9.29 kWh are intentionally different—the second number is more conservative.

Risk by Zone Dashboard

This query compares each zone’s normal operating level with its worst interval:

SELECT
  zone,
  ROUND(AVG(risk_score), 1) AS "Average risk",
  MAX(risk_score) AS "Peak risk"
FROM iaq_assessment
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
GROUP BY zone
ORDER BY "Peak risk" DESC

Configure:

Visualization: Bar gauge
Format: Table
Minimum: 0
Maximum: 100
Unit: none—the score is bounded from 0 to 100 but is not a percentage
Title: Risk by zone

Operational Hotspots Dashboard

Finish with a table that puts ventilation and energy context together:

SELECT
  building,
  zone,
  MAX(co2_ppm) AS peak_co2_ppm,
  ROUND(AVG(pm25_ug_m3), 1) AS avg_pm25,
  ROUND(
    SUM(CASE WHEN occupancy = 0 THEN power_kw * 5.0 / 60.0 ELSE 0 END),
    2
  ) AS empty_zone_kwh
FROM building_telemetry
WHERE $__timeFilter(time)
  AND building IN (${building:sqlstring})
  AND zone IN (${zone:sqlstring})
GROUP BY building, zone
ORDER BY peak_co2_ppm DESC

Configure:

Visualization: Table
Format: Table
Sort: peak_co2_ppm, descending
Title: Operational hotspots

The table should contain six rows. conference_a ranks first for CO₂, while the lab leads in raw empty-zone energy, a useful reminder that air quality and energy efficiency reveal different operational problems. Save the dashboard after adding all eight panels.

Where to take the project next?

You now have a complete InfluxDB 3 and Grafana stack running locally. Telemetry is written as line protocol, with a Python plugin enriching every row as it lands, a derived table storing decisions rather than measurements, and a Grafana dashboard querying both. The pattern is worth more than just this project. The plugin is roughly fifty lines of standard-library Python. The trigger is table-scoped so it cannot recurse. The raw table is untouched, so if you decide next month that 800 ppm was the wrong CO₂ threshold, you can rewrite the scoring and recompute from source. And because the enrichment happens once at write time, every dashboard panel stays a short, readable query.

Grafana Features to Try

You built eight panels in this tutorial, but that’s only a fraction of what Grafana can do:

Transformations - Join building_telemetry and iaq_assessment on time and zone, then use Organize fields and Add field from calculation to build a combined table without writing a more complex SQL query.
Data links and drill-downs - Turn each row of the Operational hotspots table into a link that opens a zone-scoped view with the zone variable pre-set. It’s a two-minute change that makes the dashboard feel like an application.
Ad hoc filters - An ad hoc filter variable lets viewers add their own building = hq style constraints at view time without editing any query.
Canvas and Geomap - Canvas can overlay live severity colors on a floor plan image; Geomap does the same on a real map if your zones carry coordinates. Both are far more legible to non-technical stakeholders than a time series.
Explore mode - Prototype SQL against the datasource without creating a panel first—the fastest way to iterate on a query.
Dashboards as code - Export the dashboard JSON and check it into version control, or use Grafana provisioning to deploy the datasource and dashboard together on a fresh machine.

InfluxDB 3 Features to Try

The Processing Engine plugin you wrote is one trigger type among several, and InfluxDB has caching and lifecycle features that pair directly with what you just built:

Scheduled triggers - WAL triggers run inline on the write path, so they should stay cheap. A scheduled trigger runs on an interval or cron expression instead. These are great for hourly and daily rollups, anomaly detection over a window, or anything that needs to look across many rows rather than one.
Rollup tables - Have a scheduled trigger write a zone_hourly summary. Dashboards over long ranges then read a small pre-aggregated table instead of scanning weeks of five-minute data.
HTTP request triggers - Expose a plugin at an endpoint, and you have a small API—a current-status lookup for a room display, or a webhook that returns the top three zones to investigate.
Last Value Cache - Keeps the most recent value per series in memory for very fast lookups, which suits “current state” stat panels and real-time displays far better than a MAX(time) subquery.
Distinct Value Cache - Speeds up exactly the kind of query your Building and Zone template variables run, like SELECT DISTINCT over a tag column. On a large deployment, this is the difference between dashboards that load instantly and dashboards that stall on variable refresh.
Retention periods - Set a retention period on the database so raw five-minute data expires while your rollup table keeps the long history. This is the standard way to control storage cost in time series systems.
InfluxDB 3 Explorer - A browser UI for browsing databases and prototyping queries, handy when you want to check a table’s shape without dropping into the CLI.

Get started with InfluxDB 3 and Grafana

If you have not set up InfluxDB 3 yet, start a free InfluxDB 3 Enterprise trial or download InfluxDB 3 Core from the InfluxData downloads page, then follow the installation guide. The full Processing Engine reference is in the InfluxDB 3 documentation.

Built something with this pattern? A different plugin, a better scoring model, a dashboard for a domain we didn’t think of? Share it in the InfluxData Community forums. Questions are welcome there too.

Telegraf Controller 1.1: Make Fleet-Wide Config Changes with a Single Edit

Scott Anderson (InfluxData) — Tue, 25 Aug 2026 00:25:00 +0000

Telegraf is easy to stand up. You just need a config file with a few plugins and data flows. That ease is why Telegraf fleets grow fast, and why managing the agents that collect data becomes more difficult than collecting it. A change that takes minutes on ten agents takes days across a few hundred. Telegraf Controller is a centralized control plane for managing, configuring, and monitoring your fleet of Telegraf agents.

Telegraf Controller 1.1 is available today and addresses that management problem from two sides: keeping the Controller layer itself reliable, and making fleet-wide changes without touching every config. The release adds high availability, configuration versioning, global constants, configuration groups, and aliases.

High availability (Telegraf Enterprise)

High availability lets you run multiple Controller instances from a shared database with automatic failover. If an instance goes down, agents keep pulling configuration and reporting health through the remaining instances.

For production monitoring, compliance systems, and other mission-critical pipelines, the configuration layer needs to meet the same reliability requirements as the rest of the stack. High availability also simplifies planned maintenance: one instance can go offline for patching and the config path stays open. In strict environments that require redundancy, it also removes Controller as a single point of failure.

Configuration versioning

Configuration versioning saves every configuration change as a new version, including who made it. If an edit causes errors, compare the current version against the previous one in a side-by-side, color-coded diff and revert.

Configuration history also provides an audit trail. Teams can trace when individual settings changed and test tuning changes without losing the last working configuration.

Global constants

Global constants let you define a value once (an output endpoint, a collection interval, a region name) and reference it from any configuration; updating the constant updates every configuration that references it.

Reference a constant anywhere in a configuration with the ::{constant_name} syntax. When Controller serves a configuration to an agent, it resolves each reference to the constant’s current value:

[agent]
  interval = "::{collection_interval}"

[[outputs.influxdb_v3]]
  urls = ["::{influxdb_url}"]
  token = "${INFLUX_TOKEN}"
  database = "::{metrics_database}"

The immediate benefit is consistency: shared values live in one place instead of being duplicated across dozens of configurations and drifting out of sync. Constants also simplify migrations: moving your fleet to a new output endpoint or standardizing collection intervals across teams becomes one edit instead of a config-by-config sweep.

Configuration groups

Configuration groups bundle multiple configurations into an ordered unit that agents retrieve in a single request. Instead of assigning each agent its own stack of individual configs, you assign the group.

Groups compose by reference, not by copy. A config can belong to multiple groups, and editing a config propagates the change to every group that includes it.

That’s what makes groups work as role profiles. Build one base config with the system inputs every host runs, then compose it with the configs specific to a web server or a database host. Tune the base config once and every role updates without maintaining separate copies that can drift. Groups also serve as templates. A group proven in production becomes the starting point for the next site or deployment, instead of another copy-paste job.

Configuration aliases

Configuration aliases let you use custom, human-readable identifiers for configs in both the UI and the API. Agents request web-baseline instead of a UUID, so when it’s time to move agents to a different config, simply move the alias and the fleet cuts over on the next pull.

If you are running multiple Controllers use a single alias to reference the same config on each instance rather than config UUIDs, which are unique to each Controller.

One change, fleet-wide

Constants, groups, and aliases are each useful on their own, but they’re designed to work together. If every site’s agents request the same group by alias, and that group’s configurations pull shared values from global constants, a fleet-wide change—a new endpoint or interval—is a single edit. Every site picks it up on its next config pull.

What’s free and what requires Telegraf Enterprise

Feature	Free	Enterprise
High availability	No	Yes
Configuration versioning	Yes	Yes
Configuration aliases	Yes	Yes
Global constants	Yes	Yes
Configuration groups	Yes	Yes

Get started

The value of Telegraf Controller 1.1 is a config path that stays up and is far less work to keep the fleet current. High availability maintains uptime through instance failures, so the layer serving your configs meets the same reliability as the rest of your stack. Shared values are defined once instead of copied across every config, and config changes reach the whole fleet on the next pull with a record of what moved and an easy revert if something went wrong.

Telegraf Controller 1.1 is available today. Download and install Telegraf Controller for free or contact us about Telegraf Enterprise.

FAQ

What's new in Telegraf Controller 1.1?

Telegraf Controller 1.1 adds high availability (Enterprise only), configuration versioning, global constants, configuration groups, and configuration aliases. Together, these allow a single edit, like a new output endpoint or collection interval, propagate across an entire fleet on the next agent config pull.

How does high availability work in Telegraf Controller?

High availability lets you run multiple Telegraf Controller instances against a shared database with automatic failover. If one instance goes down, agents keep pulling their configuration and reporting health through the remaining instances.

How do global constants work in Telegraf Controller?

Global constants let you define a value once (i.e. an output endpoint, collection interval, or region name) and reference it from any configuration using ::{constant_name} syntax. When Controller serves a config to an agent, it resolves the reference to the constant's current value, so updating the constant updates every configuration that uses it.

A Guide to Downsampling Time Series Data with InfluxDB 3

Charles Mahler (InfluxData) — Wed, 19 Aug 2026 08:00:00 +0000

This tutorial demonstrates both approaches using the InfluxDB 3 Processing Engine’s built-in bird tracking simulator plugin. You will generate telemetry, aggregate it into 10-second windows, and validate the result with SQL. The same pattern works for infrastructure metrics, industrial sensors, application telemetry, and other time series workloads.

Why downsample time series data?

High-resolution data is valuable while diagnosing a recent event, but its value often changes as it ages. A temperature reading collected every second may be useful for an active incident, while a daily report may only need 10-minute or hourly averages.

Downsampling helps you:

scan fewer rows in long-range queries
make dashboards over weeks or months more responsive
retain useful historical trends at a lower resolution, reducing storage costs
calculate common summaries once instead of repeating the work
keep raw data only for as long as its full resolution is useful

Downsampling is not the same as deleting raw data; it creates a summarized view or table at a lower granularity. Retention is a separate decision and process where data is fully deleted after a set period of time.

Choose Query-Time or Persisted Downsampling

InfluxDB 3 gives you two practical patterns for downsampling:

Approach	How it works	Best for	Main tradeoff
Query-time SQL	Uses `DATE_BIN` and aggregate functions in a `SELECT` query	Exploration, flexible dashboards, and changing aggregation requirements	Recomputes the result each time and does not reduce stored raw data
Python Processing Engine	Runs the official downsampler plugin on a schedule and writes aggregate rows to a target table	Repeated long-range queries, predictable rollups, and tiered retention	Requires you to choose aggregates and scheduling behavior in advance

A useful starting point is to develop and validate an aggregate in SQL. If the same query becomes a frequent or expensive workload, then use the downsampler plugin.

Prerequisites

To follow this tutorial, you need:

InfluxDB 3 Core or Enterprise with the Processing Engine enabled
InfluxDB 3 CLI installed and connected to the server
An authorization token with permission to create a database and triggers
Outbound access to GitHub so InfluxDB can load the official plugins referenced by gh: paths

The examples assume a database named bird_demo:

influxdb3 create database bird_demo

If you are using the local Docker environment that accompanies this article, InfluxDB is available at http://localhost:8181. InfluxDB 3 Explorer is available separately at http://localhost:8888 for running the SQL and capturing visual results.

Generate Sample Telemetry with the Official Bird Simulator

InfluxData’s bird data simulator is a convenient fit for this tutorial. It creates repeatable time series behavior without requiring a separate data generator or hardware sensor.

The plugin writes to the bird_tracking table. Its tags include species and name, and its fields include body_temp, longitude, latitude, speed, and heading.

First, install the plugin’s Faker dependency:

influxdb3 install package Faker

influxdb3 create trigger \
  --database bird_demo \
  --path gh:influxdata/bird_data_simulator/bird_data_simulator.py \
  --trigger-spec every:1s \
  --trigger-arguments bird_count=10 \
  bird_tracking_demo

After the trigger has run for several seconds, confirm that data is arriving:

SELECT *
FROM bird_tracking
ORDER BY time DESC
LIMIT 5;

At one write per bird per second, the simulator produces approximately 600 rows per minute for 10 birds.

Downsample at Query Time with SQL

InfluxDB 3 SQL supports time bucketing with DATE_BIN(). The following query groups the raw bird readings into 10-second intervals and calculates speed and body-temperature statistics for each bird:

SELECT
  DATE_BIN(INTERVAL '10 seconds', time) AS time,
  species,
  name,
  AVG(speed) AS avg_speed,
  MIN(speed) AS min_speed,
  MAX(speed) AS max_speed,
  AVG(body_temp) AS avg_body_temp,
  COUNT(*) AS record_count
FROM bird_tracking
WHERE time >= now() - INTERVAL '2 minutes'
GROUP BY 1, species, name
ORDER BY 1 DESC, species, name;

DATE_BIN aligns each timestamp to a 10-second boundary. GROUP BY 1 refers to the first expression in the SELECT list while species and name preserve one series per bird.

This is true query-time downsampling: the server returns fewer, summarized rows, but it does not write them to another table. Change the interval or aggregates whenever the question changes. For example, a long-range dashboard might replace INTERVAL '10 seconds' with INTERVAL '1 hour'.

Always include a bounded time predicate. It reduces the data scanned and makes the query’s intended resolution explicit.

Persist Downsampled Data with the Python Processing Engine

For an aggregate that many users or dashboards repeatedly request, calculate it on a schedule with InfluxData’s official downsampler plugin. The plugin queries the source table, computes aggregates, and writes the results to a target table.

This trigger creates one average speed and body-temperature row per bird for every 10-second interval:

influxdb3 create trigger \
  --database bird_demo \
  --path gh:influxdata/downsampler/downsampler.py \
  --trigger-spec every:10s \
  --trigger-arguments \
  'source_measurement=bird_tracking,target_measurement=bird_tracking_10s,interval=10s,window=2min,offset=10s,calculations=speed:avg.body_temp:avg,specific_fields=speed.body_temp' \
  bird_tracking_downsample

The trigger arguments control the rollup:

source_measurement is the raw source table.
target_measurement is the table that receives aggregates
interval=10s defines the time-bin width.
calculations assigns an aggregate function to each field
specific_fields limits processing to the fields needed by this rollup.
offset=10s delays the queried window so its newest bin has time to close.

Why the Offset Matters

The offset is not cosmetic. Without it, the simulator and downsampler could execute on the same 10-second scheduler boundary. Without an offset, the downsampler may query the newest bin while writes are still arriving, producing partial aggregates.

With offset=10s, the preceding completed bin and every aggregate in the validation window should have the expected 10 source points. In production, set the offset to at least the maximum delay you expect between an event occurring and becoming queryable. Workloads with late or out-of-order data may need a larger offset and lookback window.

Inspect the Persisted Result

The downsampler names calculated fields by appending the aggregate function, so speed becomes speed_avg and body_temp becomes body_temp_avg. It also writes record_count, time_from, and time_to metadata.

The plugin stores the data with nanosecond precision and converts it with TO_TIMESTAMP_NANOS() when you want readable timestamps:

SELECT
  time,
  species,
  name,
  ROUND(speed_avg, 2) AS avg_speed_mph,
  ROUND(body_temp_avg, 2) AS avg_body_temp_c,
  record_count,
  TO_TIMESTAMP_NANOS(time_from) AS source_start,
  TO_TIMESTAMP_NANOS(time_to) AS source_end
FROM bird_tracking_10s
ORDER BY time DESC, species, name
LIMIT 20;

Sample Output

Time (UTC)	Species	Bird	Avg. speed	Avg. body temp.	Source points	Source start
2026-08-14 21:21:00	American Robin	Tracy	22.47	41.94	10	21:21:00
2026-08-14 21:21:00	Blue Jay	Sara	21.59	41.67	10	21:21:00
2026-08-14 21:21:00	Cactus Wren	Brandon	18.78	41.74	10	21:21:00
2026-08-14 21:21:00	Great Blue Heron	Brenda	6.38	41.10	10	21:21:00
2026-08-14 21:21:00	Great Blue Heron	Pamela	24.97	41.35	10	21:21:00

Validate the Reduction with SQL

Do not judge a downsampling job only by whether the target table contains rows. Compare a fixed, completed interval so active writes cannot change the counts during validation.

The following query compares two completed minutes of source data with the corresponding persisted rollups. Replace the timestamps with a completed interval from your own run:

WITH raw AS (
  SELECT COUNT(*) AS raw_rows, COUNT(DISTINCT name) AS birds
  FROM bird_tracking
  WHERE time >= TIMESTAMP '2026-08-14T21:20:00Z'
    AND time " TIMESTAMP '2026-08-14T21:22:00Z'
),
downsampled AS (
  SELECT
    COUNT(*) AS downsampled_rows,
    SUM(record_count) AS represented_raw_rows,
    AVG(record_count) AS avg_points_per_row
  FROM bird_tracking_10s
  WHERE time >= TIMESTAMP '2026-08-14T21:20:00Z'
    AND time " TIMESTAMP '2026-08-14T21:22:00Z'
)
SELECT
  raw_rows,
  birds,
  downsampled_rows,
  represented_raw_rows,
  avg_points_per_row,
  ROUND(
    100.0 * (
      1.0 - CAST(downsampled_rows AS DOUBLE) / CAST(raw_rows AS DOUBLE)
    ),
    1
  ) AS row_reduction_percent
FROM raw CROSS JOIN downsampled;

Example Output

The equality between raw_rows and represented_raw_rows is an important completeness check. The 90% figure is a reduction in rows for this query shape, not a promise of an identical reduction in bytes on disk. Actual storage depends on schema, tags, fields, compression, and retention settings.

You should also compare aggregates against the query-time SQL version before applying any raw-data retention policy.

Downsampling best practices for production

The tutorial uses short intervals so you can see results quickly. A production workload might keep second-level raw data briefly, create 5-minute summaries for operational dashboards, and return hourly summaries for long-term reporting.

When designing that pipeline:

window=2min gives each execution a lookback window large enough to reprocess recent data.
Start with the questions users need to answer, then choose the interval. A bin that is too wide can hide short-lived behavior.
Preserve the tags you need for filtering and grouping. Removing a dimension during aggregation cannot be reversed later.
Select aggregates that match the signal. Gauges often need average, minimum, and maximum; counters may need sums or rates.
Account for ingestion delay with offset, and use a lookback window that can catch expected late data.
Validate counts and values over multiple completed intervals before shortening raw-data retention.
Monitor the Processing Engine logs and query latency after deployment.

Troubleshoot a scheduled downsampler

If the target table remains empty, inspect the Processing Engine logs:

SELECT
  trigger_name,
  log_level,
  log_text,
  event_time
FROM system.processing_engine_logs
ORDER BY event_time DESC
LIMIT 20;

Then check the most common causes:

The source table or a field name does not match the trigger arguments.
The source does not contain data within the plugin’s window and offset.
A Python dependency required by a plugin has not been installed.
The server cannot retrieve a remote gh: plugin.
The selected aggregate is not valid for a field’s data type.
The newest interval is incomplete because the offset is too small.
Getting started with downsampling with InfluxDB 3

InfluxDB 3 makes it possible to use the same SQL aggregation logic at two stages of a workload: interactively at query time and operationally as a persisted rollup. Start with DATE_BIN to confirm the right interval and dimensions. When the query becomes a stable, repeated access pattern, schedule the official Python downsampler and include an offset so it works on completed data.

Try the tutorial with InfluxDB 3 and the official InfluxDB 3 plugin library. Once your results match the raw source over a completed interval, adapt the interval, aggregates, offset, and retention strategy to your production workload.

FAQs

What is downsampling?

Downsampling is the process of grouping time series points into wider time intervals and calculating summaries such as averages, minimums, maximums, sums, or counts. InfluxDB 3 can calculate those summaries at query time with SQL or persist them with a Python Processing Engine.

How do I downsample data with InfluxDB 3 SQL?

Use DATE_BIN to place timestamps into fixed intervals, apply aggregate functions such as AVG or MAX, and group by the binned time plus any tags you want to preserve. SQL downsampling returns aggregate rows but does not automatically write them to another table.

When should I use the Python Processing Engine instead of SQL alone?

Use the Processing Engine when you want to precompute and store a rollup on a schedule. It is a good fit for aggregates used repeatedly by dashboards or long-range reports. Use query-time SQL when you need flexible intervals, are still exploring the data, or do not want another stored representation.

How do I prevent partial downsampling windows?

Set the downsampler plugin’s `offset` so it queries intervals that have finished receiving data. The offset should cover normal ingestion latency and expected late arrivals. Validate completeness by comparing the sum of `record_count` in the aggregate table with the raw row count over the same closed interval.

Does downsampling delete the original data?

No. Both a SQL aggregate query and the downsampler plugin leave the source data intact. The plugin writes additional rows to a target table. Raw-data deletion or expiration is controlled separately through retention settings.

What does record_count mean in the downsampled table?

`record_count` is the number of source records represented by an aggregate row. It is useful for detecting incomplete bins and for comparing the target table with the source over the same period.

Can I calculate more than one aggregate per interval?

Yes. A SQL query can return multiple functions such as AVG(speed), MIN(speed), and MAX(speed) in the same group. The official downsampler accepts calculation mappings for multiple fields. Choose only the summaries your queries need to avoid unnecessary write and storage overhead.

Does this approach work with InfluxDB 3 Cloud Serverless or Cloud Dedicated?

The embedded Python Processing Engine workflow in this tutorial applies to InfluxDB 3 Core and Enterprise. For InfluxDB Cloud Serverless, follow the documented client-library downsampling pattern: query aggregates with SQL, write the results back, and schedule the client externally. For Cloud Dedicated, you can use the same general query-and-write pattern with an InfluxDB 3 client library and an external scheduler.

How much storage will downsampling save?

There is no universal percentage. The tutorial reduced the number of rows returned for its fixed test window by 90%, but byte-level storage depends on the schema, data types, tag cardinality, compression, the aggregates stored, and how long you retain each resolution.

A Rust Client for InfluxDB 3

Ian Clark (InfluxData) — Thu, 13 Aug 2026 08:00:00 +0000

Time series data shows up wherever the physical world meets software. A satellite constellation streams altitude, power, and thermal telemetry from every spacecraft on every pass. A factory floor running on Industry 4.0 principles instruments every line, every motor, every batch. And underneath all of it sits a humbler problem that anyone who has worked in operational technology knows well: getting telemetry out of the PLCs and edge controllers that actually run the machines, off the bus, and into a database that can enable real-time asset intelligence.

InfluxDB 3 is built for this class of workload. It is the latest generation of the InfluxDB time series engine, built on an open source stack: Apache Arrow for in-memory columnar data and Apache DataFusion as the query engine. In practice, that means InfluxDB 3 is a columnar, vectorized engine that speaks SQL, exchanges data over Arrow Flight, and interoperates with the broader Arrow ecosystem, rather than a closed world with its own bespoke query path. For high-cardinality telemetry (thousands of spacecraft channels, tens of thousands of sensor tags on a plant floor), that columnar foundation is what keeps both ingest and analytical queries fast.

What has been missing for Influx users is a first-class Rust client. We just built one: influxdb3-client, an async Rust client for InfluxDB 3 Core and Enterprise that mirrors the feature set of the official Go and Python clients with an idiomatic Rust API.

Why Rust, when Go and Python clients already exist?

The honest answer is that for a lot of jobs, you shouldn’t switch. If you’re exploring data in a notebook, the Python client is the right tool. If you’re writing a typical backend service, the Go client is mature and perfectly fast. Rust earns its place in the parts of a telemetry pipeline where the other two start to fight you. Here are some scenarios where it makes sense to switch:

The edge box next to the PLC. The machine that bridges OPC UA or Modbus to your historian is often an ARM gateway with a few hundred MB of RAM, no package manager you control, and a change window measured in months. Rust cross-compiles to a single static binary, with no Python interpreter to install and patch on the box and no runtime to ship. scp it over, run it for a year.

Ingest where tail latency is the spec. During a ten-minute satellite pass, the ground segment has to drain every frame the downlink produces; there is no catching up later. A garbage collector that pauses at the wrong moment turns into dropped telemetry. Rust’s lack of a GC doesn’t make your code faster on average; it makes the worst case boring, which is what you actually care about when the data source won’t wait.

Backpressure you can reason about. High-rate ingest lives or dies on flow control: how many batches are in flight, how much memory they pin, what happens when the database slows down. With tokio, that’s an explicit semaphore and bounded buffers checked by the type system, rather than a goroutine count you tune by load testing.

The telemetry source is already Rust. Increasingly, the code producing the telemetry is Rust: a ROS 2 node on an autonomous mobile robot, drone flight software, a soft-PLC runtime, or a protocol bridge that speaks OPC UA or MQTT-Sparkplug. When the producer is a Rust process, the historian client should be a library you embed in it: same binary, same async runtime, no sidecar process to deploy and monitor on every robot in the fleet. An Arc"Client" shared across your tokio tasks is the whole integration.

Compile once, use anywhere. The same binary often has to write to whatever InfluxDB the customer runs. As of 0.2, writes default to the V2 /api/v2/write endpoint, so one client works unchanged against InfluxDB 3 Core and Enterprise as well as InfluxDB Clustered and Cloud Dedicated/Serverless. A config flag, not a code change, opts into the V3-only extras like no_sync when you control the server.

You’re already in the Arrow ecosystem. InfluxDB 3 itself is written in Rust on Arrow and DataFusion. With this client, query results come back as native Arrow RecordBatches—the same types you’d hand to DataFusion, Polars, or your own analytics code, with no serialization boundary in between. The client and the server are speaking the same in-memory format end-to-end.

If none of these scenarios describe your situation, the Go and Python clients remain great choices. If one of them does, you should get familiar with the Rust client.

Installation

The client is on crates.io and requires Rust 1.89 or later:

cargo add influxdb3-client

Or add it to your Cargo.toml alongside an async runtime:

[dependencies]
influxdb3-client = "0.2"
tokio = { version = "1", features = ["full"] }

There is an optional polars feature for DataFrame-based workflows, which we’ll come back to later.

Let Claude Write the Boilerplate

If you use Claude Code, there’s an influxdb3 skill that teaches it the InfluxDB 3 API surface: line protocol, the v3 SQL and InfluxQL query paths, token and database administration, and the client libraries—this one included. With the claude-influxdb3 plugin installed, you can skip the docs-spelunking and ask things like:

*"Write me a Rust snippet that writes a batch of sensor readings to my InfluxDB 3 cluster and reads the last hour back with SQL."*

You’ll get working code against this client’s actual API. It also knows the troubleshooting terrain: 401s from token scoping, line-protocol parse errors, and queries that silently return no rows. That’s most of what a first hour with any database consists of.

Configuring a client

uuA client needs a host, a database, and (usually) an API token. This is the most explicit way is to build the configuration yourself:

use influxdb3_client::{Client, ClientConfig};

#[tokio::main]
async fn main() -> influxdb3_client::Result"()" {
    let client = Client::new(
        ClientConfig::builder()
            .host("http://localhost:8181")
            .token("my-api-token")
            .database("sensors")
            .build()?,
    )
    .await?;
    Ok(())
}

For deployments where configuration comes from the environment, such as a container or a systemd unit on an edge box, read INFLUX_HOST, INFLUX_TOKEN, and INFLUX_DATABASE directly:

let client = influxdb3_client::Client::from_env().await?;

Optional variables (INFLUX_AUTH_SCHEME, INFLUX_ORG, INFLUX_PRECISION, INFLUX_GZIP_THRESHOLD, and the INFLUX_WRITE_* family) configure the same write defaults the builder exposes, so a deployed agent can be retuned without a rebuild.

Or, parse a single connection string, which is handy when configuration arrives as a single opaque value:

"let client = influxdb3_client::Client::from_connection_string(
    "https://cluster.example.io/?token=TOKEN&database=mydb",
).await?;

The Arrow Flight channel used for queries is opened lazily on the first query, so constructing a client never blocks on query connectivity, and a write-only ingest agent never pays for a query connection it won’t use.

Writing data

client.write(data) returns a builder; chain the options you want, then .await it. The data argument is flexible—it can be a line-protocol string, a Vec"Point", or (with the polars feature) a DataFrame.

Points

The Point builder is the most ergonomic way to construct measurements in code:

use influxdb3_client::{Point, Precision};

let points = vec![
    Point::new("temperature")
        .tag("location", "office")
        .tag("floor", "2")
        .field("celsius", 22.5_f64)
        .field("humidity", 48_i64)
        .field("occupied", true),
];

client.write(points).precision(Precision::Millisecond).await?;

Raw Line Protocol

If you already have line protocol, say forwarded straight off a device, you can write it as is:

client
    .write("cpu,host=server01 usage_user=42.3,usage_system=1.2")
    .await?;

Write Options

The builder exposes the knobs that matter for real ingest pipelines:

client.write(points)
    .precision(Precision::Nanosecond)
    .batch_size(10_000)          // points per HTTP request
    .max_inflight(8)             // concurrent in-flight requests
    .default_tag("region", "us-east")
    .tag_order(["region", "host"])
    .await?;

Large inputs are split into batches and sent as multiple pipelined requests, with one batch buffer held in memory at a time, so memory stays bounded even on very large writes.

tag_order matters more than it appears to. The first write defines the physical tag column order for a table, and that order affects query performance; tags you filter on most should sort first. .tag_order(...) serializes the listed tags first, then appends any remaining tags in deterministic lexicographic order, so the machine that happens to boot first doesn’t accidentally pick a bad layout for everyone. (Background: sort tags by query priority.)

Which Write Endpoint?

As of 0.2, writes go to the V2 /api/v2/write endpoint by default, which means the same client also works against InfluxDB Clustered and InfluxDB Cloud Dedicated/Serverless without changes. Opting into the V3 endpoint (ClientConfig::builder().write_use_v2_api(false), or INFLUX_WRITE_USE_V2_API=false in the environment) unlocks two V3-only behaviours: no_sync() (acknowledge before the WAL is synced) and partial-write reporting, both covered below.

High-Throughput Ingest

For sustained, high-volume writes, such as a satellite pass or a full plant floor, the throughput levers are batch_size (points per request) and max_inflight (concurrent requests per call). On the V3 endpoint (write_use_v2_api(false)), no_sync() adds a third: acknowledge before the WAL is synced, trading a little durability for speed.

A single write call serializes its batches on one task. To use more CPU cores and connections, run several write calls concurrently. A Client is cheap to share, and its HTTP connection pool is reused, so the idiomatic pattern is to wrap it in an Arc, spread chunks across tasks, and cap concurrency with a semaphore to keep in-flight buffers bounded:

use std::sync::Arc;
use tokio::sync::Semaphore;

let client = Arc::new(client);
// cap concurrent writes
let gate = Arc::new(Semaphore::new(8)); 

// each chunk is a Vec"Point"
for chunk in chunks {                    
    let permit = gate.clone().acquire_owned().await.unwrap();
    let client = Arc::clone(&client);
    tokio::spawn(async move {
        // released when the write completes
        let _permit = permit;            
        client
            .write(chunk)
            .batch_size(10_000)
            .max_inflight(8)
            .no_sync()

            .await
    });
}

To spread load across multiple ingest nodes, put a load balancer in front of the cluster, or construct one Client per node and distribute chunks across them.

Querying data

InfluxDB 3 supports both SQL and InfluxQL, and the client exposes both through the same query-builder pattern: client.sql(q) or client.influxql(q).

let result = client
    .sql("SELECT * FROM temperature ORDER BY time DESC LIMIT 10")
    .await?;

for row in result {
    let row = row?;
    let loc = row["location"].as_str().unwrap_or("");
    let c = row["celsius"].as_f64().unwrap_or(0.0);
    println!("{loc}: {c}");
}

InfluxQL is called in exactly the same way, which makes it easy to bring existing InfluxQL queries forward:

let result = client
    .influxql("SELECT MEAN(celsius) FROM temperature WHERE time > now() - 1h")
    .await?;

Parameterized Queries

Bind parameters with .param() rather than interpolating into the query string:

let rows = client
    .sql("SELECT COUNT(*) AS n FROM cpu WHERE host = $host")
    .param("host", "server01")
    .await?
    .rows()?;

if let Some(r) = rows.first() {
    println!("count: {}", r["n"]);
}

Working with Rows

A QueryResult can be iterated row by row, collected all at once with .rows(), or accessed as raw Arrow RecordBatches with .record_batches() if you want to hand the columnar data straight to another Arrow-aware library. A Row is indexed by column name (row["col"]) or position (row[0]), and yields a Value with typed accessors: as_f64, as_i64, as_str, as_bool, is_null.

One deliberate design choice: if a query returns an Arrow type the row API doesn’t support, you get an explicit Error::UnsupportedArrowType, rather than a silent null. Telemetry pipelines fail quietly often enough without the client library helping.

Streaming Large Results

For analytical queries whose results are too large to hold in memory, like a scan over a month of high-rate telemetry, stream the Arrow batches instead of collecting them:

use futures_util::TryStreamExt;

let mut stream = client.sql("SELECT * FROM temperature").stream().await?;
while let Some(batch) = stream.try_next().await? {
    println!("got {} rows", batch.num_rows());
}

Reliability

Telemetry pipelines run unattended, so the client retries transient failures automatically with exponential backoff and full jitter. Connection errors, timeouts, 429, and 5xx responses are retried, and Retry-After is honored when present. Deterministic failures (other 4xx responses and partial writes) are never retried. Retrying writes is safe because line-protocol writes are idempotent at the (series, timestamp, field) level, i.e., re-sending the same point simply overwrites it.

use influxdb3_client::RetryConfig;
use std::time::Duration;

// Per-request override.
client.write(points)
    .retry(RetryConfig { max_retries: 5, base_delay: Duration::from_millis(100), ..RetryConfig::default() })
    .await?;

// Disable retries for a single call.
client.write(points).no_retry().await?;

On the V3 endpoint, when a batch contains invalid lines, the server accepts the valid ones and reports the rest, which surfaces as Error::PartialWrite with the rejected lines attached:

use influxdb3_client::Error;

if let Err(Error::PartialWrite(e)) = client.write(line_protocol).await {
    for line_error in &e.line_errors {
        eprintln!("line {}: {}", line_error.line, line_error.message);
    }
}

If all-or-nothing semantics fit your pipeline better, .accept_partial(false) rejects the entire batch when any line fails.

Polars integration

For data-engineering and analysis workflows, the optional polars feature lets you write a DataFrame directly and read query results back as one:

influxdb3-client = { version = "0.2", features = ["polars"] }

use influxdb3_client::write_dataframe::DataFrameWrite;
use polars::prelude::*;

let df = df![
    "host"    => ["srv1", "srv2"],
    "region"  => ["us-east", "us-west"],
    "cpu_pct" => [42.5_f64, 71.0_f64],
    "time"    => [1_700_000_000_000_000_000_i64, 1_700_000_001_000_000_000_i64],
]?;

client
    .write(
        DataFrameWrite::new(&df, "server_metrics")
            .tags(&["host", "region"])
            .timestamp_column("time"),
    )
    .await?;

let df_back = client
    .sql("SELECT * FROM server_metrics")
    .await?
    .to_polars()?;

Backfilling from Parquet Files

Let’s look at a common migration task. Say you have historical telemetry sitting in Parquet files, exported from another system or batch dumped from a data lake, and you want it in InfluxDB where it can be queried alongside live data. File IO deliberately lives in your code rather than the client; read the file with Polars, then hand the frame to DataFrameWrite. Enable the Parquet reader on Polars in your own Cargo.toml:

polars = { version = "0.53", features = ["Parquet"] }

use std::fs::File;
use polars::prelude::*;
use influxdb3_client::write_dataframe::DataFrameWrite;

let df = ParquetReader::new(File::open("sensors.Parquet")?).finish()?;

client
    .write(
        DataFrameWrite::new(&df, "sensor_data")
            .tags(&["site", "line", "machine_id"])
            .timestamp_column("time"),
    )
    .await?;

Parquet files carry their schema, so dtypes arrive correct—floats stay floats, timestamps stay timestamps. Columns you name in .tags(&[...]) become tags, the timestamp column sets each point’s time, and every remaining column becomes a field. The whole pipeline, from Parquet reader through DataFrame and client to server, is Arrow-native, so the data never leaves columnar form until the final encode.

For a multi-gigabyte backfill, read and write in file-sized chunks rather than one giant frame, and reuse the high-throughput pattern from earlier (batch_size, max_inflight, one task per file) to keep the pipe full.

Loading CSV Exports

Most SCADA packages and historians will export CSV, so it’s often the format you’re handed. The same programming pattern works, with one caveat: CSV carries no schema, so Polars infers column types, and anything ambiguous infers as a string. A string column becomes a string field in InfluxDB, and you can’t MEAN() a string. Supply the dtypes explicitly and parse the timestamp at read time:

polars = { version = "0.53", features = ["csv"] }

use polars::prelude::*;
use influxdb3_client::write_dataframe::DataFrameWrite;

let schema = Schema::from_iter([
    Field::new("machine_id".into(), DataType::String),         
    Field::new("rpm".into(), DataType::Float64),                       Field::new("spindle_load_pct".into(), DataType::Float64),  
    Field::new("alarm_active".into(), DataType::Boolean),     
    Field::new("time".into(), DataType::Datetime(TimeUnit::Nanoseconds, None)),
]);

let df = CsvReadOptions::default()
    .with_schema(Some(Arc::new(schema)))
    .try_into_reader_with_file_path(Some("plc_export.csv".into()))?
    .finish()?;

client
    .write(
        DataFrameWrite::new(&df, "machine_telemetry")
            .tags(&["machine_id"])
            .timestamp_column("time"),
    )
    .await?;

If you’d rather let inference do the first pass, that works too. Just cast() the numeric and boolean columns before writing, or they’ll land as string fields and you’ll be wondering why your aggregation queries return nothing.

FAQ

What is `influxdb3-client?`

The Rust influxdb3-client is a Rust native client library for programmatically interacting with Influxdb. It simplifies writing Line Protocol (Influxdb’s native format) as well writing queries in SQL and Influxql.

What Rust version does it require?

The crate requires Rust version 1.89 or later.

Does it work with InfluxDB Cloud Dedicated, Clustered, or Serverless, or only Core and Enterprise?

Yes! The client library has a full backwards compatible api and integrates with any version of Influxdb that supports the v2 write API.

Does the client support InfluxDB 1.x or 2.x?

Yes. Later versions of InfluxDB have forward compatibility APIs, and all versions of Influxdb support the v2 write API.

Why would I use this instead of the Go or Python client?

Rust excels in embedded programing environments, or integrations with other Rust codebases.

Is the Polars integration required?

No. Polars enables reading and writing to CSV and Parquet files, or if you want to leverage Polars Dataframes, but isn’t required.

Does it retry failed writes automatically?

Yes, the client retries transient failures automatically with exponential backoff and full jitter.

Where do I report issues or request features?

https://github.com/InfluxCommunity/influxdb3-rust

Try it

The repository ships runnable examples in examples/: a quickstart that does an end-to-end write and query, a Cloud Dedicated connection example, and a Polars DataFrame round-trip. Point them at a running InfluxDB 3 instance and go:

INFLUX_HOST=http://localhost:8181 INFLUX_TOKEN=token INFLUX_DATABASE=mydb \
    cargo run --example quickstart

The client is influxdb3-client on crates.io, the source lives on GitHub, and the API docs are on docs.rs. It’s early, and feedback, issues, and pull requests are all welcome.

Where Historians Fall Short for Physical AI

Conrad Chuang (InfluxData) — Tue, 04 Aug 2026 08:00:00 +0000

Physical AI enables machines and industrial systems to perceive conditions, reason about them, and act in the real world. In industrial settings, as part of an industrial AI strategy, physical AI models can help organizations identify risks earlier, optimize operations, and respond to changing conditions in real-time.

Delivering these outcomes starts with training AI models on detailed historical operational data. Then, when deployed, these models need access to real-time telemetry to interpret current conditions, make decisions, and automate actions.

For organizations built around traditional historians, supporting model training and real-time operations creates new challenges and new opportunities.

Where historians fall short for Physical AI

Data historians remain essential systems for industrial operations. They create a durable record of process and equipment behavior, supporting engineering analysis, troubleshooting, reporting, auditability, and, where required, regulatory compliance.

But the issue is, simply put, data historians were built for, well, historical data. The data requirements of Physical AI are different.

At inference time, models need immediate access to current, sufficiently detailed operational data. During development and training, they need consistent, well-labeled history drawn from many operating conditions, assets, and sites. Historian-centered architectures can make both jobs difficult.

Retaining Operational History Versus a Live Model Feed

Data historians are effective at recording operations and helping engineers investigate what happened. But many historian deployments were not designed to continuously serve high-frequency OT data to AI models and applications operating across edge, IT, and cloud environments. The data may be collected in real-time, yet still be difficult to use in real time. Historian data commonly remains inside the OT environment, where access is constrained by network segmentation, security requirements, proprietary interfaces, and site-specific infrastructure. Making it available to an AI application may require gateways, scheduled queries, replication, exports, or additional integration pipelines.

Every additional step introduces operational complexity, and more importantly, delays. At inference time, latency matters. Physical AI systems must evaluate current conditions while there is still an opportunity to respond. If telemetry reaches the model after the equipment state or process condition has changed, the data may still support investigation, but it can no longer support timely intervention.

Compression Removes Relevant Signals for Model Training

Legacy data historians often use techniques such as (deadbands, exception processing, compression, aggregation, or downsampling, to reduce data volume while preserving operational trends. This approach is appropriate for traditional data historian workloads, e.g., reporting, troubleshooting, and compliance.

By comparison, Physical AI models need to be trained on high-resolution telemetry that preserves the patterns required to recognize normal and abnormal operating states, predict outcomes, and determine the appropriate action. When those details are removed before training, models may not be able to learn the subtle behaviors that distinguish one condition from another.

The Cost of Fragmented Data

Legacy data historian architectures were designed in an era when operational technology (OT) and information technology (IT) environments were largely separate. That separation creates challenges when training Physical AI models because much of the context needed to interpret telemetry, such as maintenance records, production schedules, quality results, operator actions, business processes, and asset relationships, resides in IT applications such as ERP, MES, and CMMS systems.

In addition, historian architectures also tend to be site-centric. Historians are typically deployed and managed at the plant, facility, or asset level, creating separate stores of operational history across the organization. Physical AI initiatives may need data from multiple—or even all—sites to build an enterprise-level history that captures a broader range of assets, operating conditions, failures, and outcomes.

Lastly, training datasets for Physical AI models are increasingly multimodal, combining telemetry with inputs such as images, video, audio, and LiDAR. When these sensory inputs are connected and aligned in time, models can learn how observations—across sight, sound, spatial awareness, and machine state—relate to operating conditions, how events unfold, and which outcomes or actions follow. This multimodal training prepares Physical AI models to interpret a wider range of sensory inputs at inference time, reason about current conditions, and ultimately act within the physical world.

The challenge is that legacy historian architectures preserve time series telemetry as an operational record, but they do not inherently connect it with enterprise context, history from other sites, or data held in specialized multimodal systems.

Bridging these data silos requires building ETL pipelines, custom integrations, and manual workflows to align timestamps, asset identities, operating conditions, events, and outcomes. Engineers spend significant time collecting, reconciling, and preparing data before it can be used to train Physical AI models.

The Problem	Historian Limitation	InfluxDB 3 Solution
Inference needs live data	OT data is trapped behind gateways and exports	Ingests at the edge with low-latency queries
Training needs full signal details	Compression, downsampling, and aggregation strip patterns out	Retain and serve full resolution data at scale
IT/OT connection	Context lives outside the historian	Connects telemetry with applications (ERP, MES, CMMS)
AI needs data from every site	Stores data on a per-site basis	Consolidates multi-site data
Models need to learn from more than sensor data	Historians don't line up video, images, or audio with telemetry	Syncs telemetry with other data types by time

A modern time series architecture connects edge and cloud

Fortunately, teams don’t need to rip out their historians and toss them aside. With InfluxDB 3, organizations can build on existing historian investments while creating a more modern operational data architecture for Physical AI. Historians can continue to preserve the operational record, while InfluxDB provides a distributed time series data layer for ingesting, processing, consolidating, and distributing telemetry across edge, cloud, and enterprise environments.

At the industrial edge, time series services can sit close to the source, where teams can process and query live telemetry for low-latency inference and action. Some or all of that data can also be sent to InfluxDB Cloud, creating a common, time-aligned data layer that brings together operational history from multiple sources. This gives organizations the detailed, connected historical datasets needed for model training, evaluation, and enterprise analysis.

The cloud consolidation point also serves as a distribution layer. Telemetry can be made available without building a separate DataOps pipeline or custom integration between each source and every consumer. The same architecture can therefore support local decision-making at the edge and enterprise-wide learning in the cloud.

Even better, this shared data layer can connect telemetry with asset metadata, data from enterprise systems such as ERP, MES, and CMMS, and multimodal data such as images, video, and audio. Time-aligned telemetry provides the operating context for these other data types, showing machine state, load, temperature, vibration, control settings, and process conditions at the moment a multimodal observation was captured or an operator action was taken. The result is a richer training foundation that helps Physical AI models learn not just what happened, but the conditions in which it happened, context that supports more accurate inference, stronger root-cause analysis, and better operational decisions.

Building a Context-Rich Training Dataset for Physical AI

Delivering Live Telemetry to AI at Inference

Built on Apache Arrow and DataFusion with SQL support, InfluxDB 3 enables fast time series queries across large volumes of time-stamped data. It works alongside legacy historians as a real-time time series layer, or hub. Teams can ingest high-frequency telemetry, query recent data as it arrives, and use that data in dashboards, and to trigger alerts and automation workflows. With the Python Processing Engine, teams can process signals, extract features, detect anomalies, and act on data as it arrives. This brings analysis closer to ingestion, helping deployed physical AI models run inference on current operating conditions and respond as they change.

Built for the physical world

Legacy data historians will continue to play an important role in preserving operational history and supporting long-term analysis. But as AI-driven operations become more common, organizations need additional capabilities to make detailed operational data continuously available for training, inference, and action.

By extending historian investments with a modern, distributed time-series architecture, teams can support real-time action at the edge while consolidating and distributing operational data across the enterprise.

Ready to build a stronger foundation for Physical AI? Explore InfluxDB 3 open source with InfluxDB 3 Core or a free trial of InfluxDB 3 Enterprise. For more on this topic, watch the webinar, Physical AI for Industrial IoT: Edge Impulse + InfluxDB.

FAQ

What is Physical AI, and how does it differ from other forms of AI?

Physical AI refers to AI systems that interact with the material world, interpreting telemetry through the lens of physical laws rather than just processing numbers or generating content. In industrial settings, it relies on continuous operational data such as sensor telemetry, machine states, and process conditions to interpret its environment and act in real-time.

What's the difference between a data historian and a time series database?

A data historian is built to record industrial process and equipment data for engineering analysis, troubleshooting, and compliance reporting. A time-series database, like InfluxDB 3, is purpose-built to ingest, query, and act on time series data in real-time across edge, cloud, and enterprise environment. Historians excel at retaining a historical record; time series databases are built to also serve that data live to applications and AI models.

Why can't traditional historians support real-time AI inference?

Many historian deployments store data inside OT environments where network segmentation, proprietary interfaces, and site-specific infrastructure limit real-time access. Getting that data to an AI model typically requires gateways, scheduled queries, or export pipelines, each of which adds latency.

How does InfluxDB 3 help unify data across multiple industrial sites?

Historians are typically deployed at the plant or facility level, creating separate stores of operational history. InfluxDB 3 can consolidate time series data from multiple sites into a centralized or cloud-based layer, giving Physical AI models an enterprise-wide dataset spanning more assets, operating conditions, and failure modes than any single site can provide alone.

What’s New in InfluxDB 3.11: A Significant Performance Upgrade for Complex Time Series Workloads

Peter Barnett (InfluxData) — Thu, 30 Jul 2026 07:30:00 +0000

Time series workloads rarely stay predictable for long. A system might begin with a few devices reporting a small set of measurements. As the fleet grows, new sensors come online, tags multiply, and query patterns change. A table that looked simple at the start becomes wide and sparse. A workload built around recent data expands into long-range analysis. As complexity grows, maintaining fast query performance and a predictable resource profile becomes much harder.

InfluxDB 3.11 was built for that reality.

Our last two releases gave users an early look at a set of performance improvements designed for heavier, more complex time series workloads. Today’s release of InfluxDB 3.11 makes those performance improvements GA in InfluxDB 3 Enterprise, bringing significantly faster queries on live data, greater flexibility for wide and ultra-sparse schemas, and more predictable performance under heavy load. The release also adds new Enterprise capabilities for backup and recovery, bulk data import, row-level deletes, and cluster operations.

Performance and flexibility for heavier, more complex workloads

Faster Reads for Single-Series Workloads

Time series applications rely on fast access to recent data, whether it’s the latest reading from a device, the current state of an asset, a narrow time range from a sensor, or a live view that tracks ingest. For highly selective queries, like those for a single time series, this new release of InfluxDB 3 Enterprise is up to 4x faster than previous versions.

Actual performance will vary by workload, schema, hardware, and query shape. But for industrial monitoring, fleet management, observability, energy systems, and other applications built around live operational data, these gains mean faster access to the current state of the system.

More Room for Wide, Sparse, and Changing Schemas

Time series data rarely arrives in one clean shape. As devices, sensors, tags, and operating environments change, schemas can become wide, sparse, and highly variable. Rigid schema limits can force teams to split data across more tables, drop useful context, or design around the database instead of the application.

InfluxDB 3.11 expands schema flexibility with support for thousands of tables and millions of columns, while efficiently handling ultra-sparse datasets where only a small fraction of fields may be populated at any given time. Teams can model complex, changing telemetry around the data itself, with predictable query performance even as schemas grow wider and sparser.

For customers moving from InfluxDB 1.x or 2.x to InfluxDB 3, this brings forward the schema flexibility they know from InfluxDB, now with the full SQL query engine, object-store-based durability, and unlimited cardinality.

More Predictable Performance Under Load

InfluxDB 3.11 reduces the resource spikes that can occur during heavy ingest and compaction. Memory usage is more predictable, and compaction runs with a more consistent resource profile, making it easier to understand what a workload actually requires.

Teams can size infrastructure with more confidence instead of holding extra capacity for occasional spikes. Query responsiveness stays steadier under load, while memory and infrastructure costs are easier to plan for as workloads grow.

New data management capabilities for Enterprise

InfluxDB 3.11 also adds new Enterprise capabilities for backing up, importing, and deleting data:

End-to-End Backup & Restore: You can now run full or incremental backups to capture compacted data. Restores run asynchronously, providing disaster recovery and allowing you to roll a live cluster back to an earlier point in time.
Bulk Import from Parquet: Bringing existing or external data into InfluxDB 3 is now much simpler. A new bulk-import feature lets you upload an entire directory of Parquet files to ingest the data directly.
Row-Level Deletes: Deleting individual rows is inherently more complex in columnar storage where data is optimized to be written and read in larger blocks. InfluxDB 3.11 now lets you target specific data by time range or tag predicate, without having to drop an entire table.

InfluxDB 3 Explorer UI, now built in

InfluxDB 3.11 brings the Explorer UI directly into InfluxDB 3, giving users a visual interface for querying, exploring, and managing their data out of the box.

Explorer goes well beyond basic data visualization. You can query data using SQL, InfluxQL, or natural language, convert existing Flux queries to SQL with AI-assisted explanations, and manage Processing Engine plugins from the built-in plugin manager. Explorer also includes schema browsing, sample data generation, visualization, and live instance monitoring in one interface.

Get started with InfluxDB 3.11

InfluxDB 3.11 brings the performance improvements introduced in our last two releases to GA, with faster single-series queries, support for wide and ultra-sparse schemas, and more predictable performance under load. New Enterprise data management capabilities and the built-in Explorer UI make these improvements easier to deploy and manage in production.

As time series workloads grow, so do demands on the database. InfluxDB 3.11 is built to maintain performance as complexity increases.

Download the latest version of InfluxDB 3 Core or Enterprise, pull the newest Docker image, or check out the docs (Core, Enterprise) to get started.

AI-Powered Spacecraft Operations with InfluxDB 3

Charles Mahler (InfluxData) — Wed, 29 Jul 2026 08:00:00 +0000

When a satellite is drifting toward a fault, operators don’t need another dashboard full of disconnected charts. They need to know what changed, what it means, and what to check before the next ground pass closes. That’s the idea behind our satellite telemetry demo: a live mission-control experience built on InfluxDB 3.

The demo monitors a simulated fleet of 12 satellites, continuously ingesting telemetry such as onboard computer temperature, battery voltage, solar current, reaction wheel RPM, power draw, RF link margin, ground station, orbit pass, and attitude status. One satellite is actively degrading, while historical incidents provide useful context for comparison.

You can check out the live demo here or watch the video to see it in action:

Demo overview

From Telemetry Stream to Operator Signal

The main dashboard provides a fleet overview showing which satellites are online, which are currently in contact, and where anomalies are occurring. Operators can then drill into individual spacecraft to get a more specific view and look at historical data.

Detecting Anomalies as Data Arrives

Behind the scenes, the InfluxDB 3 Processing Engine observes incoming data as it is written to the database and automatically creates alerts based on conditional thresholds or sensor states.

That means anomaly detection happens without waiting for a separate pipeline to catch up. Another processing engine task incorporates NOAA data for environmental context alongside vehicle behavior.

This pattern can be extended beyond satellites. Any connected system with high-volume and time-sensitive data, such as industrial equipment, energy infrastructure, production systems, or logistics networks, will benefit.

Accessing Operational Truth Using AI

This demo also includes an AI agent powered by the InfluxDB 3 MCP server. Instead of generating answers based on generic knowledge, the agent can access data stored in InfluxDB. You can ask about fleet health, a specific satellite, or the root cause of a suspected issue. The agent can then query InfluxDB throughout a conversation and summarize what it found.

Under the hood: From raw telemetry to operational context

This demo goes beyond the dashboard; it illustrates how InfluxDB 3 can transform live data into enriched operational data without external tools, as well as how to integrate InfluxDB into LLM-powered workflows.

Alerting on Real-Time Data

Each incoming batch of satellite telemetry data triggers a processing engine plugin that evaluates data, such as:

Onboard computer temperature
Reaction wheel RPMs
Power draw
Attitude status

If an anomaly is found, an alert is written to a separate InfluxDB table. The row contains all relevant information for managing an incident, both in the short term and for historical tracking. Instead of the AI agent burning tokens querying and searching raw telemetry, it works from a dedicated alert stream that preserves the signal behind the alert.

Enriching Telemetry with Third Party Data

Another way the demo uses the Processing Engine collecting NOAA planetary Kp index data with an external API call. This data is then stored in InfluxDB where operators can analyze how satellites are being impacted by external conditions and surface any correlated relationship between them.

Scheduled Processing Engine jobs help enrich operational data. Depending on your use case, this could include weather, energy prices, traffic, or financial market data. It can also calculate rollups, forecast, or downsample data at a scheduled interval.

Integrated AI Agent Using the InfluxDB 3 MCP Server

The AI agent is connected to InfluxDB via the MCP server. Rather than relying on a static prompt or blindly summarizing a dashboard, it can query recent telemetry and alerts, inspect the result, and explain its conclusion.

The UI exposes that query/tool trace so operators can see what evidence informed the answer. The agent effectively becomes an interface to your data model.

Putting the processing engine to work

InfluxDB 3’s Processing Engine runs Python inside the database and supports triggers on data writes, schedules, and HTTP requests. That allows it to do far more than simple threshold alerts. You can check the documentation for more detail on the three trigger types and how plugins can retain state between executions.

Here are a few interesting ways you can take advantage of the Processing Engine:

Trigger type	Use case	Outcome
On write	Stateful anomaly detection	Detect drift against a rolling baseline, not just a static threshold.
On write	Schema validation and enrichment	Reject or flag malformed data; add additional metadata.
On write	Alert routing	Write an alert record and then kick off an incident management workflow with related context.
Scheduled	Deadman check	Identify data sources that have stopped writing data.
Scheduled	Forecasting and error evaluation	Generate expected readings, compare them to actual behavior, and detect changes before a hard limit is crossed.
Scheduled	Data lifecycle	Downsample or export selected data.
HTTP request	Operational runbooks	Expose an API endpoint that an app can use to retrieve data or start a workflow.

If you don’t want to start from scratch building with the Processing Engine, there are a number of plugins built and supported by the InfluxDB team. Some plugin examples:

Anomaly detection
Schema validation
Notifications
Iceberg export
Integrations for Kafka, MQTT, and AMQP

The bigger opportunity is to compose these pieces. You could ingest data, validate it on write, detect drift against a baseline, write a contextual alert, enrich it with scheduled external data, and let an MCP-enabled AI agent explain the event in plain language.

Check out the demo and start building

While this demo is built specifically for satellites, the architecture is designed for any use case where time series data is used to take action and direct important decisions.

InfluxDB 3 stores the live signal. The Processing Engine detects, enriches, and routes meaningful events. The MCP server gives an AI agent a grounded way to investigate the data and show its work. Together, they turn telemetry from data teams merely collect into something they can understand and act on.

Resources

FAQs

How does the demo detect anomalies in real-time?

The InfluxDB 3 processing Engine watches incoming data as it is written and automatically generates alerts based on conditional thresholds or sensor states. This removes the need for a separate processing pipeline.

What is the InfluxDB 3 Processing Engine and what can it do beyond alerting?

The Processing Engine allows InfluxDB 3 to run custom Python code inside your database. This code can be activated by three different trigger types: data writes, schedules, or via HTTP request. Beyond threshold alerts, it can be used for schema validation, deadman checks, downsampling, data transformation, and many other use cases.

How can InfluxDB be used with an AI agent?

This demo uses the InfluxDB MCP server to connect to an AI agent, giving the LLM context directly from InfluxDB to answer questions about the current state of the satellite fleet. InfluxDB also has a CLI and REST API that can be utilized by AI agents.

Is this demo specific to satellites or can the architecture be reused elsewhere?

The architecture is designed for any use case built on time series data that is used to drive decisions. It could be used for monitoring industrial equipment, energy infrastructure, or logistics networks. The same combination of InfluxDB for storage, Processing Engine for anomaly detection and enrichment, and MCP for AI-powered investigation generalizes for all of these use cases.

What is InfluxDB 3?

InfluxDB 3 is a time series database used to store and analyze time series data for high performance workloads. It has a built-in Python VM for low latency data analysis and an MCP server for integration with AI agents.