如何在ThinkPHP中监控API的QPS和响应时间_结合Prometheus与Grafana打点-ThinkPHP-PHP中文网

thinkphp中应通过psr-15中间件集成prometheus/client_php扩展实现api打点，避免控制器内埋点；需用单例collectorregistry、规范命名指标、预设直方图buckets、清洗label非法字符、路由暴露/metrics并禁用中间件与调试模式。

如何在thinkphp中监控api的qps和响应时间_结合prometheus与grafana打点

直接用 prometheus/client_php 官方扩展，别自己拼指标字符串。ThinkPHP 6+ 是基于 PSR-15 中间件的，打点逻辑必须塞进中间件里，否则会漏掉异常路径（比如路由未匹配、中间件提前退出）。

常见错误是把计数器写在控制器方法里——这样 404、500、中间件抛异常时根本不会执行，QPS 和延迟数据严重偏低。

安装扩展：composer require prometheus/client_php
初始化注册器要单例，推荐放在 app/middleware/PrometheusMiddleware.php 的 __construct() 里，用 Prometheus\CollectorRegistry::getDefault()
指标命名按 Prometheus 规范：用下划线分隔，带业务前缀，比如 tp_api_request_total、tp_api_response_time_seconds
响应时间直方图（Histogram）必须预设 buckets，别用默认值；API 常见响应区间是 0.01s ~ 2s，建议设为 [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2]

大概率是没在请求结束时调用 $histogram->observe($duration)，或者 $duration 单位错了——Prometheus 要求秒级浮点数，但 ThinkPHP 的 App::getBeginTime() 返回毫秒整数，得手动除以 1000。

另一个坑是直方图 label 值含非法字符：比如把完整 URL 当作 path label，里面带 /、?、= 会导致指标写入失败（Prometheus 不允许 label 值含这些）。必须做清洗：

不能直接用 PHP 内置服务器跑 index.php 暴露指标——它没做并发保护，高 QPS 下 CollectorRegistry 会因多协程/多进程写冲突导致数据错乱或崩溃。

正确做法是走 ThinkPHP 路由 + 独立控制器，且强制单进程处理：

定义路由：Route::get('metrics', 'Metrics/index');
控制器中禁用所有中间件（尤其是 ORM、Auth 类），防止副作用；开头加 ini_set('opcache.enable', '0'); 避免 OPcache 缓存指标输出
响应头必须设为 Content-Type: text/plain; charset=utf-8，否则 Prometheus 抓到 406
别用 echo $registry->render() 后直接 exit —— ThinkPHP 可能还有后续钩子，要用 Response::create(...)->send(); die;

不是采集问题，是 PromQL 写法不对。直接用 rate(tp_api_request_total[1m]) 在低流量时段会剧烈抖动（比如每分钟只有 2 次请求，某分钟刚好 0 次就显示 0，下分钟 4 次就跳到 4）。

真实 API 监控得兼顾灵敏度和稳定性：

QPS 推荐用 avg_over_time(rate(tp_api_request_total[2m])[5m:1m])：先按 2 分钟算 rate，再滑动窗口取 5 分钟均值
延迟 P95 用 histogram_quantile(0.95, sum(rate(tp_api_response_time_seconds_bucket[5m])) by (le, path, method))，注意必须带 sum ... by (le, ...)，否则分位数计算失效
检查 Prometheus 的 scrape_interval 是否 ≤ 15s；ThinkPHP 指标暴露接口响应超过 10s 就可能被超时丢弃

最常被忽略的一点：ThinkPHP 开启了调试模式（APP_DEBUG = true）时，日志和 trace 会显著拖慢 /metrics 接口，导致抓取超时或采样丢失——上线监控前务必关掉调试模式。