InfluxData Blog - Developer

What’s New in InfluxDB 3: 5 New Processing Engine Plugins

Charles Mahler (InfluxData) — Thu, 23 Jul 2026 08:00:00 +0000

The InfluxDB team has released five new Processing Engine plugins. They range from making it easy to call a hosted ML model to pulling in stock market data in real-time. Every one of them can be activated with a few terminal commands. No external services or tools—they all run inside your existing InfluxDB instance.

Here’s what’s new, when you’d reach for them, and a few quickstart examples to get you going in minutes.

Processing Engine primer

If you aren’t familiar, the Processing Engine is an embedded Python runtime inside InfluxDB 3 that allows you to execute Python code on the following triggers:

Schedule - Run code at scheduled intervals
Data write - Runs whenever data is written to a table
Request - A custom HTTP endpoint that handles incoming requests

Plugins can query InfluxDB, transform your data, and write it back to a new table. They can also be used to hit external services outside InfluxDB.

SageMaker inference

The SageMaker plugin pulls rows of data, formats them how your SageMaker model expects, calls the model endpoint, and writes the prediction back to InfluxDB. It can build CSVs or 8 different JSON schema options, so it supports TensorFlow Serving, AWS’ built-in algorithms, and Hugging Face models.

This plugin allows you to use your deployed SageMaker models without having to create a custom plugin. Just point the plugin at your endpoint to get anomaly scores, classifications, forecasts, or whatever else your endpoint returns, and have it written directly to InfluxDB.

Example: Anomaly Scoring with Built-In AWS Model

influxdb3 install package boto3
influxdb3 install package pandas

influxdb3 create trigger \
  --database iot \
  --path "sagemaker.py" \
  --trigger-spec "every:30s" \
  --trigger-arguments 'endpoint_name=rcf-anomaly,source_measurement=metrics,feature_order={cpu}|{mem}|{rps}|{p99_ms},json_shape=instances_features,output_fields=anomaly_score=scores[*].score,interval=2min,limit=20' \
  rcf_score

With this setup, every 30 seconds the last 20 rows of metrics will get batched into a request to your Random Cut Forest endpoint. Each score comes back as a new row in the specified output table.

Value counter

This plugin is a port of the Telegraf value counter aggregator plugin. Point it at a field, and it will count how many times each unique value shows up in your data. It can be used with a data write trigger that counts as rows arrive or a scheduled trigger that aggregates the time window since it last ran. Common use cases for this plugin are HTTP status codes or log-level counts.

Chronos forecasting

The Chronos forecasting plugin allows you to use Amazon’s Chronos time series foundation models directly against your InfluxDB data. Chronos models don’t require a training step; you point the plugin at a measurement, and it returns a median forecast and prediction interval between 50% and 80%. This plugin works as a scheduled trigger for recurring forecasts and as an HTTP trigger for on-demand forecasting.

The benefit of using Chronos models is that you don’t need to mess around with training data or tuning per series. If you want to start getting forecasts on your data as soon as possible, this is the fastest path.

Example: On-Demand Forecast via HTTP

influxdb3 install package chronos-forecasting
influxdb3 install package torch

influxdb3 create trigger \
  --database mydb \
  --path chronos_forecasting.py \
  --trigger-spec "request:forecast_series" \
  chronos_forecast_http

influxdb3 enable trigger --database mydb chronos_forecast_http

curl -X POST "http://localhost:8181/api/v3/engine/forecast_series" \
  -H "Content-Type: application/json" \
  -d '{"table": "sensor_data", "field": "temperature", "horizon": 28, "context_limit": 128}'

This will return your historical context and a 28-step forecast, with each point having a median value and 50%-80% confidence bounds.

Simple data replicator

This plugin replicates data from your local InfluxDB 3 instance to a remote instance over HTTP, with built-in table/field filtering and renaming. It can be run on a schedule or on every data write. Data is buffered in a queue with automatic retries to support unreliable network connectivity.

The data replicator makes it easier to set up edge-to-cloud deployments, sync dev and staging environments, or deploy InfluxDB in multiple regions.

Example: Replicate Data on Every Write

influxdb3 install package influxdb3-python

influxdb3 create trigger \
  --database mydb \
  --trigger-spec "all_tables" \
  --plugin-filename gh:influxdata/simple_data_replicator/simple_data_replicator.py \
  --trigger-arguments host=example.com,remote_token=apiv3_token,database=remote_db,tables="home home2",unique_file_suffix=wxyz5678 \
  simple_data_replicator_trigger

influxdb3 enable trigger --database mydb simple_data_replicator_trigger

Stock portfolio tracker

With the stock portfolio tracker plugin, you can fetch live stock prices from Yahoo Finance. Define the tickers you want to track in a TOML configuration file and monitor values over time. This plugin is mostly an example of how versatile the Processing Engine is, showing how you can make external API calls, aggregate data on a schedule, and roll up your data.

Mix and match your plugins

These five plugins are just some of the most recent created by the InfluxDB team. The official plugin library already has plugins for data transformation, downsampling, anomaly detection, alerting, and more. The biggest benefit of the Processing Engine is the ability to combine these out-of-the box tools. Here is some inspiration:

SageMaker Inference + Notifier - SageMaker writes anomaly scores to InfluxDB as time series data. You can then use the Notifier plugin to send alerts to Slack, email, or a webhook if a threshold is crossed without needing a separate alert stack.
Value Counter + State Change - If you are tracking the status of something, you can use the value counter to tell you how many times a value has appeared and combine it with the state change to tell you when it changed. Together you can track frequency counts and status-change events for alerting, giving you a complementary view of the same data.
Simple data replicator + Downsampler - Downsampling your data locally before sending it to your remote InfluxDB instance will help to reduce bandwidth usage.
Simple data replicator + InfluxDB to Iceberg - This combination allows you to move hot data from InfluxDB to another instance for redundancy or regional access, and then export cold data to Iceberg for long-term storage.

All five are live now in the influxdb3_plugins repository. Grab one, wire up a trigger, and see what you can build with the InfluxDB 3 Processing Engine.

FAQs

Q: Do I need to write Python to use these plugins?

No, each plugin is ready to run after you install its dependencies with influxdb3 install package, then wire it up with influxdb3 create trigger. You only need to touch Python if you want to modify the plugin’s behavior or create a custom plugin.

Q: Do I need to write Python to use these plugins?

Q: Can I configure a plugin with a file instead of inline commands?

Yes, every plugin supports using a TOML configuration file via the config_file_path argument. Using a configuration file is recommended for setups that require more than a few parameters.

Q: Where do I see plugin errors or logs?

Every plugin writes to the system.processing_engine_logs table in the trigger’s database.

Q: Do these plugins work with all versions of InfluxDB 3?

All five run on both InfluxDB 3 Core and InfluxDB 3 Enterprise; you just need the Processing Engine enabled (--plugin-dir /path/to/plugins when you start the server).

Telegraf 1.39 Release Notes

Sven Rebhan (InfluxData) — Fri, 10 Jul 2026 08:00:00 +0000

A new feature-bearing release for Telegraf is now available:

Telegraf 1.39 — Release notes

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:

