InfluxData Blog - Developer

Data Center Telemetry in the AI Era

Charles Mahler (InfluxData) — Fri, 23 Oct 2026 08:00:00 +0000

A decade ago, a typical enterprise rack drew five to ten kilowatts and was cooled by air. Today, reference designs for liquid-cooled AI racks run up to 132 kW per rack, and a large training cluster can swing a facility’s power draw by megawatts in a few seconds. More than half of operators in Uptime Institute’s 2026 survey built or upgraded high-density space in the past year, and 70% plan to in the next year as well. The entire industry is changing as AI-focused workloads become more common.

Telemetry is how operators see what all that hardware is doing. Most data centers already collect a great deal of it. The trouble is that this data lives in different systems, at different resolutions, with different clocks, owned by different teams. In a data center running AI workloads, where a cooling problem can surface as a slow training job, that fragmentation makes problems difficult to trace. Handling this new set of problems requires a different approach and different tools.

What is data center telemetry?

Data center telemetry is the continuous, time-stamped measurement of every layer of a data center, from the utility feed to the training job. It is used for three things:

Monitoring: dashboards, threshold alerts, and on-call response
Automation: actions taken on the data, like draining an unhealthy node or flagging a rack whose coolant flow is drifting
Planning: capacity, power provisioning, forecasting, hardware replacement, and contract evidence, all built on history

It helps to think of telemetry in seven layers. The first three belong to the facility (operational technology, or OT). The last four belong to the IT stack.

Layer	Signals	Sources
Power	Utility feeds, switchgear, UPS state of charge and battery health, and PDU branch-circuit load	EPMS, power meters, SNMP, Modbus
Cooling	Supply and return temperatures, chilled water, CDU flow, pressure, leak detection, coolant conductivity	BMS, SCADA
Environment	Rack inlet temperature, humidity, differential pressure, airflow	Sensors, DCIM tools
Compute	CPU, memory, fans, power supplies, firmware events	Host agents, BMC (Redfish, IPMI)
Accelerators	GPU power, clocks, temperature, ECC errors, HBM row remapping, NVLink errors, XID events	NVIDIA DCGM
Network	Port counters, congestion, pause frames, link flaps, InfiniBand error counters	gNMI streaming, SNMP, NVIDIA UFM, NetQ
Workload	Job starts/ends, checkpoints, node drains, queue state	Slurm, Kubernetes

How AI changed data center telemetry

At AI rack power levels, air cooling stops being enough and liquid cooling becomes mandatory. That adds a new set of plumbing signals to watch like flow balance across compute trays, pressure drop across filters, coolant chemistry and hundreds of quick-disconnect fittings per rack.

In a training job, thousands of GPUs work in lockstep. They alternate between compute-heavy and communication phases, and they pause together for checkpoints. Uptime Institute describes facility-scale load steps every few seconds, with checkpoints causing steep drops that recover tens of seconds later. Bloomberg reported in August 2026 that these swings are wearing out power and cooling equipment, including batteries and generators, far sooner than expected, with spikes as high as 50% above design capacity.

At this scale, hardware failures are routine. During the Llama 3 training run, Meta’s 16,384 GPU cluster saw 419 unexpected interruptions in 54 days, roughly every three hours.

Slow hardware is even more common than failed hardware. Researchers studying clusters of more than 10,000 GPUs found that 59% of large training jobs experience “fail-slow” stragglers, with an average 34.6% longer time to completion.

Taken together, these mean the cause of a problem and its symptoms often sit in different layers. A drifting coolant loop shows up as GPU throttling, and a flapping link shows up as a slow job. Without unifying your datal, you won’t be able to find the root cause of many of the problems you are facing.

Why data center telemetry is a hard workload

Eight main challenges repeatedly come up when trying to collect data center telemetry in a way that correlates the layers..

Protocol Sprawl

A single site might use SNMP, Modbus, BACnet, Redfish, IPMI, gNMI, OPC UA, MQTT, and Prometheus endpoints. Integrators routinely chain gateways to translate between them. Every translation hop is another place for data to get lost.

High-Cardinality Data

Every GPU ID, NVLink pair, switch port, circuit, and job adds tags, and every tag combination is a separate time series. In a write-up on monitoring more than 500 GPUs, Backend.AI’s team found that a single GPU temperature metric produced 504 series, and some high-cardinality queries ran out of memory as a result.

Mismatched Resolution

