JVM 检查（Inspections）全解析：从指标采集到 eBPF/async-profiler 剖析

JVM 检查Inspections全解析从指标采集到 eBPF/async-profiler 剖析【免费下载链接】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/corootJVM 是 Coroot 观测体系中最成熟的运行时之一coroot-node-agent在节点上自动采集每个 JVM 的指标无需任何额外配置即可生成完整的 JVM 检查报告在此基础上结合 eBPF 与 async-profiler 两套剖析方案可以进一步获得可读的 CPU 火焰图、内存分配与锁竞争分析。本文以 docs/docs/inspections/jvm.md 为主体结合源码链路讲清 JVM 检查的每一项能力、图表含义、阈值逻辑以及两种 profiling 方案的开启前提与取舍。JVM 检查零配置的运行时体检Coroot 的 JVM 检查Inspection完全建立在coroot-node-agent自动采集的 JVM 指标之上。凡是运行在节点上的 JVM 进程无论是否容器化都会被自动纳入监控范围基础 JVM 监控无需任何配置。从实现上看节点上的采集工作由 collector 完成采集到的指标在 Coroot 服务端由 constructor/jvm.go 的loadJVM()统一装配以jvm标签为键把同一 JVM 归并到对应实例并挂载到应用Application的Instances[*].Jvms映射上见 model/instance.go。一个应用是否被视为 JVM 应用正是依据该映射是否非空来判断见 model/application.go 的IsJvm()。采集阶段会从 Prometheus 拉取 12 个container_jvm_*指标查询定义见 constructor/queries.go采集指标处理后字段用途container_jvm_info含java_version标签JavaVersion实例表展示 Java 版本container_jvm_heap_used_bytesHeapUsed堆使用量container_jvm_heap_max_size_bytesHeapMaxSize堆上限对应-Xmxcontainer_jvm_gc_time_seconds按gc标签分组GcTime各垃圾回收器耗时container_jvm_safepoint_time_secondsSafepointTimesafepoint 停顿时间container_jvm_safepoint_sync_time_secondsSafepointSyncTimesafepoint 同步时间container_jvm_alloc_bytes_totalAllocBytes分配字节数async-profilercontainer_jvm_alloc_objects_totalAllocObjects分配对象数async-profilercontainer_jvm_lock_contentions_totalLockContentions锁竞争次数async-profilercontainer_jvm_lock_time_seconds_totalLockTime锁等待时间async-profilercontainer_jvm_profiling_statusProfilingEnabled是否已启用 async-profiler其中速率类指标GC、safepoint、分配、锁在查询阶段即通过rate(...[$RANGE])转换为每秒速率并统一使用平均值填充WithFillFunc(timeseries.FillAvg)。值得注意的细节是jvmName()constructor/jvm.go当进程名以.jar结尾时Coroot 会取 jar 文件名如my-service.jar作为展示名否则取主类名的最后一段去掉包名前缀使图表与实例表更易读。最终auditor/jvm.go中的appAuditor.jvm()把上述指标渲染成检查报告AuditReportJvm报告名常量见 model/audit_report.go。两项内置检查可用性与 Safepoint 停顿JVM 报告包含两条检查Check它们的定义与阈值都在 model/check.go 中JVM availabilityJVM 可用性类型CheckTypeItemBased基于实例逐项检查默认阈值0判定条件不可用的 JVM 实例数量 阈值判定依据Jvm.IsUp()的实现非常朴素——只有当堆使用量HeapUsed.Last() 0时才认为实例存活见 model/jvm.go即有堆指标即为存活。检查逻辑位于 auditor/jvm.go对每个实例下每个 JVM若实例未过期!IsObsolete()、Pod 未成功退出!IsSucceeded()且IsUp()为 false则记为一条告警项。同时生成的实例表Instance / Status / Java version 三列会以红色 down (no metrics) 标注失联实例绿色 up 标注正常实例。JVM safepointsSafepoint 停顿类型CheckTypeItemBased默认阈值0.05秒/秒即平均每秒有 0.05 秒处于 safepoint 停顿判定条件safepoint 停顿时间 阈值告警文案high safepoint time on ...见 model/check.gosafepoint 是 JVM 进行 GC、偏向锁撤销、线程 dump 等操作时必须暂停所有应用线程的全局同步点。如果应用频繁触发 safepoint 或单个 safepoint 耗时过长例如存在大量的类卸载、巨型对象分配或某些 JDK 版本下的已知问题就会表现为应用周期性卡顿。这条检查与GC time、Safepoint time两个图表绑定在同一个 widget 下见 auditor/jvm.go告警时可直接在图上定位停顿来源。阈值可在告警规则配置中调整且两条检查都能直接用于告警规则见 model/alerting_rule.go 中基于Checks.JvmAvailability与Checks.JvmSafepointTime的规则引用。图表组堆、GC 与 Safepoint 时间线JVM 报告内置三组核心图表auditor/jvm.go 中的GetOrCreateChartGroup/GetOrCreateChart调用Heap size堆大小堆图表按每个 JVM 实例一条序列展示overview视图各实例的堆使用量HeapUsed叠加展示单实例视图蓝色 used 序列堆使用量并叠加 total 阈值线HeapMaxSize对应-Xmx配置的堆上限一眼即可看出堆是否逼近上限、是否需要扩容或排查内存泄漏。GC timeGC 耗时按垃圾回收器gc标签如 G1 Young Generation、G1 Old Generation、ZGC 等拆分为多个子图每个子图叠加各实例的 GC 速率秒/秒。当 GC 时间异常升高时结合 safepoint 检查与下方 GC 图即可判断停顿是否由 GC 引起。Safepoint timeSafepoint 停顿时间各实例的 safepoint 停顿速率序列与 safepoint 检查告警直接联动。基础三图即可完成 JVM 健康体检若节点上未启用 async-profiler报告顶部会显示配置提示ConfigurationHint——Enable async-profiler to get Java CPU, memory allocation, and lock contention profiles and metrics见 auditor/jvm.go引导用户开启更丰富的剖析能力。启用 async-profiler 后的扩展图表当对应 JVM 实例的container_jvm_profiling_status指标大于 0即ProfilingEnabledtrue见 constructor/jvm.go时JVM 报告会额外出现两组图表Allocation rate分配速率bytes/second每秒分配字节数objects/second每秒分配对象数。Lock contention锁竞争contentions/second每秒锁竞争次数delay, seconds/second每秒锁等待时间。关键交互这两组图表的每个子图都带有下钻链接DrillDownLink点击后跳转到对应应用的 Profiling 报告并直接定位到内存分配ProfileCategoryMemory或锁竞争ProfileCategoryLock的火焰图见 [auditor/jvm.go](https://link.gitcode.com/i/df9e831169efc26d8005cf668a150847#L29-L35、L88-L97。这正是指标看趋势、火焰图看细节的完整闭环。如何启用 async-profiler在节点 Agent 上设置--enable-java-async-profiler启动参数或通过环境变量ENABLE_JAVA_ASYNC_PROFILERtrue开启。在 Coroot 自定义资源中配置方式如下apiVersion: coroot.com/v1 kind: Coroot spec: nodeAgent: env: - name: ENABLE_JAVA_ASYNC_PROFILER value: true完整的启用流程、兼容性与开销说明见 docs/docs/profiling/java-profiling.mdagent 通过 JVM Attach API 动态加载 async-profiler无需改动 Java 应用、无需 JVM 参数、无需重启。需要说明的是该方案支持 HotSpot 系 JVMOpenJDK / Oracle JDK / Amazon Corretto 等OpenJ9 不支持推荐 JDK 11支持 x86_64 与 ARM64且不需要perf_event_open等特权能力。eBPF 剖析 Java 的符号化原理除了 async-profilerCoroot 还内置基于 eBPF 的 CPU 剖析器见 docs/docs/profiling/ebpf-based-profiling.md在无需任何配置的情况下持续剖析节点上所有进程。但 Java 应用有一个特殊问题JVM 重度依赖 JIT 编译运行时生成的本地代码默认不携带符号信息导致 eBPF 在内核层抓到的栈是乱码地址。要让火焰图可读JVM 必须通过jcmd pid Compiler.perfmap导出符号映射perf map 文件。Coroot 的 agent 会在后台周期性自动执行jcmd检测到-XX:PreserveFramePointer标志后约每分钟导出一次 perf map无需用户手工干预且对容器化应用同样生效。但前提是-XX:PreserveFramePointer该标志要求 JVM 在 JIT 编译时保留帧指针从而得到准确的栈回溯与 JIT 代码符号化。其代价是 1%–3% 左右的性能开销属于可接受的常规取舍。因此两条 Java 剖析路线的适用边界非常清晰维度eBPF 剖析async-profiler前置条件启动参数-XX:PreserveFramePointer节点 Agent 开启--enable-java-async-profiler覆盖范围节点上所有进程含非 Java仅 HotSpot JVMCPU 剖析支持需保留帧指针支持无需帧指针使用itimer无 safepoint bias内存分配 / 对象不支持支持TLAB 分配事件锁竞争不支持支持JavaMonitorEnter阈值 10ms额外指标无提供分配速率与锁竞争时间序列指标性能开销内核采样开销极小 帧指针 1%–3%每个被剖析 JVM 约 1%–2%简单来说只关心 CPU 热点且能接受 1%–3% 开销时eBPF -XX:PreserveFramePointer是零部署成本的选择需要无帧指针的 CPU 剖析、内存分配与锁竞争分析时则启用 async-profiler并在 JVM 检查报告中直接获得对应的分配速率与锁竞争图表及其火焰图下钻。总结Coroot 的 JVM 检查把零配置的基础体检与可选的深度剖析整合在同一份报告中默认即可获得 JVM 可用性、safepoint 停顿两项检查以及堆大小、GC 时间、safepoint 时间三组图表开启 async-profiler 后追加分配速率与锁竞争两组图表并可一键下钻火焰图。数据链路从 collector 的container_jvm_*指标constructor/queries.go经 constructor/jvm.go 装配为model.Jvmmodel/jvm.go最终由 auditor/jvm.go 渲染为检查报告全程无需手写任何配置——这正是 Coroot 开箱即用 设计理念在 JVM 可观测性上的完整落地。【免费下载链接】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），仅供参考