应用性能监测（APM）之 前世今生（一）

目录

一、APM核心定义与两大核心数据体系

1.1 APM基础概念

1.2 Metrics（指标数据）核心定义与分类

1.3 Trace & Span（链路追踪）核心定义

二、APM全链路架构

        2.1 组件讲解

2.1.1. 探针（Agent / SDK）

1）SDK（代码埋点）

2）Agent（无侵入探针）

3）eBPF（Extended Berkeley Packet Filter，扩展伯克利包过滤器）

eBPF 探针采集原理

eBPF 探针能采集什么

eBPF 探针短板（非常关键，不能神话 “零侵入万能”）

eBPF 可观测主流开源组件

2.1.2.Collector（采集器）

2.1.3.APM 后端（存储 + 计算层）

2.1.3.1 Metrics 指标后端（时序存储）

2.1.3.2 Trace 链路后端

2.1.3.4. 展示器（UI 可视化层）

2.1.4 概念速查表

2.1.5 常见误区澄清

2.2 Collector核心能力（核心五大功能）

2.3 三大主流开发语言采集方案适配对比

2.3.1 Java语言

2.3.2 Go语言

2.3.3 C++语言

三、APM行业厂商演进：闭源传统厂商到开源云原生体系

3.1 传统闭源商业APM（初代行业方案）

核心架构

核心特点

现状与市场萎缩原因

3.2 国产开源一体化APM：Apache SkyWalking

核心架构

核心核心组件OAP释义

优缺点总结

3.3 国际开源标准体系：OTel + Prometheus + Grafana 生态

组件分工

四、现代两大主流APM架构体系深度对比

4.1 架构一：SkyWalking一体化架构

完整链路

适用场景

核心优势

核心短板

4.2 架构二：CNCF标准LGTM架构（OTel+Mimir+Tempo+Grafana）

完整链路

适用场景

核心优势

核心短板

4.3 架构三：单机简易原型架构（小集群、测试环境）

五、主流存储方案选型：彻底告别ClickHouse+ES传统架构

5.1 传统架构：ClickHouse + ES

5.2 现代替代方案对比

六、行业大厂选型现状与底层逻辑

6.1 海外大厂

6.2 国内大厂选型两极分化

6.3 招聘技术栈底层逻辑

七、全文总结与选型终极建议

一、APM核心定义与两大核心数据体系

1.1 APM基础概念

如果我们写了一简单小程序，那么自己单元测试，压力测试，日志记录一下异常和耗时可能就够用了，但是当系统足够复杂的时候，就需要有一整套系统来监测整体运行情况。这包括服务器本身，也包括了各种应用以及业务运行状态等。

APM（Application Performance Monitoring，应用性能监控）是云原生、微服务架构下的核心可观测基础设施，核心目标是实现分布式应用的性能追踪、故障定位、指标告警与服务治理。微服务架构下，一次用户请求会跨数十个服务、中间件、数据库、网关，传统监控完全无法追踪调用链路。

APM的核心价值，就是打通应用层、服务层、基础设施层的全维度观测数据，实现从“大盘发现异常”到“精准定位代码级瓶颈”的全流程闭环，是互联网企业、云服务商、政企系统稳定性保障的核心底座。

完整的现代可观测体系包含Metrics（指标）、Trace（链路追踪）、Logs（日志）三大支柱，其中Metrics与Trace是APM的核心骨架，日志作为辅助排查手段，三者互补构成完整观测能力。

1.2 Metrics（指标数据）核心定义与分类

Metrics是结构化、可聚合、时序化的数值数据，用于统计系统、服务、业务的长期运行趋势，是告警、大盘观测、容量评估的核心依据，具备写入轻、存储量小、可预聚合、适合统计分析的特点。

Metrics的本质是对系统状态的量化快照，不记录单次请求细节，只输出聚合统计结果，生产中分为四大标准数据模型：