Building management trends are often logged every one to 15 minutes, or only when a value changes. SNMP polling typically runs every 30 to 300 seconds. Prometheus scrapes and NVIDIA UFM’s default telemetry runs around every 30 seconds. AI power swings happen every few seconds, so a one-minute average can hide them completely.

Clock Drift

When each system stamps data with its own clock, you can’t reliably line up a coolant excursion with a GPU throttling event after the fact. SNMP makes this worse, because values are usually time-stamped when they reach the collector, which can be some time after the measurement.

Ownership of Systems

Facilities own the BMS and EPMS; IT operations own DCIM and network monitoring; the GPU platform team owns DCGM and Prometheus; ML or research teams own the scheduler and job logs. Each system has its own alerts and history, and each was designed to answer its own team’s questions. This makes it hard to integrate all these different systems from both a technical and simple access perspective.

The Backend.AI team notes that earlier research found ECC and NVLink errors were detected through CPU metrics more often than through GPU metrics. Before one NVLink failure on their own cluster, the earliest warning sign was an application task count on the affected node jumping to about 18 times its normal level. They concluded that no single metric type caught every failure, so you need coverage across layers.

Data Retention Costs

Real-time monitoring needs recent, high-resolution data. Capacity planning, warranty claims, SLA disputes, and billing need months or years of it. Prometheus-style systems are excellent at recent data, but long retention at GPU fleet cardinality usually means bolting on another tier for historical data.

Data Collection

A large data center can run thousands of collection agents across GPU nodes, BMC networks, fabric collectors, and facility gateways. Each one needs proper configuration, including credentials and a suitable polling interval. Configuration drift across a fleet of agents becomes its own source of blind spots.

Security

Facility control networks are segmented from IT for good reason. Facilities teams rarely let IT tools poll their PLCs or power meters directly, so telemetry usually comes through read-only paths like the BMS or EPMS itself, a historian, an OPC UA server, or an MQTT broker at the OT boundary.

What a good telemetry architecture looks like

Whatever tools you choose as part of your tech stack, a few principles apply:

Collect from every layer, because the cause and the symptom are often in different places. Put any data you need to correlate on one clock, in one store.
Match resolution to the signal. Collect GPU and rack power at around one second where it matters; most other signals are fine at 15 to 60 seconds.
Keep fast control local. Protective relays, UPS systems, rack power-smoothing hardware, GPU firmware, and CDU pump loops act in microseconds to milliseconds and should never depend on a database. Telemetry records what they did.
Store history in open formats, so analytics and ML teams can use it without exporting it first.
Manage collection as a fleet, with central configuration in place of hand-edited files on individual hosts.

How fast each control loop runs decides where a telemetry platform fits.

The first two tiers, protecting and stabilizing, belong to hardware and dedicated controllers. A telemetry platform supplies the history that shapes their policies, but it is not in their loop.

From seconds upward, telemetry takes over. Automation can act within seconds to minutes, for example by draining and requeueing an unhealthy node or flagging a fail-slow GPU. Over longer periods, cooling setpoint optimizers read telemetry every few minutes and recommend changes—which local control systems check before anything happens—and months of history drive capacity planning and hardware replacement.

How Telegraf and InfluxDB 3 fit into a data center telemetry architecture

Telegraf

Telegraf is an open source collection agent with more than 400 plugins. It works alongside your existing tools: it collects from the same exporters your GPU team already runs, and it reads facility data over read-only paths without polling control equipment directly. Because every source goes through the same agent, every data point arrives with consistent tags and timestamps.

These are the plugins most useful in a data center:

Layer	Telegraf plugin	Collects from	Why it matters
Accelerators	Prometheus	NVIDIA DCGM exporter, plus other exporters such as UFM's	Reuses the GPU metrics the platform team already exposes, so there is no second GPU agent to run
Accelerators	NVIDIA SMI	GPUs directly, through nvidia-smi	A simple option for smaller clusters that don't run DCGM
Compute	Redfish	Server BMCs	Health, power, temperature and fan data from the management controller, even when the operating system is down
Compute	IPMI Sensor	Older BMCs	Covers servers that predate Redfish
Network	gNMI	Ethernet switches that stream telemetry	Captures short congestion bursts and link flaps that slower polling misses
Network and power	SNMP	PDUs, UPS systems, older switches, environmental sensors	The protocol nearly all existing data center hardware speaks
Power and cooling	Modbus	Power meters and CDUs, directly or through protocol gateways	Reads the industrial devices common in electrical and mechanical rooms
Power and cooling	OPC UA	Facility systems such as the BMS or a historian	A read-only path to facility data that respects the OT network boundary
Facility	MQTT Consumer	Facility message brokers and IoT sensors	Subscribes to data the facility side already publishes
Workload	Slurm and Kubernetes	Job schedulers and clusters	Adds job and node state, so problems can be tied to the work they affect
Any layer	OpenTelemetry	Existing OpenTelemetry collectors	Brings in data from pipelines teams already run, without changing them