GNMI dial-out input (inputs.gnmi_listener)
- Receive GNMI dial-out telemetry data pushed by network equipment such as Nokia SR OS devices.
- Please open a feature request to request support for your devices.
- Contributed by srebhan

Important changes

Here are some changes to highlight:

OPCUA node discovery
- The OPCUA input plugins, both inputs.opcua and inputs.opcua_listener, can now be configured to discover nodes based on filtering patterns. This allows Telegraf to work in dynamic environments where nodes are added or removed on the server side.
- If configured, the plugin will browse available nodes on the server and filter them according to your settings. It will then subscribe or listen to the remaining nodes to create metrics.
- Use the browse settings to specify the root node and depth for the nodes to discover and one or more browse.paths patterns to filter the nodes found.
Oracle SQL driver support
- Use the outputs.sql plugin to stream metrics to Oracle databases.
- Custom header support for Kafka
- Set custom record headers for messages sent by outputs.kafka. The header values support templating, taking the metrics sent as input.
MongoDB custom metadata
- Set custom metadata in outputs.mongodb for the MongoDB documents written by specifying a tag subset. This allows easier and more efficient querying while keeping the full metric information.
OpenTelemetry improvements
- The outputs.opentelemetry plugin now allows using a proxy or authenticating with a token.
More system details
- The inputs.system plugin provides more details on the host system, such as DMI hardware and operating system information.
- To include this information, please opt in by adding the respective include settings in your configuration.

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.

What's New in InfluxDB and Telegraf: Q2 2026 Product Updates

Ryan Nelson (InfluxData) — Wed, 01 Jul 2026 06:00:00 +0000

Here’s everything that shipped.

Telegraf Enterprise reaches general availability

Telegraf is the open source standard for collecting telemetry from infrastructure, applications, and devices. But what happens at scale? An enterprise running thousands of agents doesn’t have one collection problem; it has thousands of slightly different configs, no single view of agent health, and no safe way to roll out changes with confidence. Today, that usually means leaning on Ansible, Puppet, Chef, or some homegrown script nobody fully trusts. We built Telegraf Enterprise to solve that.

Telegraf Enterprise reached general availability on June 24, 2026, giving teams a centralized way to manage, monitor, and support tens of thousands of Telegraf agents. It combines Telegraf Controller, a console for fleet management, with official InfluxData support. Open source Telegraf doesn’t change—teams get the same lightweight agent and 400+ official plugins. What changes is the operational layer above it: one place to see every agent’s health, standardize configurations, and roll out fleet-wide changes with confidence.

For platform teams running telemetry across hundreds of environments, that visibility is the difference between reacting to problems and operating with control.

	Telegraf Controller (free)	Telegraf Enterprise
Managed agents	Up to 100	Enterprise scale (10,000s of agents)
Configurations	Up to 20	Unlimited
Audit logging	No	Yes
LDAP/OIDC	No	Yes
Support	Community	Official support for Controller and Telegraf

The free tier is enough to evaluate Telegraf Controller. Telegraf Enterprise removes the ceiling, adds the audit trail and identity integrations that production environments need, and upgrades in place with no disruption or re-platforming.

Download Telegraf Controller or contact us about Telegraf Enterprise to get started.

InfluxDB 3.9 and 3.10 close the gap before production

Running a database at the center of your stack takes more than speed. It takes operational control: who can access it, how quickly you can recover, how easily access scales with your team, and how reliably it performs under heavy load. InfluxDB 3.9 and InfluxDB 3.10, released June 17, 2026, deliver both. 3.9 strengthened day-to-day operations; 3.10 built on top of it, advancing the performance beta.

InfluxDB 3.9 focused on day-to-day operations, the kind that matters once a database is someone’s responsibility, not just a tool they query. 3.9 came with

CLI: new flags for headless automation and data validation
Database lifecycle: background resources like triggers now clean up properly on deletion
Access control: improved visibility across permissions and product identity for Core and Enterprise builds
Performance beta (opt-in, Enterprise): optimized single-series queries, smoother resource usage under heavy compaction or ingestion, wider and sparser schema support, and automatic distinct value caching to cut metadata query latency

InfluxDB 3.10 expanded the beta with enterprise features. Most teams aren’t held up by the database engine itself when they’re ready to go live. The basics hold them up: can we back this up, can we delete what we’re not supposed to keep, can we control who has access to what. 3.10 closes those gaps, offering:

End-to-end backup and restore
Row-level deletes by time range or tag predicate
Bulk import from Parquet files or directories
Multi-user auth and RBAC (preview): built-in Admin, Auditor, and Member roles with OAuth and OIDC support, no changes to existing token-based workflows

Outside the beta, every InfluxDB 3 Enterprise deployment gets cross-database plugin queries, a new / ready endpoint that checks object store connectivity before reporting healthy, and parallel compaction to keep query nodes current under heavy ingest.

On the performance side, 3.10 improves query latency for single-series lookups, last-value fetches, and hot-data access, with a reduction in average query latency over prior InfluxDB 3 releases on workloads that hit those paths. Metadata queries like SHOW TAG VALUES see the biggest jump, thanks to automatic distinct value caching. Results are workload-dependent, as always, but the direction is consistent: the trade-offs between scale, flexibility, and performance that real-time systems have to navigate are getting smaller, and the upgrade itself requires no migration and no architecture change.

Query with SQL, InfluxQL, or Flux in InfluxDB 3 Explorer

The Explorer UI started as a place to query data and ended up able to manage schema, move data in, stream it continuously, and speak whichever query language a team already runs.

You can now create, inspect, and delete tables directly in Explorer—no API calls, no CLI—with just the UI, plus a guided import from any v1, v2, or v3 instance and a Transform Data section for renaming, converting, filtering, and downsampling on ingest.

InfluxDB 3 Explorer also learned to keep data moving. MQTT, Kafka, and AMQP streams now wire directly into databases, two new Live Data plugins write continuously, and line protocol validates itself before a single row is written.

The headline addition in InfluxDB 3 Explorer 1.9 is an AI-assisted Flux-to-SQL converter that explains its own translations line by line, so migrating off Flux doesn’t mean rewriting every query by hand. Alongside it, InfluxQL became first-class in the Data Explorer, schema commands, per-tag charts, so teams that came up on InfluxDB 1.x or 2.x don’t have to leave the UI to use the commands they already know.

Teams keep the queries, data, and workflows they already rely on, and get there faster in InfluxDB 3.

A few things people have asked us

What’s the real difference between free Telegraf Controller and Telegraf Enterprise? Mostly limits and accountability. Free caps you at 100 agents and 20 configs with no audit trail. Enterprise removes the caps and adds the audit logging, LDAP/OIDC, and Enterprise Support that a real production fleet needs.

Do I have to migrate anything to get InfluxDB 3.10? No. It’s a seamless upgrade for existing InfluxDB 3 Enterprise and Cloud Dedicated customers. No migration tooling, no architecture change.

Can Explorer actually convert my Flux queries? Yes, the Flux-to-SQL converter is available in beta. Paste in a Flux query and get back equivalent SQL, plus a line-by-line explanation of how it got there.

Is InfluxQL fully supported in InfluxDB 3 now? As of Explorer 1.9, yes. It’s a first-class language in the Data Explorer alongside SQL, including the schema-exploration commands InfluxQL veterans rely on.