从业务维度划分，Metrics可分为三层：

• 基础设施指标：服务器CPU、内存、磁盘IO、网络流量、TCP连接数、负载、文件句柄数；比如Prometheus + Grafana，面板包含 Gauge 类型的 CPU、内存使用率；Counter 衍生的网络收发速率；Histogram 磁盘 IO 延迟：

  

• 中间件指标：比如向量数据库（Qdrant）、检索引擎（Meilisearch）、大模型服务（Ollama）的QPS、延迟、错误率、并发数；

• 业务自定义指标：比如，RAG检索成功率、Embedding调用耗时、LLM Token吞吐、工具调用次数、业务报错计数器。

1.3 Trace & Span（链路追踪）核心定义

Trace是单次用户请求在分布式系统中的完整调用轨迹，由全局唯一TraceID串联所有调用节点，记录请求从入口到结束的全流程路径、耗时、报错信息、调用参数。

Span是Trace的最小执行单元，代表一次具体的操作，比如HTTP请求、数据库查询、缓存读取、内部函数调用、RPC调用。一条完整的Trace由多个父子嵌套的Span组成，形成有向无环的调用树，精准记录每一步操作的耗时与异常。

Trace 标准可视化形式为瀑布图（Waterfall）：横轴代表时间，横向条块代表 Span，条块长度代表耗时；缩进代表父子调用层级；不同颜色区分不同服务；红色标记异常报错 Span。下面分别展示 Jaeger 与 SkyWalking 的典型界面。

Jaeger 链路示例界面（开源经典 Trace 实现，Tempo 也兼容 Jaeger UI）

Jaeger Trace 详情瀑布图说明：

Jaeger 搜索列表页：可以按服务名、耗时区间、错误 tag 筛选 Trace 列表，再点进去查看完整瀑布。

Jaeger 的特点：UI 完全围绕 Trace 模型设计，不内置指标大盘；可以对接 Mimir/Prometheus 提供 Metrics 告警；存储后端可以用 ES、Cassandra，现在更多搭配 Tempo 做存储。

Apache SkyWalking Trace 示例界面（国内主流 APM）

• Default：瀑布时序视图（最常用）；

• Tree：调用树拓扑图，弱化时间，突出调用关系；

• Statistics：对该 Trace 内所有 Span 做聚合统计，统计各操作最大、平均耗时；

SkyWalking 与 Jaeger UI 关键差异：

Jaeger vs SkyWalking Trace 能力对比表

表格

工程落地要点

Trace的核心价值与Metrics完全互补：

• Metrics看趋势：发现“服务P95延迟飙升、错误率上涨”的宏观异常；

• Trace看细节：定位“具体哪一次请求、哪一个服务、哪一段代码导致延迟过高”的微观根因。

Trace数据具备写入量大、高基数、存储成本高、写多读少的特点，绝大多数链路数据不会被二次查询，仅故障排查时按需检索，这也是Trace与Metrics必须物理分库存储的核心原因。

这里解释一个细节：每个trace都有traceId，一般是uuid或者算法生成的唯一编号，带着这个编号去记录的各个 span 就能在后端组织起来，一般在http业务中，可以在header中传递相关信息；

二、APM全链路架构

2.1 组件讲解

一套完整 APM 系统，逻辑上分为 4 层，从上到下：探针 (Agent/SDK) → Collector 采集网关 → APM 后端存储 & 计算层 → 展示器 (UI 可视化)。 很多人会把探针、Collector、后端、UI 混为一谈，这里把每一层职责、边界、开源组件讲清楚。

【业务应用进程】
      ↓
探针（Agent / SDK）：埋点采集，生成Metrics / Trace / Logs
      ↓网络（OTLP / 私有协议）
Collector（采集网关）：协议转换、批处理、过滤、缓冲、扇出转发
      ↓
APM后端（存储+计算）：接收数据、持久化、聚合计算、告警规则执行
      ↓
