资讯动态

Coroot eBPF 持续 Profiling:免代码改动的节点级 CPU 火焰图与符号化优化

发布时间:2026/9/16 11:06:19 来源:尧图企业网站定制
Coroot eBPF 持续 Profiling免代码改动的节点级 CPU 火焰图与符号化优化【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot本篇讲解 Coroot 内置的 eBPF 持续 CPU Profiling 能力coroot-node-agent如何直接在节点上抓取所有进程的调用栈、与容器元数据关联并上报以及针对 Java-XX:PreserveFramePointer与 Node.jsperf map 选项的符号化增强方式最后介绍如何按进程粒度关闭 profiling 并调优上报开销。读完后你可以零侵入地为任意语言的应用建立节点级 CPU 火焰图并在遇到 JIT/解释型语言栈帧丢失时正确配置符号化。工作原理node-agent 内建的 eBPF CPU ProfilerCoroot 的coroot-node-agent内置了一个基于 eBPF 的 CPU profiler。它持续continuously对节点上运行的所有进程进行采样 profiling将采样到的调用栈与容器的元数据即进程属于哪个 Pod、哪个容器进行关联然后把结果发送到 Coroot collector 侧。整体 profiling 栈由以下组件组成参见 Profiling 概览coroot-node-agent监视节点上运行的进程通过内核态 eBPF 程序采集 CPU 调用栈node-agent 文档中说明其使用的是 Pyroscope 的 eBPF profiler通过自定义 HTTP 协议发送见 coroot-node-agent 配置文档Coroot 服务端collector接收 profile 数据并做批处理写入ClickHouse作为 profile 数据的存储后端Web 界面按应用查询 profile 并渲染为 FlameGraph 供分析。使用 Helm 安装 Coroot 时以上组件会被自动安装并相互集成通常无需为 eBPF profiling 做任何额外配置——这就是out of the box的含义。需要明确的一点是eBPF 方式只能采集 CPU profile。如果要采集内存分配、锁竞争等其他 profile 类型需要依赖语言专属 profiler如 Go 的 pprof、Java 的 async-profiler这是 Coroot 中 eBPF profiling 与语言专属 profiling 的分工边界。从源码看数据链路服务端入口是 collector/profiles.go 中的Profiles处理器通过请求头中的 API Key 解析出 project再校验查询参数中的service.name必填使用github.com/google/pprof/profile解析请求体中的 pprof 格式 profile第 44 行profile.Parse(r.Body)ProfilesBatch.Add将 profile 展开为逐样本记录把每个 location/line 拼成函数名 文件名:行号的栈帧序列并用 FNV-64a 计算StackHash第 191-197 行StackHash函数数据按limit行数或定时器批量写入 ClickHouse 的profiling_stacks去重后的调用栈与profiling_samples时间区间、类型、labels、数值、栈哈希两张表第 153-189 行save方法。也就是说node-agent 上报的 pprof profile 在服务端被拆解为栈 样本两层存储火焰图查询时可以按栈哈希聚合、去重。在 profile 类型定义上eBPF 采样的 CPU profile 对应 model/profile.go 中的ProfileTypeNodeAgentCPU ProfileType ebpf:cpu:nanoseconds其在 UI 中的展示名为CPU (eBPF)类别为 CPU、聚合方式为 sum、NodeAgent: true即按节点实例/容器维度过滤。Java 应用的符号化-XX:PreserveFramePointer对 JVM 应用来说eBPF 只能采到原生栈帧JIT 编译后的 Java 方法默认没有稳定的帧指针信息直接采样得到的栈是缺失或不可读的。解决办法是让 JVM 暴露 JIT 符号perf map-XX:PreserveFramePointer在 JVM 启动参数中加上该 flag 后Coroot 的 node-agent 会自动检测到该 flag 的存在检测到后agent 会每分钟周期性调用一次 JVM让其 dump 出 perf map 文件agent 再用这份 perf map 把采样的栈帧地址翻译成具体的 Java 方法名。文档明确说明该流程在容器化场景下可以无缝工作无需在应用内做其他改动。-XX:PreserveFramePointer会轻微影响 JIT 生成的代码质量保留帧指针换来可读的采样栈。如果你不想加这个 JVM flag或者还需要 Java 的内存分配、锁竞争 profile可以参考 Java profiling with async-profilernode-agent 可以动态加载 async-profiler 到 HotSpot JVM同样无需改应用。Node.js 应用启用 perf map 文件Node.js 同样支持生成 perf map 文件来改善符号化质量。启动 Node.js 进程时加上以下两个选项--perf-basic-prof-only-functions --interpreted-frames-native-stack加上这两个 flag 后Node.js 进程会自动维护自己的 perf map 文件Coroot 的 node-agent 检测到该文件后即会读取并用于把解释型帧解析为具体函数名。与 Java 不同这里无需 agent 周期性触发 dump——perf map 由 Node.js 进程自身持续维护。按进程粒度关闭 eBPF Profiling如果某些进程不适合被采样例如安全敏感进程、不希望引入任何内核观测的程序可以对该进程设置环境变量COROOT_EBPF_PROFILINGdisabled其判定机制是Coroot agent 会检查每个进程的/proc/pid/environ文件发现该变量被设置时即跳过对该进程的 profiling。由于读取的是进程自身的环境空间这一控制是按进程精确生效的且 node-agent 的容器环境变量文档 将其归类为容器级控制项——在 Kubernetes 里只需给目标容器的 env 加上这一项即可。上报调优剪枝与上报端点为降低网络流量和 Coroot 侧的 profile 摄取内存占用node-agent 在上传前会先对 profile 做剪枝占比低于 0.25% 总采样量的调用栈会被截断。对应参数来自 coroot-node-agent 配置表Flag环境变量默认值说明--profiles-prune-fractionPROFILES_PRUNE_FRACTION0.0025丢弃占 profile 总量低于该比例的次要代码路径0表示禁用剪枝--profiles-endpointPROFILES_ENDPOINT–自定义 profile 上报 URL不指定时使用--collector-endpoint统一端点文档解释了这个默认剪枝策略不影响 UI 呈现火焰图本来就会隐藏占比极小的帧而被截断栈的采样值保留在其父帧上因此聚合结果不变。如果你的场景需要完整的长尾栈可以把PROFILES_PRUNE_FRACTION调小甚至置0。在 UI 中查看 eBPF Profile 结果所有 profile 都可以在应用详情页的Profiling标签页访问eBPF 采样的 CPU profile 在其中显示为CPU (eBPF)类型。CPU 和 Memory 标签页也提供了到对应 profile 的快捷入口。火焰图的组织方式每个帧代表一个函数消耗的 CPU 时间帧越宽代表消耗越多下方的帧代表嵌套调用同一包名的函数共享颜色。默认展示所选时间范围内所有 profile 的聚合火焰图也可以在图表上选取时间段切换Zoom模式查看子区间或切换Comparison模式与上一时间段对比——性能劣化的函数标红、改善的标绿详见 Profiling 概览 的 Using profiles 一节。服务端对该视图的渲染逻辑位于 api/views/profiling/profiling.goRender按service.name集合与 profile 类型查询 ClickHouseCPU 类别默认选中 Featured 类型eBPF 类型NodeAgent: true按实例过滤时使用容器 ID 集合第 160-166 行最后由ch.GetProfile生成火焰图树。适用前提与限制结合仓库文档可以归纳 eBPF profiling 的适用边界仅限 Linux 节点node-agent 配置文档 的 Windows 章节明确列明 eBPF L7 tracing 和 profiling 属于 Linux-only 能力Windows agent 不支持仅 CPU 类型eBPF 采集只覆盖 CPU profile内存、锁竞争等需走语言专属 profiler符号化质量依赖运行时Java/Node.js 等 JIT 或解释型运行时在未配置相应 flag 时栈帧可读性会下降需按上文配置 perf map依赖 eBPF 内核支持需要节点内核允许加载 eBPF 程序可参考 安装要求 与 性能影响 两篇文档了解 eBPF 观测对节点资源的影响。小结Coroot 的 eBPF profiling 把无侵入 CPU 采样做成了 node-agent 的默认能力内核态采集 容器元数据关联 pprof 格式上报 ClickHouse 存储 火焰图可视化全链路无需改代码。需要开发者介入的只有两处JVM 加-XX:PreserveFramePointer、Node.js 加 perf map 选项以及用COROOT_EBPF_PROFILINGdisabled按需豁免个别进程。配合--profiles-prune-fraction控制上报开销即可在大规模节点上长期开启持续 profiling。【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价