←back to thread

Show HN: Coroot – eBPF-based, open source observability with actionable insights

(github.com)
162 points openWrangler | 1 comments | 08 Apr 25 16:49 UTC | HN request time: 0.246s | source

A common open source approach to observability will begin with databases and visualizations for telemetry - Grafana, Prometheus, Jaeger. But observability doesn’t begin and end here: these tools require configuration, dashboard customization, and may not actually pinpoint the data you need to mitigate system risks.

Coroot was designed to solve the problem of manual, time-consuming observability analysis: it handles the full observability journey — from collecting telemetry to turning it into actionable insights. We also strongly believe that simple observability should be an innovation everyone can benefit from: which is why our software is open source.

Features:

- Cost monitoring to track and minimise your cloud expenses (AWS, GCP, Azure.)

- SLO tracking with alerts to detect anomalies and compare them to your system’s baseline behaviour.

- 1-click application profiling: see the exact line of code that caused an anomaly.

- Mapped timeframes (stop digging through Grafana to find when the incident occurred.)

- eBPF automatically gathers logs, metrics, traces, and profiles for you.

- Service map to grasp a complete at-a-glance picture of your system.

- Automatic discovery and monitoring of every application deployment in your kubernetes cluster.

We welcome any feedback and hope the tool can improve your workflow!

Show context
emmanueloga_ ◴[09 Apr 25 05:54 UTC] No.43629274[source]▶
I looked into eBPF-based observability tools for k8s some time ago and found at least four tools that look incredibly similar: Pixie, Parca, Coroot, and Odigos. There are probably others I missed too. Do you have any thoughts about this?

From a user perspective, having several tools that overlap heavily but differ in subtle ways makes evaluation and adoption harder. It feels like if any two of these projects consolidated, they’d have a good shot at becoming the "default" eBPF observability solution.

replies(2): >>43629402 #>>43630035 #
1. nikolay_sivko ◴[09 Apr 25 06:18 UTC] No.43629402[source]▶
From a user’s perspective, it doesn’t really matter how the data is collected. What actually matters is whether the tool helps you answer questions about your system and figure out what’s going wrong.

At Coroot, we use eBPF for a couple of reasons:

1. To get the data we actually need, not just whatever happens to be exposed by the app or OS.

2. To make integration fast and automatic for users.

And let’s be real, if all the right data were already available, we wouldn’t be writing all this complicated eBPF code in the first place:)