展示器（UI）：大盘图表、Trace瀑布图、服务拓扑、告警展示

2.1.1. 探针（Agent / SDK）

运行在业务服务所在机器 / 进程内部，负责生成观测数据，是数据来源。 两种形态：SDK 代码埋点、Agent 无侵入探针。业务探针优先全部采用 OpenTelemetry SDK / OTel‑Java Agent，尽量统一数据协议为 OTLP，不必混用 Jaeger、SkyWalking 私有协议。探针统一使用 OpenTelemetry（OTel）就可以，他们的协议已经成为标准被各个厂商兼容。

OTLP 协议（OpenTelemetry Protocol）

OTLP 是 OpenTelemetry 定义的标准可观测数据协议，传输 Metrics、Trace、Logs 三类信号。

• 序列化：Protobuf；

• 传输：gRPC（推荐） / HTTP‑protobuf；

• 流向：探针主动上报（Push 推送模式），探针把数据发给 OpenTelemetry‑Collector。

1）SDK（代码埋点）

把库编译链接进业务程序，业务代码显式调用 API 埋点。

• Go：go.opentelemetry.io OTel‑Go SDK

• C++：opentelemetry‑cpp

• Java：OpenTelemetry Java SDK 特点：侵入业务代码；可控性强；Go/C++ 没有无侵入方案，只能 SDK 埋点。

2）Agent（无侵入探针）

不修改业务代码，附加到业务进程，拦截框架、RPC、数据库调用自动生成 Span、指标。

• Java：SkyWalking‑Agent、OpenTelemetry‑Java Agent（‑javaagent参数加载）

Java 靠 JVM 字节码增强，就是在类加载器中搞一些小动作，做到无侵入；Go/C++ 编译型语言没有这个能力。

探针只做采集，不做存储、不做复杂聚合、不做告警，尽量轻，不能把业务搞慢。 输出协议：标准 OTLP；或者 SkyWalking、Jaeger 私有协议。

3）eBPF（Extended Berkeley Packet Filter，扩展伯克利包过滤器）

eBPF是 Linux 内核提供的沙箱虚拟机技术，可以在内核中安全执行自定义字节码程序，不需要修改内核源码、不需要加载内核模块，通过 kprobe、uprobe、tracepoint、XDP 等钩子点捕获系统调用、函数执行、网络报文事件博客园。

eBPF 探针不属于业务进程内部，它运行在内核，一般以 Node‑Agent（DaemonSet）形式部署在宿主机 / 节点上，不需要修改、重启业务应用，实现语言无关的数据采集。

eBPF 探针采集原理

eBPF 探针能采集什么

• 全语言网络流量：HTTP、gRPC、SQL、Redis、MQ 请求延迟、错误、请求体；

• 系统层面指标：系统调用耗时、锁竞争、上下文切换、磁盘 IO、TCP 网络延迟；

• 持续性能剖析：CPU 火焰图、线程栈；

• 可以观测闭源程序、第三方中间件、遗留业务，这些业务无法接入 SDK/Agent。

eBPF 探针短板（非常关键，不能神话 “零侵入万能”）

✅工程最佳实践：eBPF 和传统 SDK/Agent 是互补，不是替代。 eBPF 拿到全栈基线观测、网络、内核性能；核心业务链路用 OTel‑SDK 注入业务标签、Trace 上下文，两者数据在 Collector / 后端关联起来，形成完整证据链。

eBPF 可观测主流开源组件

2.1.2.Collector（采集器）

典型代表：OpenTelemetry‑Collector、Grafana Alloy。

不在业务进程内，独立部署的服务，是 APM 体系的中间转发管道。 也就是agent或者进行使用SDK发送采集的信息发送到Collector然后再发送到后端。这样多加一层是有原因的：

✅核心职责：

❗重要：Collector 本身不持久保存历史数据，不做指标聚合，不做服务拓扑，不做告警，只是管道。