Telegraf can then write everything to InfluxDB 3 or another database of your choice.

Telegraf Controller: run data collection as a fleet

Telegraf Controller is a control plane for Telegraf agents. Agents pull their configurations from it, and operators get one view of the whole fleet. Configuration templates cover each layer (GPU nodes, BMC collectors, fabric collectors, and facility gateways). Staged rollouts let changes reach one rack or hall before every site, and agent health checks and drift detection catch broken or misconfigured agents before they leave a blind spot.

Telegraf Enterprise adds support for tens of thousands of agents, unlimited configurations, audit logging, LDAP/OIDC, and commercial support. The free Controller tier covers up to 100 agents and 20 configurations.

Telegraf Controller also lets you set collection resolution per rack or per job. Collecting every signal at one second is expensive. With templates and staged rollouts, you can push a one-second power and GPU profile to the racks running a large training job, or to a rack you’re investigating, and roll it back when you’re done.

InfluxDB 3

InfluxDB 3 is built for high-cardinality, high-resolution time series data, so per-GPU, per-port, per-circuit and per-job series can live together without being trimmed to fit. You query it with SQL or InfluxQL. GPU and facility data can sit in separate databases, owned by separate teams, and still be queried together.

Data is stored in object storage, which keeps long-term history inexpensive and lets lakehouse and ML tools read it directly. InfluxDB 3 can be run self-hosted, which matters for on-premises and air-gapped AI sites where SaaS monitoring isn’t an option.

The Processing Engine runs Python code inside the database, either on a schedule or as new data arrives. That makes it a natural fit for the response tier: checks and automation that need to run within seconds to minutes, next to the data.

Processing Engine feature	What it does	How it helps in a data center
Data write triggers	Runs code as soon as new data is written to a table	React to a GPU error event or a leak-sensor reading as it arrives, without waiting for the next dashboard refresh
Scheduled triggers	Runs code at a fixed interval or on a cron schedule	Compare each GPU with the others in its node every 30 seconds to catch fail-slow hardware, or produce daily health reports
HTTP request triggers	Exposes a plugin as an HTTP endpoint	Lets other tools, such as a scheduler or a runbook, ask for a node's health status on demand
Results written back as data	Plugins store their findings as new time series	Health flags can feed alerts and dashboards from one source, and an automation script can turn them into drain requests to Slurm or Kubernetes
Trigger arguments	Passes settings, such as thresholds, when a trigger is created	Tune the same check per cluster or hardware generation without changing code
Plugin Library	Ready-made plugins for common tasks such as downsampling and alerting	Get started without writing code, and downsample high-resolution data for long-term retention
Python packages	Plugins can use standard Python libraries	Use familiar statistics and anomaly-detection libraries for trend and drift checks

Data center telemetry use cases

Connecting Power Swings to Training Jobs

With power data from the GPUs up to the UPS in the same store as job and checkpoint events, you can see which jobs produce which load steps, and how often they cycle the batteries. Facilities and platform teams then have a shared, factual starting point for tuning power smoothing, power capping, checkpoint timing, or job placement.

Retiring GPUs Before They Fail

In the Llama 3 run, 30.1% of interruptions were caused by GPU faults (including NVLink) and 17.2% by HBM3 memory. Trending memory errors (ECC errors and row-remapping counts) and HBM temperature per GPU over several weeks produces a short list of devices to pull at the next maintenance window, before they take down a job running across thousands of GPUs. The same history becomes evidence for RMA (return) claims.

Catching Liquid-Cooling Drift

Liquid loops tend to degrade slowly before anything trips an alarm. Trending the worst-flowing branch, filter pressure drop, pump effort, and coolant conductivity, and alerting on rate of change rather than absolute limits, turns a surprise outage into a scheduled repair.

Settling SLA and Billing Questions

When facility and GPU timelines sit in one store, a colocation provider and its tenant can check whether a GPU slowdown started with a cooling event in the hall or inside the tenant’s own hardware. The same records help reconcile power billed per circuit with GPU usage billed per job.

Getting started with InfluxDB and Telegraf for data center telemetry workloads