Looking ahead

Some of the most important work this quarter is still in progress. If you’re testing the performance beta or trying the Flux-to-SQL converter, we’d love to hear what’s working, what isn’t, and what you’d like to see next. That feedback plays a direct role in where we go from here.

What's New in InfluxDB 3 Explorer 1.9: Flux-to-SQL Conversion, InfluxQL Support, and More

Daniel Campbell (InfluxData) — Tue, 30 Jun 2026 07:30:00 +0000

InfluxDB 3 Explorer 1.9 makes it easier to work with your existing queries. Whether you’re migrating Flux queries to SQL or you’ve been writing in InfluxQL for years, this release helps bring your existing queries forward instead of starting from scratch.

For teams moving to v3 from earlier versions of InfluxDB, query migration is often one of the last major hurdles. Explorer 1.9 introduces an AI-assisted Flux-to-SQL converter to help automate that process, while also bringing InfluxQL directly into Explorer.

On top of that, this release adds two new live sample data simulators, an improved plugin log viewer, search across every list page, and query error history.

Convert Flux queries to SQL

InfluxDB 3 uses SQL and InfluxQL to query data, but many teams still have Flux queries powering dashboards and alerts they’d rather not rewrite by hand. The new Flux-to-SQL converter (beta) does that translation for you.

You’ll find it as a new tab in the Data Explorer, right next to SQL and InfluxQL. Paste in a Flux query, click Convert to SQL, and Explorer returns the equivalent InfluxDB 3 SQL in a side-by-side Flux and SQL layout. The conversion is powered by Kapa.ai, the same AI assistant behind the Ask AI helper on our documentation site.

Here’s a typical example. Take this Flux query that reads CPU idle and derives a “busy” percentage from it:

from(bucket: "instance_monitoring")
  |> range(start: -1h)
  |> filter(fn: (r) => r._measurement == "system_cpu")
  |> filter(fn: (r) => r._field == "idle")
  |> map(fn: (r) => ({r with busy: 100.0 - r._value}))

Click Convert, and you get back SQL:

SELECT
  time,
  100.0 - idle AS busy
FROM
  system_cpu
WHERE
  time >= now() - INTERVAL '1 hour'

It isn’t a black box, either. The tool explains each conversion, walking through the translation line by line. The range() call becomes the WHERE time clause, the _measurement filter becomes the FROM table, and the _field filter narrows things to the idle field, which in InfluxDB 3 is just a native column (no pivot() needed). The Flux map() that computes busy turns into a plain expression in the SELECT list, 100.0 - idle AS busy. The panel also flags a behavioral difference worth noting: Flux’s map() keeps every existing column, while the SQL selects only time and computed busy, so if you want the original idle alongside it, add it to the SELECT list or use SELECT *. When a database is selected, you can hit Run SQL Query and execute the converted query right there.

One note: the converter is beta and AI-generated, so its output can vary. Review the converted SQL before running your queries, and use the thumbs-up and thumbs-down buttons under the explanation to help improve future conversions.

InfluxQL comes to the Data Explorer

Many InfluxDB users have years of InfluxQL muscle memory, dashboards, and tooling built around it. In Explorer 1.9, InfluxQL is now a first-class query language. There’s an InfluxQL tab right beside SQL, you can run InfluxQL directly against your databases, save and load queries as InfluxQL, and view them in your query history alongside SQL. This matters because some things are simply more natural in InfluxQL. The schema-exploration commands are the clearest case: there’s no SQL equivalent for how InfluxQL asks a measurement which tag values it has. For example:

SHOW TAG VALUES FROM "bird_tracking" WITH KEY = "species"

That returns the distinct species in the table as a tidy key/value list. The same goes for SHOW MEASUREMENTS, SHOW TAG KEYS, and SHOW FIELD KEYS, along with time series idioms like GROUP BY time(5m) fill(previous) that don’t have a one-to-one SQL counterpart. If those are part of how you work, you no longer have to leave Explorer to use them.

InfluxQL visualizations, with per-tag series

InfluxQL results aren’t stuck in a table either. You can render them as line and bar charts, and Explorer automatically groups series by tag. Take this query:

SELECT mean("speed") FROM "bird_tracking"
WHERE time > now() - 1h
GROUP BY time(1m), "species" fill(none)

It produces one line per species, color-coded with a legend, exactly as you’d expect coming from earlier versions of InfluxDB. Group by a tag, get a series per tag value; switch between line and bar without rewriting anything.

Two new live sample data simulators

In 1.8, we added a Live Data tab to the Sample Data page, with Processing Engine plugins that continuously write data into a database on a schedule, so you have something moving to build dashboards and alerts against. 1.9 adds two more to the lineup, alongside the System Metrics Collector and US Weather Sampler.

The Bird Data Simulator generates synthetic bird telemetry: a persistent flock of named birds that move on each scheduled run with sinusoidal flight speed, drifting headings, and some temperature jitter. Each run writes to a bird_tracking measurement with species, name tags, and fields like speed, heading, latitude, and longitude. Because it’s naturally multi-series across many species, it pairs well with the per-tag InfluxQL charts above, and the only settings are volume controls, so it’s hard to misconfigure.

The Signal Generator is for when you want a clean, controllable signal instead of a realistic one. It produces composable waveforms (sine, square, triangle, sawtooth, noise, and spikes), and the default preset, a slow sine with light noise and occasional spikes, is immediately useful for testing alerts and anomaly detection. It fills gaps between runs so your data stays continuous, configurable, and reliant only on the Python standard library.

As with the other live plugins, you’ll need InfluxDB 3 Core or Enterprise with the Processing Engine enabled.

Quality-of-life improvements

A release isn’t only headline features. A few smaller changes in 1.9 take some daily friction out of Explorer.

A better plugin log viewer. Logs now open in a dedicated viewer with line numbers and color-coded output, a search box for finding a specific message, level filters for Info, Warn, and Error, and an Export button. Now you can filter straight to the errors, search for the exact message, and spot why a plugin misbehaved at a glance.

Search across every list page and a smarter database selector. Manage Databases, Tables, Tokens, the Plugin Dashboard, and server configuration now have search boxes, so you can find an item by typing a few characters. The database selector is also an autocomplete picker that works the same everywhere it appears, which saves time once you have more than a handful of databases.

Query error history. The query History panel now has an Errors tab next to your query history. Every failed query is captured with a timestamp, the query language, the database it ran against, the exact query text, and the full error message. So if a query fails, you can look back at precisely what went wrong instead of trying to reconstruct it.

The SQL editor also gets a Format button that cleans up and reflows a query for readability, handy for pasted one-liners. And the plugins page gets a Run now button, so you can trigger a plugin on demand instead of waiting for its next scheduled run, good for testing before you trust it to a schedule.

Try Explorer 1.9

If you’ve been putting off migrating Flux or you’ve been missing InfluxQL in the Explorer UI, this release closes both gaps, and the new simulators give you continuously flowing data to try it all against. If you skipped the last post, What’s New in InfluxDB 3 Explorer 1.8 covers streaming subscriptions, smarter sample data, line protocol validation, and retention controls.

To update InfluxDB 3 Explorer, pull the latest Docker image: docker pull influxdata/influxdb3-ui

