Coroot

Last reviewed Sep 13, 2026 · 946 words

Coroot's pitch is that you install one agent per host and get a service map, latency and error SLOs per service, and a "here is probably why" panel for incidents, without adding a line of instrumentation to anything. That pitch holds, with two conditions: the node agent needs a recent Linux kernel with eBPF and BTF support (a 5.x or 6.x distribution kernel is the comfortable case; a hardened cloud image or an old Debian will refuse), and the whole thing wants 1 GB of RAM to start and grows with the number of containers and connections it watches. For a Docker or Kubernetes homelab that already meets both, it is the fastest route to real observability I know of.

How it gets traces without touching your code

The coroot-node-agent attaches eBPF probes to the kernel's network and process hooks. From those it sees every TCP connection each container opens, parses the protocol on the wire (HTTP, gRPC, Postgres, MySQL, Redis, Mongo, Kafka and others), and records latency and status per request. That is enough to draw the graph of who talks to whom and to compute per-service error rates and p99s, which is most of what an APM sells you. Logs come from the container runtime, CPU profiles from a continuous profiler, and full distributed traces if your apps already emit OpenTelemetry. None of this requires the application to know Coroot exists, which is why it works on the closed-source images in your compose stack as well as your own code.

The stack you are actually running

Coroot Community Edition is more than one container. The reference compose file from the repo starts the Coroot server (UI on port 8080), the node agent with host PID and privileged access, a cluster agent for Kubernetes-side discovery, a bundled Prometheus for metrics, and ClickHouse for logs, traces, and profiles. On a single Docker host you can drop the cluster agent. The Prometheus can be swapped for an existing Prometheus or VictoriaMetrics if you already have one, and Coroot's dashboards can be pointed at it rather than duplicating the scrape. ClickHouse is the part that eats disk; set a retention that matches your interest, because a busy host emitting logs for 30 days is tens of gigabytes.

As a rough estimate for a 10 to 20 container home stack, plan on the full set settling a little above the 1 GB floor with ClickHouse the largest, and a few percent of one core for the agent. It scales with container count and request volume, not host count.

SLOs and the root-cause panel are the payoff

Once data is flowing, each detected service gets default SLOs: 99 percent of requests succeed, 99 percent complete within 500 ms. Edit those per service to something you mean. Coroot then watches the SLO burn rate and, when a service degrades, correlates the change against the things it also measures: CPU throttling in that container, a dependency's latency spike, a deploy that changed the image, memory pressure on the node, a DNS resolution slowdown. The result is a ranked list of likely causes rather than a wall of graphs. It is not magic, and on a small stack it will occasionally blame the wrong neighbour, but it reliably turns "Nextcloud feels slow" into "Postgres p99 jumped at 14:02 after the backup job started", which is the question you wanted answered.

Coroot versus the monitoring you already have

If you run Netdata, you have per-host metrics with great real-time charts and almost no view of how services relate. If you run Prometheus and Grafana, you have whatever you built dashboards for and nothing you did not. Coroot's distinct value is the service-centric view assembled automatically, and it is a complement to those tools more than a replacement: keep Grafana for long-term dashboards and alert routing, keep Netdata if you like its host view, and let Coroot answer the dependency questions. For a plain uptime-and-alerts need it is far too much; the homelab monitoring piece covers the lighter tools that solve that in 50 MB. The closer rival is SigNoz, which does the same three pillars with OpenTelemetry instrumentation instead of eBPF; SigNoz gives you richer traces if you will instrument, Coroot gives you 80 percent of the picture if you will not.

Things that bite

The agent needs --privileged, host PID namespace, and access to /sys/kernel/debug; on a Proxmox LXC it will not run, so put it on the VM or the host. Kernels without BTF (some older Ubuntu HWE builds, most Alpine-based minimal images) show a partial map with no protocol details. The Enterprise edition holds RBAC, SSO, and the AI-assisted root-cause explanations; the Community edition's correlation engine is the deterministic one and is fully open. Plan to set retention on day one, and give ClickHouse its own volume so you can watch it.

What I'd do

On a Docker host with a 6.x kernel and 20 or more containers, run Coroot Community with the bundled stack, cut ClickHouse retention to 7 days, set real SLOs on the 5 services you care about, and forward its alerts to whatever already pages you. Below 10 containers, or on a Raspberry Pi, it is more observability than the system deserves; use Netdata or Uptime Kuma and revisit when the stack grows. Everything in monitoring that competes with Coroot on the service-map question either costs money or wants you to instrument, which is the gap it fills.