Coroot: eBPF-based observability with built-in inspections for Kubernetes

The problem Coroot targets: data without conclusions

The README opens with a claim that doubles as a positioning statement: collecting metrics, logs, and traces alone doesn't make your applications observable. That is the gap Coroot is built to close. The tool assumes you already have telemetry, or can generate it, and that the hard part is turning it into a short list of things that are wrong.

The intended user is an SRE or platform engineer responsible for many services, often hundreds, on Kubernetes. The README describes an Application Health Summary meant to make the status of those services readable at a glance, plus SLO tracking and a single alert per SLO breach that bundles the results of every relevant inspection. That design choice matters: instead of one alert per symptom, Coroot tries to send one alert per user-visible problem.

It is not a general-purpose metrics database. Nothing in the README frames Coroot as a replacement for a time-series store you query by hand. The features are all opinionated views: a service map, predefined inspections, log pattern clustering, one-click profiling, deployment tracking, cost monitoring.

How Coroot collects data: eBPF, OpenTelemetry and ClickHouse

The collection story has two paths. The README states that metrics, logs, traces, and profiles are gathered automatically by using eBPF, which is what lets Coroot build a Service Map that covers the system without per-service instrumentation. For teams that can instrument, the README also lists vendor-neutral instrumentation with OpenTelemetry, and notes that eBPF-based instrumentation can capture requests from legacy or third-party services where code changes are not possible.

The repository layout shows how the pieces are separated. There are top-level directories named collector, prom, ch, clickhouse, timeseries, model, auditor, notifications, watchers, cloud and cloud-pricing, plus a front directory for the UI. The auditor directory is where the inspection logic lives; notifications is where the alerting integrations sit. The go.mod file confirms the storage and integration choices: ClickHouse/ch-go and clickhouse-go/v2 for the log and trace store, prometheus/prometheus and prometheus/client_golang for the metric path, go.opentelemetry.io/proto/otlp for OTLP, and notification SDKs for PagerDuty, Opsgenie, Slack and Microsoft Teams.

So the data flow is: agents and OTLP receivers write into Coroot, metrics land in a Prometheus-compatible path, logs and traces land in ClickHouse, the auditor evaluates predefined inspections against that data, and the UI in front renders the service map and health summaries. The README's claim that Coroot can automatically identify over 80% of issues is a product claim, not something a reader can verify from the repository alone.

Installing Coroot and getting a first service map

The README does not contain install commands. It says you can run Coroot as a Docker container or deploy it into any Kubernetes cluster, and points to the installation guide at docs.coroot.com. The Dockerfile in the repository shows what the container expects, which is useful even without the guide.

The image is built in two stages and the runtime stage is Red Hat UBI 9. The process runs as user 65534:65534, declares VOLUME /data, and exposes port 8080. The entrypoint is the coroot binary itself:

FROM registry.access.redhat.com/ubi9/ubi
COPY --from=backend-builder /tmp/src/coroot /usr/bin/coroot
RUN mkdir /data && chown 65534:65534 /data
USER 65534:65534
VOLUME /data
EXPOSE 8080
ENTRYPOINT ["/usr/bin/coroot"]

Two consequences follow directly from that file. First, /data must be writable and persistent, because the process runs unprivileged and the volume is where state lives. Second, port 8080 is what you expose or forward. If you run the container by hand, those are the two things to get right before anything else.

For Kubernetes, the repository has a deploy directory and a manifests directory, and the README says Coroot can be deployed into any Kubernetes cluster. The README does not document which manifest applies to which scenario, so treat the docs.coroot.com installation guide as the source of truth rather than copying files out of manifests blindly.

Building from source is a third option and the Makefile is explicit about the toolchain. The module targets Go 1.25.5, and the Dockerfile installs liblz4-dev before building, which tells you the build needs the LZ4 development headers present:

make go-test
make go-lint
cd front && npm ci && npm run lint

The first two targets run go test ./... and the Go lint chain, which includes go vet, gofmt and goimports. The UI is a separate npm project under front, installed with npm ci. A live demo is available at demo.coroot.com if you want to see the UI before committing to a deployment.

Where Coroot's approach costs you

