> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Important Receivers for Kubernetes
> Guide to key OpenTelemetry Collector receivers and processors for Kubernetes, explaining their purposes, typical deployment patterns, configuration snippets, and metadata enrichment and scraping considerations.
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:
```yaml theme={null}
processors:
k8sattributes: {}
```
Kubernetes metadata enrichment requires the Collector to have proper [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) permissions (to read pods, nodes, and endpoints). Ensure your Collector's [ServiceAccount](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) has the required [Role/ClusterRole](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-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:
```yaml theme={null}
receivers:
kubeletstats: {}
```
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:
```yaml theme={null}
receivers:
filelog:
include: ["/var/log/containers/*.log"]
```
## 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.
## 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:
```yaml theme={null}
receivers:
prometheus: {}
```
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.
## 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:
```yaml theme={null}
receivers:
otlp:
protocols:
grpc: {}
http: {}
```
## Quick reference table
| Receiver / Processor | Purpose | Typical Deployment | Example |
| ------------------------------ | ------------------------------------------------ | -------------------------------------------------------------------- | ----------------------------------------------------- |
| k8sattributes (processor) | Enrich telemetry with pod/node metadata | DaemonSet, sidecar, centralized Collector with RBAC | `k8sattributes: {}` |
| kubeletstats (receiver) | Node/pod/container resource metrics from kubelet | DaemonSet (local kubelet access) | `kubeletstats: {}` |
| filelog (receiver) | Tail container stdout/stderr logs | DaemonSet or sidecar with hostPath mounts | `filelog: { include: ["/var/log/containers/*.log"] }` |
| kubernetescluster / k8sobjects | Cluster-level metrics, object state & events | Centralized Collector or specialized controllers | See distribution contrib list |
| prometheus (receiver) | Scrape Prometheus-format endpoints / exporters | Sidecar, DaemonSet, or centralized Collector (depending on topology) | `prometheus: {}` (add `config.scrape_configs`) |
| hostmetrics (receiver) | OS-level node metrics | DaemonSet or node-local Collector | `hostmetrics: {}` |
| otlp (receiver) | Receive OTLP telemetry from instrumented apps | Centralized Collector or Gateway | `otlp: { 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.
## Links and references
* [OpenTelemetry Collector documentation](https://opentelemetry.io/docs/collector/)
* [Kubernetes RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
* [Kubernetes ServiceAccount](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)
* [Kubelet resource usage monitoring](https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
* [Prometheus exposition formats](https://prometheus.io/docs/instrumenting/exposition_formats/)