Most data centers are already collecting the telemetry data they need, but it isn’t available in a way that maximizes its value. As you’ve seen in this article, Telegraf and InfluxDB 3 are valuable tools for solving a number of common problems seen in data centers. Check out the resources below to get started.

FAQ:

Why is telemetry harder in AI data centers?

AI racks draw far more power and usually need liquid cooling, which adds a new set of signals to watch. Training jobs run thousands of GPUs in lockstep, so problems spread quickly and power draw can swing sharply within seconds. At this scale, hardware failures are routine, and slow GPUs and links are more common still. As a result, the cause of a problem and its symptoms often sit in different systems.

Do I need to replace Prometheus or NVIDIA DCGM to use InfluxDB 3?

No. Many GPU platform teams already run DCGM with Prometheus, and they can keep it. Telegraf can collect from the same DCGM exporter, and InfluxDB 3 adds facility data and long-term history in the same store.

What is the difference between data center telemetry and data center monitoring?

Telemetry is the data: continuous, time-stamped measurements from power, cooling, servers, GPUs, the network, and workloads. Monitoring is one thing you do with that data, such as dashboards and alerts. The same telemetry also drives automation, like draining an unhealthy node, and planning, like deciding how much power capacity a new cluster needs.

Root Cause Analysis Workflows Using InfluxDB

Community (InfluxData) — Wed, 14 Oct 2026 08:00:00 +0000

It’s 2:00 AM, and your monitoring system fires a critical alert. Latency is spiking, and overseas users are registering internal server error complaints.

How quickly can you find the root problem? Your logs and relational databases hold plenty of data about what’s happening. But it’s difficult, if not downright impossible, to coerce that information into a timeline that will help you figure out what’s happening.

Establishing an accurate sequence of events is a key step in root cause analysis (RCA), and that’s where InfluxDB comes in. It excels at collecting, storing, and querying high-resolution, time-stamped metrics.

These abilities make InfluxDB the ideal tool for reconstructing the scene of an operational crime and finding the definitive cause of an incident. Let’s see how.

What is Root Cause Analysis?

Before we start, let’s make sure we’re all on the same page. __Root cause analysis is a structured methodology for identifying the core cause of an issue, failure, or unexpected event. __

RCA uncovers why a problem occurred in the first place, ensuring you can prevent it from happening again.

It’s not uncommon for the components in a distributed system to literally and figuratively speak different languages.

Time series data is the foundation of RCA

It’s not uncommon for the components in a distributed system to literally and figuratively speak different languages. Your API gateway might be written in Go, while you’re using an off-the-shelf authorization service that’s implemented in Node.js.

At the same time, you might have a mix of backend workers running in Python and Java. So when a critical incident strikes, they’re logging messages in different languages, using different terminology, and generating stack traces that look like they’re from different worlds.

But no matter how many dialects your services speak, they share one property you can take advantage of: time. Causality is the key to RCA. You need to prove that event A caused event B. When time is the anchor, you’re halfway there.

So how do you view events from more than one service? Use InfluxDB as your central telemetry hub. Logs tell you what happened. Traces give you part of why it happened. InfluxDB tells you when and in what sequence you can tie these‌ events together.

A Root Cause Analysis workflow

Let’s examine a four-step workflow that uses time series data and InfluxDB to perform root cause analysis.

Establish the Outage Horizon (Isolate the Timeline)

When you receive a critical alert, your first instinct might be to delve into the data. If an app generated the message, you might jump right into the code. If it came from infrastructure, you might start by examining logs and tweaking configurations.

Don’t do that.

Before you can figure out why something happened, you need to establish exactly when it started.

Identify T-0: The Exact Moment of Impact

Every incident has a definitive starting point: the millisecond the system transitioned from healthy to degraded. This is your T-0, and you identify it by looking at the metric that triggered the alert. So, in the example above, you’d be looking for the leading edge of that spike in latency.

You might be tempted to look back at the trigger for spikes in CPU utilization or disk I/O. But that’s moving the goalposts.

The event was an increase in latency, and you’re trying to identify the root cause. You may look at those metrics later, and you may learn you need to set up new alerts for them. But you’re not there yet.

First, use InfluxDB to zoom in on where the trend abruptly changes direction. That exact second or millisecond is an anchor point.

Whatever caused the problem must have occurred at, or immediately before, this timestamp. Any event, error, or metric shift after T-0 is a symptom, not a trigger.

*Alt text: A sudden spike in latency doesn’t mean much unless you can contrast it with what was normal before the problem. *

Define Your Window

After you’ve identified T-0, add some context. A sudden spike in latency doesn’t mean much unless you can contrast it against what was normal before the problem occurred.

