Coroot¶

Open-source, eBPF-powered observability and APM platform with zero-instrumentation auto-discovery, AI-powered root cause analysis, and continuous profiling.

Overview¶

Coroot is a zero-instrumentation observability platform that leverages eBPF to collect metrics, logs, traces, and continuous profiles directly at the kernel level — without code changes, SDK installations, or application restarts. It focuses on reducing Mean Time to Resolution (MTTR) through automated service map discovery and AI-powered root cause analysis.

Repository & Community¶

Attribute	Detail
Repository	github.com/coroot/coroot
Stars	~7.6k ⭐
Latest Version	v1.19.2 (April 10, 2026)
Language	Go
License	Apache 2.0 (Community), Proprietary (Enterprise)
Company	Coroot, Inc.

Evaluation¶

Why it's better: The only open-source platform that provides eBPF-based auto-instrumentation across all 4 pillars (metrics, logs, traces, profiles) with zero code changes. AI-powered root cause analysis dramatically reduces MTTR. Automatically discovers and maps all services, databases, and external API dependencies.
When it fits (Applicability):
Teams wanting observability without instrumenting every service
Kubernetes-native environments needing automatic service discovery
Organizations seeking to minimize MTTR with AI-driven diagnostics
Small-to-medium teams without dedicated platform engineering
Pros and Cons:

Pros	Cons
Zero instrumentation required (eBPF)	Requires Linux kernel 4.16+ for eBPF
Auto-generated service maps	Younger project, smaller community
AI root cause analysis	Enterprise features behind paywall
Continuous profiling included	Less customizable dashboards vs Grafana
Apache 2.0 (community)	eBPF data may miss application-level context
Multi-cluster support	No built-in log management (uses ClickHouse/Prometheus)

Architecture¶

flowchart TB
    subgraph Agents["Data Collection"]
        NA["coroot-node-agent<br/>(eBPF DaemonSet)"]
        CA["coroot-cluster-agent<br/>(DB discovery)"]
        OTEL["OTel SDK<br/>(optional)"]
    end

    subgraph Core["Coroot Server"]
        direction TB
        Inspect["Automated Inspections<br/>& AI RCA"]
        SM["Service Map Engine"]
        Cache["Metric Cache<br/>(on-disk)"]
        UI["Web UI"]
    end

    subgraph Storage["Storage Backends"]
        Prom["Prometheus / VM / Mimir"]
        CH["ClickHouse<br/>(logs, traces, profiles)"]
    end

    NA --> Core
    CA --> Core
    OTEL --> Core
    Core --> Prom
    Core --> CH
    Inspect --> UI
    SM --> UI

Key Components¶

Component	Role
coroot-node-agent	eBPF DaemonSet: collects metrics, logs, traces, profiles at kernel level
coroot-cluster-agent	Discovers databases (Postgres, MySQL, Redis, MongoDB) and collects internal metrics
Coroot Server	Aggregation, automated inspections, AI analysis, visualization
Storage	Prometheus/VictoriaMetrics/Mimir for metrics; ClickHouse for logs, traces, profiles

Key Features¶

Feature	Detail
eBPF Collection	Kernel-level telemetry without code changes
Service Map	Auto-discovery of services, databases, external APIs
Continuous Profiling	CPU and memory profiling down to specific code lines
Distributed Tracing	eBPF auto-traces + OTel SDK support
SLO Monitoring	Built-in SLO compliance tracking
Cloud Cost Insights	Per-application resource and cost breakdown
AI Root Cause Analysis	Automated pattern detection and fix suggestions
Multi-Cluster	Unified view across multiple K8s clusters
Log Analysis	Aggregation and analysis via ClickHouse backend

Pricing¶

Tier	Cost	Features
Community	Free (Apache 2.0)	Core observability, eBPF, service maps, SLO, profiling
Enterprise	$1/CPU core/month	AI RCA, SSO, RBAC, 24x7 support, air-gapped deployments

Compatibility¶

Dimension	Support
Metrics backends	Prometheus, VictoriaMetrics, Thanos, Grafana Mimir
Log/trace storage	ClickHouse
Ingestion protocols	OTLP (logs, traces), Prometheus Remote Write
Platforms	Kubernetes, Docker, bare metal (Linux only, kernel 4.16+)
CPU architecture	amd64, arm64

