!-title: “APM和可观测性到底是啥——写给所有被这两个词搞懵的开发者”series: “Apache SkyWalking实战全解析”episode: 002publish_date: “2026-07-02”author: “技术博客作者”tags: [“APM”, “可观测性”, “Observability”, “分布式追踪”, “Metrics”, “Tracing”, “Logging”]description: “彻底厘清APM与可观测性的区别和联系解读Google Dapper论文的核心思想介绍可观测性三大支柱Metrics/Tracing/Logging帮你建立分布式系统监控的完整知识体系。”prev_article: “文章001_SkyWalking是什么.md”next_article: “文章003_SkyWalking架构全景图.md”–上一篇【第01篇】SkyWalking是什么——从中国联通的救火经历到Apache顶级项目下一篇【第03篇】SkyWalking架构全景图——四大组件的前世今生摘要你有没有遇到过这样的情况面试官问你们公司有没有做可观测性建设你回答有我们用了SkyWalking做APM。“然后面试官追问“APM和可观测性是一回事吗”……然后气氛突然尴尬了。本篇带你把这两个经常被混用的概念彻底搞清楚顺便讲讲Google Dapper这篇奠定分布式追踪基础的经典论文以及为什么SkyWalking要把自己定位为可观测性分析平台而不仅仅是APM工具”。一、从一个类比开始汽车仪表盘 vs. 飞机驾驶舱想象你在开一辆普通家用车。仪表盘上有速度表、油量表、水温表、发动机故障灯。这些信息告诉你车的当前状态够用但如果出了问题你只知道有故障不知道为什么故障。现在想象你在驾驶波音777。驾驶舱里有几百个仪表和按钮不仅显示飞机状态还记录每个系统的历史数据当任何子系统异常时你能立刻知道是哪个部件、为什么、影响范围是什么、历史上有没有类似情况。APM更像汽车仪表盘关注应用当前的性能状态。**可观测性Observability**更像飞机驾驶舱不仅知道是什么还能通过已有数据推断为什么。二、APM的定义应用性能监控APMApplication Performance Monitoring/Management直译是应用性能监控/管理。它的核心关注点是应用的响应时间是多少应用的错误率是多少应用的吞吐量是多少哪些接口是性能瓶颈APM的历史可以追溯到2000年代最早是针对单体Java应用的性能监控通过Agent注入JVM收集方法耗时、数据库查询时间等数据生成性能报告。典型的商业APM产品Dynatrace业界标杆商业APM功能最全价格最贵New RelicSaaS APM简单易用AppDynamics被Cisco收购面向大企业开源APM代表SkyWalking主角中国诞生的Apache顶级项目Pinpoint韩国Naver出品基于HBase三、可观测性的定义来自控制论的概念可观测性这个词来自控制论Control Theory由Rudolf Kálmán在1960年提出原意是一个系统的内部状态能否仅通过观察外部输出来推断。翻译成程序员语言就是当系统出了问题你仅凭系统产生的数据不用加新代码、不用重启服务就能定位根因。注意这个定义的精髓不是你能看到什么而是你能从已有数据推断出什么。┌─────────────────────────────────────────────────────────────┐ │ 可观测性 vs. 监控 的区别 │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 监控Monitoring预先定义我要看什么然后去采集 │ │ 例设置CPU 80%时告警 │ │ 问题你只能发现你事先想到的问题 │ │ │ │ 可观测性Observability收集足够的原始数据 │ │ 在问题发生后能用这些数据回答任意问题 │ │ 例生产出问题通过Trace/Metrics/Logs追溯根因 │ │ 优势能发现你事先没想到的问题 │ └─────────────────────────────────────────────────────────────┘四、可观测性三大支柱Metrics、Tracing、Logging业界公认可观测性由三大支柱构成也叫可观测性黄金三角1. Metrics指标指标是对系统状态的数值化度量通常是聚合后的统计数据。典型指标http_request_duration_secondsHTTP请求延迟分布jvm_memory_used_bytesJVM内存使用量error_rate错误率throughput_rps每秒请求数特点低存储成本只存数字占用空间小适合告警容易设置阈值缺点丢失了细节只知道P99延迟高了不知道哪个请求慢了常见工具Prometheus、InfluxDB、SkyWalking内置指标存储2. Tracing追踪追踪记录一次请求从头到尾的完整路径在分布式系统中尤为重要。一次HTTP请求从Gateway → Service A → Service B → Database的完整路径以及每一跳的耗时就是一条Trace。核心概念Trace一次完整的请求链路由唯一的TraceId标识Span链路中的一个操作单元如调用某个HTTP接口、执行一条SQLParent-Child关系Span之间形成树形结构特点细节丰富能看到具体哪个操作慢了存储成本高每条请求都要记录数据量大采样策略高流量系统通常按比例采样3. Logging日志日志是最传统的可观测性手段记录系统运行过程中的离散事件。日志的核心价值在于非结构化的上下文信息是Metrics和Tracing无法表达的。比如用户ID、业务参数、具体的异常堆栈。现代日志的最佳实践结构化日志JSON格式便于机器解析与Trace关联在日志中注入TraceId通过MDC从Trace定位到具体日志┌─────────────────────────────────────────────────────────────┐ │ 三大支柱的能力互补 │ ├──────────────┬──────────────────┬──────────────────────────┤ │ 特性 │ 你能回答的问题 │ 局限性 │ ├──────────────┼──────────────────┼──────────────────────────┤ │ Metrics │ 系统整体怎么样 │ 不知道具体哪个请求出问题 │ │ (指标) │ 现在有多少错误 │ │ ├──────────────┼──────────────────┼──────────────────────────┤ │ Tracing │ 这个请求慢在哪 │ 不知道业务上下文详情 │ │ (追踪) │ 调用了哪些服务 │ 高流量下需要采样 │ ├──────────────┼──────────────────┼──────────────────────────┤ │ Logging │ 具体发生了什么 │ 检索慢结构化程度低 │ │ (日志) │ 用户做了什么操作│ 存储成本高 │ └──────────────┴──────────────────┴──────────────────────────┘五、Google Dapper论文分布式追踪的祖师爷说完三大支柱必须提到一篇改变行业的论文Google Dapper2010年发表。这篇论文的全名是《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》是Google内部分布式追踪系统的设计论文。它不仅影响了Zipkin、Jaeger更直接影响了SkyWalking的设计。Dapper的核心思想1. Trace 一棵树Dapper把一次分布式请求建模为有根树根节点Root Span最外层的请求如前端HTTP请求子节点Child Span每次跨服务或跨资源的调用Trace (TraceId: abc-123) │ ┌─────────────┴─────────────┐ │ │ Span: API Gateway Span: Auth Service (0~100ms) (0~20ms) │ ┌───────┴────────┐ │ │ Span: Order Svc Span: User Svc (20~80ms) (20~50ms) │ Span: MySQL (60~75ms)2. 低侵入采集Dapper的设计原则之一追踪数据的采集必须对业务代码透明不能要求开发人员手动埋点。通过改写RPC框架和线程库来自动注入追踪上下文。这个思想直接影响了SkyWalking选择JavaAgent无侵入方案而不是让开发者手动调用SDK。3. 采样策略全量采样100%会带来巨大的存储和计算压力。Dapper建议使用概率采样如1/1000采样率在性能开销和数据完整性之间取得平衡。但SkyWalking在这里做了不同的选择在单进程1万TPS下支持100%采样。这是SkyWalking在性能优化上的核心竞争力。SkyWalking对Dapper的差异化设计SkyWalking没有照搬Dapper的模型而是做了重要改进最核心的差异在下一篇追踪模型中会详细讲这里先剧透一下SkyWalking引入了TraceSegment的概念在Trace和Span之间加了一层专门表示单个JVM进程内的完整调用链这使得数据的传输和存储效率更高。六、SkyWalking的可观测性定位了解了这些背景再看SkyWalking为什么要叫可观测性分析平台OAP“而不仅仅是APM工具”就很清晰了┌─────────────────────────────────────────────────────────────┐ │ SkyWalking的可观测性能力地图 │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ 可观测性平台 │ │ │ │ │ │ │ │ Metrics ──→ 服务指标/实例指标/Endpoint指标 │ │ │ │ Tracing ──→ TraceSegment/Span/调用链路 │ │ │ │ Logging ──→ 结构化日志 TraceId关联 │ │ │ │ │ │ │ │ 拓扑图 ──→ 服务依赖关系实时可视 │ │ │ │ 告警 ──→ 基于指标的实时告警规则 │ │ │ │ 性能剖析 ──→ 生产环境CPU热点分析 │ │ │ └──────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘SkyWalking是用一个系统解决了可观测性三大支柱的全部需求。你不需要像传统方案那样分别部署PrometheusMetrics ZipkinTracing ELKLogging三套系统然后费劲做三者的关联分析。当然SkyWalking也支持与Prometheus、Grafana等现有系统集成在已有监控体系的团队中SkyWalking可以作为分布式追踪和APM的专项增强而不是颠覆现有架构。本篇小结APM关注应用性能指标响应时间/错误率/吞吐量是可观测性的一个子集可观测性能通过已有数据无需改代码推断系统内部状态三大支柱是Metrics/Tracing/LoggingGoogle Dapper分布式追踪领域的奠基性论文SkyWalking的设计思路深受其影响SkyWalking的定位既是APM更是完整的可观测性分析平台一套系统搞定三大支柱下一篇我们把SkyWalking的整体架构图拆开来看搞清楚四大核心组件探针/OAP/存储/UI是怎么协作的。上一篇【第01篇】SkyWalking是什么——从中国联通的救火经历到Apache顶级项目下一篇【第03篇】SkyWalking架构全景图——四大组件的前世今生