Coroot：用 eBPF 做零埋点的开源可观测性

在 DataDog、NewRelic 这类商业 APM 之外，开源世界长期缺一个”装好就能用、还能给出结论”的方案。Coroot 给出的答案是：不再要求你手工埋点，而是用 eBPF 从内核层把指标、日志、链路和 profile 全部自动抓下来，再用预置的 inspection 规则把这些数据翻译成”哪里出了问题”。它以 Apache 2.0 协议开源，主体用 Go 编写，定位是商业可观测性产品的自托管替代品。本文基于 Coroot 官方 GitHub README 与文档，分析它到底做了什么、数字怎么来的、又有哪些官方自己承认的边界。

一、背景：为什么”采集到数据”不等于”可观测”

可观测性的传统路线是 instrumentation：你要在代码里接 OpenTelemetry 或各类 SDK，手工定义 span、埋自定义指标、拼日志字段。这套做法的痛点很明显——老系统改不动、第三方组件没有源码、微服务数量一多，埋点本身就成了一笔巨大的工程债。Coroot 在 README 开篇就直接点题：“Collecting metrics, logs, and traces alone doesn’t make your applications observable”（光把指标、日志、链路收上来，并不能让应用变得可观测）。它要解决的不是”怎么采”，而是”采上来之后怎么自动告诉你结论”。

二、是什么：零埋点 + 内置专家的组合

Coroot 把自己定位为 “Open-source observability augmented with actionable insights”。两个关键词：

• Zero-instrumentation（零埋点）：指标、日志、链路、profiling 全部由 eBPF 自动采集，不需要改一行业务代码；对无法 instrumentation 的遗留或第三方服务，eBPF 也能在无代码改动的情况下捕获请求。
• Built-in expertise（内置专家）：对每个应用跑预置的 inspection（巡检）规则，不需要你配置仪表盘，自动判断是否违反 SLO、是否存在资源瓶颈。

三、技术机制：eBPF 取数，ClickHouse 存日志，OpenTelemetry 中立

从架构上看，Coroot 是一个组合体：

1. 数据采集层：在节点上以 agent 形式通过 eBPF 抓取网络连接、请求、系统资源指标，并自动关联成调用关系。官方称其 Service Map 能 100% 覆盖你的系统、没有盲区（“covers 100% of your system with no blind spots”）。
2. 存储层：日志检索基于 ClickHouse，官方强调是 “lightning-fast search based on ClickHouse”。
3. 链路层：在标准链路数据上采用 OpenTelemetry，保持厂商中立；eBPF 抓包则作为补充，专门对付埋不到的服务。
4. 分析层：预置 inspection 规则在后台审计每个应用；当一个应用不满足 SLO 时，Coroot 会把相关 inspection 的结果打包成单条告警发出来，而不是让你被告警风暴淹没。

此外它还做了两件同类工具不太做的事：

• Deployment Tracking（发布追踪）：自动发现 Kubernetes 里的每一次发布，不需要接你的 CI/CD，并自动把新版本与前一版本做性能对比。
• Cost Monitoring（成本监控）：把云账单下钻到具体应用，支持 AWS、GCP、Azure，且官方称不需要你提供云账号访问权限。

四、关键数据与口径

Coroot 官方 README 里出现的、可核对的量化声明主要是下面几条：

需要特别注意：“自动识别 80% 以上的问题”是厂商自述口径，并非在公开可复现的基准测试里测出来的数字。README 没有给出这个比例的统计样本、问题分类定义、误报率，也没有第三方复核。它更像是产品能力的一个定性宣传，而不是一个可被证伪的 benchmark——这一点在选型时要单独打折看待。

五、评测方法批判：它根本没有公开性能基准

与 LLRT、Lightpanda 这类会附带 benchmark 的项目不同，Coroot 的 README 没有给出任何关于自身资源开销的量化基准——没有 eBPF agent 在生产节点上的 CPU/内存占用率、没有接入 N 个服务后的存储增长曲线、也没有巡检延迟。官方提供了一个 live demo（demo.coroot.com）供你上手感受，但这只是功能演示，不是性能数据。

这意味着：它宣称的”零埋点省了埋点工程”是真的，但”eBPF 采集本身的开销有多大、ClickHouse 存全量 profile 要吃多少磁盘”这些真正决定自托管成本的数字，需要你在自己的集群里实测，官方资料替不了你。

六、适用与不适用场景

适合：

• 已经跑在 Kubernetes 上、服务数量多、不想为埋点写胶水代码的团队；
• 想要 SLO 追踪 + 发布对比 + 成本下钻这种”开箱结论”，而不是自己拼 Grafana 仪表盘的人；
• 被商业 APM 按主机/按数据量收费卡住、愿意自己运维一套 ClickHouse 的中小团队。

不适合：

• 裸机/非 Kubernetes 环境下想要完整发布追踪的场景（Deployment Tracking 依赖 K8s 发现发布）；
• 对 eBPF 内核版本有要求的老内核宿主（eBPF 能力受内核版本制约）；
• 期待它直接替代全链路 tracing 后端、做精细自定义 span 分析的团队——它的强项是自动巡检与关联，不是极致灵活的手动 instrumentation。

七、客观分析：优势与局限

优势：

1. 零埋点确实降低了接入门槛：eBPF 对遗留系统和第三方服务友好，这是它对比纯 OpenTelemetry 方案最实在的差异；
2. 从”看数据”到”给结论”：预置 inspection + 单条聚合告警，符合运维想要的”少看仪表盘、多接结论”；
3. 成本与发布视角是差异化：把云账单和发布对比接进可观测性闭环，同类开源工具里少见；
4. Apache 2.0 + Go：协议友好、可自托管、无商业锁定。

局限：

1. 核心宣传数字缺公开基准：80% 问题识别率、100% 覆盖率都没有可复现的测量方法；
2. 自身开销不透明：官方未公开 agent CPU/内存与存储占用基准，自托管 TCO 需要自行压测；
3. 能力偏 K8s 与云厂商绑定叙事：成本监控只覆盖 AWS/GCP/Azure，发布追踪依赖 Kubernetes 发现；
4. 高级能力分企业版：README 底部单独挂了 Coroot Enterprise，开源版与企业版的边界需要以官方文档为准。

八、谁该关注

如果你正被商业 APM 的账单压着、又不想从零搭一套 Grafana+Loki+Tempo+Pyroscope 的全家桶，Coroot 代表了一条”eBPF 自动取数 + 预置规则给结论”的务实路线。但选型时务必在预发环境实测两件事：eBPF agent 在你的内核与业务负载下的真实开销，以及”自动识别 80% 问题”在你自己故障样本上的命中率——官方口径不能直接当验收标准。

参考来源

• Coroot 官方 GitHub 仓库
• Coroot 官方文档
• Koala 项目库条目：Coroot | 开源 eBPF 可观测性工具