To learn more, check out the InfluxDB 3 Explorer documentation and the 1.9 release notes.

How Mumu Migrated From Prometheus to InfluxDB and Tripled Their Metric Coverage

Charles Mahler (InfluxData) — Thu, 25 Jun 2026 08:00:00 +0000

When a team uses an internal Slack channel for everything from contact form submissions to deployment alerts and server warnings, the notification engine quickly becomes critical infrastructure. When the same team builds that engine as a product for other teams to use, the bar gets even higher.

Mumu is an all-in-one productivity platform for modern teams. While most companies stitch together separate SaaS tools for org charts, agile estimation, internal Q&A, skill mapping, recognition, and notifications, Mumu offers all of those as connected modules under a single subscription. The premise is that your organizational structure shouldn’t be replicated across five different databases; it should live in one place and flow into every workflow your team uses.

In this blog, we will go over why the Mumu team rebuilt their monitoring stack on InfluxDB 3 and how the migration went.

Why pull-based monitoring stopped making sense

Like many teams running their own infrastructure, Mumu started off using Prometheus as its primary monitoring solution. The main problem over time was the fundamental mismatch between Prometheus’s pull-based data collection model and the type of data Mumu was working with. Rather than telemetry data that can be scraped at a regular interval, Mumu often needs to track discrete events like user triggered actions, scripts completing, and a pipeline finishing. As a result, push-based delivery for tracking events made more sense.

That architectural mismatch wasn’t the only problem. As Mumu evaluated alternatives like Betterstack, VictoriaMetrics, PostHog, Graphite, Datadog, and New Relic, issues related to transparency became a concern. Several of the SaaS solutions came with documentation that made it genuinely hard to understand what was happening under the hood, particularly around how metrics were ingested and stored. For a team that ships fast and needs to be able to debug its own pipeline, that was a dealbreaker.

Why InfluxDB 3 was the right option

Two things about InfluxDB stood out during evaluation. The first was that self-hosting was effortless. Mumu runs its own dedicated servers, and spinning up an InfluxDB 3 Core instance using the official Docker image took almost no time or configuration overhead.

The second factor was the push-based HTTP API. InfluxDB’s Line Protocol HTTP API lets Mumu’s services emit metrics at the exact line of code where an event occurred with no sidecar, no exposition format, no scrape interval, just a POST request at the moment an event happened.

In hindsight, the team’s biggest evaluation lesson was that they should have built a small proof of concept with InfluxDB earlier. The time spent evaluating other tools wasn’t wasted as it gave them context and confidence in the final decision, but InfluxDB’s simplicity would have been apparent within an afternoon.

Migration process

The migration involved three phases over a 3-month period: dual writing to InfluxDB and the existing Prometheus setup, validation, and finally, decommissioning the Prometheus infrastructure.

Phase 1: Dual-Writing via Vector

The first move was to make the same metrics flow into both systems at once. Mumu added InfluxDB as a second sink alongside Prometheus in their existing Vector pipeline, so every metric was being written to both simultaneously. That parallel run is what made the eventual cutover risk-free by allowing the team to confirm performance and validate both systems against each other.

Migrating to InfluxDB is made easy using AI agents.

About 80% of the migration work, such as Vector configuration changes, the dual-write sink setup, and the boilerplate around the new HTTP drivers in Go and TypeScript, was generated by coding agents.

A migration becomes a lot less daunting when the routine work compresses into hours, but what really made this work was what the agent had to work with on the InfluxDB side. InfluxDB 3 exposes a full REST API with a published OpenAPI specification. When an AI agent can read that contract directly, it doesn’t have to guess at parameter names from stale blog posts or hallucinate endpoint shapes from vague documentation. It reads the spec, generates correct client code, and gets the integration right on the first pass. InfluxDB also has an MCP server for integrating with AI agents, although it wasn’t used by Mumu.

This is an important property in a world where agents are doing more and more of the integration work. The systems that will be easiest to adopt over the next few years are not necessarily the ones with the most features, they’re the ones whose APIs are legible to machines.

Phase 2: Validation

Running two systems in parallel only helps if you actually compare them, and this is where the team spent its caution wisely. The validation approach was deliberately simple: they duplicated their Grafana panels side by side, with one panel pulling from Prometheus and an identical panel pulling from InfluxDB. When two panels showing the same metric look identical for weeks on end, confidence accumulates quickly.

Beyond visual parity, four things got specific attention:

Retention policies: Confirming data was being stored at the right granularity and for the expected duration.
Tag cardinality: Making sure the tagging strategy wouldn’t cause write-performance problems at scale. Keeping cardinality low on high-volume metric streams is a lesson the team internalized early.
Batch write behavior: Validating that the NestJS batching logic produced correct time series data with no gaps or duplicates.
Dashboard parity: Rebuilding key Grafana dashboards from scratch against InfluxDB to confirm they told the same story as their Prometheus equivalents.

Phase 3: Cutover

Because Mumu’s Go and TypeScript codebases already had proper abstractions and interfaces for metric delivery, writing a new driver that sent metrics to InfluxDB via the HTTP API required almost no changes to the application code. The abstraction layer in their app code meant that swapping the metrics backend was a contained, well-scoped task rather than a sprawling refactor.

The TypeScript driver came in at around 160 lines of code, largely because the team leaned on the official InfluxDB 3 client library package. The Go implementation was slightly longer due to manual HTTP handling, retry logic, and error handling, but was still a straightforward, bounded piece of work. Once the drivers were in place, the team decommissioned Prometheus for business metrics and declared the migration complete.

Benefits of InfluxDB 3—from 150 to 560 metrics

Before InfluxDB, Mumu collected around 150 metrics. Today, they collect 560 metrics, and that number is constantly increasing.

That growth didn’t come from a dedicated instrumentation initiative. There was no mandate, no quarter-long observability push, it happened organically because adding a new metric became a one-line HTTP call. When friction drops that far, engineers instrument things they would previously have skipped.

The number is less a measure of throughput than a measure of how much the team’s relationship with its own data changed once the cost of asking a question fell to nearly zero. And because metric delivery was suddenly cheap, Mumu started instrumenting things that would have seemed impractical before:

Operational automation: Mumu sends a metric for every command executed on their servers, with automations built on top using MsgGO, and certain commands automatically trigger a Slack alert. The result is passive visibility into operational activity with no manual reporting required.
CI/CD observability: They emit metrics from their Bitbucket pipelines, including how long each pipeline runs. Over time, this has established a baseline for normal build duration, making regressions easy to spot.
Per-developer environments: Every developer tags their metrics with an env field set to their local environment name, such as local:john, local:kate, and so on. Each developer can observe their own environment in Grafana, test new instrumentation locally before it ships, and build personal dashboards, all without polluting shared production data.
General script instrumentation: Bash scripts, custom CLI commands, and database migration durations during deployments are all now tracked, where before each would have demanded disproportionate effort.

SQL on time series data

Volume was not the only shift. InfluxDB 3’s SQL support meaningfully improved Mumu’s ability to build dashboards and debug metric data. Before the migration, querying time series data meant learning a specialized query language and reasoning about its particular semantics. With SQL, any engineer on the team can write an ad-hoc query to investigate a metric anomaly, validate that a new event is being tracked correctly, or prototype a Grafana panel without consulting documentation.

