上云之后，应用性能监控（APM）的五维能力模型没有变，但验收要点要按"接入层 — 传输层 — 应用层"的链路结构重新排布。这篇按三层拆开讲，最后给大规模微服务场景的三个专项要求。
核心要点
- 接入层看用户体验：RUM 与拨测双路，公网回传要管好合规与就近接入。
- 传输层看调用链：TraceID 跨服务传播对齐 W3C 标准，采样策略决定成本。
- 应用层看深度：探针与无代理混合，SQL 与方法栈是归因的最后一公里。
- 告警治理把云事件纳入白名单，基线先行再谈 AI。
- 大规模微服务要专项验证：服务发现联动、拓扑自动收敛、成本三笔账。
一、接入层：用户侧的慢要先看得见
接入层是用户请求的第一跳：DNS、CDN、网关、WAF。用户说慢，一大半问题出在这一层——静态资源加载慢、跨运营商链路抖动、网关限流。接入层的监控组合是RUM + 拨测：真实用户监控回答"哪些地区的用户实际多慢"，拨测从多个探针节点按频率模拟访问，回答"入口服务现在是否正常"。
验收要点三条：拨测节点覆盖主要用户地域；RUM 口径对齐 Core Web Vitals（LCP / INP / CLS）；RUM 数据能下钻到后端链路——用户侧 3 秒的加载，要能拆出多少在 CDN、多少在网关、多少在服务端。拆不开的 RUM 只是报表，不是工具。
二、传输层：调用链与采样
服务间调用是性能问题的多发区，也是调用链追踪的主战场。两个硬要求：
TraceID 跨服务传播对齐 W3C Trace Context 标准——跨语言技术栈、HTTP / RPC / 消息队列混布，链路不断才算合格。自研传播协议的方案每接入一个新组件都要适配，这是签约前看不出来的隐性成本。
采样策略决定成本与质量。头部采样实现简单，但决策时还不知道这条链路会不会慢，慢请求恰好被丢；尾部采样在链路结束后按条件保留——错误 100%、超 P99 的慢请求 100%、正常流量按比例抽。生产环境建议两者组合，验收时重点确认"问题样本不丢"。
传输层还有一个云上特有项：跨可用区调用的延迟差异要能单独标记。同一服务跨可用区互调，延迟天然比同可用区高一个档位，混在一起看会掩盖真正的劣化。同理，专线接入的分支流量与公网接入的门店流量也要分开建基线——两类链路的延迟特征完全不同，混看必错。
三、应用层：归因的最后一公里
调用链把问题定位到某个服务后，还要往下钻到代码级：慢在哪个方法、哪条 SQL、哪次外部调用。这要求探针（插桩）能自动捕获 JDBC、Redis、消息队列等常见组件的调用细节。无代理采集（eBPF、网关侧）接入快、零侵入，但深度有限——成熟做法是混合：全量服务用无代理自动发现，关键业务补 SDK 深度插桩。评估时让厂商明确"自动发现能看到什么、插桩补充什么"。
资源层指标（CPU、内存、连接池、线程池）在这一层与请求层指标交汇：连接池打满是"实例看着闲、请求就是慢"的常见根因，实例层与请求层两条口径必须能互相下钻。
四、告警治理与成本
告警四件套不变：动态基线、按影响面分级、按依赖拓扑抑制级联、告警到工单闭环。云上的额外项是把弹性伸缩、维护窗口这类计划内事件接入静默白名单，否则每次扩容都是一轮假告警。AI 异常检测必须基线先行——数据不满一两个业务周期，误报会耗光所有人的信任。
成本按三笔账算：采集开销（全量追踪的探针消耗与计费方式）、存储留存（高精度指标一周到一个月、聚合一年起；追踪全量一周、问题样本一季度；日志按合规）、传输流量（跨地域数据回传就近聚合，能省一个量级）。留存不是越长越好，"够复盘"就好。
五、大规模微服务的三个专项要求
服务数量上到几百个后，三件事要专项验证：
- 服务发现联动：新服务上线、实例扩缩容后，监控对象自动纳入，禁止手动登记——否则拓扑永远滞后于现实；
- 拓扑自动收敛：几百个服务的依赖图要能按调用频次聚合展示、按异常路径下钻，一张平铺大图没人看得懂；
- 标签基数控制：把无界字段（用户 ID、订单号）加进指标标签会让存储爆炸，方案必须有白名单与基数熔断。
FAQ
Q1：跨可用区调用要不要单独监控？
要。跨可用区延迟天然偏高，混在同一条基线里会掩盖真实劣化。按"可用区对"维度单独出基线，异常才看得出来。
Q2：无代理和探针怎么选？
全量接入用无代理（快、零侵入），关键业务补探针（深、能到 SQL 与方法栈）。两者覆盖范围让厂商写清楚，避免盲区。
Q3：RUM 采集要考虑哪些合规项？
采集字段清单与脱敏规则、URL 敏感参数过滤、用户告知与隐私政策覆盖。公网回传链路就近接入，降低额外延迟。
Q4：采样率怎么定？
正常流量 1%-10% 起步，错误与慢请求全保留。策略优先于比例：宁可正常流量采得稀，不丢问题样本。
Q5：几百个服务的拓扑怎么管？
按调用频次聚合默认视图、按异常路径自动下钻，配合服务发现自动更新。手工维护的拓扑在百级服务规模下必然失效。
参考来源
- W3C Trace Context Recommendation（分布式追踪上下文传播标准），可在 W3C 官网技术报告栏目检索
- W3C Navigation Timing Level 2（前端性能采集口径），可在 W3C 官网技术报告栏目检索
- OpenTelemetry 规范（指标 / 日志 / 追踪统一数据模型），可在其官网文档栏目检索
- 厂商实现文档（仅作技术对照，非推荐）：可自行搜索应用性能监控产品的官方帮助文档站点
一句话总结
按"接入层看体验、传输层看链路、应用层看深度"的顺序验收 APM 五维能力，再对大规模微服务补上服务发现联动、拓扑收敛、基数控制三个专项——链路结构清晰了，选型标准自然清晰。