So, establish your investigation window by zooming out and capturing thirty to sixty minutes of data before T-0.

This window represents your baseline. By framing your InfluxDB queries to include this buffer, you map out the contrast between a healthy system and a failing one. You’re looking for clues that started before the problem.

So, now it’s time to look at those other metrics.

Was CPU utilization creeping up before the crash?
Did database response times start spiking prior to the alert?
Is there a deployment or feature-flag toggle leading up to the event?

This takes us to the next step.

Correlate the Four Golden Signals

Now that you’ve defined your window, you can overlay latency, traffic, errors, and saturation to see how they interact. Here’s where InfluxDB shines: you can use queries to stack these metrics on a single time axis.

Aligning them makes it easy to see, for example, if a spike in traffic caused an increase in saturation or if saturation climbed while traffic stayed completely flat.

Let’s look at a pair of examples.

First, let’s use a SQL query to map user impact. It will place average query latency and error count next to each other during the event window.

SELECT time, 
avg("duration_ms") AS avg_latency, 
count("error_code") AS error_count 
FROM "application_source_events" 
WHERE time BETWEEN '2026-07-05T13:15:00Z' AND '2026-07-05T14:15:00Z' GROUP BY time(1s)

Next, you can query your concurrency and system metrics over the same window.

SELECT time, 
count("request_id") AS requests_per_sec, 
avg("cpu_percentage") AS cpu_util, 
avg("pool_active_connections") AS active_db_conns 
FROM "system_telemetry" WHERE time BETWEEN '2026-07-05T13:15:00Z' AND '2026-07-05T14:15:00Z' GROUP BY time(1s)

If you stack these queries, you can check for an intersection at T-0:

Traffic Spike + High Saturation = Capacity Problem. Did your systems run out of memory, I/O capacity, or headroom for threads?
Flat Traffic + High Saturation = Resource Leak. Something, such as a task, an unoptimized query, or a memory leak, is consuming excess resources.
Flat Traffic + Low Saturation + High Latency = Blocking. This points to an issue that will require more sleuthing. The application is idling, likely because it’s waiting on an external dependency, like a locked database row or an API request that isn’t responding.

Drill Down

Those two queries already told us a lot, but InfluxDB is capable of more. You’ve identified which signal caused the issue, but it’s only an average. Now it’s time to find the real culprit.

InfluxDB’s multi-dimensional tag system tells you where a specific data stream is coming from. And Influx indexes these tags, so you can group, filter, and pivot telemetry to drill down to exactly where your problem started.

The fastest way to isolate the culprit is to split your failing metric across logical infrastructure boundaries. If your API latency spikes, you need to know if the failure is systemic or isolated.

Here’s a query that groups metrics by container:

SELECT time,
avg("duration_ms") AS metric_value 
FROM "application_source_events" WHERE time BETWEEN '2026-07-05T13:15:00Z' AND '2026-07-05T14:15:00Z' GROUP BY time(10s), "container_id"Identify the "Smoking Gun"

You’ve isolated your timeline, correlated the signals, and used InfluxDB’s tags to isolate the issue. Now for the last step: finding the exact data point that proves causality.

When you’re waist-high in the proverbial weeds, it’s easy to mistake an outlying metric for the true cause. To prove that event A caused B, your data needs to satisfy these conditions:

Precedence: The root cause must occur before or exactly at T-0. If it shifted even a few milliseconds later, it’s a symptom.
Proportionality: The severity of the outage reacts in proportion to the intensity of the root cause.

One way to ensure you satisfy these requirements is to look at the delta before the incident occurred. You can do this with an InfluxDB query, too.

Let’s graph the derivative of active database connections so we can view it alongside the error rate.

SELECT time, 
derivative("pool_active_connections", 1s) AS connection_change_rate 
FROM "system_telemetry" WHERE time BETWEEN '2026-07-05T13:45:00Z' AND '2026-07-05T14:15:00Z' GROUP BY time(1s)

If the rate of new connections accelerated sharply before T-0 and stayed high until and through T-0, you have your smoking gun.

Moving from reactive to proactive

Root cause analysis doesn’t have to feel like searching for a needle in a haystack. We’ve covered a four-step process that shows you how, treating time as your primary anchor and leveraging InfluxDB’s sophisticated queries, you can systematically perform root cause analysis.

Explore how InfluxDB helps teams collect, analyze, and correlate time series data to accelerate root cause analysis across infrastructure, applications, industrial systems, and IoT environments.

