Linux 日志治理：logrotate、journalctl、采集和告警

一、日志为什么需要治理

日志是排查线上问题最直接的证据，但不加治理的日志也会带来风险：

• 文件无限增长，磁盘被写满。
• 多进程写同一个文件，内容交错。
• 日志级别混乱，关键错误被淹没。
• 服务重启后旧日志无法关联。
• 没有采集和告警，问题只能靠人工发现。

日志治理要解决三个问题：写到哪里、保留多久、怎么发现异常。

二、文件日志和 journal

Linux 服务常见两种日志方式。

第一种是写文件：

/var/log/my_app/app.log
/var/log/my_app/error.log

优点：

• 容易被传统工具读取。
• 可按业务拆分文件。
• 和旧系统兼容好。

第二种是写 stdout/stderr，由 systemd 收集到 journal：

journalctl -u my_app -f

优点：

• 不需要应用自己管理文件。
• 天然关联服务名、PID、启动时间。
• 查询和过滤方便。

对于 systemd 管理的服务，推荐至少把关键日志输出到 stdout/stderr。

三、使用 logrotate

如果应用写文件日志，就必须配置轮转。

示例：

/var/log/my_app/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    copytruncate
    dateext
}

含义：

• daily：每天轮转。
• rotate 14：保留 14 份。
• compress：压缩历史日志。
• missingok：文件不存在不报错。
• notifempty：空文件不轮转。
• copytruncate：复制后截断原文件。
• dateext：文件名带日期。

测试配置：

sudo logrotate -d /etc/logrotate.d/my_app

强制执行：

sudo logrotate -f /etc/logrotate.d/my_app

四、copytruncate 的取舍

copytruncate 很方便，不需要应用重新打开日志文件。但它有一个小窗口：复制和截断之间写入的新日志可能丢失。

更可靠的方式是让应用支持重新打开日志文件，然后在轮转后发送信号：

/var/log/my_app/*.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    postrotate
        systemctl kill -s USR1 my_app.service
    endscript
}

是否值得这么做，取决于业务对日志完整性的要求。

五、journalctl 常用查询

查看某个服务：

journalctl -u my_app

实时查看：

journalctl -u my_app -f

查看最近 200 行：

journalctl -u my_app -n 200

按时间过滤：

journalctl -u my_app --since "2026-06-21 10:00:00"

查看本次启动以来的日志：

journalctl -u my_app -b

输出 JSON：

journalctl -u my_app -o json

JSON 输出适合被脚本或采集器进一步处理。

六、日志采集链路

常见采集链路如下：

关键点：

• 采集器要记录读取 offset。
• 多行日志需要合并规则。
• 日志字段尽量结构化。
• 采集失败要有本地缓冲。
• 后端存储要设置生命周期。

应用日志建议至少包含：

timestamp
level
service
trace_id
message
error

如果是 HTTP 服务，还可以增加：

method
path
status
latency_ms
client_ip
user_id

七、告警不要只看 error 数量

只按 ERROR 数量告警容易误报，也容易漏报。

更实用的告警维度：

• 错误率：错误请求数 / 总请求数。
• P95/P99 延迟。
• 关键任务失败次数。
• 日志采集延迟。
• 磁盘剩余空间。
• 服务重启次数。

告警规则要配合时间窗口。例如 5 分钟内错误率超过 5%，比单次错误更有意义。

八、落地清单

• 服务日志输出到 stdout/stderr 或固定目录。
• 文件日志必须配置 logrotate。
• 日志目录要有磁盘使用监控。
• 关键字段结构化，至少包含 trace_id。
• 采集器配置多行合并和 offset 持久化。
• 告警基于错误率、延迟和关键任务状态。
• 日志保留周期和业务合规要求一致。