php监控核心是分层精准埋点：web层看请求与进程、应用层看指标与错误、系统层看资源与存活；盲目堆砌工具反增故障面，有效监控需“够用、可定位、不误报”。
PHP主流架构的运行状态监控，核心不是“装一堆工具”，而是按架构分层精准埋点：Web 层看请求与进程、应用层看指标与错误、系统层看资源与存活。盲目堆砌 New Relic + Prometheus + Zabbix 反而增加故障面，真正有效的监控是“够用、可定位、不误报”。
怎么监控 PHP-FPM 进程状态（最常被忽略的基础）
PHP-FPM 是绝大多数 Laravel、ThinkPHP、Symfony 等框架的实际执行容器，它的健康度直接决定服务是否可用。不看它，等于没监控。- 必须开启
pm.status_path（如/status），并在 Nginx/Apache 中配置安全访问（限制 IP 或加 auth_basic） - 用
curl "<a href="https://www.php.cn/link/075b71ebbee1f5ca0675bdddbedebf37">https://www.php.cn/link/075b71ebbee1f5ca0675bdddbedebf37</a>"能拿到实时字段：active processes、max active processes、slow requests、accepted conn - 关键阈值建议：
-
active processes / max children > 0.8→ 需扩容或查阻塞 -
slow requests持续增长 → 立即查slowlog文件（路径由slowlog配置项指定） -
listen queue len > 0（需开启pm.status_path的详细模式）→ 表示请求已在队列排队，FPM 已过载
-
location /status {
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
allow 127.0.0.1;
deny all;
}怎么暴露和采集 PHP 应用指标（Prometheus 实操要点）
Laravel、Hyperf、Swoole 等现代框架都适合用 Prometheus 抓取自定义指标，但很多人卡在「暴露了却抓不到」或「数据不准」。- 使用
prometheus/client_php库时，/metrics接口必须是 无认证、无重定向、无中间件拦截 的纯响应（否则 Prometheus 抓取失败） - 不要只统计「总请求数」，至少暴露三类基础指标：
-
http_requests_total{method="GET",code="200"}（Counter） -
http_request_duration_seconds_bucket{le="0.1"}（Histogram，用于算 P95/P99） -
php_memory_usage_bytes（Gauge，用memory_get_usage(true)上报）
-
- 常见坑：在 Laravel 中把 metrics 路由写在 API 中间件组里 → 导致未登录用户无法访问 → Prometheus 抓取返回 401；应单独注册为「无中间件」路由
怎么判断 PHP 微服务是否真活着（不只是 HTTP 200）
/health 返回 200 ≠ 服务健康。数据库连不上、Redis 超时、下游 HTTP 接口不可达，这些都会让服务“半死”。
-
/health接口必须做依赖探活，例如：- 尝试执行一条轻量 SQL（
SELECT 1） -
redis->ping()（带超时，如 200ms） - 对关键下游发 HEAD 请求（
curl_setopt($ch, CURLOPT_NOBODY, true)）
- 尝试执行一条轻量 SQL（
- Prometheus 的
up{job="my-service"}只反映端口可达性，真正可用性得靠你自己的service_health_status{dependency="mysql"} 0 or 1这类业务指标 - 切忌在
/health里查大表、调重接口 —— 它本身不该成为性能瓶颈
什么时候该用 APM 而不是自己埋点（New Relic / Datadog / Blackfire）
自己写microtime(true) 和日志能解决简单问题，但一旦出现「某个请求慢，但看不出哪一行慢」「并发下内存泄漏难复现」「跨服务调用链断裂」，就必须上 APM。
- New Relic 适合已用云服务、需要快速上线的团队：装 agent 后自动捕获所有 DB 查询、外部 HTTP、函数耗时，无需改代码
- Blackfire 更适合深度优化：支持「对比两次 profile」，比如改了缓存逻辑后，直接看出 SQL 调用次数降了 70%，P99 从 1200ms → 320ms
- 注意兼容性：Datadog 的
ddtrace在 Swoole 协程环境下需额外配置ddtrace.request_init_hook，否则 span 会丢失
真正容易被忽略的是：监控数据本身的质量。比如把 error_log 写到磁盘但没轮转，半年后日志文件占满根分区；或者 Prometheus 抓取间隔设成 15s，却用它查“某次具体慢请求”的堆栈 —— 它根本不是为单请求设计的。监控不是越多越好，而是每条数据都得有明确用途和处置路径。
