前言
做 Java 后端开发，线上排查故障离不开可观测三大件：日志 Logs、指标 Metrics、链路 Traces。ELK 和 SkyWalking 是国内开源圈最常拿来对比的两套方案。
很多开发在选型时容易踩两个典型误区：
- 误认为二者属于同类产品，可以直接互相替换；
- 分不清谁更 "重"，盲目全套部署，低配服务器资源耗尽。
前置核心结论： ELK 核心是日志检索系统；SkyWalking 核心是 APM 分布式链路追踪系统。同等单机部署条件下，SkyWalking 整体架构、运维复杂度更高；资源开销要看存储选型。二者不是替代关系，可以单独部署，特定微服务场景可以搭配联动。
可观测三类基础概念回顾
- Logs：业务输出的文本日志，包含业务信息、异常堆栈；
- Metrics：时序指标，QPS、接口耗时、JVM 内存、GC 次数等；
- Traces：分布式调用链路，记录一次请求跨多个服务完整调用过程。
一、两套系统核心定位完全不同
ELK（Elasticsearch + Logstash + Kibana + Filebeat）
定位：集中式日志分析检索平台 ELK 诞生的核心目标，解决海量文本日志的收集、清洗、结构化、全文检索问题。 Filebeat 负责采集业务日志；Logstash 完成过滤、Grok 解析、多行异常合并；Elasticsearch 作为搜索引擎支撑全文检索；Kibana 提供可视化查询与日志仪表盘。
业务无侵入：不需要修改项目 JVM 启动参数，不需要字节码埋点，只读取已经落地到文件的日志文本。
强项：全文检索、复杂异常堆栈查看、日志关键词检索、日志结构化解析。 短板：原生不擅长分布式链路追踪，指标监控能力较弱。
Apache SkyWalking
定位：APM 应用性能监控平台，以分布式链路追踪为核心 SkyWalking 是 Apache 顶级开源国产 APM 项目。整体架构由 Agent 探针、OAP 后端服务、存储层、Web UI 四部分组成。
Java 应用通过-javaagent挂载探针，依靠字节码增强自动埋点，采集接口调用信息、SQL 执行、接口耗时、JVM 指标、服务拓扑，同时附带日志采集能力。
强项：分布式调用链路、服务拓扑图、接口耗时分析、慢 SQL 捕获、JVM 监控、告警能力。 短板：日志全文检索能力远弱于 ELK，复杂堆栈检索、模糊搜索体验有限。
关键区分 ELK：读取已经打印落地的日志文件 SkyWalking Agent：在代码执行阶段拦截，采集调用运行时信息
二、谁更重？从资源开销、运维复杂度两个维度分析
1. 硬件资源开销对比
单机 ELK（docker-compose，ES+Logstash+Kibana+Filebeat）
- ES 堆内存：512M；Logstash 堆内存：512M；Kibana 占用数百 MB；Filebeat 属于轻量组件，仅几十 M。
- 最低运行环境：4G 内存虚拟机即可跑通测试环境。
- 资源压力主要集中在 Elasticsearch，日志量大时 ES 占用会上涨；低日志量场景压力很小。
SkyWalking
SkyWalking 资源消耗取决于后端存储选型：
- 存储选用 H2（仅单机测试，不适合长期生产）：OAP + UI 基础服务内存开销略低于 ELK；但业务应用挂载 Agent，会给 SpringBoot 应用带来额外 CPU、内存开销。采样率越高，业务侧性能损耗越大。
- 存储选用 Elasticsearch（生产推荐方案）：OAP 服务 + UI + ES，等于 SkyWalking 叠加 ES 两套组件。整体内存开销明显大于单机 ELK。
资源层面总结： 存储使用 ES 的 SkyWalking > ELK；H2 单机版 SkyWalking 基础服务内存略轻，但业务应用存在 Agent 性能损耗。
2. 运维 & 学习复杂度（SkyWalking 更重）
ELK 复杂度
难点集中在日志解析环节：Grok 表达式调参、Java 多行异常堆栈合并。 排障链路简短清晰： 采集不到日志 → 排查 Filebeat； 日志解析乱码 / 字段缺失 → 调整 Logstash Grok； 检索不到数据 → 检查 ES 索引。
学习重点：Grok 语法、Kibana KQL 检索。业务侧无需任何改动，上线、下线、扩容操作不会影响业务代码。
SkyWalking 复杂度
除部署 OAP、UI、存储之外，业务应用必须挂载 Java Agent，修改 JVM 启动参数。 需要额外掌握的概念：Trace、Span、Segment、采样策略、服务拓扑、探针拦截规则。 排障链路更长： 接口无链路数据 → 排查 Agent 探针 → 排查 OAP 接收状态 → 排查存储写入。
常见坑点：
- 采样率配置两难：全量采集会快速耗尽存储，低采样率容易丢失故障链路；
- 异步线程、线程池场景 TraceId 丢失，链路断裂；
- 探针字节码增强冲突，和部分第三方依赖包存在兼容性问题。
结论：运维层面 SkyWalking 更重，学习成本、排坑难度高于 ELK。
三、选型：只部署一个？还是两个一起部署？
方案 1：只部署 ELK
适用场景：
- 核心需求：日志集中收集、检索、查看 Java 异常堆栈；
- 单体 SpringBoot、小型项目，无复杂跨服务调用；
- 不想修改业务启动参数，追求低接入成本。
优点：部署简单，业务无侵入，全文检索能力强，4G 虚拟机即可运行。 缺点：没有分布式调用链路、接口耗时统计、服务拓扑能力。
方案 2：只部署 SkyWalking
适用场景：
- 微服务架构，需要排查跨服务调用故障；
- 重点关注接口响应耗时、慢 SQL、JVM 监控、服务依赖拓扑；
- 日志仅作为辅助查看，对全文检索无强需求。
优点：一套平台统一管理链路、指标、日志，中文 UI 友好。 缺点：业务应用需要挂载 Agent，存在接入成本；日志检索能力弱于 ELK；探针会带来一定性能开销。
方案 3：ELK + SkyWalking 同时部署
中大型微服务生产环境的经典组合，二者分工明确：
- SkyWalking：查看调用链路、接口耗时、服务拓扑、JVM 指标；链路生成唯一
traceId。 - SpringBoot 日志输出
traceId；ELK 采集日志，通过 traceId 检索单次请求完整日志与异常堆栈。
优势：宏观链路看调用过程，ELK 查看本次请求详细日志，故障定位能力最强。 代价：两套系统都需要部署维护，资源开销最大，虚拟机建议至少 6G 内存起步，低配测试机不推荐。
联动原理：SkyWalking Java Agent 自动将 traceId 注入日志，日志打印 traceId 字段；在 ELK 中以 traceId 作为检索条件，一次性获取整条调用链所有服务日志。
四、对比汇总表
表格
| 对比项 | ELK（Elastic Stack） | SkyWalking |
|---|---|---|
| 核心定位 | 日志集中检索平台 | APM 分布式链路追踪平台 |
| 数据采集方式 | Filebeat 采集日志文件，业务无侵入 | Java Agent 字节码增强，侵入应用 JVM |
| 核心能力 | 日志收集、Grok 结构化、全文检索、异常堆栈 | 分布式链路、服务拓扑、接口耗时、JVM 指标、慢 SQL |
| 日志检索能力 | ⭐⭐⭐⭐⭐ 极强，支持复杂检索、堆栈解析 | ⭐⭐⭐ 基础日志查看，全文检索偏弱 |
| 单机资源消耗 | 4G 内存可正常运行 | H2 存储：基础服务内存低；ES 存储：高于 ELK；业务存在 Agent 开销 |
| 运维复杂度 | 中等，难点 Grok、多行日志 | 较高，需要理解 Trace/Span、采样、探针兼容问题 |
| 适用架构 | 单体、微服务均可，主打日志场景 | 优先微服务分布式系统 |
| 业务改动 | 无需修改业务代码 / 启动参数 | 应用需要增加 - javaagent 探针参数 |
五、生产落地避坑经验
- 不要为了 "全套监控" 盲目同时部署两套。单体项目，仅需查询日志场景，直接使用 ELK 即可，无需引入 SkyWalking 增加复杂度。
- SkyWalking 采样率不要直接设置 100% 全量采集，线上大流量场景存储会快速爆满，常规推荐 10%~50%，故障场景可临时开启全量采样。
- ELK 生产环境不要使用单机 ES，单机 ES 黄色状态仅适合测试环境；生产环境必须搭建集群，同时配置索引生命周期，自动清理过期日志，防止磁盘占满。
- TraceId 联动日志，是组合部署最核心的价值；只使用 SkyWalking 自带日志模块，遇到长堆栈、模糊关键词检索，体验较差。
- 虚拟机测试环境：低配机器优先选择 ELK；内存≥6G，微服务场景，再考虑 ELK+SkyWalking 组合。
六、选型总结
- 需求只是收集 SpringBoot 日志、检索异常堆栈 → 只部署 ELK；
- 微服务，需要查看跨服务调用链路、接口性能瓶颈 → 只部署 SkyWalking；
- 微服务，既要链路追踪，又需要强大日志全文检索、详细异常栈排查 → ELK + SkyWalking 一起部署，通过 traceId 联动。
误区纠正：很多人认为 ELK 很重。ELK 生产集群部署确实重，但是 docker-compose 单机轻量化部署 ELK，门槛很低；SkyWalking 因为 Agent、链路概念、采样策略等因素，整体运维复杂度更高。
七、面试考点：ELK 和 SkyWalking 区别与项目选型
面试问题：ELK 和 SkyWalking 的区别？项目中如何选型？
参考回答： ELK 是日志分析系统，SkyWalking 是 APM 链路追踪系统，二者定位不同。ELK 无侵入采集日志，擅长全文检索；SkyWalking 通过 Java Agent 字节码埋点，采集调用链路、接口指标。 单体应用只需要查询日志，选择 ELK；微服务需要分布式链路追踪，选择 SkyWalking；企业级微服务可以两者搭配，SkyWalking 查看链路，ELK 检索对应 traceId 的日志。