Flask 商店的 /order 端点响应缓慢，目标是找出瓶颈。传统的秒表方法需要修改代码，会产生未链接的日志行，并且难以处理间歇性缓慢的问题。分析器提供的细节过多，会掩盖请求特定的信息。利用现有配置，初步的跟踪立即揭示了时间的细分。请求耗时 37.3 毫秒，视图耗时 36.3 毫秒，服务耗时 35.9 毫秒，账本耗时 35.1 毫秒，而网关仅耗时 8 微秒。这表明账本是导致缓慢的主要原因。“自时间”的概念区分了本身缓慢的操作和因其子项而缓慢的操作。Wrapture 计算出这一点，显示账本本身就很慢，而服务和视图因为调用账本而变慢。使用 wrapture.instrumentation 和 wrapture.timeline 的测试证实了这一点：OrderService.place 的自时间为 173 微秒，总耗时为 31.0 毫秒，而 Ledger.record 占用了大部分时间。标准分析器无法提供这种详细程度的信息。对于长期监控，Aggregate 收集器会收集大量请求的统计信息，包括总时间、自时间、最小时间和最大时间。将三十个请求发送到服务器的报告证实了 Ledger.record 是自时间的最大贡献者。为了跟踪每个租户的缓慢情况，wrapture.annotate 允许添加自定义数据，如“X-Tenant”，到正在进行的事件中。这使得可以过滤跟踪，以确定哪些租户的请求响应更慢。Counter 收集器提供了一种更经济的选择，它只计算操作而不保留持续时间，适用于测试套件中的基于预算的断言（例如，检测 N+1 查询问题）。下一步是将这些事件馈送到跟踪后端。