Telflo Docs

The component library: receivers, processors, exporters, connectors, and extensions.

OpenTelemetry Collector pipelines are built from five kinds of components. Each has its own role and connection rules.

ReceiverProcessorExporterConnectorExtension

Type	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	Joins two pipelines, as the exporter of one and the receiver of the next	Both, across pipelines
Extension	Adds capabilities outside the data path	None

To add a component, drag it from the palette onto the canvas. The palette is grouped by type, and each component is color-coded on the canvas.

The available components depend on the configuration's collector distribution, and the components and their fields depend on the collector version selected in the toolbar. The following lists cover the palette for OpenTelemetry Collector Contrib.

Receivers

Receiver	Description
`otlp`	OTLP over gRPC or HTTP. The most common entry point.
`prometheus`	Scrape Prometheus metrics endpoints.
`datadog`	Receive telemetry from Datadog agents.
`docker_stats`	Container CPU, memory, network, and block I/O metrics from the Docker daemon's stats API. Metrics pipelines only, Linux only; the collector needs read access to the Docker socket.
`filelog`	Tail and parse log files. A collector that runs in a container sees only mounted paths: a server fleet's deploy group dialog lists the directories the receiver's `include` and `exclude` paths point at under Read/write paths, and a Kubernetes supervisor fleet's under This config references paths with no matching volume mount, so you can add a read-only volume mount for each. See Volume mounts.
`fluentforward`	Receive logs from Fluent Bit and Fluentd `forward` outputs over TCP or a Unix socket. Logs pipelines only; TLS and the Forward handshake are not supported.
`hostmetrics`	Host system metrics, such as CPU, memory, disk, and network.
`jaeger`	Jaeger traces in the legacy Jaeger formats: gRPC, Thrift over HTTP, and Thrift compact or Thrift binary over UDP. gRPC, Thrift HTTP, and Thrift compact are enabled by default.
`journald`	Read the systemd journal as log records. Linux only; the collector needs the `journalctl` binary and read access to the journal.
`zipkin`	Zipkin trace spans.
`k8s_cluster`	Kubernetes cluster-level metrics.
`k8s_events`	Kubernetes events.
`k8sobjects`	Kubernetes object state.
`kubeletstats`	Kubelet and container metrics.
`netflow`	Network flow data.
`syslog`	Syslog messages.
`statsd`	StatsD metrics.

Processors

Processor	Description
`batch`	Batch telemetry before export. Telflo recommends it on most pipelines to reduce export calls.
`memory_limiter`	Limit collector memory use. Place it first when used.
`resource`	Add or modify resource attributes.
`attributes`	Add, update, or remove attributes on spans, data points, or logs.
`filter`	Drop telemetry that matches a condition.
`probabilistic_sampler`	Head-based sampling at a fixed rate.
`tail_sampling`	Policy-based trace sampling after spans complete.
`k8sattributes`	Enrich telemetry with Kubernetes metadata.
`redaction`	Remove or mask attribute values.
`cumulativetodelta`	Convert cumulative metrics to delta.
`resourcedetection`	Detect resource attributes from the host and cloud environment.
`transform`	Apply OTTL statements to telemetry.
`logdedup`	Aggregate identical log records within an interval and emit one record with a duplicate count. Logs pipelines only.
`span`	Rename spans from attribute values, extract attributes from span names with regex capture groups, or override span status. Traces pipelines only.
`groupbyattrs`	Regroup spans, metrics, and logs into resources keyed by the listed attribute values; with no keys, compact records that share a resource. Pair it with `batch`.
`metricstransform`	Rename metrics, add or rename labels, scale values, and aggregate across labels or label values, within a batch only. Metrics pipelines only.

Exporters

Exporter	Description
`otlp`	OTLP over gRPC. The most common destination.
`otlphttp`	OTLP over HTTP.
`datadog`	Send traces, metrics, and logs to Datadog.
`prometheus`	Expose pipeline metrics at a `/metrics` endpoint for a Prometheus server to scrape. Pull-based; metrics pipelines only.
`prometheusremotewrite`	Push metrics to a Prometheus remote-write endpoint, such as Prometheus, Cortex, Mimir, Thanos, or ClickStack. Metrics pipelines only. TLS is required by default, so a plain `http://` endpoint needs Disable TLS.
`loadbalancing`	Distribute telemetry across backend endpoints.
`zipkin`	Send trace spans to a Zipkin backend.
`clickhouse`	Send traces, metrics, and logs to ClickHouse tables. ClickHouse performs best with large batched inserts; keep async inserts on or add a `batch` processor upstream.
`debug`	Print telemetry to the collector console.
`file`	Write telemetry to a file.

Connectors

A connector is both an exporter and a receiver. It consumes telemetry at the end of one pipeline and emits telemetry into another, and it can change the signal type in between.

Connector	Description
`spanmetrics`	Generate request, error, and duration (RED) metrics from spans.
`forward`	Forward telemetry of the same signal type between pipelines: merge several pipelines into one, or fan one out into many. The input and output signal types must match, and it has no configuration.
`routing`	Route telemetry to different pipelines of the same signal type with an ordered table of OTTL conditions, for example by tenant, environment, or severity. Telemetry that matches no route goes to the default pipelines, or is dropped when none are set. The input and output signal types must match. Target and default pipelines are chosen in the connector's configuration rather than drawn as edges; the canvas shows them as dashed route edges. See Canvas & pipelines.

Extensions

Extensions add capabilities that are not part of a pipeline.

Extension	Description
`health_check`	Expose an HTTP health endpoint.
`pprof`	Expose a performance-profiling endpoint.
`zpages`	Expose in-process debug pages.
`file_storage`	Persist state to disk, such as file offsets and sending queues. On a container install, its directory needs a writable volume mount, or the checkpoints are lost when the container restarts; a server fleet's deploy group dialog lists the directory under Read/write paths, and a Kubernetes supervisor fleet's under This config references paths with no matching volume mount. See Volume mounts.
`opamp`	Connect the collector to an OpAMP server for remote management over WebSocket or HTTP polling. Reports the effective configuration and health, and can accept restart commands.
`memory_limiter`	The same limits as the `memory_limiter` processor, applied before requests are decoded. Not in the stock Contrib distribution, so validation against Contrib reports it as unknown; ClickStack includes it.
`bearertokenauth`	A static bearer-token authenticator, referenced from a receiver or exporter as `auth.authenticator: bearertokenauth`. Takes a token, a token list, or a token file.
`oidc`	Verify incoming bearer JWTs against one or more OIDC providers, matched by issuer, referenced from a receiver as `auth.authenticator: oidc`.

Collector distributions

A configuration's collector distribution is chosen when the configuration is created and decides which components the palette offers. A configuration on OpenTelemetry Collector Contrib, the default, offers the full palette above. A ClickStack configuration, available in private preview, offers only the components the ClickStack collector ships and hides the rest. On ClickStack 2.36.0 that is the otlp, prometheus, datadog, docker_stats, filelog, fluentforward, hostmetrics, k8s_cluster, and kubeletstats receivers; every processor; the otlp, otlphttp, prometheusremotewrite, clickhouse, and debug exporters; the forward and routing connectors; and every extension, except oidc on ClickStack versions before 2.35.0. A component that ClickStack does not ship is also reported by validation if it reaches the YAML. Configurations created through the API or the CLI are always on OpenTelemetry Collector Contrib. See Key concepts and Managing configurations.

Next steps

Connect components into pipelines. See Canvas & pipelines.

Components