内容提要
JProfiler团队开源JVMGuard引发关注,但.NET生态已有更优雅的解决方案。.NET从Core 3.0起内置EventPipe诊断架构,dotnet-monitor支持生产环境自动捕获,CLRScope MCP让AI分析诊断数据。两者互补,实现性能问题可观测、可捕获、可回溯,未来将支持全栈追踪。
延伸解读
架构差异:进程内 vs 进程外
JVMGuard 采用 Java Agent 注入进程内,而 .NET 从 Core 3.0 起内置 EventPipe,诊断工具作为外部旁观者通过 IPC 通信。这种进程外设计避免了注入代码对应用的影响,也使得 dotnet-monitor 能以 Sidecar 容器运行,与目标应用共享 PID namespace,实现按需或自动收集诊断数据,架构上更优雅。
自动抓取现场:Collection Rules 实战
dotnet-monitor 的 Collection Rules 允许配置触发条件和动作,例如当 CPU 持续 1 分钟超过 80% 时自动抓取 30 秒 Trace 和 Full Dump。这种自动化能力与 JVMGuard 的“平时 lightweight,出事 heavyweight”理念一致,但无需人工干预,更适合生产环境。
AI 诊断:CLRScope MCP 的落地
CLRScope MCP 基于 MCP 协议,让 AI 代理直接分析 .NET 进程,内置四种一键诊断工作流,并支持堆分析定位对象持有者。它与 dotnet-monitor 互补:生产环境自动捕获,本地 AI 分析,形成完整链路。这比 JProfiler MCP Server 覆盖更全面,体现了 .NET 生态在 AI 诊断上的进展。
未来趋势:全栈追踪
随着 .NET 10 中 EventPipe 对 user_events 的支持,未来 .NET 的托管事件将与内核事件、Native 事件统一收集,实现真正的全栈根因分析。这意味着 AI 代理可以从用户代码追踪到系统调用,进一步提升诊断的深度和广度。
Q&A
JVMGuard 是什么?它和 JProfiler 有什么关系?
JVMGuard 是 ej-technologies(JProfiler 的开发公司)在 2026 年 8 月开源的生产环境 JVM 监控与 Profiling 工具。它采用 Server(Web UI)+ Java Agent 的双层架构,支持低开销日常监控和按需深度捕获,并具备授权和审计日志功能。
.NET 生态中有没有类似 JVMGuard 的生产环境诊断工具?
有,.NET 生态中的 dotnet-monitor 就是微软开源的生产环境诊断工具,定位与 JVMGuard 几乎一致。它基于 .NET 内置的 EventPipe 架构,无需注入代码即可按需或自动收集诊断产物,如 trace、dump、gcdump 等。
dotnet-monitor 如何实现自动捕获性能现场?
dotnet-monitor 通过 Collection Rules 实现自动捕获。例如,可以配置当 CPU 使用率持续 1 分钟超过 80% 时,自动抓取 30 秒的 trace 和 full dump。这些规则基于 EventCounter 触发,并执行相应的收集动作。
EventPipe 是什么?为什么说它是 .NET 诊断架构的核心?
EventPipe 是 .NET 运行时内置的诊断架构,从 .NET Core 3.0 开始引入。它采用三层架构:运行时层(GC、JIT、ThreadPool 等)通过 EventPipe 聚合器将事件序列化为 .nettrace 格式,通过 IPC 通道(Named Pipe、Unix Domain Socket 等)暴露给外部工具。这使得诊断工具可以以外部旁观者的身份工作,无需注入代码,是 .NET 诊断能力的基础。
CLRScope MCP 是什么?它如何帮助 AI 分析 .NET 诊断数据?
CLRScope MCP 是一个基于模型上下文协议(MCP)的 .NET 诊断服务器,它让 LLM 代理(如 Claude、Cursor)能够直接对 .NET 进程进行深度分析,包括性能剖析、内存泄漏检测等。它内置了资深工程师的诊断工作流,支持一键诊断(如 CPU 性能、内存分析),并能通过自然语言触发。
dotnet-monitor 和 CLRScope MCP 是什么关系?
它们是互补的上下游关系。dotnet-monitor 负责在生产环境自动捕获诊断数据(如 .gcdump、.nettrace),而 CLRScope MCP 负责分析这些数据,让 AI 能够理解并给出诊断结论。两者结合可以实现从数据采集到智能分析的完整链路。
.NET 开发者如何搭建类似 JVMGuard 的自动诊断能力?
建议使用 dotnet-monitor 作为 Sidecar 容器与应用共享 PID namespace,配置 Collection Rules 自动捕获诊断数据。同时,可以结合 CLRScope MCP 进行 AI 分析。在 Kubernetes 中,可以在同一 Pod 中添加 dotnet-monitor 容器,并设置环境变量如 DOTNET_MONITOR_DiagnosticPort__ConnectionMode=Listen。
JVMGuard 和 dotnet-monitor 在架构上有什么本质区别?
JVMGuard 采用进程内 Java Agent 路线,需要注入 agent 到 JVM 中;而 dotnet-monitor 基于 .NET 内置的 EventPipe,采用进程外旁观者模式,无需注入代码。这是由运行时架构差异决定的,两者各有优劣。