RootTrace / Integrations / Amazon EKS
Containers & orchestration
EKS monitoring that knows it's on EKS.
The collector detects EKS automatically, verifies the AWS add-on pods alongside your workloads, and reports failing pods with names, phases, and reasons, plus cluster name and Kubernetes version for context.
What RootTrace watches
Every reading is checked continuously; bad readings become grouped issues with the evidence attached. RootTrace also remembers whether it has seen the same incident before.
- Automatic EKS detectionThe check recognizes an EKS cluster and records how it detected it. There is no flag to set.
- Add-on pod checksaws-node, CoreDNS, kube-proxy, and other add-on prefixes verified as their own signal.
- Failing pods with reasonsNames, namespaces, phases, and reasons in the evidence. The list is bounded, so a big cluster doesn't flood.
- Cluster contextCluster name and Kubernetes version reported alongside the results.
Warn and fail thresholds, prefilled
Sensible defaults out of the box, overridable per host with environment variables. No threshold spreadsheet required on day one.
- Add-on pod checks on / off
ROOTTRACE_EKS_ADDON_POD_CHECKS - Startup grace minutes
ROOTTRACE_KUBERNETES_STARTUP_GRACE_MINUTES - Pod evidence cap
ROOTTRACE_KUBERNETES_MAX_POD_EVIDENCE
Setup
# deploy the non-root collector DaemonSet from the dashboard's setup page. # EKS detection and add-on checks are automatic. Optional naming: $ export ROOTTRACE_EKS_CLUSTER_NAME='prod-us-east-1'
Read-only by architecture: no write path, no remediation executor, no inbound ports. Credential-like evidence is redacted before it leaves the host.
One collector, live in minutes
Everything on this page comes from the same read-only collector: one command per host, then point it at your targets.
$ # after adding the signed RootTrace dnf or apt repository:
sudo dnf install roottrace-collector # apt: sudo apt install roottrace-collector
sudoedit /etc/roottrace/collector.env # set ROOTTRACE_COLLECTOR_TOKEN and API URL
sudo roottrace-collector-setup apply
sudo systemctl enable --now roottrace-collector
Questions, answered honestly
How is this different from the Kubernetes integration?
It runs alongside it. The Kubernetes checks cover the API, auth, and workloads; the EKS check adds AWS-specific context: detection, cluster naming, and the add-on pods AWS ships that everything else depends on.
Is this safe to run next to production?
The collector is read-only by architecture, not by policy: there is no write path, no remediation executor, and no privileged mode to switch on. It sends short-lived outbound HTTPS requests, opens no inbound ports, and redacts credential-like evidence before anything leaves the host.
Do I need a separate agent for this?
No. One RootTrace collector per host covers every integration on this site: databases, web servers, containers, endpoints, and the Linux host itself, all from one signed package or container. You point it at targets with environment variables; there is nothing else to deploy.
Related integrations
Free on 5 hosts. Live in minutes.
Create a workspace, install one collector, and watch issues explain themselves.
RootTrace