PHP 项目最值得重点关注的指标
PHP 项目的指标体系需要结合语言特性（同步阻塞、请求生命周期短、FPM 进程模型）和业务场景来筛选，以下是按优先级分层的核心指标清单。
运行时性能指标（最核心）
响应时间（Latency）
- P50 / P95 / P99 分位值：平均值会掩盖长尾问题，PHP 项目中慢请求往往集中在少数复杂 SQL 或外部调用上，P95/P99 是最值得盯的。
- 区分接口维度：区分核心交易接口 vs 普通查询接口，各自设阈值。
吞吐量（QPS / RPS）
- 单机 QPS 与集群 QPS，结合 FPM 进程数判断是否已达瓶颈。
- QPS 与响应时间的关系曲线：找到拐点，避免在高负载下响应时间陡增。
错误率
- HTTP 5xx 比例、业务异常率、PHP Fatal Error 率。
- 按错误类型分类（超时 / 数据库错误 / 依赖服务错误 / 代码异常），比单纯看总数更有价值。
PHP-FPM 与进程模型指标（PHP 特有，极易被忽视）
PHP 的同步阻塞模型决定了 FPM 进程池状态直接决定系统可用性：
| 指标 | 为什么重要 |
|---|---|
| FPM 活跃进程数 / 空闲进程数 | 活跃进程接近 pm.max_children 时，新请求会排队 |
| listen queue（等待队列长度） | 队列持续非零 = 进程池不足，用户已在等待 |
| max children reached 次数 | 直接反映容量瓶颈，是最灵敏的扩容信号 |
| 进程重启次数 | 频繁重启可能意味着内存泄漏或 OOM |
| 单请求内存峰值 | PHP 内存泄漏常见，需监控 memory_get_peak_usage |
关键洞察：PHP 项目"响应慢"很多时候不是代码慢，而是进程池被打满在排队，listen queue 和 max children reached 应该作为一级告警指标。
数据库与外部依赖指标（PHP 应用的主要瓶颈来源）
PHP 请求生命周期短，性能问题极少出在 PHP 本身，多出在 IO：
- SQL 慢查询数量与耗时分布（按 SQL 指纹聚合）
- 数据库连接数 / 连接池等待时间
- Redis / 缓存命中率——命中率下降会瞬间把压力打到 DB
- 外部 HTTP 调用耗时（P95/P99）与超时率——PHP 同步调用外部服务时，一个慢依赖会拖垮整个 FPM 进程
- N+1 查询检测（ORM 场景高频问题）
资源与容量指标
- CPU 使用率（PHP 是 CPU 密集型，注意区分 us/sy）
- 内存使用率与 OOM 次数
- 磁盘 IO / 网络 IO
- 单机承载的 QPS 与资源消耗比（用于容量规划）
业务与可用性指标
- 核心业务成功率（下单、支付等，比 HTTP 200 更有意义）
- 可用性 SLA（按分钟级统计）
- 依赖服务健康度（DB、缓存、MQ、第三方 API）
可观测性基础（支撑上述指标的前提）
- 分布式链路追踪（OpenTelemetry / SkyWalking），能把慢请求定位到具体 SQL 或外部调用
- 结构化日志 + 错误聚合（如 Sentry），按错误指纹去重
- 慢请求采样：记录 P99 以上请求的完整上下文
优先级建议（如果只能选 5 个）
- P95/P99 响应时间（按接口）
- 错误率（5xx + 业务异常，分类）
- FPM listen queue + max children reached（PHP 特有的容量信号）
- 慢 SQL 数量与缓存命中率（主要瓶颈来源）
- 核心业务成功率（最终用户视角）
一个常见误区
很多团队只监控 CPU / 内存 / 平均响应时间，这三者在 PHP 项目里恰恰最不灵敏：
- 平均响应时间掩盖长尾；
- CPU 高不一定是问题（可能是正常业务量），CPU 低也不代表健康（可能在等 DB 或排队）；
- 真正该告警的是 listen queue 非零、慢 SQL 激增、缓存命中率骤降、错误率突增。
需要我针对你的具体架构（比如是否用 Laravel/Swoole、有无连接池、是否容器化）给出更定制的指标与告警阈值建议吗？
