总体思路

面向ThinkPHP在Linux环境下的性能监控，一个行之有效的策略是构建“三层联动”的观测体系：

• 应用层：在框架内部进行埋点，精准记录每一次请求的耗时、执行的SQL、内存峰值以及异常情况。
• 系统层：借助Linux原生命令与专业工具，持续观测服务器底层的CPU、内存、磁盘I/O及网络等核心资源。
• 平台层：接入像Prometheus+Grafana或Datadog这样的可视化监控平台，实现数据的长期趋势分析和阈值预警，让问题无所遁形。

应用层监控

这一层的关键在于从代码内部获取第一手数据。

• 中间件埋点记录请求详情（适用于TP5/6，TP3也可通过类似中间件改造实现）
  新建一个中间件文件，例如 app/middleware/PerformanceLogger.php：

  namespace app\middleware;
  use think\facade\Request;
  use think\facade\Log;
  
  class PerformanceLogger
  {
      public function handle($request, \Closure $next)
      {
          $start = microtime(true);
          $response = $next($request);
          $duration = (microtime(true) - $start) * 1000; // 转换为毫秒
  
          Log::info('perf', [
              'method' => $request->method(),
              'url' => $request->url(true),
              'ip' => $request->ip(),
              'ms' => round($duration, 2),
              'mem' => memory_get_peak_usage(true),
          ]);
          return $response;
      }
  }

  在全局或模块中间件中注册后即可生效。这里有个小建议：日志最好按天切割，并配置为异步写入，这样可以最大程度避免对请求响应时间造成影响。
• 使用StatsD/Datadog上报指标
  首先安装客户端：composer require datadog/php-datadogstatsd。
  配置与打点示例：

  // config/datadog.php
  return [
      'host' => '127.0.0.1',
      'port' => 8125,
      'namespace' => 'my_tp_app',
      'tags' => ['env:production', 'app:tp'],
  ];
  
  // 在控制器或服务中
  $statsd = new \DataDog\DogStatsd(config('datadog'));
  $statsd->timing('tp.request', $durationMs, ['route'=>$route]);
  $statsd->increment('tp.request.count', 1, ['method'=>$method]);

  需要确保服务器本机或内网能够访问到Datadog Agent（默认UDP端口8125），或者在代码中将其地址修改为你自己的Agent地址。
• 利用框架自带调试能力（仅限开发或预发环境）
  • 开启app_debug后，页面底部会显示调试面板，其中包含了SQL语句、加载时间等信息，对于快速定位问题非常方便。
  • 对于ThinkPHP 3.2版本，可以在公共入口记录开始时间到$GLOBALS[‘_beginTime’]，然后在页面或公共函数中输出“耗时：x.x s”，用于快速验证性能。当然，生产环境务必关闭调试面板。

系统层监控

当应用出现性能瓶颈时，系统层面的指标往往是问题的根源所在。

• 实时与轻量排查
  • CPU/内存：top, htop, mpstat -P ALL 1, free -h
  • 磁盘：df -h, iostat -x 1 3, dstat, iotop
  • 网络：ss -tulnp, iftop, nload, netstat -s, tcpdump -i eth0 port 80
• 历史与趋势
  • 使用sar -u 1 3（CPU）、sar -r 1 3（内存）、sar -b 1 3（I/O）查看历史统计，这需要安装sysstat包。
• 进程与内核细节
  • atop（按日记录进程活动，高亮资源消耗）、slabtop（查看内核slab缓存）、lsof（列出打开的文件和连接）、sysdig（强大的系统调用与事件追踪工具，例如sysdig proc.name=php-fpm）。

平台化监控与告警

将零散的数据汇聚到统一的平台，是实现自动化运维和智能告警的关键一步。

• Prometheus + Grafana（自建方案，适合有技术团队的复杂或多机环境）
  • 以php-fpm状态页或Nginx日志作为数据源，采集请求耗时、吞吐量、5xx错误率、慢查询等指标。在Grafana中配置仪表盘和告警阈值，再通过Prometheus Alertmanager发送告警（例如，当P95响应时间持续超过阈值，或错误率突然飙升时）。
• Datadog / New Relic / AppDynamics（SaaS方案，接入快速）
  • 安装对应的Agent，在应用内使用StatsD/DogStatsd或APM探针上报指标与调用链路。这类服务通常提供开箱即用的仪表盘和成熟的告警策略。
• 日志聚合与检索
  • 将ThinkPHP的应用日志接入ELK/EFK或Loki等日志系统。基于慢请求阈值、异常堆栈、SQL慢日志建立索引和可视化看板，便于问题回溯和审计。

落地步骤与阈值建议

理论再好，也需要清晰的执行路径。以下是分步实施的建议：

• 第一步：基础埋点与验证
  在应用入口或中间件进行埋点，将“请求耗时、内存峰值、状态码、路由、请求方法”输出到本地日志。这一步主要是验证数据格式的正确性，并评估性能开销（建议采用采样或异步写入来降低影响）。
• 第二步：指标上报与可视化
  部署Datadog Agent或Prometheus Exporter，打通应用指标的上报通道。随后，在Grafana中建立“TP应用总览”和“关键接口P95/P99耗时”等核心监控面板。
• 第三步：配置告警规则（示例）
  • 应用层：P95响应时间 > 500ms（持续5分钟）、5xx错误率 > 1%、单个接口95分位耗时 > 1秒。
  • 系统层：CPU使用率 > 80%（持续10分钟）、可用内存 < 10%、磁盘%util > 90%、TCP重传率出现异常波动。
• 第四步：压测校准与闭环优化
  使用JMeter或ab等工具进行压力测试，在模拟的峰值流量下校准各项监控阈值，并制定相应的扩容策略。最终，将慢SQL、外部API依赖耗时等关键因素也纳入监控看板，形成从“代码 -> SQL -> 系统 -> 平台”的完整优化闭环。