The qualitative win is harder to put a number on, but is equally important: the metrics are now trusted. Engineering time that used to go into questioning whether a dashboard was telling the truth now goes into acting on what it shows.

Architecture overview

Mumu runs entirely on its own dedicated servers, giving the team full control, room for hardware-level optimization, and predictable costs. The application layer runs on Docker, with services written in Go and NestJS; Go handles core infrastructure-level work while NestJS handles application layer operations.

Metrics reach InfluxDB along two paths. Vector collects and transforms log-based metrics from the server environment and forwards them to InfluxDB. The Go and NestJS services send business and application metrics directly over the HTTP API.

The tagging strategy reflects that split. Server-level and infrastructure metrics carry richer tag sets like env, container, process_name, process_instance, and service. Business and application metrics are tagged more lightly, typically just env plus a small number of domain-specific identifiers. On the NestJS side, metrics are batched and flushed either every 60 seconds or when the batch size crosses a configured threshold, which is a configuration the team continues to tune to balance data freshness against RAM usage and write overhead. Grafana sits on top of it all, querying InfluxDB directly.

Future plans for utilizing InfluxDB 3

For Mumu, InfluxDB has unlocked more than just an internal observability story. The team is now actively building toward making it a first-class part of their product surface.

The most immediate project is integrating InfluxDB as a delivery target inside MsgGO. Today, MsgGO routes messages to Slack, Telegram, Discord, Email, SMS, and Webhooks. Adding InfluxDB as a target means any system already sending events through MsgGO like contact forms, deployment notifications, server alerts, and application events, can now route structured event data directly into InfluxDB with no additional integration work. Since Mumu uses MsgGO heavily inside its own infrastructure, this would pay off immediately in its own workflows, with the customer-facing benefits coming close behind.

Further out, the team is evaluating whether to move user-activity statistics that are currently kept as activity records in a NoSQL database into InfluxDB. That data is inherently time series in nature, and putting it in InfluxDB would let them expose richer usage analytics inside the Mumu dashboard without needing a separate query infrastructure. And they want to lean on InfluxDB’s SQL interface to drive product decisions, using internal usage metrics to understand which modules see the most engagement, where users drop off, and how feature adoption shifts after a release.

Telegraf Enterprise Now Generally Available: Manage Telegraf Fleets at Scale

Scott Anderson (InfluxData) — Wed, 24 Jun 2026 06:00:00 +0000

Telegraf has become the standard for collecting telemetry across cloud, edge, and physical infrastructure. With more than five billion downloads and 400+ official plugins, Telegraf is the open source standard to connect virtually any data source to any destination.

Over the years, we’ve seen Telegraf evolve from a lightweight collection agent into a foundational part of production infrastructure. But as deployments grow, the challenge shifts from collecting telemetry to managing the systems that collect it. Large Telegraf deployments require consistent configurations across environments, clear visibility into fleet health, and safe rollout of changes to thousands of agents. Many teams rely on scripts, internal tools, and manual processes to manage this, but these approaches quickly break down as deployments scale.

Telegraf Enterprise is now generally available to address these challenges, giving teams a centralized way to manage configurations, monitor fleet health, and operate Telegraf deployments with tens of thousands of agents from a single system.

Centralized control for large Telegraf deployments

As Telegraf becomes more deeply embedded in production environments, visibility and consistency become increasingly important. Teams need to understand which agents are healthy, what configurations are running across environments, and whether changes have been deployed successfully. They also need a way to manage differences between regions, customers, and environments without creating hundreds of nearly identical configurations.

Telegraf Enterprise combines Telegraf Controller, a centralized management console for Telegraf, with official InfluxData support. Telegraf Controller provides a centralized way to manage those deployments. Teams can create and manage configurations centrally, assign them to agents, and monitor fleet health from a single interface. Configuration templates and parameter substitution make it possible to standardize shared configurations while still allowing environment-specific values where needed.

For organizations operating large Telegraf deployments, consistency is just as important as collection. Keeping configurations aligned across thousands of agents, while continuing to work with existing automation systems, can quickly become an operational challenge.

The visual configuration builder makes it easier to create and review configurations across Telegraf’s 400+ plugin ecosystem without manually authoring every line of TOML.

“We run thousands of Telegraf agents across diverse customer environments. Telegraf Controller will help us use our existing automation tools to keep agent configurations consistent and up to date across our fleet as we continue expanding our observability platform.” – Poul H. Sørensen, Senior Systems Consultant at Orange Business

Open source Telegraf remains unchanged. The agent, the plugin ecosystem, and community continue as they always have. Telegraf Controller’s free tier supports up to 20 configs and 100 agents, making it easy to get started with centralized fleet management.

What an Enterprise license buys you

As your fleet grows and more people touch your Telegraf configurations, the free tier’s limits start becoming constraints. Telegraf Enterprise removes those constraints and scales to your needs, offering:

Raised scale limits: The free version of Telegraf Controller makes it easy to get started and evaluate the product. A Telegraf Enterprise license raises the agent and configuration limits based on your licensed entitlement, allowing Telegraf Controller to grow with the size of your fleet.
Audit logging: Telegraf Enterprise records security-relevant and administrative events, including configuration changes, permission updates, agent actions, login activity, and license changes. This provides clearer operational history for troubleshooting, compliance, and security investigations.
Identity provider integration: Organizations can integrate Telegraf Enterprise with LDAP and OIDC rather than maintaining a separate user directory. For organizations using SSO or MFA through an identity provider, Telegraf Controller can integrate into that existing model.

Official support for Telegraf

Telegraf Enterprise adds an official InfluxData support path for organizations running Telegraf as part of their critical production infrastructure. Customers get support for both Telegraf Controller and the Telegraf agent, including installation, configuration, operational guidance, and troubleshooting assistance.

Upgrade in place

If you’re already running Telegraf Controller, there’s no separate Enterprise deployment or migration process. Add a valid license to your existing installation and the Enterprise capabilities unlock in place. The same deployment, agents, and configurations remain in place while additional scale, security, and support capabilities become available.

Get started

Telegraf Controller is available today with a free tier. Telegraf solved the problem of collecting telemetry from almost anywhere; Telegraf Enterprise helps teams operate that collection layer as it grows into critical infrastructure.

Download and install Telegraf Controller or contact us about Telegraf Enterprise.

Why Relational Databases Fail Satellite Telemetry

Allyson Boate (InfluxData) — Fri, 19 Jun 2026 08:00:00 +0000

Satellite operations depend on telemetry as the primary interface to systems that teams cannot directly inspect. Once a spacecraft reaches orbit, signals such as battery levels, temperature, signal strength, and fault codes become the foundation for understanding system health and maintaining control.

Telemetry streams continuously, so the underlying data system becomes a critical control point that needs to handle a constant, heavy flow of data. When that system cannot ingest, query, and manage data efficiently, dashboards lag, investigations slow, and the clarity teams rely on begins to erode.

Relational data vs. satellite telemetry

Relational data organizes information into structured records with consistent fields and defined relationships. A business application might represent customers, orders, and products as related datasets, making it easy to answer questions such as which customer placed an order or which products were included in a purchase. This relational model works well when information is relatively stable and relationships between records are clearly defined.

