Vibe Coding 上线前负载验收：让日志、指标与 Trace 解释饱和点

压测报告写着“支持每秒一千请求”，却可能只循环命中一个缓存键、忽略登录与写入、让客户端在服务变慢时自动降低发送速率。吞吐看似稳定，真实流量一来就出现连接池排队、队列年龄增长和依赖重试。另一种失败是采集了海量 trace，却没有 workload 身份和用户结果，无法解释第一个饱和点在哪里。

本文不是通用可观测性搭建指南。调试日志与 Trace用最小观测验证故障假设，本篇则要求日志、指标和 Trace 在发布前共同解释一套受控负载：系统接收了多少、完成了多少、拒绝了多少、为何排队，以及撤掉压力后能否恢复。

先建立流量模型，不先选并发数

从生产预测或现有访问证据定义 operation mix、到达率、会话长度、think time、请求大小、读写比例、租户与热点分布、缓存命中、第三方调用和异步任务。峰值不能只乘一个平均数；突发、批处理重叠和少数大租户应单列 cohort。没有历史的新产品明确写出假设与置信度，测试结果只能验证该假设下的容量。

区分开放与封闭模型。固定虚拟用户会在服务变慢时减少新请求，可能掩盖排队；固定到达率能持续施加目标流量，却需要生成器本身有余量。记录 offered、accepted、completed 与 dropped 四个速率，不能只报服务成功吞吐。生成器 CPU、网络或连接耗尽时结果无效。

准备确定性数据，但保留真实基数和争用。所有用户访问同一对象会夸大缓存收益，全部唯一对象又可能低估热点锁。写入带测试命名空间、幂等 ID 和清理清单；禁止在生产对真实支付、邮件或客户数据做未批准负载。

按阶段回答不同问题

先做 smoke 证明脚本和观测正确，再在预期负载保持稳定窗口；随后分别做 stress 找容量拐点、spike 看突发卸载、soak 看泄漏与积压，最后观察恢复。Grafana k6 官方指南同样区分这些测试类型；一次陡升到极限再结束，不能代替稳态与恢复证据。

每阶段预先写 ramp、持续时间、安全上限、停止条件和成功标准。数据库错误、数据差异、依赖配额或资源保护触发时自动停止扩大，保留证据。不要在看到曲线后临时延长测试直到得到好结果，也不要把压垮共享环境当作“找到极限”。

基线和候选使用同一 workload revision、数据 snapshot、服务制品、配置和基础设施配额。容量变化若来自多给 CPU 或连接，应明确记录，不写成代码优化。客户端 Web 路径还可接入Web 性能回归门，服务端吞吐不能证明浏览器体验。

让三类遥测各自回答问题

指标负责连续量：请求到达、完成与拒绝率，延迟分布，CPU、内存、GC、线程或 event loop，连接池，锁等待，队列深度与年龄，下游配额。平均延迟会隐藏尾部，百分位也要带样本和窗口。资源利用接近上限却无排队可能尚可，排队增长而 CPU 不高则应寻找锁、池或依赖。

Trace 负责拆分一条代表请求的阶段和依赖，关联入口、数据库、缓存、队列与外部 API。OpenTelemetry 提供信号与上下文规范，但采样策略仍由系统设计。稳态可采样，错误、超时和极慢请求提高保留概率；采样决定和 workload phase 一起记录。不能因负载大就关闭所有 trace，再凭指标猜路径。

日志负责离散决定与不可聚合事件，例如准入拒绝原因、熔断状态变化、重试耗尽和数据校验失败。使用结构化错误类别与 request/trace 关联，不记录 Prompt、token、正文或个人字段。性能测试本身也要验证日志量不会形成第二次过载，高基数标签和同步写日志应在上线前暴露。

三者共享 release、scenario、phase、operation 与环境身份，但不把用户 ID、完整 URL 或缓存 key 放进指标。时间同步和采集丢失率进入报告；观测后端丢数据时标为不可判定，不能把“没有错误日志”解释成没有错误。

在过载时验证有界失败

逐步提高 offered load，寻找延迟开始非线性上升、队列持续增长或错误类别改变的拐点。Google SRE 的过载章节强调服务需要在过载时保护自身；测试应验证准入、deadline、限流、负载卸载和重试预算，而不是只测无限排队。限流、退避与熔断中的层级协调在这里接受真实压力。

拒绝必须快速、可识别且不产生部分副作用。客户端收到 deadline 后，服务端工作应取消或受控完成；层层重试不能让下游负载倍增。对写操作注入响应丢失和依赖超时，检查幂等与结果查询。降级路径保持安全与数据边界，不能为了吞吐返回伪造成功。

数据库路径结合查询计划与 N+1 审查，观察 query family、连接等待和锁，而不只看数据库 CPU。队列路径同时看入队、处理与最老消息年龄；消费者吞吐短暂追上不等于积压已恢复。

恢复窗口决定测试是否完成

停止压力后继续观察内存、连接、线程、队列、熔断、自动扩容和错误率。资源应在声明窗口回到基线，临时扩容有安全缩容路径，积压能收敛且没有重复副作用。只能重启服务才能恢复的泄漏必须记录为阻断或受批准风险，不能在报告里忽略收尾阶段。

接受标准连接用户 SLO、容量余量和运营动作，而不是一个孤立最大 RPS。阈值在测试前由 owner 批准，可参考SLO 与错误预算，但新服务没有数据时不得捏造精确可靠性。结果分为目标负载通过、过载保护通过、恢复通过和证据完整，任一缺失都不能写“压测通过”。

最终制品包含 workload、数据、环境、服务与配置摘要，生成器校准，原始时间序列，代表 trace，错误分类，拐点，恢复结果和人工裁决。Agent 可以关联异常并提出下一次实验，不能从相关曲线自动宣布根因。通过编程 Agent 改动验证门后，报告才成为上线证据。

负载验证的价值不是找到一个最大的数字，而是证明目标流量下用户任务可完成，超过边界时系统会有界失败，压力离开后还能恢复。让日志、指标和 Trace 围绕这三个问题协作，Vibe Coding 的上线决定才有可以复算的容量依据。