为什么你的App卡顿用户总在投诉？
早上九点，公司内部群突然炸了：‘线上订单提交不了！’运维冲进办公室，数据库CPU才30%，网络带宽也没跑满，服务器看起来一切正常。可用户就是没法下单——这就是典型的应用层性能问题。
硬件指标正常，不代表服务就真的正常。就像一辆车仪表盘没报警，但空调忽冷忽热、收音机断断续续，乘客照样难受。应用层性能监控要盯的，正是这些“乘客体验”。
它到底在监控什么？
和传统监控CPU、内存不同，应用层性能监控（APM）关注的是代码怎么跑的。比如一个支付接口，从请求进来开始计时，中间调用了哪些方法、访问了几次数据库、有没有异常抛出、耗时多少，全都记录下来。
举个例子，你点外卖时点击‘去支付’，这个动作触发了一个API调用。APM工具会告诉你：整个流程花了1.8秒，其中网关验证200ms，订单校验150ms，调用微信预支付接口用了1400ms。一眼就能看出瓶颈在第三方服务。
关键指标不只是响应时间
响应时间当然重要，但只看平均值会出事。假设100次请求里99次是200ms，1次是10秒，平均下来才300ms左右，看起来很美。可那个10秒的请求可能已经让用户点了三次返回键。
所以P95、P99这类分位数指标更真实。P95意思是95%的请求都快于这个值。如果P95是800ms，说明每20次就有一次比较慢。结合错误率一起看，比如某接口错误率突然从0.1%跳到5%，哪怕响应时间没变，也得立刻查。
链路追踪是怎么工作的？
现代应用多是微服务架构，一个操作可能经过七八个服务。这时候需要分布式追踪技术，给每次请求打上唯一ID，像快递单号一样跟着它流转。
Spring Cloud Sleuth就是干这事的。加个依赖就行：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>加上之后，日志里自动带上traceId和spanId。你在Kibana里搜同一个traceId，就能看到这次请求走过的所有节点。
别等用户反馈才行动
有家公司做在线教育，每次大课开始前总有几百人进不了直播间。后来上了APM发现，开课瞬间配置中心推送更新，所有服务同时拉取配置，把网络打满了。他们加了个错峰加载策略，问题就解决了。
监控不是为了写汇报材料，而是提前发现问题。设置合理的告警规则，比如某个接口P99连续3分钟超过1秒就发短信，比半夜被电话叫醒强多了。
真实世界的应用就像厨房炒菜，火候、调料、锅气都在动态变化。光看炉子功率不够，得尝味道才知道成色。应用层性能监控，就是那个帮你尝味道的人。