Skip to main content
This guide recaps the most important OpenTelemetry Collector receivers and related processors commonly used in Kubernetes, where they typically run, and short configuration examples. The goal is to visualize which components collect which telemetry, and how they enrich or forward it to the Collector.

​
Kubernetes attributes processor

The k8sattributes processor enriches incoming telemetry with Kubernetes metadata such as pod name, namespace, labels, annotations, and node information. This processor is commonly used when the Collector runs as a DaemonSet, sidecar, or centralized Collector with appropriate RBAC access so it can attach Kubernetes context to traces, metrics, and logs. Example configuration:
Kubernetes metadata enrichment requires the Collector to have proper Kubernetes RBAC permissions (to read pods, nodes, and endpoints). Ensure your Collector’s ServiceAccount has the required Role/ClusterRole.

​
kubeletstats receiver

The kubeletstats receiver scrapes the kubelet summary endpoint on each node to collect node-, pod-, and container-level resource metrics (CPU, memory, filesystem, network). Because it needs local kubelet access, it is typically deployed as a DaemonSet so each Collector pod can reach the local kubelet. Example configuration:
Notes:
  • The kubelet summary endpoint may require authentication or TLS; configure the receiver to meet your kubelet security configuration.
  • Use kubeletstats alongside hostmetrics and Prometheus scrapes for a complete resource and workload view.

​
filelog receiver

The filelog receiver tails container log files (commonly /var/log/containers/*.log) and forwards container stdout/stderr logs to the Collector for processing and export. Example configuration:

​
Kubernetes cluster and objects receivers

  • kubernetescluster (cluster receiver) gathers cluster-level metrics and high-level entity events (e.g., cluster resource usage, aggregated signals).
  • k8sobjects (objects receiver) retrieves Kubernetes object state and events such as Pod, Deployment, and StatefulSet statuses.
Use these receivers to gain visibility into cluster health, topology, and object lifecycle events. Receiver names can vary between Collector distributions—check your distribution’s contrib receivers list for exact names.
The image shows a diagram of a Kubernetes cluster sending cluster metrics and events to a collector, with k8sobjects indicated in the flow.

​
Prometheus receiver

The Prometheus receiver scrapes metrics exposed in the Prometheus exposition format. Use it to scrape instrumented applications and exporters that expose /metrics. Example minimal snippet:
The Prometheus receiver requires a full config.scrape_configs section (service discovery or explicit scrape_configs). The example above is minimal—define jobs, targets, and relabeling to avoid misconfigured scrapes.
If multiple Collectors can scrape the same Prometheus targets you will receive duplicate metrics. Coordinate scrapes (for example, partition targets or use a target allocator) to avoid duplication and metric inflation.

​
hostmetrics receiver

The hostmetrics receiver collects OS-level metrics from nodes, such as CPU, memory, disk, and network usage. When used together with kubeletstats and Prometheus scrapes, it helps provide a full observability picture for both nodes and workloads.
The image illustrates data flow diagrams for Prometheus and Hostmetrics receivers, showing how a collector gathers data from service endpoints and nodes.

​
OTLP receiver (application telemetry)

The OTLP receiver accepts traces, metrics, and logs from instrumented applications over gRPC/HTTP in the OTLP format. Use this when your workloads export telemetry directly to the Collector. Example configuration:

​
Quick reference table

Receiver / ProcessorPurposeTypical DeploymentExample
k8sattributes (processor)Enrich telemetry with pod/node metadataDaemonSet, sidecar, centralized Collector with RBACk8sattributes: {}
kubeletstats (receiver)Node/pod/container resource metrics from kubeletDaemonSet (local kubelet access)kubeletstats: {}
filelog (receiver)Tail container stdout/stderr logsDaemonSet or sidecar with hostPath mountsfilelog: { include: ["/var/log/containers/*.log"] }
kubernetescluster / k8sobjectsCluster-level metrics, object state & eventsCentralized Collector or specialized controllersSee distribution contrib list
prometheus (receiver)Scrape Prometheus-format endpoints / exportersSidecar, DaemonSet, or centralized Collector (depending on topology)prometheus: {} (add config.scrape_configs)
hostmetrics (receiver)OS-level node metricsDaemonSet or node-local Collectorhostmetrics: {}
otlp (receiver)Receive OTLP telemetry from instrumented appsCentralized Collector or Gatewayotlp: { protocols: { grpc: {}, http: {} } }

​
Summary and deployment choices

  • Use the k8sattributes processor to attach Kubernetes context to telemetry; ensure RBAC is configured.
  • Deploy kubeletstats and hostmetrics as node-local (DaemonSet) collectors when you need local resource visibility and access to the kubelet.
  • Use filelog to collect container logs from node file paths or run sidecars that forward logs into the Collector.
  • Enable kubernetescluster and k8sobjects when you need cluster-level visibility and Kubernetes object events; verify exact receiver names for your Collector distribution.
  • Use the prometheus receiver to scrape Prometheus-format endpoints—always define proper scrape_configs and coordinate scrapes to avoid duplicates.
  • Use otlp to accept telemetry from instrumented workloads directly.
Review and adapt these choices to match your Collector deployment model (DaemonSet, sidecar, or centralized) and to ensure RBAC, network access, and scrape topology are configured correctly.

Watch Video