Satellites are dynamic systems. Operators are not tracking static records or one-time transactions, but monitoring systems that change continuously. Telemetry arrives as a stream of time-stamped measurements, or time series data. Each value depends on when the system recorded it and its change relative to earlier readings.

A single battery reading of 80% may appear normal. In isolation, it provides limited insight. If that value declined from 95% over the past hour, the same reading indicates a different condition. Operators need the sequence, rate of change, and surrounding context to determine whether a change reflects normal behavior, an emerging anomaly, or a sign of impending failure.

As telemetry volume grows, individual readings lose meaning without historical continuity. Teams need to understand how values change over time, not just what they are at one moment. As that requirement grows, relational systems show their limits.

Where relational databases start to strain

PostgreSQL- and MySQL-style databases can support early telemetry workloads, especially when teams already use them for operational data. The strain begins when a transactional, row-oriented database becomes the primary store for high-volume telemetry.

For these systems, telemetry challenges typically appear in three areas: query speed, data lifecycle management, and storage efficiency.

Speed and Query Performance

Satellite operations rely on dashboards, alerts, and analytics to maintain visibility into system health. When a subsystem begins overheating or signal strength drops during a contact window, teams need recent data immediately.

Relational databases such as PostgreSQL and MySQL can store telemetry, but they don’t optimize for high-volume time series workloads. As measurements accumulate, queries must process larger datasets, indexes expand, and the database spends more resources balancing continuous writes with analytical reads.

Slow queries affect more than latency. Delayed dashboards and alerts reduce the time teams have to detect anomalies, investigate issues, and make operational decisions. Teams may need additional infrastructure and ongoing tuning to keep systems responsive, increasing the cost of managing mission data.

Time Awareness and Data Lifecycle

Telemetry does not retain the same value over time. Recent measurements are critical for real-time monitoring, anomaly detection, and fault investigation, where operators need full-resolution data. Older data remains useful, but teams more often use it for trend analysis, reporting, and long-term performance evaluation.

PostgreSQL- and MySQL-style transactional databases do not manage this telemetry lifecycle by default. Teams can use partitions, scheduled jobs, archive tables, or custom pipelines to retain, move, or summarize older records, but those processes require separate design, maintenance and governance. Other relational systems handle historical analysis differently. Analytical databases and data warehouses can support large-scale scans and reporting, but continuous telemetry creates separate tradeoffs around ingest speed, data freshness, cost, and operational responsiveness.

For telemetry stores, lifecycle management becomes ongoing operational work. Without a clear strategy, raw measurements continue to accumulate, historical datasets grow harder to manage and queries may process more full-resolution data than operators need for long-term analysis.

Storage and Scale

Satellite telemetry generates large volumes of measurements, many of which share the same contextual information. Spacecraft identifiers, subsystem names, and sensor metadata often repeat across millions of records while only the timestamp and value change.

Telemetry schemas can also become large and sparse as missions add more sensors, subsystems, and measurement types. Not every field applies to every reading, but the database still has to store, index, and manage the growing structure around those measurements. As the number of sources and dimensions increases, data volume grows rapidly, and cardinality expands, multiplying the number of unique series the system must store.

PostgreSQL- and MySQL-style transactional databases are not optimized for this pattern. Row-oriented storage works well when each row represents a distinct transaction or operational record. Telemetry behaves differently. It repeats similar context across continuous streams of time-ordered measurements, which can make compression less efficient and increase storage overhead.

Over time, organizations may allocate more infrastructure simply to retain and manage telemetry. What begins as a manageable archive can become increasingly expensive to maintain, especially when long-term historical data remains important for analysis and mission planning.

These limitations stem from storage models designed for transactional records rather than continuous, time-ordered measurements.

Time series databases: A better fit for time-series data

Time series databases are purpose-built for data that changes over time. Instead of organizing information around static records and relationships, they structure data around timestamps, time ranges, and continuous streams of measurements.

This design matches how satellite telemetry behaves. Operators need to monitor recent readings, compare values across time windows, identify trends, and investigate anomalies using historical context. The database must support both high-ingest workloads and fast access to time-based data.

InfluxDB is a time series database built for these requirements. It provides a data layer optimized for telemetry, helping satellite teams power real-time dashboards, alerts, anomaly detection, and long-term analysis while avoiding many of the performance and scalability challenges that emerge when telemetry is stored in a relational database.

Maintaining Query Speed at Scale

InfluxDB 3 maintains query performance as telemetry volumes grow. Its architecture combines a real-time columnar engine with technologies designed for analytical workloads, helping teams retrieve and analyze large datasets efficiently.

Telemetry is stored in a columnar format, allowing queries to read only the fields they need instead of scanning entire records. Because data is organized around time, queries can focus on relevant time ranges rather than searching across the full dataset.

InfluxDB 3 also uses Apache DataFusion to power SQL queries. DataFusion applies filters early and processes data efficiently through batches, reducing the amount of information that must be scanned and moved during query execution.

For satellite operations, these optimizations help keep dashboards, alerts, and investigations responsive even as telemetry volumes increase. Teams can access recent measurements and historical trends without the growing query overhead that often affects relational systems handling large-scale time series data.

Managing Data Over Time

Telemetry does not retain the same value over time. Recent measurements are critical for real-time monitoring, anomaly detection, and fault investigation, where operators need full-resolution data. Older telemetry remains useful, but teams more often use it for trend analysis, reporting, and long-term performance evaluation.

InfluxDB supports this lifecycle through retention and downsampling. Retention policies define how long data remains available, while downsampling converts older high-frequency telemetry into lower-resolution aggregates that preserve long-term trends.

This approach helps teams manage telemetry according to how it’s actually used. Recent data can remain detailed and readily accessible for operational workflows, while historical data can be summarized to reduce storage requirements and query costs.

By automating retention and downsampling, InfluxDB reduces the need for custom cleanup scripts, archive processes, and manual data management. Teams can spend less time maintaining telemetry pipelines while keeping storage growth and query overhead under control.

Reducing Storage Overhead at Scale

Telemetry adds both fresh and repeated data. As missions add sensors, measurement types, and metadata, telemetry schemas can become large, sparse, and expensive to store. InfluxDB 3 organizes telemetry in a columnar format built on Apache Arrow and Apache Parquet, which helps store similar values together and improve compression.

This matters for satellite workloads. Spacecraft, subsystem, and sensor labels may repeat across large volumes of readings, while different measurements may rely on different fields. A storage model designed for time series data can compress repeated values and sparse data more efficiently than a transactional model that treats each reading like a separate record.

Stronger compression helps reduce storage overhead as telemetry volume and cardinality grow, allowing teams to retain historical context without carrying the full storage cost of every raw measurement, repeated label, and unused field. InfluxDB 3 also supports architectures that separate compute from storage, giving organizations more flexibility to scale storage and query resources independently as data grows.

It’s a model that helps slow the growth of storage overhead: satellite teams can keep more telemetry available for analysis while reducing the infrastructure cost of storing large, repetitive telemetry datasets.

Processing telemetry beyond storage

The value of satellite telemetry lies in understanding and responding to real-time spacecraft behavior. Operational impact comes from turning continuous streams of measurements into timely insights that help teams maintain visibility and make informed decisions with confidence.

