K8sevents Receiver
contrib, k8s
Maintainers: @dmitryax, @TylerHelmuth, @ChrsMark
Source: opentelemetry-collector-contrib
Supported Telemetry
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 ofnone(for no auth),serviceAccount(to use the standard service account token provided to the agent pod), orkubeConfigto use credentials from~/.kube/config.namespaces(default =all): An array ofnamespacesto collect events from. This receiver will continuously watch all thenamespacesmentioned 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 seeclient-side throttlingwarnings in the collector logs.kube_api_burst(default =10): Maximum burst size for requests to the Kubernetes API. Increase this alongsidekube_api_qpsif you seeclient-side throttlingwarnings.k8s_leader_elector(default: none): if specified, will enable Leader Election by usingk8sleaderelectorextensionstorage(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 withk8s_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.
- Local or node-pinned volumes (
dedup_interval(default =0): Throttles MODIFIED watch events per Event UID. See Event Deduplication.
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
dedup_interval | Behavior |
|---|---|
0 (default) | No throttling — emit every MODIFIED |
Positive (e.g. 5m) | Emit the first MODIFIED per UID, then drop until the interval elapses |
Negative (e.g. -1s) | Drop all MODIFIED events |
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 asdedup_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
Whendedup_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 forotelcontribcol. Replace OTLP_ENDPOINT
with valid value.
Service Account
Create a service account that the collector should use.RBAC
Use the below commands to create aClusterRole 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 EventConfiguration
Example Configuration
Last generated: 2026-07-06