竞品对比 — 为什么选择 dlz-lens
市面上不缺监控工具，但 dlz-lens 的定位和它们都不一样。
总览对比表
| 能力 | SkyWalking | ELK | Druid | P6Spy | dlz-lens |
|---|---|---|---|---|---|
| TraceID 串联 | ✅ | 要自己打 | ❌ | ❌ | ✅ |
| 精确到代码行 | ❌ 方法级 | ❌ | ❌ | ❌ | ✅ 行号+IDE跳转 |
| SQL 参数值 | ❌ | 要自己打 | ⚠️ 部分 | ✅ | ✅ 结构化 |
| 自动诊断（N+1/事务） | ❌ | ❌ | ❌ | ❌ | ✅ |
| 一键跳 IDE | ❌ | ❌ | ❌ | ❌ | ✅ |
| 嵌入式零部署 | ❌ Agent | ❌ 全套 | ✅ | ⚠️ 配代理 | ✅ 一个jar |
| Redis/HTTP 同屏 | ⚠️ 看配置 | ❌ | ❌ | ❌ | ✅ |
| 故事回放视图 | ❌ | ❌ | ❌ | ❌ | ✅ |
| 业务线程开销 | 中（μs级） | 中（日志IO） | 中 | 高 | 极低（ns级） |
| 接入成本 | 高 | 很高 | 低 | 中 | 极低 |
逐项解读
TraceID 串联
- SkyWalking：✅ 原生支持，全链路追踪
- ELK：⚠️ 需要你自己在日志里打 traceId（用 MDC 等），而且只能关联日志，不能结构化聚合
- Druid / P6Spy：❌ 没有 Trace 概念，只能看到单条 SQL
- dlz-lens：✅ 开箱即用，WebTraceFilter 自动绑定，不需要改代码
精确到代码行
这是 dlz-lens 最大的差异化优势。
- SkyWalking：只能定位到方法级（类名+方法名），不知道具体哪一行
- ELK：日志里打了类名和行号才有，而且是"日志打印的行"不是"SQL执行的行"
- Druid / P6Spy：完全没有调用者概念
- dlz-lens：精确到行号，点击直接跳 IDE。不是方法级，是行号级
SQL 深度信息
- SkyWalking：只有 SQL 语句和耗时，没有参数
- ELK：完全取决于你打了什么日志。大部分团队不打参数（性能+安全考虑）
- Druid：有 SQL 和执行次数统计，但参数信息不全
- P6Spy：有 SQL 和参数，但只是拼好的字符串，不是结构化的
- dlz-lens：完整的 SQL + 结构化参数列表（值 + 类型），可以直接复制重放
自动诊断
- SkyWalking：有告警规则，但没有 N+1 检测、事务风险检测这类业务层诊断
- ELK：完全靠你自己写查询和告警
- Druid：有慢 SQL 统计，没有智能诊断
- P6Spy：没有诊断能力
- dlz-lens：内置 N+1 检测、慢调用标记、事务风险检测、错误高亮——常见问题自动标出来
一键跳 IDE
- SkyWalking / ELK / Druid / P6Spy：都没有。你得自己复制类名，回 IDE 里搜
- dlz-lens：点一下就跳，精确到行号。这是体验上的质的区别
嵌入式零部署
- SkyWalking：需要部署 Collector + ElasticSearch + UI，还要在每个应用加 agent
- ELK：需要部署 ElasticSearch + Logstash + Kibana + Filebeat，一整套很重
- Druid：✅ 嵌入式，加依赖就能用，但功能仅限连接池监控和 SQL 统计
- P6Spy：需要配置驱动代理，改 JDBC URL 或 DataSource 配置
- dlz-lens：✅ 一个依赖 + 一行配置，自动包装 DataSource，自动注册 Filter。零代码侵入
Redis/HTTP 同屏
- SkyWalking：支持但需要配置对应插件，且不同类型的调用在不同页面看
- ELK：不同的日志索引，要分别查
- Druid / P6Spy：只有 SQL
- dlz-lens：所有类型的 IO 调用在同一条时间线上，前后关系清清楚楚
故事回放视图
这是 dlz-lens 独有的核心功能。
- 其他工具都只能看到"一条条的记录"
- dlz-lens 能看到"一个完整的故事"——按 TraceID 聚合的时间线，事务边界、调用顺序、诊断标签，一目了然
业务线程开销
- SkyWalking：微秒级（字节码增强 + 数据上报）
- ELK：取决于日志量，日志 IO 开销较大
- Druid：中等（统计+连接池管理）
- P6Spy：最高——业务线程上做 SQL 格式化、参数拼接、日志写入
- dlz-lens：最低——业务线程只做栈快照+非阻塞入队（~200-500ns），重活全在异步线程
接入成本
| 工具 | 要做的事 | 大概耗时 |
|---|---|---|
| SkyWalking | 部署服务端 + 加 agent + 配置插件 | 半天 ~ 1 天 |
| ELK | 部署 ELK 全套 + 配置 Filebeat + 改日志格式 | 1 ~ 3 天 |
| Druid | 换连接池 + 配置监控 | 1 ~ 2 小时 |
| P6Spy | 改驱动配置 + 改 DataSource | 30 分钟 ~ 1 小时 |
| dlz-lens | 加依赖 + 加一行配置 | 5 分钟 |
和 SkyWalking 的关系
不竞争，是互补。
| 维度 | SkyWalking | dlz-lens |
|---|---|---|
| 定位 | 生产环境全链路 APM | 开发/测试环境调试神器 |
| 部署 | 独立集群部署 | 嵌入式，零部署 |
| 精度 | 方法级 | 行号级 |
| 功能广度 | 全（服务/数据库/缓存/MQ…） | 专（IO 调用调试） |
| 体验 | 大盘+统计为主 | 调试+诊断为主 |
| 性能影响 | 中（需要 Agent） | 极低（纳秒级+异步） |
典型用法：
- 生产环境用 SkyWalking 做监控告警
- 开发/测试环境用 dlz-lens 做调试排障
- 线上出了问题 → SkyWalking 发现哪个接口慢 → 测试环境用 dlz-lens 深入分析定位根因
和 ELK 的关系
不竞争，是不同维度。
ELK 是"日志搜索平台"，dlz-lens 是"IO 调用透视工具"。
| 维度 | ELK | dlz-lens |
|---|---|---|
| 数据来源 | 应用打出来的日志文本 | 调用层拦截的结构化数据 |
| 数据完整度 | 取决于你打了什么 | 第一手完整上下文 |
| 适用场景 | 日志搜索、全文检索、大盘统计 | 调试排障、性能分析、故事回放 |
| 部署方式 | 独立部署，很重 | 嵌入式，零部署 |
| 代码跳转 | 不能 | 点击直达行号 |
典型用法：
- ELK 做全量日志存储和搜索
- dlz-lens 做开发期调试和问题定位
- 两边结合使用，不冲突
和 Druid 的关系
不竞争，Druid 是连接池，dlz-lens 是调试工具。
Druid 的核心价值是连接池管理（监控连接数、活跃连接、等待队列等），SQL 监控只是附加功能。
dlz-lens 不做连接池管理，专注在"调用透视 + 故障诊断"。
两个可以一起用——Druid 管连接池，dlz-lens 做调试。
和 P6Spy 的关系
直接竞争，但 dlz-lens 是全面升级。
| 维度 | P6Spy | dlz-lens |
|---|---|---|
| 核心功能 | 打印 SQL 日志 | IO 调用透视 + 故事回放 + 智能诊断 |
| 调用者定位 | ❌ | ✅ 行号级 + IDE 跳转 |
| 性能影响 | 高（业务线程格式化+写日志） | 极低（异步消费） |
| Web UI | ❌ | ✅ 精美控制台 |
| TraceID 串联 | ❌ | ✅ |
| N+1 检测 | ❌ | ✅ |
| Redis/HTTP | ❌ | ✅（逐步支持） |
如果你现在在用 P6Spy，换成 dlz-lens 是体验上的质的飞跃。
总结：为什么选择 dlz-lens
如果你想要的是：
- 🚀 5 分钟接入，不用部署任何东西
- 🎯 点一下就跳回代码行，不用再搜来搜去
- 📖 看得到完整的调用故事，不是零散的日志
- 🔍 问题自动标出来（慢/N+1/事务风险/错误）
- 🚄 对业务零性能负担（纳秒级开销）
- 🔄 SQL / Redis / HTTP / MQ 都在同一张屏上
那就试试 dlz-lens。加一个依赖，开一个开关，你就知道它有多香。