在扩容前追踪一个慢请求

选择一个预期结果明确的请求

对于一个示例报表端点，记录路由模式、大致数据量、认证上下文以及它是否会产生后台工作。使用测试账户和具有代表性的脱敏数据。不要将令牌、客户标识符或完整请求体复制到事故记录中。

将首次请求的启动成本与重复的稳态行为区分开。记录 UTC 时间窗口和发布版本。确定是所有路由都慢，还是只有大型报表受影响，或者延迟跟随某一个外部依赖。这些区分比宽泛地收集不相关指标更能让下一次测量有价值。

构建时间线时避免重复计数

OpenTelemetry 跟踪通过跨服务边界传播的上下文连接相关跨度。仅时间戳匹配是不够的。嵌套的同步跨度和并行调用可能重叠。异步子跨度可能比其父跨度存活更久，因此将每个跨度时长相加可能会重复计算经过时间。应关注决定请求何时完成的操作。

技术参考： OpenTelemetry 跟踪 · OpenTelemetry 跨度结束行为.

最大的区间提示了应检查的位置，而不是根本原因。在 API 中测量的数据库区间可能包含查询到达数据库之前等待连接的时间。遥测数据缺失也不能证明没有发生工作；请检查采样和插桩覆盖范围。

关联应用和主机观测数据

收集同一窗口内的请求耗时、错误、数据库连接使用情况、队列年龄、CPU、内存和磁盘压力。注意并发的备份、迁移或发布。单张利用率截图可能遗漏影响该请求的突发峰值。

在脱敏日志中使用关联 ID 和时间戳，并采取适当的保留和访问控制。避免原始密钥、客户负载和无界指标标签。对假设所需的边界进行插桩，并审查开销。新的跟踪代理本身就是一项值得观察的变更。

在不引发另一起事故的情况下检查查询

首先识别查询形态、输入规模特征以及连接或锁等待。PostgreSQL EXPLAIN 描述的是一份计划； EXPLAIN ANALYZE 实际执行语句并增加插桩开销。写入可能更改数据，而昂贵的读取仍会产生负载。初始调查请使用隔离的具有代表性的数据库。

规划器成本不是经过的毫秒数。微小的测试表可能产生与应用程序更大数据集不同的计划。检查统计信息、索引和分布，并在更改后比较相同的查询形态。绝不要仅仅为了获得计时，就把未知的写入粘贴到生产环境的分析命令中。

技术参考： PostgreSQL EXPLAIN.

预测某一项更改应改善什么

如果连接池等待占主导，请检查工作进程连接或那些不必要地占用连接的请求。如果查询执行占主导，请检查计划和请求的行数。如果外部 API 占主导，请检查超时、重试以及该工作是否必须同步。序列化期间的 CPU 饱和指向另一项实验。

写下预测：降低导出并发应减少 API 连接池等待，同时导出耗时更长。这揭示了权衡。重复相同的请求组合，比较延迟和错误，并检查改进是否只是把失败转移到了不断增长的队列中。

保留结果及其不确定性

记录原始观察、测试的更改、比较方法和剩余不确定性。如果证据与假设矛盾，请在适当情况下撤销隔离更改并调查另一个边界。避免积累没有解释的永久调优更改。

当测量确定存在可额外分配资源来解决的资源约束时再扩容。使用 工作负载预算 并在 事故简报中记录发布回归。结果是经过推理的诊断，而不是承诺的延迟或供应商基准。