部署两种模式

❌不要把 SkyWalking OAP 当成 Collector。OAP 虽然能接收 OTLP，但收到之后转为私有模型，做聚合、存储、拓扑，属于APM 后端，不是转发管道。

2.1.3.APM 后端（存储 + 计算层）

接收 Collector 转发过来的数据，做持久化、时序聚合、Trace 组装、规则计算、告警判断。 Metrics 后端和 Trace 后端通常是两套独立组件。从前文可以得知Metrics展示的图最常用的都是按时间进度看仪表盘情况，而trace都是通过过滤查询比较慢的执行过程原因，一起配合故障处理问题的，所以trace和log在99.9%情况下是没有没查看过的，而且当多用户，多应用情况下，查看trace的span很费算力。所以Metrics 后端和 Trace 后端通常是分开的讨论的，而且一般使用不同的存储方式。

2.1.3.1 Metrics 指标后端（时序存储）

负责保存时序数值，执行 PromQL，做预聚合、告警规则计算。下面是几个常用的产品

• Prometheus：Prometheus 是 CNCF 毕业项目，是云原生领域事实标准的指标采集与单机时序数据库，专注 Metrics 指标，不原生处理 Trace 链路数据。注意：Prometheus 是单机设计，不是分布式集群。数据存在本地磁盘，没有内置分片、多副本、多租户、对象存储能力。数据默认按保留时间自动删除，不适合 PB 级海量、多机房、多租户大厂场景。

• Mimir：Grafana Mimir 是 Grafana Labs 开源、基于 Cortex 演进而来的水平可扩展、高可用、多租户 Prometheus 兼容时序后端存储Grafana。

  定位：只做指标存储与查询，不做抓取（Scrape），不处理 Trace 链路。完全兼容 Prometheus 的数据模型、remote_write协议、PromQL 查询语法，用来解决原生 Prometheus 单机无法扩容、无副本、无多租户、数据不能长期保存的痛点。 许可证：AGPL‑v3，内部业务使用没问题；如果对外改造后作为云服务对外提供，存在合规约束，很多大厂合规会重点评估这一点。

• VictoriaMetrics：VictoriaMetrics（简称 VM），Go 语言开发，Apache‑2.0 开源协议，没有 AGPL 协议约束，是业界主流的 Prometheus 兼容时序数据库，定位为高性能、低资源开销的 Metrics 存储后端，完全兼容 Prometheus 数据模型与 PromQL 语法，解决原生 Prometheus 单机容量、保存周期的痛点。

  补充生态：配套 VictoriaTraces 专门用于存储 Trace 链路数据；VictoriaLogs 用于日志存储，整套栈可以一套生态覆盖 Metrics‑Trace‑Logs 三大可观测信号，对标 Grafana LGTM 栈（Mimir+Tempo+Loki）VictoriaMe…。

• ClickHouse：OLAP 数据库；早期的各种产品比如One-Apm就是用这个数据库来存储数据。好处就是可以自动归并数据。缺点是不适合高并发的查询；用这个数据库需要做的开发还挺多的；

能力：保存 Counter/Gauge/Histogram；支持 PromQL/SQL 查询；内置告警规则执行。

VictoriaMetrics vs Mimir 对比表

2.1.3.2 Trace 链路后端

保存 Span/Trace 数据，按 TraceID 读取完整调用树。

• Tempo：Grafana Tempo 是 Grafana Labs 开源分布式链路追踪后端，属于 LGTM 栈的 Trace 组件，只存储 Trace，不处理 MetricsGrafana。接收 OTLP、Jaeger、Zipkin 协议，一般由 OTel‑Collector 上报 Span 数据，数据以 Parquet 列存格式持久化到 S3 兼容对象存储，无需 ES/Cassandra 等重数据库，存储成本低Grafana。

  支持按TraceID精准查询，内置 TraceQL 可按标签检索链路，Grafana 作为 UI 渲染瀑布图；可自动生成 RED 指标，和 Mimir 指标、Loki 日志互相关联跳转Grafana。支持单体 / 微服务部署，原生多租户。短板：属性全检索性能弱于 ES；强依赖对象存储；不自带服务拓扑，拓扑需要依靠 metrics‑generator 生成。常搭配 OTel‑Collector，与 Mimir 组成拆分式可观测后端。

