Receivercreator Receiver
contrib, k8s
Maintainers: @dmitryax, @ChrsMark
Source: opentelemetry-collector-contrib
Supported Telemetry
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 theextensions 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:
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:
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
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
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 withtype == ("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
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 thek8sobserver.
The discovery feature for K8s is enabled with the following setting:
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:
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 enablesfile_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 thefile_log receiver is the following (configurable via default_file_log_config):
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:
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:Configuration
Example Configuration
Last generated: 2026-08-24