new relic 能精准定位 laravel 慢查询、长事务和第三方调用瓶颈，但必须同时满足：php agent 正确加载、安装 laravel-newrelic 扩展、配置自定义埋点；缺一不可，否则仅上报“unknown transaction”。
直接上结论：New Relic 能精准定位 Laravel 的慢查询、长事务和第三方调用瓶颈，但必须配合 PHP Agent + laravel-newrelic 扩展 + 有针对性的自定义埋点，缺一不可；单纯装包不配置，只会上报“Unknown transaction”。
确认 New Relic PHP Agent 已在 CentOS 上正确加载
很多性能数据不上报，根本原因不是 Laravel 配置错，而是底层 Agent 没跑起来。在 CentOS 上尤其容易卡在这步：
- 运行
php -m | grep newrelic，必须看到输出newrelic，否则 Agent 未启用 - 检查
/etc/newrelic/newrelic.ini是否已设置newrelic.license和newrelic.appname，且newrelic.enabled = true - Apache 用户需重启
httpd，Nginx + PHP-FPM 用户必须重启php-fpm（仅 reload 不生效） - 验证 Agent 是否上报：访问任意 Laravel 路由后，登录 New Relic APM 页面，等待 1–2 分钟，看是否出现应用名称——没出现就说明 Agent 层断了
用 laravel-newrelic 替代手动埋点，避免事务命名混乱
手动在中间件里调 NewRelic::nameTransaction() 很容易把所有请求都打成 WebTransaction/PHP/Unknown，因为 Laravel 的路由解析发生在中间件之后。正确做法是依赖 laravel-newrelic 的 ServiceProvider 自动注入：
- 执行
composer require newrelic/laravel-newrelic（注意不是laravel-new-relic这个旧包） - 确保
config/app.php中providers数组包含NewRelic\Laravel\NewRelicServiceProvider::class - 它会自动将事务名设为
WebTransaction/Laravel/{controller}@{method}，比如WebTransaction/Laravel/CheckoutController@pay - 若需覆盖默认命名逻辑（例如合并多个 API 版本），可在
config/newrelic.php中修改transaction_naming配置项
对 Eloquent 和 PDF 生成等重操作加自定义指标
New Relic 默认只抓 HTTP 入口和 DB 查询，但像 dompdf->render() 或批量 Model::upsert() 这类耗时操作不会被自动识别，必须显式上报：
- 在 PDF 生成处（如
PDF.php::render()）用newrelic_custom_metric('Custom/PDF/RenderTime', $ms)记录毫秒级耗时 - 对关键模型操作加观察者：在
boot()中注册static::updating(...)，用NewRelic::recordCustomMetric('Custom/Eloquent/User/UpdateDuration', $duration) - 避免高频打点：用
mt_rand(1,100) 控制仅采样 5% 请求，防止监控本身拖慢系统 - 不要在循环内调
recordCustomMetric，每次调用都有 IPC 开销；应先聚合再上报
最容易被忽略的是缓存层与 New Relic 的协同——APCu 或 Redis 命中率低时，New Relic 会把重复渲染或查库归因到控制器，实际瓶颈却在缓存失效策略。务必同步检查 apc_enabled 配置和 cacheDir 权限，否则你看到的“慢事务”，可能只是缓存没生效的假象。