• Jaeger：CNCF 开源分布式链路追踪系统，Uber 开源捐赠，接收 OTLP、Jaeger‑Thrift、Zipkin 协议，由 Collector 接收 Span 存入外置存储（ES/OpenSearch、Cassandra），Query 服务提供 API 与内置 UI 渲染瀑布图、依赖拓扑图GitHub。支持多种采样策略，擅长按标签、错误、耗时做链路全文检索。现代部署一般用 OTel‑Collector 替代原生 Jaeger‑Agent 做采集转发。无内置 Metrics 与告警，需对接外部监控。缺点：强依赖重型数据库，资源开销高，无原生多租户；新项目常被 Tempo 替代，但 Jaeger‑UI 仍可作为 Tempo 的前端查看链路。

  数据流：OTel‑Collector → Jaeger‑Collector → ES/Cassandra → Jaeger‑UI。

• SkyWalking OAP Server：一体化后端；存储可选用 ES / BanyanDB / ClickHouse；做 Trace 存储 + 指标聚合 + 服务拓扑 + 告警

• Elasticsearch：早期 APM 用来存 Trace，擅长全文检索，但资源开销大。而且ES用过的都知道，各个版本之间不兼容，这个太麻烦了。

区分：

• SkyWalking OAP 是完整一体化 APM 后端：Trace 存储、指标聚合、服务拓扑、告警全部在 OAP 内部完成。

• Mimir 只处理 Metrics；

• Tempo 只处理 Trace，二者是拆分式后端。

2.1.3.4. 展示器（UI 可视化层）

只负责渲染图表，本身不存 Metrics、Trace 原始数据，查询时去拉 APM 后端的数据。

• 对接 Mimir/VictoriaMetrics 拿 Metrics；对接 Tempo 拿 Trace；

• 输出大盘、线图、直方图、Trace 瀑布图；配置告警；

• 自身配置（仪表盘、账号）存在 PostgreSQL/MySQL；时序数据不在 Grafana。

这里给出两套典型完整开源 APM 栈对照，探针用OTel不用犹豫了，核心就是用谁做后端和展示：

方案 A：LGTM（OTel‑Collector + Mimir + Tempo + Grafana）拆分式架构

业务：Go/C++ OTel‑SDK / Java OTel‑Agent 【探针】
      ↓OTLP
OpenTelemetry‑Collector 【采集网关】
  ├‑metrics → Mimir 【Metrics后端】
  └‑traces → Tempo 【Trace后端】
Grafana 【展示器】查询Mimir和Tempo，画大盘、看Trace瀑布图

特点：各层组件解耦，可以单独替换某一层；没有一体化的服务拓扑；Tempo 全文检索弱。

方案 B：SkyWalking 一体化 APM 架构

业务：SkyWalking‑Agent(Java无侵入) / OTel‑SDK(Go/C++) 【探针】
      ↓私有协议 / OTLP
OpenTelemetry‑Collector（可选，做转发处理）
      ↓OTLP
SkyWalking OAP Server 【一体化APM后端：接收、聚合、拓扑计算、存储】
      ↓存储：ES/BanyanDB/ClickHouse
SkyWalking UI 【展示器】

特点：后端一体化，自带服务拓扑、告警；Java 无侵入 Agent 体验好；内部转为私有模型，生态绑定。

2.1.4 概念速查表

2.1.5 常见误区澄清

