Coroot

What Coroot does

Coroot is an observability tool built around the idea that collecting telemetry is not enough: it also tries to interpret it. An agent on each node uses eBPF, a Linux kernel feature, to observe every container and systemd service. Without changes to your code it records metrics on network calls between services, logs, request traces and continuous CPU and memory profiles. From that data Coroot draws a service map of who talks to whom and runs a set of predefined inspections on each application, covering CPU, memory, network, storage, application instances, log errors, JVM, .NET and Python runtimes, and databases such as Postgres, MySQL, Redis and MongoDB.

The main view is a health summary of all services rather than a wall of dashboards. You define service level objectives for latency and availability, and when a service breaks one, Coroot sends a single alert that includes the results of the relevant inspections, rather than separate alerts for every symptom. It also notices each Kubernetes rollout on its own and compares the new release with the previous one, and estimates cloud costs per application on AWS, GCP and Azure without access to your cloud account.

Data collection and storage

The node agent exposes metrics in Prometheus format or pushes them with remote write, and sends logs and traces over OpenTelemetry. A cluster agent connects to databases it discovers on the service map, such as Postgres, MySQL, Redis, Memcached and MongoDB, gathers profiles from annotated Go applications, and can pull telemetry from AWS RDS and ElastiCache. Applications already instrumented with OpenTelemetry can send traces and logs straight to Coroot.

Metrics live in Prometheus or any compatible database such as VictoriaMetrics, Thanos or Grafana Mimir. Coroot keeps its own metric cache, so Prometheus can run with short retention; ClickHouse can also store metrics. Logs, traces and profiles go to ClickHouse.

Self-hosting Coroot

Coroot runs with Docker Compose, on Kubernetes (including EKS, GKE, AKS, OpenShift, K3s and MicroK8s), on Docker Swarm or on Amazon ECS. The reference Compose file starts Coroot, both agents, ClickHouse and Prometheus. Because collection depends on eBPF, nodes need Linux kernel 4.16 or later, and the profiler needs a distribution with CO-RE support such as Ubuntu 20.10, Debian 11 or RHEL 8.2 and later. Docker-in-Docker setups like Minikube and WSL1 are not supported. The agent must run on every node you want to see.

Community and Enterprise editions

The Community Edition is Apache-2.0 and includes the collection, service map, inspections, tracing, logs, profiling, deployment tracking and cost monitoring described above. Coroot Enterprise is a separate image unlocked with a license key and priced per monitored CPU core; it adds single sign-on, role-based access control, AI-powered root cause analysis and support. Community users can connect to the Coroot Cloud service for AI analysis with a small free monthly allowance. There is no hosted version of the platform itself.

Limitations

Coroot depends on Linux and eBPF, so Windows hosts and some restricted environments are out of reach. You run and size ClickHouse and Prometheus yourself. Access control and SSO are paid. Claims about how many problems the inspections detect come from the vendor, so test it against incidents you know.

Who it suits

Coroot suits teams running Kubernetes or containers on Linux who want APM-style visibility into services they cannot or will not instrument, and prefer guided diagnosis to building dashboards. Teams that already use OpenTelemetry heavily may also compare SigNoz; for infrastructure dashboards only, Prometheus with Grafana is the usual pairing.