The most concrete trade-off is the storage dependency. Logs and traces are backed by ClickHouse, per the repository layout and go.mod. That is a real operational commitment: another stateful system to run, size, back up and upgrade, and one that Coroot's own documentation, not the README, has to cover. If your team has deliberately standardized on a single observability backend, adding ClickHouse is the kind of decision that outlives the tool evaluation.

The second constraint is eBPF itself. The README presents eBPF as the reason the service map has no blind spots, but eBPF collection depends on kernel capabilities and on the agent having the privileges to attach probes. The README does not state kernel version requirements, nor which capabilities the collector needs. If your cluster runs on a managed platform that restricts privileged workloads, or on older kernels, that is the first thing to check rather than the last.

The third is scope. Coroot is opinionated by design: predefined inspections, predefined dashboards, an alert per SLO breach. If your workflow is ad-hoc PromQL over a long-retention Prometheus and a Grafana board per team, Coroot does not replace that. It reads more like a layer that answers a narrower question, what is broken right now, and it will feel constraining if you want to build arbitrary queries and panels.

Finally, the README does not document rollback, upgrade procedure or data migration for the Coroot deployment itself. It does point to a Contributing Guide and a community Slack, but for production lifecycle questions the README is silent.

Coroot compared with Grafana, Prometheus and Datadog

The comparison that matters is not feature counts but where the conclusion is drawn. Prometheus collects and stores time series and gives you PromQL; the judgement about what the numbers mean is yours. Coroot takes the same raw material and ships the judgement as predefined inspections plus a service map, with SLO tracking on top. If you already run Prometheus, Coroot is not a competitor to it so much as a consumer of that style of data with an opinion layer attached.

Grafana is the closest point of contrast on the visualization side. Grafana is a general dashboarding and query front end that connects to many backends; you decide what each panel shows. Coroot ships its own UI with a fixed vocabulary of views: service map, application health summary, log patterns, one-click profiling, deployment tracking. The trade is flexibility for defaults. Teams that have invested in Grafana dashboards as code will find Coroot's views additive, not a substitute.

Datadog is the fully managed path, and the difference is operational rather than conceptual. Coroot is Apache-2.0 and self-hosted, so you run the collector, the storage and the upgrades. The README also separates a Coroot Enterprise offering from the open-source project, and notes that deployment tracking requires no integration with your CI/CD pipeline, which is a deliberate contrast with agent-and-pipeline setups. If your constraint is headcount rather than licence cost, a managed vendor is the simpler answer, and Coroot is the wrong tool.

Licence, maintenance and upgrade cost

Coroot is licensed under the Apache License, Version 2.0, and the repository carries the LICENSE file at the top level. The Dockerfile copies that same LICENSE into the image at /licenses/LICENSE and labels the image as the Coroot Community Edition, which is a deliberate signal that the community build and the commercial product are separate artifacts. Apache-2.0 is permissive and business-friendly, but this is not legal advice; if you plan to redistribute or embed the image, read the licence and the enterprise page yourself.

The maintenance picture from the repository is straightforward. The default branch is main, the repository is not archived, and the last push was on 2026-09-15. The most recent releases listed are v1.26.3 on 2026-09-15, v1.26.2 on 2026-09-15 and v1.26.1 on 2026-09-14. Three releases in two days suggests a fast patch cadence around a 1.26 line, which cuts both ways: fixes arrive quickly, and pinning a specific patch is worth the effort.

Upgrade cost is where the documentation, not the code, decides. The README does not describe an upgrade procedure, a compatibility policy between versions, or how ClickHouse schema changes are handled across releases. The Makefile shows how to build and test from source, and go.mod pins Go 1.25.5, so building your own binary ties you to that toolchain and to liblz4-dev being present. Budget time to read the release notes on the repository rather than assuming patch upgrades are drop-in.

Editorial conclusion

Adopt Coroot if you run Kubernetes and want a service map plus inspections without adding instrumentation to every service, and if you already accept ClickHouse as part of the stack. Do not adopt it as a general-purpose dashboarding and query layer for arbitrary Prometheus data, and do not expect the README to tell you how to size or operate the deployment. Before rolling it out, verify three things: whether the docs.coroot.com installation guide covers your deployment model, whether the collector's eBPF requirements match your kernel and cluster permissions, and whether the Community Edition limits listed on the Coroot Enterprise page are acceptable for your team.

Frequently asked questions

Official sources

1. coroot/coroot on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases