InfluxData

Material Event filed 2026-09-18

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 numb

Material Event filed 2026-09-11

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 t

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 -

When people hear that the average breach lifecycle still spans hundreds of days , they often blame inefficiency or apathy. The reality is that most teams, especially those in SMBs, are flying blind and relying on logs scattered across dozens of SaaS platforms. The information needed to understand a breach is there, but it often sits behind paywalls or is delivered without enough context to form a coherent picture. When security events are modeled as time series, they form a continuous stream of behavior rather than isolated snapshots. File downloads, admin actions, and authentication attempts shift from static snapshots to dynamic patterns. Once everything is tracked as a sequence over time, the early signs of trouble become visible far earlier than the consequences do. Digital Supply Chain Observability That realization wasn’t theoretical for us. A few years ago, a third-party tool in our pipeline was compromised, and the SaaS didn’t detect it—one of the SaaS’s other customers did. By

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 inst

Annual Report filed 2026-08-20

Material Event filed 2026-08-20

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 r

Time series data shows up wherever the physical world meets software. A satellite constellation streams altitude, power, and thermal telemetry from every spacecraft on every pass. A factory floor running on Industry 4.0 principles instruments every line, every motor, every batch. And underneath all of it sits a humbler problem that anyone who has worked in operational technology knows well: getting telemetry out of the PLCs and edge controllers that actually run the machines, off the bus, and into a database that can enable real-time asset intelligence. InfluxDB 3 is built for this class of workload. It is the latest generation of the InfluxDB time series engine, built on an open source stack: Apache Arrow for in-memory columnar data and Apache DataFusion as the query engine. In practice, that means InfluxDB 3 is a columnar, vectorized engine that speaks SQL, exchanges data over Arrow Flight, and interoperates with the broader Arrow ecosystem, rather than a closed world with its own be