Why We Built Flows

Are you assembling your collector config from six different component READMEs?

Are you copying a pipeline out of a blog post written four collector versions ago?

Are you finding out in production that two processors were in the wrong order?

For most teams adopting OpenTelemetry, this is what the usual setup looks like. The SDKs aren't that hard to put in and the backend is usually pretty straightforward once you've decided on which one. And all that's left is deploying the collectors. But things can quickly take a turn for the worse here. The otel contrib repo has over 240 components, each documented on its own, and almost nothing that explains which ones belong together, in what order, with which settings.

The order matters more than it looks. For example, the memory_limiter has to run first, batch has to run last, and some processors stop working without any error if you place them after a sampler. In one discussion from last year, a team's Kubernetes labels got dropped from every trace because two processors were swapped. There were no errors and nobody noticed until there was an outage and they couldn't find the correct labels to query by. It took four days to find.

So teams copy. From blog posts, from Helm charts, from a colleague's repo, from their favorite LLM. The copies are usually a few versions old, and component names have been changing this year, so a config that runs on one collector version can fail to start on another. When the OpenTelemetry project surveyed collector users in 2025, 63% named configuration management as the area that most needed improving. Ahead of stability.

Why we built Flows

We build Telflo, an OpenTelemetry-native control plane that provides centralized configuration management for collector fleets. So we talk with teams who are in the middle of this every week. The same requests kept coming up: collect from a fleet of VMs, redact PII before telemetry leaves the network, survive a backend outage without losing data, set up Kubernetes properly, run two backends side by side during a migration etc. And each time, we assembled the same pipeline from the same READMEs and explained the same gotchas.

Flows is all that work, explained, cataloged and ready to use. A Flow is a complete, working collector pipeline for one use case: the components, the order, the settings, the reasoning behind each choice, and the gotchas that otherwise surface in production. Every Flow is validated against a specific collector version, so it opens without errors. Currently, each one is built and maintained by us.

Inside the library

The library is organized by use case rather than by component. Each card maps to a use case. You can filter by signal (logs, metrics, traces) or by what you are trying to do: cost control, Kubernetes, compliance, migration, reliability. There are about a dozen Flows so far, and we are adding more soon.

A worked example: Kubernetes

Collecting from Kubernetes takes two collectors working together, so it is covered by a pair of complementary Flows designed for this specific use case. A node agent runs on every node and does the collecting and the enrichment, because the node is where the pod IP is still visible. And a gateway runs once per cluster, stamps the environment, removes/adds attributes to match your reqs, and sends everything to your backend.

The reason for the split, the selection and order of the components is a decision the otel contrib docs leave to you. In a Flow it is already made, explained and usable with one click.

How you use one

Pick the use case at telflo.com/flows. Read the page. If it is close to what you need, click "Use this flow in Telflo". The Flow opens in the editor as a working pipeline on the canvas, pinned to the latest collector version it was validated against. Every component is already configured and the only thing left for you to do is fill out the variables like the backend endpoint, API key etc.

When it does what you want, push it to your collectors. Oh and you can test it too; Telflo can run the pipeline against sample telemetry to show you exactly what comes out the other end.

Who Flows are for

Flows are for your first collector, the migration gateway or the setup you would otherwise assemble from reading the otel contrib docs. If your team already has a working config and a promotion pipeline for changes, a Flow will not teach you much. Most teams are not there yet.

The library grows as use cases come up in conversations with teams, and the next few are already drafted and releasing soon. If you run a setup you think should be a Flow, tell us about it.