ubuntu上thinkphp日志管理技巧有哪些

日志管理这事，说大不大，说小不小。很多团队在 Ubuntu 上跑 ThinkPHP 项目，日志要么是默认配置凑合用，要么是等磁盘满了才想起来处理。实际上，把日志管好，不仅能让你在排查问题时少掉几根头发，对安全和合规也是一种保护。

下面这套方法论，核心思路就一句话：日志要分得开、存得住、查得快、扫得净。具体怎么落地，我们从几个关键维度展开。

一 基础配置与目录规范

首先，日志到底写到哪里？很多新手会直接把日志丢到系统 /var/log 下面，这其实不太明智。系统日志和应用日志混在一起，权限、备份、清理都会很麻烦。更合理的做法是统一写到项目目录下的 runtime/logs，这样既能隔离风险，也方便后来接手的人快速定位。

环境的区别也要考虑进去。开发环境可以开 debug 和 sql 级别的日志，帮你在编码阶段快速定位问题；生产环境就只保留 info、notice、warning、error 这些必要级别，避免不必要的 I/O 开销，也减少了信息暴露的风险。

还有一个容易被忽略的细节——日志格式。如果你还在用那种多行文本格式，当你需要把日志导入到 ELK 或 Graylog 的时候，你就知道什么叫“解析地狱”了。所以建议开启单行 JSON 格式记录，ThinkPHP 从 5.1.15 版本开始就支持这个特性了。一个典型的配置如下：

// config/log.php
return [
    'default' => env('log.channel', 'file'),
    'level' => env('APP_DEBUG') ? 'debug' : 'info',
    'type'=> 'File',
    'path'=> runtime_path('logs'),
    'json'=> true, // 单行 JSON，便于采集
    'max_files' => 30, // 保留最近30个文件（自动清理）
];

这里 max_files 和 json 是关键点，ThinkPHP 从 5.1.6 开始支持按文件数量自动清理。

二 分级存储与保留策略

把所有日志写到一个文件里，然后让它们一起滚动，这是最省事的做法，但也是最不聪明的做法。真正有效的方案是“分级通道”——把常规日志、错误日志、紧急日志分开放，各自设置不同的保留周期和分割策略。这样既能方便日常排查，又能控制存储成本。

来看一个配置模板：

// config/log.php
return [
    'default' => 'stack',
    'channels' => [
        'stack' => [
            'type' => 'stack',
            'channels' => ['daily', 'error_file', 'emergency'],
        ],
        'daily' => [
            'type' => 'file',
            'path' => runtime_path('logs/daily'),
            'level' => ['info','notice','warning'],
            'max_files' => 30, // 保留30天
            'file_size' => 10485760,// 10MB 分割
            'json' => false,
        ],
        'error_file' => [
            'type' => 'file',
            'path' => runtime_path('logs/error'),
            'level' => ['error','critical'],
            'max_files' => 90, // 保留90天
            'apart_level' => true, // 每个级别单独文件
            'file_size' => 20971520,// 20MB 分割
            'json' => true,// JSON 便于分析
        ],
        'emergency' => [
            'type' => 'file',
            'path' => runtime_path('logs/emergency'),
            'level' => ['emergency'],
            'max_files' => 365,// 保留1年
        ],
    ],
];

这个配置的核心逻辑很直观：日常运行的 info 日志，按天或按文件大小滚动，保留一个月就够了；error 及以上级别的错误日志，保留三个月，方便排查线上问题；至于 emergency 级别，那是真正的“出大事了”，需要保留一整年作为审计依据。

三 系统级日志轮转与清理

虽然 ThinkPHP 自带的 max_files 已经能解决一部分日志清理的问题，但如果你对日志管理有更高的要求——比如想按日轮转、希望在滚动时压缩旧日志、或者需要精确控制文件权限——那么 logrotate 是不可替代的。

在 Ubuntu 上配置 logrotate 非常简单，只需创建一个配置文件，比如 /etc/logrotate.d/thinkphp：

/path/to/project/runtime/logs/*.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 640 www-data www-data
    sharedscripts
    postrotate
        # 如需要，可在此触发应用内刷新句柄（可选）
    endscript
}

这个配置的意思是：每天轮转一次、保留 30 个副本、旧日志压缩存储、日志文件在轮转后如果为空则不创建新文件、新文件默认权限为 640 并属于 www-data 用户组。对于大部分项目来说，这样的配置已经足够稳健。

如果你觉得 logrotate 还不够，或者某些场景下需要更灵活的兜底方案，crontab + find 仍然是一个有效的补充策略。比如下面这条命令，每 30 分钟清理一次 10 天前的日志：

# 每30分钟清理一次10天前的日志
*/30 * * * * find /path/to/project/runtime/logs -mtime +10 -name "*.log" -delete

提醒一句：logrotate 是首选，find 方案适合作为应急或特定目录的补充。两者不冲突，可以结合使用。

四 安全与合规要点

日志里容易踩的一个坑，就是敏感信息泄露。很多框架默认的日志会将所有上下文记录下来，如果你在应用中传了 password、token 或者 credit_card 这样的字段，它们也会被原样写进日志。这在生产环境中是非常危险的。

解决思路很简单：在写日志之前，对上下文做一层过滤。例如：

$context = array_filter($context, function($key) {
    return !in_array($key, ['password','token','credit_card']);
}, ARRAY_FILTER_USE_KEY);

另外，错误日志建议统一采用 JSON 格式。这不只是为了好看——当你需要对接 ELK 或 Graylog 这类日志分析平台时，JSON 格式的日志可以省去大量的解析工作。如果你用的是数据库日志驱动，还可以在驱动层直接忽略敏感字段，做到一劳永逸。

最后一条硬规则：生产环境必须关闭 APP_DEBUG。只保留必要级别的日志，既能减少性能开销，也能最大程度降低信息泄露的风险。

五 集中化与扩展采集

当你的项目不止一台服务器时，分散在机器上的日志就变成了管理负担。这时候就需要考虑引入 Monolog 这样的第三方库，或者自己写一个日志驱动，把 error 和 emergency 级别的日志同步到外部日志服务或消息通道。

以 Monolog 为例，它可以非常方便地写入文件并支持自动滚动：

use Monolog\Logger;
use Monolog\Handler\RotatingFileHandler;
use Monolog\Formatter\LineFormatter;

$logger = new Logger('app');
$handler = new RotatingFileHandler('/path/to/project/runtime/logs/app.log', 30, Logger::DEBUG);
$formatter = new LineFormatter(
    "[%datetime%] [%channel%.%level_name%] %message% %context% %extra%\n",
    'Y-m-d H:i:s',
    true,
    true
);
$handler->setFormatter($formatter);
$logger->pushHandler($handler);

$logger->error('Something went wrong', ['uid'=>123]);

单靠文件日志还不够。如果你想实现对日志的快速检索、可视化分析和告警，ELK Stack 或者 Graylog 是更成熟的选择。把日志从文件推到 Logstash，再到 Elasticsearch，最后通过 Kibana 呈现出来，这几乎是现代 DevOps 的标准配置。

归根到底，日志管理的意义不在于“存了多少”，而在于“需要的时候能不能调出来、调出来之后能不能看懂”。上面的这些技巧，归根到底都是围绕这个目标在服务。