Introduction
What Telflo is, the problem it solves, and who it's for.
Telflo is a control plane for OpenTelemetry (OTel) Collector configuration. It covers the full lifecycle of a collector config: you build it, test what it does, publish it as a version, and manage it across a fleet of collectors.
Two properties define how Telflo works:
- Standard configuration. Telflo produces standard OpenTelemetry Collector YAML. There is no proprietary format in between and no separate agent or distribution to install. A configuration built in Telflo is one you could have written by hand.
- Out of the data path. Telemetry flows directly from your collectors to your backend, as it does today. Telflo manages the configuration that produces the telemetry, not the telemetry itself.
The problem
The OpenTelemetry Collector receives, processes, and exports telemetry, and it is configured in YAML. A configuration defines an ordered pipeline: telemetry enters through receivers, passes through a chain of processors, and leaves through exporters. The order of the processors is the order of operations. For example, the memory_limiter processor must be first to be effective, and the batch processor must come after any sampling so that dropped telemetry is not batched. These mistakes are not reported as syntax errors.
Validation confirms that a configuration is well-formed. It does not show what the configuration does to a real span, metric, or log line. A redaction rule, a sampling rate, or a dropped attribute is confirmed only after the configuration runs in production and the output is checked at the destination.
The problem grows with scale. A single collector is one file. A fleet of collectors across clusters and regions has no single view of which configuration each one runs, no controlled rollout, and no straightforward rollback, and configurations drift as changes are applied by hand. Telemetry volume also increases over time, and most backends bill on ingest, so teams filter, sample, and route telemetry in the collector to control cost. Each of those edits changes what downstream dashboards and alerts receive.
What Telflo does
| Capability | Description |
|---|---|
| Build | Add receivers, processors, exporters, connectors, and extensions to a canvas and configure them with forms. Telflo generates the Collector YAML, and you can edit the YAML directly. See Build. |
| Visualize | Each signal path is laid out and color-coded, so you can follow data from source to backend without reading YAML. See Canvas & pipelines. |
| Validate | Telflo validates the configuration against the real collector binary for the version you target, and reports what the target environment must provide. See Validation. |
| Test | Run sample telemetry through the pipeline on a real collector, inspect the output, and save checks that a run must pass. See Testing. |
| Publish | Save versions and mark a version as a release that can be deployed. See Versions & publishing. |
| Deploy and monitor | Push a published version to a fleet of collectors, track instance status, and detect drift. See Fleet management. |
| AI assistant | Plan a pipeline, generate or modify a configuration, and answer OpenTelemetry questions from a chat panel in the editor. See AI assistant. |
Components
OpenTelemetry Collector pipelines are built from five kinds of components. Telflo enforces how they connect.
| Component | Role | Connections |
|---|---|---|
| Receiver | Receives telemetry from a source | Outgoing only |
| Processor | Transforms telemetry in flight | Incoming and outgoing |
| Exporter | Sends telemetry to a destination | Incoming only |
| Connector | Links one pipeline to another, as the exporter of one and the receiver of the next | Both, across pipelines |
| Extension | Adds capabilities outside the data path, such as health checks | None |
A pipeline connects receivers, processors, and exporters for one signal type: traces, metrics, or logs. A configuration can contain multiple pipelines. For definitions of the remaining terms, see Key concepts.
Who it's for
Telflo is for the platform engineers, observability teams, and SREs who author OpenTelemetry Collector configurations and operate them across many collectors.