在现代APM体系中，Collector是整个可观测链路的核心中转站，是打通多语言采集、多协议转换、数据过滤、削峰缓冲、多后端转发的核心组件，也是所有大厂标准化观测架构的统一入口。

2.2 Collector核心能力（核心五大功能）

很多开发者会混淆Collector与APM后端服务，核心区别：Collector只做数据处理转发，不持久化存储、不做聚合分析、不生成拓扑，纯管道型组件。

标准全链路采集流程图

# 多语言业务SDK层（C++/Java/Go）
业务服务埋点 → 输出标准OTLP协议数据
​
# 统一采集管道层
OpenTelemetry Collector，内置如下功能
├─ Receiver：接收OTLP业务数据、抓取中间件/机器Metrics
├─ Processor：批处理、过滤、标签修剪、队列缓冲
├─ Connector：SpanMetrics（链路转指标）
└─ Exporter：多后端分发
  ├─ Metrics数据 → Mimir/VictoriaMetrics
  └─ Trace数据 → Tempo
​
# 可视化与告警层
Grafana（统一UI大盘、链路查询）+ 告警引擎

2.3 三大主流开发语言采集方案适配对比

不同语言的虚拟机、编译特性不同，APM采集方案差异极大，也是企业选型的核心依据：

2.3.1 Java语言

Java拥有无侵入Agent绝对优势，是国内微服务主流选型：

• SkyWalking Java Agent：行业最优解，无需改业务代码，通过-javaagent启动参数即可自动采集SpringCloud、Dubbo、Redis、MySQL等所有中间件调用链路，自动生成服务拓扑、聚合指标，适配国内所有Java生态组件；

• OpenTelemetry Java Agent：标准中立，输出OTLP协议，后端可任意切换，但对国产中间件适配弱于SkyWalking；

• 适用场景：国内Java微服务集群优先SkyWalking Agent，多语言统一标准化场景优先OTel Agent。

2.3.2 Go语言

Go为编译型静态语言，无虚拟机、不支持运行时无侵入埋点，所有采集方案均依赖编译期处理或代码埋点：

• OpenTelemetry-Go SDK：CNCF标准，生态完善、组件齐全，基于Context上下文传递链路，完全解耦后端存储，是Go项目最优标准方案；

• SkyWalking-Go：编译期AST插桩，少代码侵入，但输出私有协议，生态封闭，后端绑定SkyWalking OAP；

• 适用场景：所有Go云原生、RAG、微服务项目，优先OTel-Go SDK。

2.3.3 C++语言

C++一般都是使用SDK自己设计记录的内容，生态最薄弱：

• OpenTelemetry-C++ SDK：唯一稳定标准方案，商用成熟、协议通用，支持全量遥测数据采集；

• SkyWalking C++ SDK（cpp2sky）：社区维护，官方支持弱、文档少、生产案例稀缺，不推荐商用；

• 适用场景：C++服务统一使用OTel-C++ SDK。

三、APM行业厂商演进：闭源传统厂商到开源云原生体系

国内APM行业经历了商业闭源垄断 → 开源方案崛起 → 云原生标准化统一三个阶段，新旧方案的迭代，直接决定了当前企业的技术选型与招聘技术栈。

3.1 传统闭源商业APM（初代行业方案）

代表产品：OneAPM（蓝海讯通）、听云、博睿数据 这是国内最早的商用APM体系，2015–2018年垄断企业市场，对标国外New Relic。

核心架构

自研私有SDK采集 + 私有协议传输 + 后端自研存储（早期MySQL/ES，后期升级ClickHouse）

核心特点

现状与市场萎缩原因

3.2 国产开源一体化APM：Apache SkyWalking

SkyWalking是国内最成功的开源APM项目，Apache顶级项目，免费商用、无License限制，是国内Java微服务集群的主流选型。

核心架构

多语言Agent/OTel采集 → OAP-Server（核心后端） → BanyanDB/ES存储 → 自研UI