FAQS:

How do I choose between using InfluxDB metrics and application logs during an active incident?

Use InfluxDB to pinpoint your T-0, establish a timeline, and narrow down where the trouble is beginning. Use your application logs to troubleshoot individual components once you’ve identified them as the root cause.

What is the impact of querying high-resolution data during a major production outage?

Because InfluxDB is optimized for time series data and its native tags, it’s incredibly fast and lightweight. To minimize database load during production hours, be sure to use a strict time boundary in your queries.

3. How do I differentiate between a symptom and the actual root cause if multiple metrics spike at T-0?

Use InfluxDB’s math functions as a mechanism for an empirical test. You can calculate the rate of change using the derivative() function for the competing metrics. Your root cause will show a sharp increase before the incident, while the symptoms will follow.

Why Automotive Manufacturers Are Augmenting Data Historians, Not Replacing Them

Ryan Nelson (InfluxData) — Mon, 05 Oct 2026 08:00:00 +0000

A modern vehicle assembly line generates more time-stamped telemetry before lunch than most data historians were built to hold: weld temperatures, torque readings, and vibration traces from every robot, torque tool, vision system, and test stand, and on most historians, each signal carries its own line-item cost because the systems are still priced per tag. That model was fine when data was scarce; it breaks down as OEMs and Tier 1 and Tier 2 suppliers add sensors, stations, and higher sampling rates every year, turning instrumentation into a budgeting exercise before it becomes a visibility gain.

The instinct is to rip out the historian and start over. On a validated, IATF 16949-certified production line, that’s rarely realistic: historians from vendors like OSI PI/AVEVA, Wonderware, GE, and Honeywell are wired into SCADA systems, PLCs, robot controllers, and distributed control systems that keep the line running, and replacing that layer risks a stoppage that cascades into missed takt, JIT penalties, and downstream OEM shutdowns within hours. InfluxDB, a purpose-built time series platform, takes a more pragmatic path: augmenting the historian instead of replacing it.

Why data historians are hitting a wall in Industry 4.0

Data historians were built for Industry 3.0: one plant, one shift pattern, one set of tags, running on-premises with modest data volumes. They’re still good at that job. What they weren’t built for is Industry 4.0, where interconnected devices, IIoT sensors, and cloud-native systems generate volume, variety, and velocity of telemetry that legacy architectures never had to handle.

Three problems show up consistently as manufacturers try to close that gap.

Vendor lock-in. Historians are proprietary and tightly controlled by their vendors. Licensing, upgrades, and even adding a tag for a new robot sensor or launch program often require vendor involvement, which locks plants into a single roadmap at a time when margins are already under tariff and EV-transition pressure.

Scalability and cost. Historians can often handle a surprising volume of tags within a single plant. The real limit is cost, not raw capacity. Adding hundreds of robots, weld guns, and sensors across a modern line means more hardware and more per-tag licensing, and that compounds further at multi-plant scale, where consolidating data across sites becomes both harder and more expensive than adding capacity within one plant.

Real-time limitations. Legacy historians weren’t designed for predictive models or AI/ML workloads on high-frequency signals like torque, weld current, or robot vibration. Pulling that data out usually means batch exports or custom connectors, which delay insight and lead to avoidable downtime. In an assembly environment running on takt time measured in seconds, even a small lag can mean a missed beat, stalled production, or overtime.

Ingest, cardinality, and query range at Industry 4.0 scale

At Industry 4.0 data volumes, three things decide whether a platform can keep up: how much it can ingest without slowing down, how much metadata per time series is collected, and how far back it can query without switching to a separate system. A time series platform built specifically for this workload, like InfluxDB, is engineered to process millions of data points per second from diverse sources without performance degradation, using indexing that holds up as cardinality grows into the millions.

Characteristic	Data historian	Time series platform
Ingest volume	Thousands of points/second from fixed sources; can be overwhelmed by modern telemetry	Millions of data points per second from diverse sources, no performance degradation
Cardinality	Performance degrades as unique tags grow	Advanced indexing built for millions of unique time series
Query range	Fast on recent data; long-term history is slow or needs a separate system	Real-time and historical data unified for queries across any time range
Interoperability	Proprietary, closed; requires custom connectors	Open standards and APIs (SQL, REST, Python, Grafana, Power BI)
Cost model	Per-tag licensing	Compute-based, no per-tag penalty

Interoperability matters just as much as raw throughput: a platform that plugs directly into the tools industrial teams already use, like Grafana, Power BI, Python, and AI/ML pipelines, avoids the expensive custom connectors historians are known for. InfluxDB is built on open standards and APIs for exactly that reason.

