TP5.1 项目接入 Grafana 展示 QPS 与负载【仪表盘】

是的，这个问题很有代表性。很多人在 ThinkPHP 5.1 项目里做监控，习惯性地把目光盯在 Nginx 或者系统层面，这其实是个不小的误区。要真正看清楚业务的每秒请求数（QPS）和响应延迟，必须让 TP5.1 应用自己“开口说话”，把指标主动暴露出来。因为像中间件拦截、路由解析、数据库连接池这些 TP 层内部的瓶颈，外部工具是看不见的。 要让 TP5.1 接入 Prometheus 生态，核心思路就一条：**通过中间件采集请求数据，然后通过一个独立路由暴露指标**。 先安装核心库：`composer require prometheus/client_php`，确保 `vendor/autoload.php` 被正确加载。 接下来创建一个中间件，这是数据采集的入口。运行 `php think make:middleware RequestMetrics`，在生成的 `app/middleware/RequestMetrics.php` 里，逻辑其实很清晰：在请求开始前记录时间，在请求结束后计算耗时，然后分别更新计数器和直方图。 ```php use PrometheusCollectorRegistry; use PrometheusStorageAdapterAPC; use thinkRequest; class RequestMetrics { protected $registry; public function __construct() { // 注意：APCu 存储是必须的，file 方式在 PHP-FPM 下会失效 $this->registry = new CollectorRegistry(new APC()); } public function handle(Request $request, Closure $next) { $start = microtime(true); $response = $next($request); $duration = microtime(true) - $start; // QPS 计数器：按 status_code 分组 $counter = $this->registry->getOrRegisterCounter( 'tp5', 'http_requests_total', 'HTTP 请求总数', ['status'] ); $counter->inc(['status' => $response->getCode()]); // 响应时间直方图：桶区间需要覆盖 TP 的典型延迟（毫秒转秒） $histogram = $this->registry->getOrRegisterHistogram( 'tp5', 'http_request_duration_seconds', 'HTTP 请求耗时（秒）', ['controller', 'action'], [0.01, 0.05, 0.1, 0.3, 1.0, 3.0] ); $route = $request->routeInfo(); $histogram->observe($duration, [ $route['controller'] ?? 'unknown', $route['action'] ?? 'unknown' ]); return $response; } } ``` 中间件写好后，在 `app/middleware.php` 中把它注册为全局中间件，并确保它排在其他业务中间件之前执行。 然后需要一个控制器来暴露指标。新建 `app/controller/Metrics.php`： ```php use PrometheusCollectorRegistry; use PrometheusStorageAdapterAPC; use thinkController; class Metrics extends Controller { public function index() { $registry = new CollectorRegistry(new APC()); $renderer = new PrometheusRenderTextFormat(); $result = $renderer->render($registry->getMetricFamilySamples()); header('Content-Type: text/plain; version=0.0.4'); return $result; } } ``` 最后配置路由，在 `route/route.php` 中添加 `Route::get('metrics', 'Metrics/index');`。访问 `/metrics` 应该能返回纯文本指标，其中包含 `tp5_http_requests_total` 和 `tp5_http_request_duration_seconds` 等关键数据。 接下来是配置 Prometheus 来抓取这些指标。有两种方式： **方法一：直接抓取 TP 应用自身端点（推荐）** 在 `prometheus.yml` 的 `scrape_configs` 下新增一个 job： ```yaml - job_name: 'tp5-app' static_configs: - targets: ['your-tp-server-ip:80'] # 注意：不是 localhost，是容器或宿主机可访问地址 metrics_path: /metrics params: format: [prometheus] # 关键：TP5.1 无认证，但需防止外网暴露 relabel_configs: - source_labels: [__address__] target_label: instance replacement: tp5-prod-v1 ``` **方法二：通过 nginx-proxy 转发并加 Basic Auth（生产环境必需）** 在 nginx 配置中为 `/metrics` 路径添加 `auth_basic`，并在 Prometheus job 中配置 `basic_auth` 用户名密码。否则，任何人都可以直接访问 `/metrics` 获取全部内部监控数据，这是绝对要避免的。 数据进入 Prometheus 后，就可以在 Grafana 中搭建仪表盘了。 首先，创建一个 QPS 面板。查询语句用 `sum(rate(tp5_http_requests_total[1m]))`，标题设为“当前 QPS”，显示格式选择“None”，并开启“Show all value”来展示趋势线。 然后，配置分层响应时间面板。查询语句为 `histogram_quantile(0.95, sum(rate(tp5_http_request_duration_seconds_bucket[5m])) by (le, controller, action))`。这里的关键在于，将 Legend 设置为 `{{controller}}/{{action}}`，这样一眼就能看出是哪个控制器和动作拖慢了整体响应。 服务器负载这类辅助指标，需要额外配置。TP5.1 本身不提供 CPU、内存数据，必须搭配 `node_exporter`。在另一个面板中，输入 `100 - (a vg by(instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)`，标题设为“服务器 CPU 使用率”，单位选择“percent (0.0-100.0)”。 最后，保存仪表盘，命名为“TP5.1 QPS & Latency”，并放入“PHP Services”文件夹。这样，一个从 TP 应用层到系统层的完整监控视图就搭建完成了。