ThinkPHP Linux环境如何监控

在 Linux 环境下监控 ThinkPHP 应用，核心无非是盯紧三件事：进程是否活着、系统扛不扛得住、日志告警能不能及时反馈。

一 进程与队列的保活监控

队列消费、定时任务这类常驻进程，最忌讳的便是悄无声息的挂掉。Supervisor 是解决这个问题的标准方案，它能自动拉起异常退出的进程，并提供统一的日志管理和启停入口。

配置上其实很简单。以 ThinkPHP 6 的队列消费为例，单进程版配置大致是这样的：

[program:tp6_queue]
command=/usr/bin/php /www/wwwroot/your-project queue:work --queue=default --tries=3
directory=/www/wwwroot/your-project
user=www-data
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/supervisor/tp6_queue.out.log
stderr_logfile=/var/log/supervisor/tp6_queue.err.log

如果业务量上去了，需要多进程并发消费，也很容易扩展：

[program:tp6_queue]
command=/usr/bin/php /www/wwwroot/your-project queue:work --queue=default --tries=3
directory=/www/wwwroot/your-project
process_name=%(process_num)02d
numprocs=5
autostart=true
autorestart=true
redirect_stderr=true
stdout_logfile=/var/log/supervisor/tp6_queue.out.log
stderr_logfile=/var/log/supervisor/tp6_queue.err.log

日常管理的几个命令值得记一下：

• 重新加载配置：supervisorctl reread && supervisorctl update
• 启停进程：supervisorctl start|stop|restart tp6_queue
• 查看状态：supervisorctl status

另外，/var/log/supervisor/ 目录下的日志文件需要纳入 logrotate 管理，否则日积月累，磁盘撑满只是时间问题。

二 系统与应用性能监控

进程保活只是第一步，性能瓶颈才是真正让人头疼的。这里需要分两层来看：系统资源和应用自身。

系统资源快速排查

• CPU/内存/负载：top -n 1 -b、vmstat 1 10、pidstat -u 1 -p 是排查利器，几秒钟就能确定是不是系统层面的问题。
• 磁盘 IO：iostat -d -x -k 1 10 搭配 iotop，能精准定位哪块盘在忙、哪个进程在大量读写。
• 网络：ss -aA tcp 检查连接状态，iftop -i eth0 和 nload 实时看流量。
• 历史与综合：sar 系列命令（sar -u 1、sar -r 10 3、sar -d）和 dstat 2 10 适合做持续采集和回溯。

PHP 与框架层性能分析

• XHProf：能做到函数级别的耗时和内存分析。在开发或预发环境的关键入口开启采样，保存 run_id 后离线分析，定位慢函数和内存热点非常直观。生产环境建议以采样方式打开，避免性能开销。
• Datadog PHP StatsD：需要在 ThinkPHP 中绑定 DogStatsd 客户端，上报自定义计时和计数指标。接口耗时、队列处理时长、异常计数等都能在控制台上做可视化和告警，适合对应用健康度有持续跟踪需求的团队。

三 日志与告警闭环

再好的监控方案，如果缺少告警闭环，也等于白做。关键是把日志管好，然后让它主动“说话”。

日志集中与轮转

Web 错误日志、PHP-FPM 日志、应用日志、队列日志，统一落盘到一个便于检索的位置。同时为 Supervisor 日志配置 logrotate，可以按日切割、按大小切割、保留指定份数并压缩，省心很多。

主动告警

• 系统层：基于 sar/pidstat/iostat 的输出做脚本告警，或者直接用 Prometheus Node Exporter + Alertmanager 配置阈值。比如 CPU 使用率持续 5 分钟超过 80%、磁盘使用率超过 85%、队列进程数不足，都该触发告警。
• 应用层：在 Datadog 里配置基于指标的阈值或异常检测告警。重点关注接口 P95 延迟、队列积压数、失败重试次数激增等场景。

健康检查

对外暴露一个 /health 接口，检查数据库、Redis、缓存等组件的连通性。Nginx、负载均衡或 Kubernetes 的 Liveness Probe 可以定期探测这个接口，一旦异常就自动摘除实例，避免流量打到有问题的节点上。

四 快速落地清单

如果现在要从零开始搭建这套监控体系，建议按这个顺序逐步落地：

• 进程保活：先部署 Supervisor，为队列消费进程和自定义常驻命令配置 autostart 和 autorestart，设置好 std 日志和 logrotate。
• 即刻排障：准备一份常用命令清单（top、vmstat、iostat、ss、iftop），在流量高峰期抓取 1–5 分钟的关键指标和日志片段，往往能快速定位问题。
• 性能洞察：在开发或预发环境接入 XHProf，对慢接口和慢任务做函数级剖析；线上以采样为主，控制性能开销。
• 指标与告警：接入 Datadog 或开源替代方案，上报接口耗时、队列处理时长、失败计数等核心指标，配置 P95/P99 和错误率告警。
• 容量与趋势：保留 7–30 天的指标和日志数据，定期复盘峰值并发、慢查询、队列积压的变化趋势，提前做扩容或代码优化。