Sources¶

Tracked URLs, documentation references, and source materials for the Coroot folder.

Official Documentation¶

Source	URL	Retrieved Via
Official Website	https://coroot.com	Direct
Documentation	https://docs.coroot.com	Direct
Architecture	https://docs.coroot.com/installation/architecture/	Direct
Inspections	https://docs.coroot.com/inspections/	Defuddle
Installation	https://docs.coroot.com/installation/	Direct
Configuration	https://docs.coroot.com/configuration/	Direct

Repositories¶

Repository	URL
Coroot (main)	https://github.com/coroot/coroot
Node Agent (eBPF)	https://github.com/coroot/coroot-node-agent
Cluster Agent	https://github.com/coroot/coroot-cluster-agent
Helm Charts	https://github.com/coroot/helm-charts

Release Data¶

Source	URL	Retrieved Via
GitHub Releases	https://github.com/coroot/coroot/releases	Web Search

Community & Blog¶

Source	URL
Blog	https://coroot.com/blog
Slack Community	https://coroot.com/join-slack-community/
LinkedIn	https://www.linkedin.com/company/coroot

Questions¶

Open and answered questions about Coroot.

Open Questions¶

Answered Questions¶

What kernel version is required? → Linux 4.16+ for eBPF support. See observability/coroot/index#Compatibility.
Can Coroot work without Kubernetes? → Yes, Docker and bare metal are supported, but auto-discovery is K8s-optimized.
What is the eBPF overhead? → Negligible at 10K RPS; ~200 millicores CPU. See observability/coroot/architecture.
Does Coroot support OpenTelemetry? → Yes, OTLP for traces and Prometheus remote_write for metrics.
What is the exact ClickHouse schema Coroot uses for trace storage? → Coroot stores traces, logs, and profiles in ClickHouse with per-day partitions managed via TTL (default 7d, configurable via traces.ttl, logs.ttl, profiles.ttl). The Coroot Node Agent collects eBPF traces with configurable sampling (0.0-1.0) and writes them to ClickHouse tables created at startup. Specific column-level schema is not publicly documented in the official docs; check the Coroot source code for exact table definitions, resolved in observability/coroot/architecture
How does Coroot handle eBPF on ARM-based Kubernetes nodes (e.g., Graviton)? → eBPF programs are architecture-specific and must be compiled for the target architecture (BPF bytecode is JIT-compiled to the host's native instruction set). ARM64/Graviton support depends on whether Coroot's Node Agent includes ARM64-compiled eBPF bytecode. No explicit ARM64 compatibility matrix is documented in official Coroot docs; check the Coroot GitHub issues and release notes for ARM64 support status, resolved in observability/coroot/architecture
What are the specific AI models used in the Enterprise RCA engine? → The specific AI/ML models used in Coroot Enterprise's automated root-cause analysis engine are not publicly documented. The Enterprise edition requires a license_key in the configuration and provides automated issue detection beyond the Community edition's capabilities. Contact Coroot directly or check Enterprise documentation for model details, resolved in observability/coroot/index
How does performance degrade with > 500 services in a single cluster? → No public benchmark exists for >500 services. Coroot's Node Agent requests 100m CPU / 200Mi memory with limits of 500m / 1Gi per node, and the metric cache has a configurable TTL (default 30d) and GC interval (10m). At >500 services, the main bottlenecks would be ClickHouse query performance for cross-service traces and the metric cache size. ClickHouse supports sharding (configurable via clickhouse.shards and clickhouse.replicas in the Helm chart) for horizontal scaling. Real-world benchmark at this scale TBD, resolved in observability/coroot/architecture
Does Coroot support Kubernetes NetworkPolicy detection via eBPF? → Coroot's eBPF tracer (ebpfTracer.enabled: true) collects network connection data between services to build the service map and detect latency/errors. It tracks TCP/HTTP/gRPC connections but does not explicitly detect or validate Kubernetes NetworkPolicy resources. NetworkPolicy enforcement is handled by CNI plugins (Calico, Cilium); Coroot can visualize the resulting network topology and detect connectivity failures that may result from NetworkPolicy misconfiguration. Explicit NetworkPolicy detection via eBPF is not a documented feature, resolved in observability/coroot/architecture