Laravel 日志与监控最佳实践【避坑】-php教程-PHP中文网

生产环境日志级别应设为warning，telescope必须禁用或严格限用，log viewer需加鉴权中间件，activitylog须脱敏敏感字段并禁用自动causer_id填充。

laravel 日志与监控最佳实践【避坑】

log_level 配置错，生产环境日志爆炸或静默

默认 LOG_LEVEL=debug 在生产环境会写入海量调试日志，撑爆磁盘；设成 error 又可能漏掉关键 warning 或 info 级线索。真实线上问题常出现在 warning 和 notice 级别（比如数据库慢查询、缓存失效、第三方 API 降级），但这些在 error 下根本不会记录。

生产环境推荐设为 LOG_LEVEL=warning，兼顾可观测性与磁盘压力
用 daily 驱动时务必配 'days' => 7，避免日志文件无限堆积
stack 通道里不要混用 single 和 daily —— 前者不轮转，后者按天切，容易导致旧日志残留且无法归档
检查 storage/logs/ 目录权限：Web 进程必须有写权限，但不能被 Web 服务器直接公开访问（确保该目录不在 public/ 下）

Telescope 在生产环境开着，等于把数据库当缓存用

Telescope 默认把所有请求、查询、日志写进数据库表 telescope_entries，没做任何采样或限流。一个中等流量应用跑两天，这张表就破百万行，php artisan telescope:prune 手动清理又卡主进程，查 /telescope 页面直接 504。

生产环境必须关闭 Telescope 的自动记录：在 config/telescope.php 中设 'enabled' => env('TELESCOPE_ENABLED', false)，并在 .env 里明确写 TELESCOPE_ENABLED=false
真要监控，只开特定项：比如仅启用 'queries' 和 'exceptions'，关掉 'requests' 和 'logs'
如果非要用，务必配 'storage' => ['database' => ['batch_size' => 100]] 控制单次写入量，再加定时任务每天凌晨执行 php artisan telescope:prune --hours=24
别信“开发环境装了，上线删掉就行”——忘了删的案例太多，上线前 grep -r telescope *.php *.env 就能揪出来

Log Viewer 路由没加中间件，日志文件全暴露

opcodesio/log-viewer 默认路由是 /log-viewer，没任何鉴权。只要知道地址，攻击者就能下载 laravel.log，里面明文躺着数据库密码、用户 token、API key —— 这不是危言耸听，是真实发生过的安全事件。

Laravel

避免常见的Laravel错误：N+1查询、批量赋值、缓存陷阱及队列序列化陷阱。

下载

立刻在 config/log-viewer.php 里设 'middleware' => ['auth', 'can:view-logs']，别依赖注释里的默认值
确认 can:view-logs 这个 gate 已在 App\Providers\AuthServiceProvider 中定义，且只授予运维或管理员角色
禁止通过 LOGVIEWER_STORAGE_PATH 指向 storage/app/ 或任何可被 Web 访问的路径；必须用 storage_path('logs') 这种绝对路径
哪怕用了加密参数（如 Crypt::encrypt()），也挡不住暴力遍历或 SSRF，中间件是唯一可靠防线

Activitylog 记了密码字段，审计时直接背锅

Spatie\Activitylog 默认记录模型所有变更，User::update(['password' => 'xxx']) 会把明文密码原样写进 activity_log 表。等渗透测试扫出这行数据，合规整改单就来了。

每个带敏感字段的模型都必须显式调用 logExcept(['password', 'api_token'])，不能靠全局配置“以为都拦住了”
对邮箱、手机号这类 PII 数据，用管道机制脱敏：$event->changes['attributes']['email'] = substr($email, 0, 3) . '***@' . explode('@', $email)[1]
禁用 causer_id 自动填充（它会把当前登录用户 ID 写进去），改用 causer()->id 显式传参，避免后台任务触发时写错人
定期跑 SQL 检查：SELECT * FROM activity_log WHERE subject_type = 'App\Models\User' AND changes LIKE '%password%'; —— 有结果就得立刻清空并回溯代码

日志不是记下来就完事，每一条落盘的数据都要经得起追问：谁写的、为什么写、有没有越权、能不能反推原始信息。配置项背后是责任，不是开关。