面向电商技术团队的大促可观测方案：压测定基线、关键链路全量追踪、按秒聚合的实时告警、容量弹性联动，以及大促前中后三个阶段的执行清单。
大促流量是平时的几倍到几十倍，而且集中在秒级爆发。平时靠翻日志、看大盘能定位的问题，在峰值期根本没有时间做——等你打开面板，流量高峰已经过去了，或者已经造成了资损。大促可观测性的目标是：把“事后翻日志”变成“异常发生的下一秒就知道”。
大促前最重要的动作是压测，但压测不只是“能不能扛住”，而是产出基线。把目标 TPS 压到预期峰值的 1.2 倍，记录下每个核心接口在峰值下的 P99 延迟、错误率、数据库连接数、缓存命中率。这些数字就是大促当天的告警阈值来源——不是拍脑袋定的 90% CPU，而是压测里真实测出来的水位。
压测数据直接导进 OBSERVE，和线上数据做对比：线上某接口延迟突然偏离压测基线 30%，就是异常信号。
平时 Trace 采样 5% 就够了，大促期间对核心链路（下单、支付、库存）切到 100% 采样。成本确实上去了，但大促就几天，换来的是任意一笔订单都能还原全链路。配合尾采样：慢请求和出错请求 100% 保留，普通请求按比例抽样，兼顾成本和排查能力。
大促的告警不能用分钟级。一分钟 3000 单的场景里，延迟从 50ms 涨到 500ms 只要 30 秒，分钟级聚合早就错过了。OBSERVE 支持秒级聚合，把下单成功率、支付耗时、库存扣减这三个黄金指标按 5 秒窗口滚动，阈值用压测基线，触发即电话通知。
告警分层照旧：P0（下单/支付链路不可用、成功率跌破阈值）直接电话；P1（降级、队列积压）短信 + 群；P2 记录。但大促期间 P0 的响应要求是秒级，值班人收到电话的同时，告警里已经附带了当时的高延迟 trace 和日志快照，打开就能定位。
可观测系统还要回答一个容量问题：什么时候加机器。把集群 CPU、连接池、队列深度做成趋势看板，提前设扩容阈值——比如网关 CPU 连续 5 分钟超 70%，触发自动扩容。这个阈值同样来自压测，不是经验值。