开机日志排查是什么
开机异常要按数据源分层看：单元日志、内核消息与启动耗时分析各自回答不同的问题。开机失败卡在某个单元时，最快的方法不是逐行翻日志，而是先列出失败单元，再单独查看它的日志，最后才是分析耗时。分层看能避免在几万行输出里找线索。
基本信息
| 适用场景 | 定位开机失败、启动缓慢或启动阶段的报错 |
|---|---|
| 数据源 | 单元日志、内核消息、启动耗时分析、失败单元列表 |
| 常用入口 | 按本次启动查日志、看内核消息、分析耗时、列出失败单元 |
| 权限 | 查看完整系统日志通常需要 root |
典型使用场景
- 开机卡住：找出是哪个单元没能起来
- 启动变慢：定位耗时最长的环节
- 内核报错：查看硬件与驱动层面的异常
- 与上次启动对比：区分是新问题还是一直存在
- 排查服务互相等待：用关键链路看依赖顺序
常用示例
常用示例
journalctl -b -p err # 本次启动的错误级别日志
journalctl -b -1 -p err # 上一次启动的日志
systemd-analyze blame | head -n 20
systemd-analyze critical-chain
systemctl --failed内核启动日志
内核启动日志
dmesg -T | head -n 80
dmesg -T --level=err,warn | tail -n 50
journalctl -k -b # 只取本次启动的内核消息数据源分工
| 数据源 | 回答的问题 | 入口 |
|---|---|---|
| 单元日志 | 某个服务为什么起不来 | 按单元过滤日志 |
| 失败单元列表 | 哪些单元进入了失败状态 | 一条命令直接列出 |
| 内核消息 | 硬件与驱动层面发生了什么 | 内核日志 |
| 启动耗时分析 | 时间花在哪一步 | 分析启动链路 |
| 上次启动日志 | 与本次相比差异在哪 | 指定前一次启动 |
启动耗时按单元排序里包含并行加载带来的正常等待，看到大数字先看关键链路再下结论，否则容易把正常现象当成故障。
虚拟机时钟漂移会打乱日志时间线，多机比对或按时间排序之前，先确认系统时间已经同步。