Linux日志排查与管理深度速查
Linux 日志排查与管理深度速查笔记
一、 Linux 日志两大核心体系
Linux 日志架构分为两个主要部分：
Linux 系统日志体系
│
┌──────────────────────┴──────────────────────┐
│ │
【systemd-journald 收集】 【传统/专用文件系统】
使用 journalctl 命令查看 直接查看 /var/log/ 目录下文件
│ │
├─ 系统内核 (Kernel/Dmesg) ├─ 传统系统日志 (syslog/messages/auth.log)
├─ Systemd 管理的所有 Service ├─ 自装独立应用 (Nginx, MySQL, Redis)
└─ 系统启动/关机/硬件事件 └─ 应用内部轮转日志 (Logrotate 生成的 .gz)
1. journalctl（Systemd 统一日志中心）
由 systemd-journald 守护进程统一收集并进行结构化存储。
- 涵盖范围：内核事件、Systemd 管理的所有服务单元（如 Podman、Docker、SSH、NetworkManager 等）的标准输出（stdout/stderr）、用户登录审计、系统启动与关机记录。
- 数据存储：以二进制格式保存在内存或
/var/log/journal/目录中。
2. /var/log 目录（独立与传统应用日志）
保存未直接依赖 Systemd 集中收集日志的软件文本日志。
- 涵盖范围：
- 独立安装的应用软件：大型应用（如 Nginx 访问日志
access.log、MySQL 错误日志error.log等）通常自行将日志写入指定文本文件。 - 传统系统日志文件：部分保留
rsyslog的系统会将部分控制台日志转存为纯文本文件（如/var/log/syslog或/var/log/messages）。
二、 journalctl 与 dmesg 深度对比
dmesg 和 journalctl 均可查看内核层面的日志，但两者的作用边界和数据来源存在显著差异。
1. 核心特性对比表
| 对比维度 | dmesg (Diagnostic Message) | journalctl (Systemd Journal) |
|---|---|---|
| 日志范围 | 仅内核日志（Kernel Ring Buffer） | 全系统日志（内核 + 所有服务 + 用户登录等） |
| 数据来源 | 内存中的内核环形缓冲区（Ring Buffer） | /var/log/journal/ 中的结构化二进制文件 |
| 生命周期 | 临时（重启即丢，缓冲区满会被新日志覆盖） | 持久（默认落盘保存，可追溯历史开机记录） |
| 时间戳格式 | 默认显示开机后的相对秒数（如 [ 123.456789]） | 默认显示系统标准时间（如 Aug 04 10:50:02） |
| 典型场景 | 硬件识别、驱动报错、内存溢出（OOM）、磁盘挂载 | 软件报错、服务启动失败、定时任务排查、登录审计 |
2. dmesg 与 journalctl 的包含关系与特例
理论上，journalctl -k 完全包含 dmesg 的所有内容，且带有标准时间戳并支持持久化存储。但在以下极少数极端场景下，两者可能存在差异：
- 开机极早期（Early Boot）：在 Linux 内核刚刚加载、
systemd-journald守护进程尚未启动的几毫秒内产生的报错，仅会保留在dmesg内存缓冲区中。 - 超高频日志限流（Rate Limiting）：当硬件故障导致内核在一秒内刷出数万条日志时，
systemd-journald为保护磁盘和 CPU 会触发主动限流并丢弃部分日志，而dmesg内存缓冲区仍会完整显示（直到被循环覆盖）。
三、 日志过滤与高级查询命令
系统日志量通常十分庞大，需结合过滤参数精准定位问题。
1. 按服务与事件类型筛选
查看指定服务的日志：
journalctl -u ql.service查看内核日志（带有标准时间戳）：
journalctl -k查看上一次开机（历史开机周期）的内核日志：
journalctl -k -b -1
2. 按时间范围筛选
查看今天产生的日志：
journalctl --since today查看最近 10 分钟内的日志：
journalctl --since "10 minutes ago"
3. 按日志级别筛选
仅显示系统错误及以上级别的严重日志（排除普通提示信息）：
journalctl -p err..emerg
4. 带标准时间戳的 dmesg 命令
将
dmesg的相对秒数转换为可读的时间戳：dmesg -T
5. 经典排查场景配合
| 遇到什么问题？ | 应该优先用哪个工具？ | 执行什么命令？ |
|---|---|---|
| 进程莫名其妙消失/被杀 | dmesg（看是否触发 OOM） | dmesg -T | grep -i oom |
| 插入 U盘/新网卡没反应 | dmesg（看内核硬件识别） | dmesg -w（实时插入观察） |
| Podman / 青龙容器启动失败 | journalctl（看服务输出） | journalctl -u ql.service -n 50 |
| 查看系统今天有没有报错 | journalctl（按级别过滤） | journalctl -p err --since today |
四、 运维故障排查标准三步法
当服务器发生异常或服务运行不靠谱时，建议按照以下优先级进行排查：
第一步：检查系统级与服务状态（使用 journalctl）
确认服务单元是否有崩溃、超时或退出状态异常。
# 1. 查看全系统最近产生的错误级别日志
journalctl -p err -n 50
# 2. 查看特定服务单元的完整日志
journalctl -u 服务名 -n 50
第二步：检查应用层业务日志（查看 /var/log 或应用特定目录）
若服务在 Systemd 中显示为正常运行（active running），但实际业务不可用（如网页无法打开、数据库拒绝连接），需去应用专属日志目录查看详细业务报错。
# 查看 Nginx 错误日志
tail -n 100 /var/log/nginx/error.log
# 查看 MySQL 错误日志
tail -n 100 /var/log/mysql/error.log
第三步：检查底层硬件与内核致命崩溃（使用 dmesg 或 journalctl -k）
用于排查进程被无故杀掉（如内存不足导致的 OOM Killer）、磁盘读写故障或系统无预警重启等严重底层问题。
# 检查是否触发了内存不足强行杀进程（OOM Killer）
dmesg -T | grep -i oom
# 或使用 journalctl 筛选
journalctl -k | grep -i oom