在调整规格前跟踪一个慢请求

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

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

将首次请求的启动成本与重复的稳态行为区分开来。记录 UTC 时间窗口和发布版本。确定是所有路由都慢、只有大型报告受影响，还是延迟源于某个外部依赖。这些区分使下一次测量比广泛收集无关指标更有用。

构建时间线而不重复计算

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

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

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

关联应用与主机观测数据

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

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

检查查询而不引发另一起事故

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

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

技术参考： PostgreSQL EXPLAIN.

预测一项更改应改善什么

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

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

保留结果及其不确定性

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

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