Skip to main content

Receivercreator Receiver

Status Available in: contrib, k8s Maintainers: @dmitryax, @ChrsMark Source: opentelemetry-collector-contrib

Supported Telemetry

Logs Metrics Traces

Overview

To use the receiver creator, you must first configure one or more observers that will discover networked endpoints that you may be interested in. The configured rules will be evaluated for each endpoint discovered. If the rule evaluates to true then the receiver for that rule will be started against the matched endpoint. If you use the receiver creator in multiple pipelines of differing telemetry types, but a given dynamically instantiated receiver doesn’t support one of the pipeline’s type, it will effectively lead to a logged no-op that won’t cause a collector service failure.

Configuration

watch_observers A list of observers previously defined to be run in the extensions section. receiver_creator will watch for endpoints generated by these observers. receivers A map of receiver names (e.g. redis/1) to a template for when and how to instantiate that receiver. receivers.<receiver_type/id>.rule Rule expression using expvar syntax. Variables available are detailed below in Rule Expressions. Note: The built-in type function introduced in v1.14.1 has been relocated to typeOf. receivers.<receiver_type/id>.config This is configuration that will be used when creating the receiver at runtime. This option can use static and dynamic configuration values. Static values are normal YAML values. However, the value can also be dynamically constructed from the discovered endpoint object. Dynamic values are surrounded by backticks (`). If a literal backtick is needed use \` to escape it. Dynamic values can be used with static values in which case they are concatenated. For example:
The value of secure_url will be https:// concatenated with the value of the secure_host label. This can also be used when the discovered endpoint needs to be changed dynamically. For instance, suppose the IP 1.2.3.4 is discovered without a port but the port needs to be set inside endpoint. You could do:
If your target receiver provides an endpoint config field and you aren’t manually setting it like the above example, the observer endpoint target value will automatically be sourced. If no endpoint field is available you are required to specify any necessary fields. To develop, test or debug expvar syntax based expressions use Expr language playground. receivers.resource_attributes
This setting controls what resource attributes are set on telemetry emitted from the created receiver. These attributes can be set from values in the endpoint that was matched by the rule. These attributes vary based on the endpoint type. These defaults can be disabled by setting the attribute to be removed to an empty value. Note that the values can be dynamic and processed the same as in config. Note that the backticks below are not typos—they indicate the value is set dynamically. type == "pod" type == "port" type == "pod.container" type == "container" type == "hostport" None type == "k8s.service" type == "k8s.node" type == "k8s.ingress" See redis/2 in examples. receivers.<receiver_type/id>.resource_attributes
Similar to the per-endpoint type resource_attributes described above but for individual receiver instances. Duplicate attribute entries (including the empty string) in this receiver-specific mapping take precedence. These attribute values also support expansion from endpoint environment content. At this time their values must be strings.

Rule Expressions

Each rule must start with type == ("pod"|"port"|"pod.container"|"hostport"|"container"|"k8s.service"|"k8s.node"|"k8s.ingress") && such that the rule matches only one endpoint type. Depending on the type of endpoint the rule is targeting it will have different variables available.

Pod

Port

Pod Container

Host Port

Container

Kubernetes Service

Kubernetes Ingress

Kubernetes Node

Examples

The full list of settings exposed for this receiver are documented in config.go with detailed sample configurations in testdata/config.yaml.

Generate receiver configurations from provided Hints

Note: When hints feature is enabled if hints are present for an endpoint no receiver templates will be evaluated. Currently this feature is only supported for K8s environments and the k8sobserver. The discovery feature for K8s is enabled with the following setting:
See below for the supported annotations that user can define to automatically enable receivers to start collecting metrics and logs signals from the target Pods/containers.

Supported metrics annotations

Enable/disable discovery

io.opentelemetry.discovery.metrics/enabled (Required. "true" or "false")

Define scraper

io.opentelemetry.discovery.metrics/scraper (example: "nginx")

Define configuration

io.opentelemetry.discovery.metrics/config For "endpoint" setting specifically, it sticks to urls that include "`endpoint`" as it comes from the Port endpoint which is in form of pod_ip:container_port. This is to ensure that each Pod can only generate configuration that targets itself and not others. If no endpoint is provided the Pod’s endpoint will be used (in form of pod_ip:container_port). Example:

Support multiple target containers

Users can target the annotation to a specific container by suffixing it with the name of the port that container exposes: io.opentelemetry.discovery.metrics.<container_port>/config. For example:
where 80 is the port that the target container exposes. If a Pod is annotated with both container level hints and pod level hints the container level hints have priority and the Pod level hints are used as a fallback (see detailed example below). The current implementation relies on the implementation of k8sobserver extension and specifically the pod_endpoint. The hints are evaluated per container by extracting the annotations from each Port endpoint that is emitted.

Supported logs annotations

This feature enables file_log receiver in order to collect logs from the discovered Pods.

Enable/disable discovery

io.opentelemetry.discovery.logs/enabled (Required. Example: "true") By default "false".

Define configuration

The default configuration for the file_log receiver is the following (configurable via default_file_log_config):
This default can be extended or overridden using the respective annotation: io.opentelemetry.discovery.logs/config Example:
include cannot be overridden and is fixed to discovered container’s log file path.

Support multiple target containers

Users can target the annotation to a specific container by suffixing it with the name of that container: io.opentelemetry.discovery.logs.<container_name>/endpoint. For example:
where busybox is the name of the target container. If a Pod is annotated with both container level hints and pod level hints the container level hints have priority and the Pod level hints are used as a fallback (see detailed example below). The current implementation relies on the implementation of k8sobserver extension and specifically the pod_endpoint. The hints are evaluated per container by extracting the annotations from each Pod Container endpoint that is emitted.

Examples

Metrics and Logs example

Collector’s configuration:
Target Pod annotated with hints:

Configuration

Example Configuration


Last generated: 2026-08-24