核心核心组件OAP释义

OAP全称Observability Analysis Platform（可观测性分析平台），是SkyWalking的核心后端服务。

• 区别于Collector：OAP不仅接收数据，还承担聚合计算、拓扑生成、指标统计、告警分析、数据持久化全能力；

• 核心特性：兼容标准OTLP输入，但数据入库后转为私有内部模型，无法反向输出标准OTLP，存在生态绑定；

优缺点总结

优势：Java无侵入采集无敌、开箱即用拓扑/告警/服务治理、中文生态完善、适配国产中间件、运维简单； 劣势：内部数据模型私有、无法兼容PromQL、多语言标准化弱、不适合云原生统一标准架构。

3.3 国际开源标准体系：OTel + Prometheus + Grafana 生态

这是海外大厂、云原生项目、多语言集群的全球通用标准，完全基于CNCF开源规范，无厂商绑定。

组件分工

四、现代两大主流APM架构体系深度对比

当前行业所有企业架构，最终都会归为一体化SkyWalking架构和CNCF标准LGTM架构两大流派，二者没有绝对优劣，适配场景完全不同。

4.1 架构一：SkyWalking一体化架构

完整链路

多语言采集（Java Agent+Go/C++ OTel SDK）→ OTel Collector → SkyWalking OAP → BanyanDB/ES → SkyWalking UI

适用场景

国内传统Java微服务集群、政企项目、追求低运维成本、快速落地的团队

核心优势

核心短板

4.2 架构二：CNCF标准LGTM架构（OTel+Mimir+Tempo+Grafana）

完整链路

多语言统一OTel SDK → OTel Collector → Metrics写入Mimir（分布式时序存储） → Trace写入Tempo（轻量化链路存储） → Grafana统一可视化、告警

适用场景

云原生多语言集群（Go/C++/Java混合）、互联网新项目、对外云服务、追求标准化无绑定的团队

核心优势

核心短板

4.3 架构三：单机简易原型架构（小集群、测试环境）

OTel 探针 + Jaeger + Prometheus，不部署分布式 Mimir/Tempo，全部单机组件

探针：OTel‑SDK / OTel‑Agent
      ↓ OTLP
OpenTelemetry‑Collector
  ├‑Metrics → Prometheus remote_write（单机TSDB）
  └‑Trace → Jaeger‑Collector，存储后端使用ES单机/Badger
      ↓
Grafana + Jaeger‑UI 分别展示指标、链路

特点：全部单机组件，部署简单，上手成本低； 局限：无高可用、无分片、无多租户；数据有保留时间限制；ES 资源消耗大；仅用于测试、小规模，不适合生产大规模。

简表对比

五、主流存储方案选型：彻底告别ClickHouse+ES传统架构

早期OneAPM、自研APM普遍采用ClickHouse存Metrics、ES存Trace的重型架构，这套架构性能强但运维成本极高，现代开源方案已实现全面替代。

5.1 传统架构：ClickHouse + ES

• ClickHouse：依靠物化视图实现5/15分钟指标预聚合，时序分析性能极强；

• ES：依靠倒排索引实现Trace全文检索、异常日志检索；

• 致命缺点：两套重型集群、需要自研Schema/索引/UI/多租户，运维成本极高，仅大厂自研APM使用。

5.2 现代替代方案对比

六、行业大厂选型现状与底层逻辑

6.1 海外大厂

全员普及LGTM标准架构，Adobe、Unity、Grafana Cloud全部采用OTel+Mimir+Tempo栈，核心原因：标准化、多语言适配、可无限扩容、无生态绑定，契合云原生全球统一规范。

6.2 国内大厂选型两极分化

6.3 招聘技术栈底层逻辑

大厂高频考虑Prometheus/Grafana，极少考虑SkyWalking魔改，核心原因：

七、全文总结与选型终极建议

未完待续，后文讨论相关的协议与存储架构。