Peek into your Kubernetes clusters with Agent0

Telemetry tells Agent0 that a pod was OOM-killed, that a rollout is stuck, or that a service stopped receiving traffic. It does not tell Agent0 why. The answer is often in the cluster itself: a memory limit that is too low, a readiness probe that times out too early, a service selector that matches nothing, a network policy that drops the traffic. Until now, finding that meant switching to a terminal, running kubectl yourself, and pasting the output into the chat.

With the Agent0 Kubernetes integration provided by the Dash0 Operator, Agent0 can look for itself. During an investigation, it reads the state of your cluster, the same way you would, and connects what it finds with your logs, metrics and traces. It can inspect namespaces that send no telemetry yet, work across several clusters in a single investigation.

Agent0 finds the Service selector mismatch via kubectl.

Read-only, and you stay in control

Agent0 can look, but never touch. The integration only allows reading, so Agent0 cannot change, restart or delete anything in your cluster, and it never gets a shell into your containers. Secrets are off limits, and credentials are removed from every response before it leaves your cluster. You decide which resources Agent0 may see, and you can narrow or widen that at any time.

The connection is established from inside your cluster. There is no need to expose your Kubernetes API server, open a firewall port, or hand any cluster credentials to Dash0.

Opt in when you are ready

The integration is disabled by default. Nothing changes in your cluster until you explicitly turn it on in the Dash0 Operator (version 0.159.0 or later).

Not using the Dash0 Operator to collect telemetry? You can run it just for the Agent0 Kubernetes integration, alongside whatever you already use to send telemetry to Dash0.

Read the documentation to connect your first cluster.