ThinkPHP如何做接口调用链路采样_ThinkPHP性能分析按比例记录【方法】-ThinkPHP-PHP中文网

ThinkPHP 6需手动实现接口调用链路采样，核心是在中间件中按配置采样率（如1%）随机触发日志记录，并统一生成request_id注入上下文；SQL、队列等需显式透传该ID；采样率应动态可调，避免过高导致日志爆炸或过低无法定位问题。

thinkphp如何做接口调用链路采样_thinkphp性能分析按比例记录【方法】

ThinkPHP 本身不内置分布式链路追踪（如 OpenTracing / OpenTelemetry），所谓“采样”得靠自己控制日志或埋点的触发频率。核心思路是：在中间件或全局钩子里，按概率决定是否记录当前请求的完整链路信息（如耗时、SQL、HTTP 调用等）。

最轻量且可控的方式是用 mt_rand() 做随机采样，配合配置开关和采样率（比如 1%）。别依赖框架自动“智能采样”，它没有这个机制。

在 app/middleware/TraceMiddleware.php 中判断是否采样：
```
if (config('trace.sample_rate', 0) > 0 && mt_rand(1, 100) 
```
trace.sample_rate 配置值为整数，单位是百分比（0～100），设为 0 表示关闭；设为 5 就是约 5% 请求被采样
不要用 rand()，它在并发下可能重复；mt_rand() 更可靠
采样判断必须放在中间件早期（如 handle() 开头），避免后续逻辑已执行却没被记录

ThinkPHP 的 Log::record() 和 trace() 是调试辅助工具，不是链路追踪载体：它们默认不包含 span ID、parent ID、时间戳精度不足、无法跨服务传递上下文，且输出格式松散，不适合做采样分析。

常见错误是把所有请求都打 trace('sql')，结果日志爆炸、磁盘打满，而真正要查问题的那几条反而淹没其中——这不是采样，是日志污染。

没上下文的采样日志等于废日志。ThinkPHP 6 可通过 Request 对象和中间件属性注入唯一标识，关键是在采样开启时就固化上下文，而不是事后拼接。

推荐做法：在采样判定通过后，立刻生成 request_id（用 uniqid('', true)），并存入 think\Container 或静态属性，后续 SQL 日志、HTTP 客户端调用、缓存操作都读取它。

避免用 $_SERVER['REQUEST_ID']，Apache/Nginx 不一定透传，且 PHP-FPM 下不稳定
不要在每个模型或服务里重复生成 request_id，统一由采样中间件生成并挂载到 $this->app->make('request') 的扩展属性上
SQL 日志采样需 hook think\db\Connection::trigger('sql') 事件，检查当前是否已开启采样，再决定是否记录该条 SQL
若用了 think-queue，队列任务中需手动透传 request_id，否则链路会断

采样率不是越高越好，也不是越低越省事。1% 看似小，但在 QPS 1000 的接口上，每秒仍有 10 条采样日志——如果每条含 5 条 SQL、2 次 HTTP 调用，日志体积很容易破 MB/秒。

反过来，设成 0.1%，在低流量时段可能一整天都没一条有效采样，遇到偶发慢请求根本无从排查。

线上建议从 0.5% 起步，观察日志量和磁盘 IO；超过 5MB/小时就得调低
对核心接口（如支付回调、订单创建）可单独配置更高采样率，用路由或控制器名做条件判断
避免在 AppService 或 CommonService 这类通用类里硬编码采样逻辑，应提取为独立 TraceSampler 类，方便单元测试和替换
注意 mt_rand() 在容器重启后种子重置，但不影响采样均匀性；真正影响的是日志轮转策略——确保采样日志单独归档，别和普通日志混在一起

链路采样的本质是用可控的成本换可观测性，不是堆日志。最常被忽略的一点：采样开关必须支持运行时热更新（比如从 Redis 读 trace:sample_rate），否则每次改配置都要 reload FPM，线上不敢动。