Investigate Kubernetes workload, node, and control-plane issues using OTel telemetry (EDOT). Use when diagnosing pod failures (CrashLoopBackOff, OOMKilled, Error), node pressure, resource exhaustion, image pull failures, admission rejections, autoscaling anomalies, or correlating K8s state with application signals. OTel ingest path only — the legacy ECS Kubernetes integration shape is out of scope.
observability-k8s-investigation is a diagnostic skill for investigating Kubernetes workload, node, and control-plane issues using OpenTelemetry telemetry collected via EDOT (Elastic Distribution of OpenTelemetry) and the kube-stack collector. It is built to correlate cluster state, pod runtime metrics, K8s events, application logs, and APM to find root cause across the workload, node, and control-plane layers, and it deliberately scopes itself to the OTel ingest path, excluding the deprecated legacy Elastic Agent Kubernetes integration.
Much of the skill's value is its rigorous investigative discipline. It encodes guidelines that guard against common misdiagnoses: absence of evidence is not evidence, empty dependency data does not mean upstreams are healthy, co-symptoms are not causes, OOMKilled is not automatically a memory leak, error-termination is not automatically an application bug (check CPU limit utilization and CFS throttling first), average CPU hides p99 throttling, and container restart counts should be treated as boolean rather than a reliable counter. It documents exactly which OTel-namespaced indices and semantic-convention fields to query for each signal, from kubeletstats runtime metrics to k8sclusterreceiver state to k8sevents.
It is intended for SREs and platform engineers running Elastic observability on Kubernetes who need to diagnose CrashLoopBackOff, OOMKilled, node pressure, image pull failures, admission rejections, or autoscaling anomalies. It is a read-only, analysis-oriented skill that prefers reporting uncertainty and competing hypotheses over manufacturing false confidence.
OpenTelemetry data collected via EDOT and the kube-stack collector, stored in OTel-receiver-namespaced indices such as metrics-kubeletstatsreceiver.otel-*, metrics-k8sclusterreceiver.otel-*, and logs-k8seventsreceiver.otel-*.
No. The legacy integration (metrics-kubernetes.*, logs-kubernetes.*, kubernetes.* fields) is being deprecated and is explicitly out of scope; the skill does not author queries against those paths.
Pod failures like CrashLoopBackOff, OOMKilled, and Error terminations, plus node pressure, resource exhaustion, image pull failures, admission rejections, autoscaling anomalies, and correlation of K8s state with application signals.
k8s.container.restarts is pulled from the K8s API and may be pruned by the kubelet at any time, so the absolute value is unreliable. It should be treated as zero versus greater-than-zero, with restart patterns confirmed via Killing/BackOff events.
It prefers reporting uncertainty over manufacturing confidence, reports states like no_logs_available or insufficient_dependency_data, and treats competing hypotheses as a valid output rather than forcing a single conclusion.
Quick Setup:
.claude/skills/Repository
elastic/agent-skills