在做 Java 应用监控时，SkyWalking 几乎是绕不开的选择。
功能完整、社区成熟、链路清晰，是它最大的优势。

但在真实项目中，我最终没有选择 SkyWalking，而是自己写了一个 Java 方法级监控探针。

这篇文章不做情绪化对比，也不“拉踩”，我只从一个工程实践者的角度，回答一个问题：

它到底轻在哪里？代价又是什么？

---

一、先明确一个前提：我不是在造 SkyWalking 的轮子

在开始之前，先把边界说清楚。

我做的这个东西，并不是一个完整 APM，它刻意不做这些事情：

• ❌ 不做分布式 Trace 编排
• ❌ 不做 Service Map
• ❌ 不做复杂上下文传播
• ❌ 不做可视化大盘（至少目前不做）

我真正想解决的只有一件事：

“某个方法，在真实运行中，到底慢不慢、稳不稳、有没有异常”

一旦目标足够收敛，很多东西就可以“不要”。

---

二、接入成本：最直观的“轻”

SkyWalking 的接入成本

以最常见的 Java Agent 方式为例，你至少需要：

1. 部署 OAP
2. 选型存储（ES / ClickHouse / H2）
3. 配置 Agent
4. 理解插件机制（Spring / Dubbo / MySQL 等）
5. 处理 Trace、Service、Endpoint 的概念映射

哪怕你只是想看一个接口慢不慢，也绕不开这一整套体系。

---

我的探针：只做一件事

我现在的接入成本是：

-javaagent:pulse-agent.jar

“结束。

不需要：

• 额外服务

• 复杂配置

• 理解 APM 模型

👉 你关心什么，就监控什么。

---

三、性能开销：为什么我敢说“更轻”

SkyWalking 的开销来源（客观存在）

SkyWalking 的能力，决定了它的成本：

• Trace Span 创建与上下文维护

• 线程上下文传播

• 插件拦截链

• 异步上报与序列化

• 多维指标聚合

这些并不是“写得不好”，而是功能决定的必然成本。

---

我的探针在做什么？

我的探针只在方法边界做三件事：

1. 记录开始时间

2. 执行原方法

3. 记录结束时间 / 异常

核心逻辑类似这样（简化）：

java

复制代码

long start = System.nanoTime(); try { return zuper.call(); } catch (Throwable t) { throw t; } finally { long cost = System.nanoTime() - start; report(cost, success, exception); }

并且：

• 上报是异步

• 队列满了可以直接丢

• 不影响业务线程返回

👉 没有 Span、没有 Trace 树、没有上下文传播

---

四、配置复杂度：轻 ≠ 功能少，而是“少决策”

SkyWalking 的配置特点

SkyWalking 的配置并不算“难”，但它需要你做很多决策：

• 采样率

• 插件开关

• 存储后端

• 指标保留周期

• Trace 是否全量

这些决策本身，就会消耗心智。

---

我的探针：几乎没有策略配置

当前配置项只有：

properties

复制代码

monitor.enabled=true monitor.collect.args=false monitor.queue.capacity=10000 monitor.batch.size=100

没有：

• 采样率（默认全量，你自己决定标哪些方法）

• 插件系统

• 指标维度选择

👉 控制权从“平台策略”回到了“开发者标注”

---

五、运行模型的差异：为什么“轻”是结构性的

SkyWalking 的运行模型

mathematica

复制代码

应用 └─ Agent └─ Plugin └─ Span └─ Trace └─ OAP └─ Storage

它天然适合：

• 微服务

• 分布式系统

• 全链路分析

---

我的探针模型

markdown

复制代码

应用 └─ Agent └─ Method Interceptor └─ Event └─ Queue

它天然适合：

• 单体应用

• 中小服务

• 性能敏感系统

• 本地 / 私有部署

模型决定了“轻不是优化出来的，而是设计出来的”。

---

六、那代价是什么？我不回避

我这个探针做不到的

• ❌ 看不到跨服务调用

• ❌ 无法自动发现慢接口

• ❌ 没有现成的大盘和告警生态

• ❌ 不适合复杂微服务体系

所以我从来不建议：

“用它完全替代 SkyWalking”

---

七、那我为什么还是要写？

因为在我的场景里：

• 我更关心 “某些关键方法”

• 我更在意 性能扰动

• 我希望 接入成本无限低

• 我不想为了 10% 的需求，承担 90% 的复杂度

于是我选择了：

为一个明确问题，写一个明确工具

---

八、适用场景总结（非常重要）

更适合用 SkyWalking 的场景

• 微服务体系

• 全链路分析

• 运维主导

• 成熟平台化建设

更适合我这个探针的场景

• 单体 / 小规模服务

• 性能敏感系统

• 开发自测 / 定位问题

• 想“只看方法，不看宇宙”

---

九、写在最后：轻量不是目的，克制才是

我不认为 APM 越轻越好。

但我越来越确定一件事：

很多时候，我们并不是需要“更强的工具”，
而是“更贴合问题的工具”。

---

留一个问题，欢迎你在评论区聊聊：

• 你现在用的 APM 是什么？

• 你最不满意它的哪一点？

• 如果只保留一个功能，你会保留什么？”