Skip to main content

K8sevents Receiver

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

Supported Telemetry

Logs

Overview

Currently this receiver supports authentication via service accounts only. See example for more information.

Configuration

The following settings are optional:
  • auth_type (default = serviceAccount): Determines how to authenticate to the K8s API server. This can be one of none (for no auth), serviceAccount (to use the standard service account token provided to the agent pod), or kubeConfig to use credentials from ~/.kube/config.
  • namespaces (default = all): An array of namespaces to collect events from. This receiver will continuously watch all the namespaces mentioned in the array for new events.
  • kube_api_qps (default = 5): Maximum number of queries per second to the Kubernetes API. Increase this if you see client-side throttling warnings in the collector logs.
  • kube_api_burst (default = 10): Maximum burst size for requests to the Kubernetes API. Increase this alongside kube_api_qps if you see client-side throttling warnings.
  • k8s_leader_elector (default: none): if specified, will enable Leader Election by using k8sleaderelector extension
  • storage (default: none): specifies the storage extension to use for persisting the latest resourceVersion. When configured, the receiver persists the resourceVersion after processing each watch event. On restart, the receiver resumes from the persisted resourceVersion, preventing duplicate events.
    Important storage considerations:
    • Local or node-pinned volumes (hostPath, local PV): the collector pod becomes tied to a specific node. If that node fails or the pod is rescheduled elsewhere, the persisted data will not be accessible and persistence will not work correctly.
    • Network-attached volumes (ReadWriteMany): the volume is accessible from any node, so the collector pod can be freely rescheduled or fail over to a different node while still resuming from the correct resourceVersion. This is the recommended approach, especially when used with k8s_leader_elector.
    • Block volumes (ReadWriteOnce): supported for single-replica deployments where restarts are graceful. Not recommended with leader election across multiple nodes, as Kubernetes may take 30–90 seconds to detach and reattach the volume after a node failure.
  • dedup_interval (default = 0): Throttles MODIFIED watch events per Event UID. See Event Deduplication.
Examples:
The full list of settings exposed for this receiver are documented in config.go with detailed sample configurations in testdata/config.yaml.

Event Deduplication

dedup_interval is opt-in (default 0 preserves existing behavior). It throttles MODIFIED watch notifications per Event UID, useful when recurring events (CrashLoopBackOff, failing readiness probes, etc.) inflate log volume without adding new information. Recurrence count is preserved on each emitted record via the k8s.event.count attribute.

Configuration

ADDED events are always emitted and DELETED watch events are excluded. The dedup cache only tracks UIDs that have produced a MODIFIED, so single-fire Events do not consume cache space.

Dedup state retention

Per-UID dedup state lives in an in-memory cache so it does not grow unbounded. The entry TTL is derived automatically as dedup_interval + 5m and is not configurable. The TTL is reset on every emit, so an entry persists for as long as that UID is being actively emitted (at most once per dedup_interval); once emissions stop, the entry is evicted after the TTL elapses. The 5m buffer keeps state alive slightly longer than the throttle window so a UID that is still being throttled is never evicted mid-window.
Note: Dedup state is in-memory and is not persisted. On a collector restart or a leader election change, the cache starts empty, so the first MODIFIED seen afterward for each still-recurring Event UID is re-emitted before throttling resumes — throttling is best-effort across restarts.

Internal telemetry

When dedup_interval is set, the counter otelcol.k8s.events.modified.filtered reports how many MODIFIED watch notifications were dropped. See documentation.md for the metric definition.

Example

Here is an example deployment of the collector that sets up this receiver along with the OTLP Exporter. Follow the below sections to setup various Kubernetes resources required for the deployment.

Configuration

Create a ConfigMap with the config for otelcontribcol. Replace OTLP_ENDPOINT with valid value.

Service Account

Create a service account that the collector should use.

RBAC

Use the below commands to create a ClusterRole with required permissions and a ClusterRoleBinding to grant the role to the service account created above. Alternatively, a namespace-scoped Role and RoleBinding can be used when the receiver is configured to watch specific namespaces via the namespaces option.

Deployment

Create a Deployment to deploy the collector.

Conversion Example

The following K8s Event
will be converted to the following log

Configuration

Example Configuration


Last generated: 2026-08-24