How InfluxDB augments a data historian

InfluxDB’s role isn’t to take over what the historian already does well. It’s to take on what the historian was never designed to handle, while the historian keeps running SCADA historization, GxP and regulatory data, and the operator dashboards teams already trust.

There are two common ways manufacturers deploy InfluxDB alongside a historian.

Parallel feed. New instrumentation, robots, stations, and launch programs get routed to InfluxDB instead of adding to the historian’s tag count. Telegraf, InfluxData’s open source data collection agent with plugins for OPC-UA, MQTT, and Modbus (the same protocols already used to talk to robot controllers and weld cells), streams that data into InfluxDB with little to no latency. The historian stays in the system of record; InfluxDB handles the dashboards, anomaly detection on weld and torque signatures, and predictive maintenance work that would otherwise wait on the historian’s licensing terms.

Consolidation. Many OEMs and Tier 1 suppliers run several historians, sometimes one per plant, sometimes one per acquired site, that weren’t built to talk to each other. InfluxDB sits downstream of those systems as a central operational layer, unifying siloed feeds into a single source of truth that Grafana or a similar visualization tool can present as one dashboard, shortening launch reviews, quality audits, and warranty investigations that currently require reconciling conflicting data across plants.

For plants running a wider mix of PLCs, CNCs, and proprietary equipment than Telegraf’s protocol plugins cover on their own, InfluxData partners with Litmus, an industrial data operations platform with 250+ prebuilt connectors for OT systems like PLCs, SCADA, and CNC machines. Litmus normalizes and contextualizes raw machine signals at the edge, tagging them with asset, facility, and production-line metadata, while InfluxDB handles ingestion, real-time analysis, and long-term storage of that contextualized telemetry, locally at the plant and replicated to a central hub for fleet-wide visibility.

Automotive and industrial manufacturers already running InfluxDB

A few companies already running InfluxDB at automotive scale show what historian augmentation delivers in practice.

Toyo Tires replaced a manual system for quality control and anomaly detection that couldn’t reliably catch defective tires before they left the line, or support the 20-year data retention its audit requirements demand. With InfluxDB Enterprise, Toyo now runs real-time and long-term analysis for quality issues cost-effectively, and has scaled from a single plant in Serbia monitoring 100 machines to as many as 1,000 machines across multiple locations.

American Axle & Manufacturing, a Tier 1 automotive and mobility supplier with nearly 85 facilities in 18 countries, runs the TIG stack (Telegraf, InfluxDB, and Grafana) across its enterprise data infrastructure, including monitoring 78 file servers at remote manufacturing sites and database performance alerting. “The combination of Grafana, InfluxDB, and Telegraf is a winning one,” said Stewart McKenna, Systems Administrator at AAM. “It’s really easy to come up with use cases, and the ease of displaying the data to leadership is wonderful.”

Getting started doesn’t require a disruptive overhaul: route new telemetry, one line, one plant, or one launch program at a time to InfluxDB instead of the historian’s tag count, and expand once that pilot proves the case. InfluxData’s full guide, Scaling Time Series for Automotive Manufacturing, covers deployment architectures and a step-by-step path for scaling across a plant network. Manufacturers ready to test it against their own telemetry can request a proof of concept with InfluxData.

Frequently asked questions

How is InfluxDB different from a data historian?

InfluxDB is engineered to ingest millions of data points per second from diverse sources, support unlimited cardinality as sensor counts grow, and unify real-time and historical queries in one system. Data historians are typically limited to thousands of points per second from fixed sources, are priced per tag, and often require a separate system for long-term historical analysis.

Does augmenting a historian with InfluxDB put IATF 16949 or GxP validation at risk?

No. In an augmentation deployment, InfluxDB sits downstream of the historian and picks up new telemetry, like added sensors, robots, or launch-program data, without disrupting the existing workflows. The validated historian, SCADA, and control systems that keep the line running continue operating exactly as they are, and GxP and other regulatory data stay on the historian, so certification and compliance workflows aren't touched.

How does data get from plant floor equipment into InfluxDB?

Telegraf, InfluxData's open source data collection agent, connects to plant-floor protocols like OPC-UA, MQTT, and Modbus (the same protocols used by robot controllers and weld cells) and streams that telemetry into InfluxDB with little to no latency. For plants running a wider mix of PLCs, CNCs, and proprietary OT systems, Litmus extends that coverage with 250+ prebuilt connectors, normalizing and contextualizing machine signals at the edge before InfluxDB ingests them.