InfluxDB is the foundation that makes that possible. By combining scalable telemetry storage with built-in processing capabilities, it helps satellite teams support real-time monitoring, accelerate analysis, and automate workflows that keep mission operations running smoothly.

Whether the goal is improving spacecraft health monitoring, reducing investigation time, scaling telemetry infrastructure, or preserving long-term mission insight, InfluxDB helps transform telemetry data into a continuous source of operational value.

2Get started with InfluxDB 3 Core OSS or InfluxDB 3 Enterprise to build a telemetry platform designed for time series workloads.

What’s New in InfluxDB 3.10: Performance Beta Expanded with New Enterprise Features

Peter Barnett (InfluxData) — Wed, 17 Jun 2026 12:00:00 +0000

In our last release, we introduced a beta of performance updates designed for heavier, more complex time series workloads. InfluxDB 3.10 expands that beta to include enterprise features that give teams more control as they scale and manage larger workloads in InfluxDB 3.

This release adds end-to-end backup and restore, row-level deletes, bulk import from Parquet, user management, and an RBAC preview to the previous performance beta. It also includes cross-database plugin queries, a new readiness endpoint, and compaction improvements for InfluxDB 3 Enterprise. Together, these updates help teams evaluate the next phase of InfluxDB 3 performance and scale with more of the operational tooling they need to manage real workloads.

We’re inviting customers to test this next phase of InfluxDB 3 performance and scale, share feedback, and help shape the path to general availability.

Expanded capabilities for the performance beta

The performance improvements we previewed in InfluxDB 3.9 continue to mature in beta. These updates are designed for teams testing heavier time series workloads, including higher ingest, wider schemas, sparse data, and more demanding recent-data queries.

The beta remains opt-in and is not yet the default, so existing deployments continue running unaffected unless teams explicitly enable it with the --use-pacha-tree flag.

Once users opt in to the beta, InfluxDB 3.10 adds operational capabilities, so teams can do more than test raw performance. They can protect data, recover from known-good states, remove bad or unnecessary rows, and bring existing Parquet datasets into InfluxDB 3 for evaluation. That matters for teams working with real production patterns, where data rarely arrives perfectly clean and workloads rarely stay fixed.

The following capabilities are available only when using the performance beta, enabled with the --use-pacha-tree flag:

End-to-end backup and restore: You can now run full backups that capture cluster state and compacted data for easy rollbacks. Restores run asynchronously, allowing you to recover data into a fresh store for disaster recovery or roll a live cluster back to an earlier point in time. We’ll soon be adding incremental restores to give you even more control over your restore points.
Row-level deletes: Teams can now remove specific rows based on time ranges or tag predicates rather than dropping entire tables when data needs to be purged. The compactor applies these changes asynchronously in the background, allowing teams to clean up production data without interrupting operations.
Bulk import from Parquet: A new bulk-import function makes it easier to bring historical or external data into InfluxDB 3. Teams can point InfluxDB at a generic Parquet file or an entire directory, use simple column mappings, and ingest each file as an independent import job.

User authentication and RBAC preview

As time series workloads become more central to production systems, access control becomes increasingly important. The same database may support operators monitoring live systems, developers building applications, analysts exploring historical data, and automated services writing or transforming telemetry.

InfluxDB 3.10 Enterprise introduces a preview of multi-user authentication and role-based access control (RBAC). This feature is turned off by default for this release.

When enabled, operators can configure traditional username and password logins that issue JWTs, or opt for external identity management through OAuth and OIDC. 3.10 also introduces built-in roles, including Admin, Auditor, and Member, to enforce proper boundaries across your teams. Best of all, your existing token workflows will continue to work exactly as they do today without any breaking changes.

General updates and improvements

InfluxDB 3.10 also includes several capabilities that work across all deployments to streamline data pipelines and improve cluster management.

Cross-Database Plugin Queries

Time series data often moves through stages: raw telemetry, cleaned data, downsampled rollups, forecasts, anomaly scores, and application-ready views. Those stages may live in different databases, but teams still need to connect them without building unnecessary external pipelines.

In 3.10, Processing Engine plugins are no longer restricted to querying their own database. Now, a plugin can query any database residing on that node. This unlocks read-from-one, write-to-another data pipelines, such as reading raw telemetry from a staging database and writing compacted rollups or machine learning forecasts to a production database.

Readiness Endpoint

Production deployments need health checks that reflect whether a node can actually serve traffic, not just whether a process is running. InfluxDB 3.10 adds a new /ready endpoint. Instead of a basic uptime check, this endpoint verifies whether the node can successfully reach its underlying object store, giving operators a more reliable signal for traffic routing.

Improved Compaction

Under heavy ingest, compaction needs to keep pace with incoming writes so query nodes can access optimized data. When compaction stalls, the path from raw writes to efficient queries slows down. InfluxDB 3.10 introduces parallel compaction, ensuring that query nodes access fully compacted data more quickly and serve queries faster.

Get started with InfluxDB 3.10

InfluxDB 3.10 is available now. To get started, download the latest version or pull the newest Docker image for Core or Enterprise.

InfluxDB 3 Core remains free and open source under MIT and Apache 2 licenses, optimized for recent data and local workloads. InfluxDB 3 Enterprise adds long-range querying, clustering, advanced security, and full operational tooling for production deployments.

Check out the docs (Core, Enterprise), try the release in your environment, and share your feedback in Discord or the Community Slack. We want your feedback as the performance beta continues to mature.

Generate Synthetic Time Series Data in InfluxDB 3

Cole Bowden (InfluxData) — Fri, 12 Jun 2026 08:00:00 +0000

Getting InfluxDB 3 up and running is a pretty lightweight process with the installation script. Getting time series data into it is the next step, and for exploration, basic testing, or scenarios where you don’t have a stream of time series data ready to write, that can be a point of friction.

That hurdle is particularly high when you want to test the rest of the system around the data you’d be writing: dashboards, alerts, replication, network connectivity, edge devices, server sizing, or Processing Engine workflows—you don’t always have the ability to start writing production data into a freshly-installed database, or you may not have that data yet.

Two new InfluxDB 3 plugins help with exactly that: the Bird Tracking Simulator and the Signal Generator. Both are scheduled plugins that generate data directly to InfluxDB 3, making it easy to start writing realistic sample data with a single trigger. The Bird Tracking Simulator creates synthetic bird telemetry, while the Signal Generator creates configurable waveform data for sensor-like or metric-like use cases.

Why generate sample data this way?

A lot of InfluxDB workflows are easier to understand once data is actively moving through the system:a dashboard is easier to build when the line and the most recent datapoint keep changing, an alert is easier to validate when values cross a threshold, edge replication is easier to test when writes are arriving continuously, and a small server or single-board computer is easier to evaluate when you can watch how it behaves under a steady stream of points.

These plugins are meant to make that first step simple. Create a database, create a trigger, and InfluxDB 3 starts generating data on a schedule. From there, you can query it, visualize it, replicate it, downsample it, or use it as input for other Processing Engine plugins.

Bird Tracking Simulator

