日志分析：journalctl、logrotate 与三步找线索

系统日志的两套体系

# 传统文本日志（还在，通用）
$ tail -100 /var/log/messages        # 系统级大杂烩（Ubuntu 叫 syslog）
$ tail -100 /var/log/secure          # 登录、sudo 记录（Ubuntu 叫 auth.log）

# systemd 时代：journalctl 统一管理（二进制格式）
$ journalctl -u nginx -f             # 跟踪某服务实时日志（-f 同 tail -f）
$ journalctl -u note-app --since today
$ journalctl -u note-app -n 100      # 最近 100 条
$ journalctl --since "2026-04-11 14:00" --until "14:10"
$ journalctl -p err -b               # 本次开机以来的 error 级别以上

第 12 篇注册的 note-app 服务，它的 stdout/stderr 全被 systemd 收进 journal——journalctl -u 就是它的专属日志窗口。

logrotate：给日志上镣铐

应用日志不轮转，等于定时炸弹（磁盘篇讲过 18G 的「已删未释放」）。系统自带 logrotate，给自研应用加一份配置即可：

# /etc/logrotate.d/note-app
/var/log/app/app.log {
    daily                 # 每天切一次
    rotate 14             # 保留 14 份
    compress              # 旧日志 gzip 压缩
    missingok             # 日志不存在也不报错
    notifempty            # 空日志不轮转
    copytruncate          # 先复制再截断原文件
}

$ logrotate -d /etc/logrotate.d/note-app   # -d 演练：只看会做什么，不真做

copytruncate 是应用不停机场景的关键：普通轮转靠改名，但应用还握着旧句柄继续写（磁盘篇的灵异事件）；copytruncate 复制后把原文件截断，句柄不变，应用无感。取舍是截断瞬间可能丢极少量日志——对绝大多数场景可接受。

三步找线索

# 用户反馈 14:05 开始接口大量报错——

# 第 1 步：时间切片，只看事发窗口
$ grep -c "2026-04-11 14:0[5-9]" app.log

# 第 2 步：关键字圈定 + 带上下文（grep 篇的黄金组合）
$ grep -B 2 -A 5 "Connection is not available" app.log | head -40

# 第 3 步：按 traceId 串起整个请求（微服务系列埋的伏笔）
$ grep "traceId=7f3a92" app.log

这套动作的前提是日志里有时间、有 traceId、有上下文——日志规范不是格式洁癖，是给未来的排查铺路。

实战：500 错误三分钟定位

1. journalctl -u note-app --since "5 min ago" | grep -i error   # 量级与时间分布
2. grep -B 2 -A 10 "SQLException" app.log | head -30            # 拿到完整堆栈
3. grep "traceId=xx" app.log                                    # 还原请求全链路

至此「查日志」的工具与套路都齐了。下一篇：性能观测四件套——top、free、iostat、ss 各盯什么指标，四张仪表盘怎么联动读出瓶颈在哪。