当前位置：首页 > 文章列表 > 文章 > php教程 > PHP 应用监控：Sentry、New Relic与Prometheus集成

PHP 应用监控：Sentry、New Relic与Prometheus集成

2026-05-24 17:35:21 0浏览收藏

golang学习网今天将给大家带来《PHP 应用监控：Sentry、New Relic与Prometheus集成》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习文章或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

Sentry专注错误捕获与上下文追踪，New Relic擅长全栈性能分析（含函数级耗时、DB链路），Prometheus强于自定义指标采集与告警联动；三者职责分明，混用需严守数据边界与时间同步。

直接说结论：Sentry 适合错误捕获与上下文追踪，New Relic 适合全栈性能分析（含函数级耗时、DB 查询链路），Prometheus 适合自定义指标采集 + 告警联动。三者不互斥，但混用前必须理清数据边界和职责分工——否则你会在 Grafana 看不到 Sentry 的异常率，在 New Relic 找不到 Prometheus 的队列长度。

为什么 `Sentry` 不能替代 `New Relic` 的性能监控

Sentry 的核心是异常事件（Exception、Error、Transaction），它不采样 HTTP 响应时间分布、不记录 PHP 进程内存 RSS、也不抓取 MySQL 查询的执行计划。即使你调用了 \Sentry\startTransaction()，它默认只上报「是否成功」和「总耗时」，不会自动拆解中间件、ORM、HTTP 客户端各环节耗时。

常见错误现象：Transaction 在 Sentry 控制台显示 2.4s，但实际瓶颈在 Redis 连接池等待，而 Sentry 日志里没有 redis_pool_wait_duration_ms 这类指标
使用场景：用户报“提交失败”，你靠 Sentry 快速定位到 StripeClient::createPaymentIntent() 抛了 ConnectionTimeout，但没法判断是网络抖动还是连接数打满
关键限制：Sentry 的 tracing_sample_rate 默认 1.0（全量），高 QPS 下易打爆配额；而 New Relic 的采样是服务端控制，更可控

`New Relic` 配置中容易被忽略的三个 `php.ini` 项

装完 newrelic-php5 包后，仅写 newrelic.license 和 newrelic.appname 不够。以下三项不显式设，会导致指标断层或延迟上报：

newrelic.transaction_tracer.detail = 1 —— 关闭则函数堆栈深度被截断，看不到 vendor/laravel/framework/src/.../Router.php:123
newrelic.datastore_tracer.database_name_reporting.enabled = true —— 不开就只显示「MySQL」，不显示具体 DB 名（如 prod_app）
newrelic.attributes.include = "request.uri,request.method,http.statusCode" —— 否则 transaction 里查不到请求路径，无法按路由聚合错误率

改完必须重启 PHP-FPM 或 Apache，php --ri newrelic 能看到生效的配置值，别只信 phpinfo() 页面。

`Prometheus` 暴露 `/metrics` 时最常踩的五个坑

不是 composer require promphp/prometheus_client_php 就能跑通。以下问题在真实部署中出现频率极高：

Class 'Prometheus\CollectorRegistry' 报错：漏了 gmp 扩展（php -m | grep gmp 必须有输出），不是 autoload 路径问题
/metrics 返回空内容：响应头没设对，必须是 Content-Type: text/plain; version=0.0.4，charset=utf-8 会直接让 Prometheus 抓取失败
Counter 值一直从 0 开始：每次请求都 new CollectorRegistry()，它必须是单例（全局变量或 DI 容器里注册为 singleton）
Grafana 显示「no data」：Prometheus 的 scrape_configs 里 target 写成 localhost:8000，但 PHP 是容器部署，得写宿主机 IP 或 service name
直方图（Histogram）无数据：调用 $histogram->observe($duration) 时传了毫秒值（如 1250），但 Prometheus 要求秒级浮点（1.25）

混合集成时数据对齐的关键点

Sentry 的 transaction 时间戳、New Relic 的 WebTransaction、Prometheus 的 http_request_duration_seconds 三者单位都是秒，但精度不同：Sentry 记录到毫秒级，New Relic 默认微秒级，Prometheus 直方图桶（buckets）只支持秒级分位。这意味着：

告警规则别跨工具写，比如用 Prometheus 的 P95 延迟 > 2s 触发钉钉通知，同时又在 Sentry 设「慢事务」告警——两者阈值和统计口径不一致，会重复告警
排查问题时，先看 New Relic 的分布式追踪确认瓶颈模块，再切到 Sentry 查该事务关联的异常堆栈，最后用 Prometheus 的 php_worker_memory_bytes 确认是否内存泄漏导致 GC 频繁拖慢响应
所有工具的时间必须同步，NTP 服务没开的话，New Relic 控制台可能显示「17:02:05」，而服务器 date 输出是「17:01:58」，差这 7 秒会让关联分析失效

今天关于《PHP 应用监控：Sentry、New Relic与Prometheus集成》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！