当前位置：首页 > news >正文

【Skywalking从入门到精通】第02篇：APM和可观测性到底是啥——写给所有被这两个词搞懵的开发者

news 2026/7/3 19:32:10

<!-
title: “APM和可观测性到底是啥——写给所有被这两个词搞懵的开发者”
series: “Apache SkyWalking实战全解析”
episode: 002
publish_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的定义：应用性能监控

APM（Application Performance Monitoring/Management）直译是"应用性能监控/管理"。它的核心关注点是：

应用的响应时间是多少？
应用的错误率是多少？
应用的吞吐量是多少？
哪些接口是性能瓶颈？

APM的历史可以追溯到2000年代，最早是针对单体Java应用的性能监控，通过Agent注入JVM，收集方法耗时、数据库查询时间等数据，生成性能报告。

典型的商业APM产品：

Dynatrace：业界标杆商业APM，功能最全，价格最贵
New Relic：SaaS 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_seconds：HTTP请求延迟分布
jvm_memory_used_bytes：JVM内存使用量
error_rate：错误率
throughput_rps：每秒请求数

特点：

低存储成本：只存数字，占用空间小
适合告警：容易设置阈值
缺点：丢失了细节，只知道"P99延迟高了"，不知道"哪个请求慢了"

常见工具：Prometheus、InfluxDB、SkyWalking（内置指标存储）

2. Tracing（追踪）

追踪记录一次请求从头到尾的完整路径，在分布式系统中尤为重要。

一次HTTP请求从Gateway → Service A → Service B → Database的完整路径，以及每一跳的耗时，就是一条Trace。

核心概念：

Trace：一次完整的请求链路，由唯一的TraceId标识
Span：链路中的一个操作单元（如：调用某个HTTP接口、执行一条SQL）
Parent-Child关系：Span之间形成树形结构

特点：

细节丰富：能看到具体哪个操作慢了
存储成本高：每条请求都要记录，数据量大
采样策略：高流量系统通常按比例采样

3. Logging（日志）

日志是最传统的可观测性手段，记录系统运行过程中的离散事件。

日志的核心价值在于：非结构化的上下文信息，是Metrics和Tracing无法表达的。比如：用户ID、业务参数、具体的异常堆栈。

现代日志的最佳实践：

结构化日志（JSON格式）：便于机器解析
与Trace关联：在日志中注入TraceId（通过MDC），从Trace定位到具体日志

┌─────────────────────────────────────────────────────────────┐ │ 三大支柱的能力互补 │ ├──────────────┬──────────────────┬──────────────────────────┤ │ 特性 │ 你能回答的问题 │ 局限性 │ ├──────────────┼──────────────────┼──────────────────────────┤ │ Metrics │ 系统整体怎么样？ │ 不知道具体哪个请求出问题 │ │ (指标) │ 现在有多少错误？ │ │ ├──────────────┼──────────────────┼──────────────────────────┤ │ Tracing │ 这个请求慢在哪？ │ 不知道业务上下文详情 │ │ (追踪) │ 调用了哪些服务？ │ 高流量下需要采样 │ ├──────────────┼──────────────────┼──────────────────────────┤ │ Logging │ 具体发生了什么？ │ 检索慢，结构化程度低 │ │ (日志) │ 用户做了什么操作？│ 存储成本高 │ └──────────────┴──────────────────┴──────────────────────────┘

五、Google Dapper论文：分布式追踪的"祖师爷"

说完三大支柱，必须提到一篇改变行业的论文：Google Dapper（2010年发表）。

这篇论文的全名是《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是用一个系统解决了可观测性三大支柱的全部需求。你不需要像传统方案那样分别部署Prometheus（Metrics）+ Zipkin（Tracing）+ ELK（Logging）三套系统，然后费劲做三者的关联分析。

当然，SkyWalking也支持与Prometheus、Grafana等现有系统集成，在已有监控体系的团队中，SkyWalking可以作为分布式追踪和APM的专项增强，而不是颠覆现有架构。