1、启动日志概述：什么是系统启动日志、启动日志的作用、常见的日志系统
各位同学，咱们今天聊聊系统启动日志。说实话，这玩意儿我刚开始接触Linux那会儿，根本没当回事。总觉得系统能跑起来就行，看什么日志？直到有一次线上服务器莫名其妙重启，我翻遍了所有配置都找不到原因……嗯，后来还是靠启动日志里的一个时间戳异常，才揪出是电源模块的锅。从那以后，我养成了一个习惯：每次部署新系统，第一件事就是检查启动日志的完整性。
什么是系统启动日志？
说白了，启动日志就是系统从按下电源键到完全启动成功这段时间里，内核、驱动、服务、硬件等各个组件留下的「自白书」。你想想看，系统启动时，CPU要初始化、内存要检测、磁盘要挂载、网络要配置……每一步都可能出问题。日志就是把这些步骤的成败、耗时、异常信息，一条条记录下来。
我个人习惯把启动日志比作「系统的出生证明」。它记录了系统从无到有的全过程。比如：
- 内核版本是什么时候加载的
- 哪个驱动加载失败了
- 文件系统检查花了多久
- 某个服务启动超时了
这些信息，平时你可能觉得没用。但系统一旦出问题，它就是你的救命稻草。
核心要点：启动日志不是普通的应用日志，它记录的是系统「活着」之前的状态。很多故障，只有启动日志里才有线索。
启动日志的作用
我总结了一下，启动日志主要有三个作用。每个都是我踩过坑之后才真正理解的。
- 故障定位——这是最直接的用途。系统起不来？看日志。服务没启动？看日志。硬件不识别？还是看日志。我记得有一次，客户说服务器开机后网络不通。我远程连上去，发现系统已经起来了，但网卡没激活。查了启动日志，发现是网卡固件加载时超时了。换个固件版本，问题解决。
- 性能分析——启动慢，是很多运维头疼的问题。启动日志里记录了每个服务的启动耗时。你可以精确地知道：是磁盘I/O瓶颈？还是某个服务卡住了？还是内核参数配置不合理？我曾经帮一个客户优化系统启动时间，从90秒降到了18秒。靠的就是逐条分析启动日志里的时间戳。
- 安全审计——系统是否被非法篡改？启动日志里会有蛛丝马迹。比如内核模块被替换、启动脚本被修改、或者有异常的硬件接入。这些信息在常规日志里可能看不到，但启动日志会忠实记录。
我的小技巧：每次系统更新内核或驱动后，我都会对比一下更新前后的启动日志。看看有没有新增的警告或错误。很多潜在问题，就是在这一步被提前发现的。
常见的日志系统
说到日志系统，目前主流的有两个：systemd-journald 和 syslog。嗯，这里要注意，它们不是互斥的，很多系统两个都在跑。
| 特性 | systemd-journald | syslog（rsyslog/syslog-ng） |
|---|---|---|
| 存储方式 | 二进制日志（journal文件） | 纯文本文件 |
| 查询方式 | journalctl 命令 | grep、tail 等文本工具 |
| 结构化程度 | 高（包含元数据、时间戳、优先级等） | 低（主要是文本消息） |
| 默认保留 | 按容量或时间轮转 | 按文件大小轮转 |
| 适用场景 | 现代Linux发行版（CentOS 7+、Ubuntu 15+） | 传统Unix/Linux系统 |
systemd-journald
这是目前最主流的日志系统。它和systemd深度集成。说白了，所有由systemd管理的服务，它们的启动日志、标准输出、错误输出，都会被journald捕获。你想想看，这意味着什么？意味着你不用再去翻各种服务的独立日志文件了。一条 journalctl 命令，就能看到系统启动的全貌。
我个人最喜欢它的一个功能：按时间回溯。比如你想看「系统启动后第3秒到第10秒之间发生了什么」，用 journalctl --since "3s ago" --until "10s ago" 就能搞定。这在排查启动阶段的时序问题时，简直不要太方便。
# 查看本次启动的所有日志
journalctl -b
# 查看上一次启动的日志（系统重启后）
journalctl -b -1
# 查看内核启动日志
journalctl -k
# 查看某个服务的启动日志
journalctl -u nginx.service
注意：journald的日志是二进制的，不要直接用cat或vim去读。我曾经见过有人用cat /var/log/journal/* 然后说「怎么全是乱码」……嗯，要用journalctl。
syslog（rsyslog/syslog-ng）
syslog是更老牌的日志系统。它的设计哲学很简单：把日志写成文本文件，按设施（facility）和优先级（priority）分类。比如内核日志写到 /var/log/kern.log，系统消息写到 /var/log/messages。
虽然现在很多新系统默认用journald，但syslog并没有被淘汰。为什么呢？因为它的文本格式太方便了。你可以用grep、awk、sed这些经典工具直接处理。而且，很多老运维（包括我）已经习惯了 tail -f /var/log/messages 这种操作方式。
我记得有一次，一个客户的系统是CentOS 6，只有syslog没有journald。我远程排查启动问题，就是靠 grep -i error /var/log/messages 和 dmesg 配合着看。虽然不如journalctl那么强大，但该查的问题一样能查出来。
# 查看系统消息日志
tail -f /var/log/messages
# 查看内核日志
dmesg | less
# 查看认证相关日志
grep "Failed password" /var/log/secure
两者如何选择？
其实不用选。现代系统通常两个都装。journald负责收集和存储，syslog负责转发和归档。比如你可以配置journald把日志转发给rsyslog，然后由rsyslog写到远程日志服务器。这样既保留了journald的查询能力，又利用了syslog的集中管理优势。
我个人建议：日常排查用journalctl，长期归档用syslog。两者配合，基本能覆盖所有场景。
一句话总结：启动日志是系统的「黑匣子」。journald让你查得爽，syslog让你存得稳。两个都学会，运维路上少踩坑。