How does data get from plant floor equipment into InfluxDB?

Does getting started require migrating existing historical data out of the historian?

No. Augmentation is forward-looking: new telemetry, from added sensors, robots, or a launch program, gets routed to InfluxDB going forward, while the historian keeps its existing history and continues serving lookups against older data. There's no migration project required to start, which is what makes a single-line pilot realistic before committing to a wider rollout.

What’s New in InfluxDB 3.12: Distributed Compaction, 3x Faster Imports, and More Control

Peter Barnett (InfluxData) — Thu, 01 Oct 2026 08:20:00 +0000

Time series deployments rarely grow the way they were planned. A single-node pilot becomes a multi-node fleet, an afternoon’s worth of test data becomes weeks of backfill that has to land before anyone can query it, and three teams end up writing to a database built for one.

InfluxDB 3.11 delivered a higher-performance foundation for complex time series workloads, with significant performance improvements for single-series queries, schemas that could go wide and sparse without breaking, and a much more predictable resource profile.

For InfluxDB 3 Enterprise, 3.12 builds on that foundation with more ways to scale operations around those workloads. Bulk imports make better use of available CPU, compaction can now scale across nodes, and schema enforcement gives teams more control over shared production datasets.

The common thread is simple: as the workload grows, more of the system can grow with it.

Bulk import, now 3x faster

Historical data isn’t useful until it’s queryable. When you’re migrating to InfluxDB or backfilling months of history, import speed decides how soon that data sits alongside your live data, whether that’s by lunch or next week.

InfluxDB 3.12 makes bulk import from Parquet roughly three times faster. Imports now run in parallel, so they scale with the hardware you give them. In testing, import time fell by 64-70 percent across workloads.

Imports are also easier to lock down. Bulk import no longer requires an admin token. It now authorizes against write permission on the target database, so the credential running a backfill only needs access to the data it’s loading.

Distributed compaction, now in beta

Compaction keeps queries fast by organizing newly written data into efficient files in the background. At high ingest volumes, though, that background work can become the bottleneck: compaction falls behind, and the only fix is a bigger machine.

InfluxDB 3.12 removes that ceiling. With distributed compaction, now in beta, compaction becomes something you can scale horizontally. When compaction needs more capacity, add nodes running in compact mode, and the coordinating node spreads jobs across them. If a compact node drops out mid-job, the work is simply reassigned in the next scheduling cycle.

Distributed compaction is off by default, so existing deployments behave exactly as they do today. When you’re ready to scale past a single compactor, you can turn it on.

Schema enforcement, per database

Schema-on-write is one of the things that makes InfluxDB easy to start with: send data, and the schema takes shape around it. But in a production database shared by several applications, that flexibility cuts both ways. A typo in a field name or an unexpected column from one service quietly becomes part of the schema, and every team querying that database has to work around it.

InfluxDB 3.12 lets you lock the schema down where it matters. Define the schema when you create a database, and writes that introduce undefined columns are rejected instead of changing the schema. Bad data gets caught at write time, before it reaches dashboards, queries, or downstream consumers.

Schema-on-write remains the default, so you can enforce schemas on the databases that production depends on and keep exploratory databases as flexible as ever.

More control in the Explorer UI

The Explorer UI has a set of updates to keep pace with the teams using it.

InfluxDB 3.12 makes role-based access control generally available in InfluxDB 3 Enterprise, so teams can manage access by user and role instead of tracking individual tokens. Users can sign in with a token, a password, or SSO, and using Explorer, admins can manage users and their roles from the same place they query.

Explorer also adds six visualization types: area, single stat, gauge, pie, scatter, and ranking. Explain in SQL shows what a query is doing, which makes it easier to check before you rely on it. New deployments also start with Explorer preconfigured, so the first query doesn’t wait on connection parameters.

Other improvements in InfluxDB 3 Enterprise

The Processing Engine can now run as a separate process, so teams can deploy custom Python plugins without worrying about them affecting database stability.
InfluxDB 3 Core and Enterprise now run on Apache DataFusion 52, picking up another round of query performance improvements across joins, CASE expressions, and query planning.

Upgrading a multi-node deployment?

InfluxDB 3.12 has new requirements for node roles and upgrade order. Review the release notes before upgrading.

Get started with InfluxDB 3.12

With 3.12, more of InfluxDB scales with your workloads. Compaction can scale horizontally, imports get faster as you add cores, and production schemas no longer have to evolve by accident.

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

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.