The Bird Tracking Simulator generates a stream of synthetic bird telemetry. On its first run, it creates a persistent flock of named birds, assigns each bird a variety of tags, such as species, name, and range, and stores the flock in the Processing Engine cache. Each scheduled execution of the plugin advances the flock by updating a number of measurements, including speed, heading, latitude, and longitude, with the birds going on random walks within a predefined range for each species.

The shape of the data is useful for a few reasons. It has multiple entities, tags, and geospatial fields. It changes over time in a way that is easy to inspect visually. That makes it a good fit for testing dashboards, map panels, edge replication, and basic query patterns that group or filter by tags.

The plugin writes to the bird_tracking measurement. Its configuration is also intentionally small, specified with simple trigger arguments: bird_count controls how many persistent birds are tracked, and points_per_bird controls how many movement points each bird emits per scheduled run. The defaults are 25 birds and 1 point per bird. The number of data points the plugin generates is a simple product of these two options and the trigger specification for how often the plugin runs.

The plugin requires Faker, so install that first:

influxdb3 install package Faker

Then create a database and a scheduled trigger:

influxdb3 create database sample_data

influxdb3 create trigger \
  --database sample_data \
  --path "gh:influxdata/bird_data_simulator/bird_data_simulator.py" \
  --trigger-spec "every:10s" \
  --trigger-arguments bird_count=10,points_per_bird=10 \
  bird_tracking_demo

After the trigger has run a few times, query the generated data:

influxdb3 query \
  --database sample_data \
  "SELECT * FROM bird_tracking ORDER BY time DESC LIMIT 5"

For a denser stream, increase the flock size, increase the points per bird, or adjust the trigger interval. That gives you a simple way to create a steady stream of entity-oriented time series data. You can use it to populate dashboards, test writes across a network, or quickly confirm that a new InfluxDB 3 setup is receiving, storing, and querying data as expected.

Signal Generator

The Signal Generator achieves many of the same things, but by generating numeric signals rather than named entities. The default preset produces a signal centered around 30, with a slow sine trend, Gaussian noise, and occasional spikes. It uses only the Python standard library, supports configurable measurement names, field names, tags, and point resolution, and can compose multiple waveform types together. Supported waveform types include sine, square, triangle, sawtooth, noise, and spike.

That makes it useful for testing dashboards, threshold checks, alerting behavior, anomaly detection, and any workflow that requires a predictable yet non-static stream of numeric values. A line with trend, noise, and the occasional spike gives you something closer to the patterns you usually care about when working with time series data.

The simplest version uses the default preset:

influxdb3 create database signals

influxdb3 create trigger \
  --database signals \
  --path "gh:influxdata/signal_generator/signal_generator.py" \
  --trigger-spec "every:10s" \
  signal_basic

Once the trigger has run, query the latest generated values:

influxdb3 query \
  --database signals \
  "SELECT time, value FROM signal ORDER BY time DESC LIMIT 10"

You can also aggregate the generated signal over time:

influxdb3 query \
  --database signals \
  "SELECT
     time_bucket(time, INTERVAL '1 minute') AS minute,
     AVG(value) AS avg_value,
     MIN(value) AS min_value,
     MAX(value) AS max_value
   FROM signal
   WHERE time > now() - INTERVAL '1 hour'
   GROUP BY minute
   ORDER BY minute DESC"

For custom waveforms, the plugin can be configured with JSON arguments through InfluxDB 3 Explorer or the Processing Engine API. That lets you define signals for different measurements, fields, and tags, or stack waveforms together to create the shape you want.

For example, you might create one signal that looks like a temperature sensor, another that behaves like CPU utilization, and another that emits occasional spikes to test an alerting path. Because each trigger can have its own configuration, you can build out a small set of synthetic streams that exercise different parts of your system.

Lightweight data generation for InfluxDB 3

The Bird Tracking Simulator and Signal Generator are small plugins, but they solve a useful problem: they make it easy to get fresh time series data flowing through InfluxDB 3 with very little setup, allowing you to test your deployment and ensure data is flowing to and from every system downstream of your InfluxDB instance.

Use the Bird Tracking Simulator when you want moving, entity-oriented telemetry with tags and location fields. Use the Signal Generator when you want numeric signal data for dashboards, alerts, thresholds, and processing workflows.

Check out the plugins in the InfluxDB 3 plugin repository, try them on the hardware you already have, and use them as a quick way to exercise InfluxDB 3, the Processing Engine, and the systems connected to them.

InfluxData Blog - Developer

What’s New in InfluxDB 3: 5 New Processing Engine Plugins

Processing Engine primer

SageMaker inference

Example: Anomaly Scoring with Built-In AWS Model

Value counter

Chronos forecasting

Example: On-Demand Forecast via HTTP

Simple data replicator

Example: Replicate Data on Every Write

Stock portfolio tracker

Mix and match your plugins

Related resources

FAQs

Q: Do I need to write Python to use these plugins?

Q: Do I need to write Python to use these plugins?

Q: Can I configure a plugin with a file instead of inline commands?

Q: Where do I see plugin errors or logs?

Q: Do these plugins work with all versions of InfluxDB 3?

Telegraf 1.39 Release Notes

New plugins

Important changes

Downloads

InfluxDB University

What's New in InfluxDB and Telegraf: Q2 2026 Product Updates

Telegraf Enterprise reaches general availability

InfluxDB 3.9 and 3.10 close the gap before production

Query with SQL, InfluxQL, or Flux in InfluxDB 3 Explorer

A few things people have asked us

Looking ahead

What's New in InfluxDB 3 Explorer 1.9: Flux-to-SQL Conversion, InfluxQL Support, and More

Convert Flux queries to SQL

InfluxQL comes to the Data Explorer

InfluxQL visualizations, with per-tag series

Two new live sample data simulators

Quality-of-life improvements

Try Explorer 1.9

How Mumu Migrated From Prometheus to InfluxDB and Tripled Their Metric Coverage

Why pull-based monitoring stopped making sense

Why InfluxDB 3 was the right option

Migration process

Phase 1: Dual-Writing via Vector

Phase 2: Validation

Phase 3: Cutover

Benefits of InfluxDB 3—from 150 to 560 metrics

SQL on time series data

Architecture overview

Future plans for utilizing InfluxDB 3

Telegraf Enterprise Now Generally Available: Manage Telegraf Fleets at Scale

Centralized control for large Telegraf deployments

What an Enterprise license buys you

Official support for Telegraf

Upgrade in place

Get started

Why Relational Databases Fail Satellite Telemetry

Relational data vs. satellite telemetry

Where relational databases start to strain

Speed and Query Performance

Time Awareness and Data Lifecycle

Storage and Scale

Time series databases: A better fit for time-series data

Maintaining Query Speed at Scale

Managing Data Over Time

Reducing Storage Overhead at Scale

Processing telemetry beyond storage

What’s New in InfluxDB 3.10: Performance Beta Expanded with New Enterprise Features

Expanded capabilities for the performance beta

User authentication and RBAC preview

General updates and improvements

Cross-Database Plugin Queries

Readiness Endpoint

Improved Compaction

Get started with InfluxDB 3.10

Generate Synthetic Time Series Data in InfluxDB 3

Why generate sample data this way?

Bird Tracking Simulator

Signal Generator

Lightweight data generation for InfluxDB 3