用户说页面慢，客服说订单偶尔失败，运营说活动转化掉了。
开发打开服务器看 CPU，好像还行；看数据库，好像也没完全打满；翻日志，日志很多，但不知道该搜什么。最后大家只能在群里互相问：刚才谁发版了？哪个服务有问题？
这就是没有可观测性的典型状态：系统不是没数据，而是没有能把问题串起来的数据。
可观测性的价值，不是做一个漂亮大屏，而是在故障发生时尽快回答三个问题：哪里坏了，影响多大，为什么坏。
很多容量问题，最早其实都在监控里露过头。
只是当时没人看，或者看到了也觉得“还行”。CPU 偶尔抬一下，慢查询多几条，队列积压几分钟，接口 P95 慢一点，这些信号单独看都不吓人。
等到事故发生后再回头看曲线，大家才会发现它不是突然坏的，是一路变坏的。
所以可观测性不是为了出事以后截图复盘，它更重要的作用，是让团队在出事之前就愿意相信那些不太好看的信号。
日志、指标、链路、告警和压测，最后都在回答同一个问题：问题在哪里，影响多大，为什么会发生。
一、日志要能串起一次请求
日志是排查问题最基本的材料。
但日志不是越多越好。没有请求 ID、没有业务关键字段、没有错误上下文的日志，数量再多也很难用。
一次下单请求从网关到订单服务，再到库存、优惠券、支付回调、MQ，如果没有统一 traceId，排查时就只能在一堆日志里碰运气。
日志里也要保留关键业务字段，比如订单号、用户 ID、商品 ID、活动 ID、设备编号、任务 ID。
否则你只知道接口报错，却不知道影响了哪一笔业务。
二、指标要看趋势，也要看尾部
指标适合看系统状态。
常见指标包括 QPS、错误率、平均耗时、P95、P99、CPU、内存、磁盘、连接池、线程池、队列长度、缓存命中率、数据库慢查询。
平均值很容易骗人。
一个接口平均耗时 100ms，但 P99 到了 3 秒，说明已经有一部分用户体验很差。活动系统里，这部分用户可能刚好集中在下单或支付链路上。
高并发系统里，我会特别关注尾部延迟、错误率变化、队列积压、连接池耗尽、缓存命中率下降。这些指标往往比 CPU 更早暴露问题。
三、链路追踪用来定位慢在哪里
微服务多了以后，一个请求可能经过很多服务。
如果只有单个服务日志，很难判断到底是订单服务慢、库存服务慢、数据库慢，还是外部支付接口慢。
链路追踪的作用，是把一次请求的调用路径和每段耗时展示出来。
它能帮你看见：
- 请求经过了哪些服务。
- 每个服务耗时多少。
- 哪个下游拖慢了主链路。
- 是否出现重复调用或异常重试。
链路追踪不是只有大公司才需要。只要系统开始拆服务，它就会越来越有价值。
四、告警要能叫醒人，也要避免吵死人
告警太少，故障没人知道；告警太多，大家会麻木。
好的告警应该关注业务影响，而不是所有技术波动。
核心接口错误率升高、支付成功率下降、订单积压、数据库连接池耗尽，这些比某台机器 CPU 短暂升高更值得优先处理。
告警也要分级。P0 需要马上处理，P1 可以快速响应，P2 可以工作时间处理。否则所有告警都很急，最后等于都不急。
我更喜欢能给出上下文的告警：哪个服务、哪个接口、影响范围、最近变化、关联日志或看板链接。这样值班的人不用从零开始找。
五、压测和容量评估要在事故前做
容量规划不能只靠感觉。
系统能扛多少 QPS，数据库能承受多少写入，缓存命中率下降后会发生什么，MQ 积压到多少开始影响业务，这些最好通过压测和演练提前知道。
压测不只是把接口打到很高 QPS。它应该模拟真实业务比例、数据分布、热点场景、异常场景。
容量评估也不是一次性工作。业务增长、功能变化、数据量变化，都会改变系统瓶颈。系统应该有性能基线，知道正常情况下各项指标大概是什么水平。
没有基线，就很难判断“现在是不是异常”。
六、可以带走的判断清单
- 日志要有 traceId 和关键业务字段。
- 指标不要只看平均值，要看 P95、P99。
- 链路追踪用来定位慢在哪一段。
- 告警要围绕业务影响分级。
- 压测要模拟真实业务比例和热点场景。
- 系统要有性能基线，否则很难判断异常。
看不见的问题，最后都会变成事故。
本系列：
暂无评论