目录
一、引言：日志，运维的“监控录像”
二、/var/log：传统日志文件的藏宝图
2.1 核心日志文件速览
2.2 messages / syslog：系统的“杂记本”
2.3 secure / auth.log：安全的“门禁记录”
2.4 dmesg：内核的“第一手信息”
三、journalctl：systemd时代的日志利器
3.1 rsyslog与journald的关系
3.2 基本查询
3.3 按服务过滤
3.4 按时间过滤
3.5 按优先级过滤
3.6 高级过滤技巧
四、看懂内核报错信息
4.1 OOM Killer日志解读
4.2 磁盘I/O错误日志解读
4.3 网络相关内核日志
五、综合实战：日志排查的黄金流程
六、本篇小结
动手练习
七、下篇预告
一、引言：日志，运维的“监控录像”
想象一座大楼发生了入室盗窃案。安保人员调查的第一件事是什么？查监控录像。
Linux系统也一样。当服务突然崩溃、磁盘莫名其妙满了、有人尝试暴力破解SSH——这些事件的“监控录像”就是日志文件。
但日志和监控录像有一个共同的问题：信息量巨大，准确找到关键帧很难。/var/log下可能有几十上百个日志文件，每个文件可能包含几十万行记录。如果不掌握过滤和搜索技巧，面对海量日志会像大海捞针。
今天的目标就是让你掌握从海量日志中快速定位问题线索的能力。
二、/var/log：传统日志文件的藏宝图
2.1 核心日志文件速览
/var/log是系统日志的集中存放地。不同发行版可能略有差异，但以下文件是通用的：
bash
ls -l /var/log/
| 日志文件 | 记录内容 | 典型排查场景 |
|---|---|---|
/var/log/messages | 系统通用日志，包括内核、服务启动信息（CentOS/RHEL） | 系统启动问题、服务报错 |
/var/log/syslog | 同上，Ubuntu/Debian的等效文件 | 同上 |
/var/log/secure | 认证和安全相关事件（SSH登录、sudo提权、密码失败） | 安全审计、暴力破解排查 |
/var/log/auth.log | Ubuntu/Debian的等效文件 | 同上 |
/var/log/dmesg | 本次启动的内核环缓冲区日志 | 硬件检测、驱动加载问题 |
/var/log/boot.log | 系统启动过程日志 | 排查开机启动失败的服务 |
/var/log/cron | cron定时任务执行记录 | 确认crontab是否正常运行 |
/var/log/nginx/ | Nginx访问日志和错误日志（默认路径） | Web服务排查 |
/var/log/mysql/ | MySQL错误日志、慢查询日志 | 数据库故障排查 |
2.2 messages / syslog：系统的“杂记本”
这是最常用也最庞杂的日志文件。几乎所有系统服务都把日志发到这里。
bash
# 查看最近10条系统日志 tail -10 /var/log/messages # CentOS/RHEL tail -10 /var/log/syslog # Ubuntu/Debian # 实时监控（排查问题时打开，复现问题观察日志变化） tail -f /var/log/messages # 搜索包含error的行（不区分大小写） grep -i error /var/log/messages # 搜索特定时间段（例如今天10点到11点） grep "Apr 26 10:" /var/log/messages
2.3 secure / auth.log：安全的“门禁记录”
这个文件记录所有与认证相关的事件：谁登录了、谁退出了、谁输错了密码、谁用sudo提权了。
bash
# 查看最近20条认证记录 tail -20 /var/log/secure # CentOS/RHEL tail -20 /var/log/auth.log # Ubuntu/Debian
典型场景一：排查SSH暴力破解
bash
grep "Failed password" /var/log/secure | tail -20
输出示例：
text
Apr 26 03:15:22 myserver sshd[12345]: Failed password for root from 192.168.1.100 port 54321 ssh2 Apr 26 03:15:23 myserver sshd[12346]: Failed password for root from 192.168.1.100 port 54322 ssh2 Apr 26 03:15:24 myserver sshd[12347]: Failed password for admin from 192.168.1.100 port 54323 ssh2
看到凌晨3点有大量失败尝试，且来自同一个IP，基本可以确定是暴力破解。应对措施：封禁该IP，或切换到密钥登录。
bash
# 统计每个IP的失败尝试次数 grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn典型场景二：查看sudo使用记录
bash
grep sudo /var/log/secure | tail -10
2.4 dmesg：内核的“第一手信息”
dmesg显示内核环缓冲区（Kernel Ring Buffer）的内容，记录了从内核加载那一刻起的硬件检测、驱动初始化信息。
bash
# 查看全部内核日志 dmesg # 分页查看 dmesg | less # 只看错误和警告 dmesg --level=err,warn # 只看内存相关 dmesg | grep -i memory # 只看磁盘相关 dmesg | grep -E "sd[a-z]" # 查看最新的10条内核日志 dmesg | tail -10
dmesg在排查硬件故障时特别有用——比如插入U盘没反应，执行dmesg | tail就能看到系统是否检测到了新设备。
三、journalctl：systemd时代的日志利器
3.1 rsyslog与journald的关系
现代Linux有两套日志机制在协同工作：
| 机制 | 角色 | 特点 |
|---|---|---|
| journald | systemd内置的日志收集组件 | 二进制存储，支持结构化查询 |
| rsyslogd | 传统syslog守护进程 | 将日志写入/var/log/下的文本文件 |
它们的协作流程是：服务产生日志 → journald收集（内存+二进制存储）→ rsyslogd读取并写入传统日志文件。
journalctl的优势：你可以用丰富的过滤条件精确查询日志，而不需要手工grep。
3.2 基本查询
bash
# 查看所有日志（从本次启动开始） journalctl # 查看本次启动的日志 journalctl -b # 查看上一次启动的日志（排查“重启后就出问题”的神器） journalctl -b -1 # 实时跟踪（类似tail -f） journalctl -f # 从新到旧显示（最新在最前） journalctl -r # 限制输出行数 journalctl -n 50
3.3 按服务过滤
这是journalctl最常用的功能——只看某个服务的日志：
bash
# 查看Nginx的所有日志 journalctl -u nginx # 查看SSH服务的日志并进行实时跟踪 journalctl -u sshd -f # 查看某服务的最近100条日志 journalctl -u nginx -n 100
3.4 按时间过滤
bash
# 查看今天以来的日志 journalctl --since today # 查看最近30分钟的日志 journalctl --since "30 min ago" # 查看指定时间范围 journalctl --since "2026-04-26 09:00:00" --until "2026-04-26 10:00:00" # 组合：查看某服务在指定时间段的日志 journalctl -u nginx --since "2026-04-26 08:00:00" --until "2026-04-26 09:00:00"
3.5 按优先级过滤
Linux日志有8个优先级（从严重到轻微）：
| 优先级 | 编号 | 关键词 | 含义 |
|---|---|---|---|
| emerg | 0 | Emergency | 系统不可用 |
| alert | 1 | Alert | 必须立即处理 |
| crit | 2 | Critical | 严重错误 |
| err | 3 | Error | 错误 |
| warning | 4 | Warning | 警告 |
| notice | 5 | Notice | 正常但重要 |
| info | 6 | Info | 信息 |
| debug | 7 | Debug | 调试信息 |
bash
# 只看错误级别及以上 journalctl -p err # 只看警告级别及以上 journalctl -p warning # 组合过滤：某服务最近一天的警告和错误 journalctl -u nginx -p warning --since yesterday
3.6 高级过滤技巧
bash
# 按用户ID过滤（查看某用户相关的日志，通过id查看UID） id -u nginx journalctl _UID=997 # 按进程名过滤 journalctl _COMM=sshd # 多条件“与”组合（同时满足） journalctl -u nginx _PID=12345 # 查看占用磁盘空间的日志量 journalctl --disk-usage # 清理旧日志（保留最近7天） sudo journalctl --vacuum-time=7d
四、看懂内核报错信息
前面我们学了怎么找日志，但找到了还得看懂。内核报错信息通常比较晦涩，但掌握几个常见模式就能应对大部分情况。
4.1 OOM Killer日志解读
OOM（Out of Memory）Killer是内存耗尽时内核的“急救措施”——选择一个“罪魁祸首”进程杀死，防止整个系统崩溃。
触发场景：某个程序内存泄漏，吃光了所有可用内存和交换空间。
典型日志（通过dmesg或journalctl -k查看）：
text
[123456.789] mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [123456.790] mysqld cgroup=... memory=... memory_swap=... [123456.891] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name [123456.892] [ 12345] 1001 12345 2048000 524288 1024000 16384 0 mysqld [123456.893] Out of memory: Killed process 12345 (mysqld) total-vm:2048000kB, anon-rss:524288kB
如何解读：
invoked oom-killer：内核说“我要开杀戒了”表格显示了所有进程的内存使用情况
Killed process 12345 (mysqld)：MySQL被选中杀死了
排查思路：OOM Killer杀了进程只是表象，根因通常是某个程序内存泄漏。查看被杀进程的内存使用趋势，确认是否有异常增长。
4.2 磁盘I/O错误日志解读
典型日志：
text
[123456.789] sd 0:0:0:0: [sda] Unhandled sense code [123456.790] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [123456.791] sd 0:0:0:0: [sda] Sense Key : Medium Error [current] [123456.792] sd 0:0:0:0: [sda] Add. Sense: Unrecovered read error [123456.793] blk_update_request: critical medium error, dev sda, sector 9876543
如何解读：
sd 0:0:0:0: [sda]：出问题的设备是sda硬盘Medium Error+Unrecovered read error：磁盘介质损坏，数据读不出来sector 9876543：问题出在这块磁盘的哪个扇区
紧急行动：磁盘出现物理坏道时，应立即备份还能读出的数据，更换新磁盘。继续使用可能导致数据全部丢失。
4.3 网络相关内核日志
bash
# 查看网卡相关日志 dmesg | grep -i eth0 # 查看TCP相关日志 dmesg | grep -i tcp
常见网络日志：网卡up/down状态变化、TCP连接队列满、防火墙丢弃数据包等。
五、综合实战：日志排查的黄金流程
当系统出现“不明不白”的问题时，按以下优先级查询日志：
第一步：确定问题发生的时间范围
bash
# 用journalctl查看最近30分钟的所有错误及以上级别日志 journalctl -p err --since "30 min ago"
第二步：根据问题类型选择目标日志
| 问题表现 | 首选日志来源 | 命令示例 |
|---|---|---|
| SSH连不上 | secure/auth.log | journalctl -u sshd --since "10 min ago" |
| 网站500错误 | 应用日志 + Nginx错误日志 | tail -100 /var/log/nginx/error.log |
| 磁盘空间报警 | 无需日志，df -h直接定位 | 然后用du -sh逐层深入 |
| 服务莫名重启 | journalctl查看该服务 | journalctl -u 服务名 --since yesterday |
| 内存/CPU飙升 | dmesg看OOM，journalctl看应用日志 | dmesg | grep -i oom |
第三步：时间对齐分析
bash
# 假设网站10:15开始报错，查看10:14-10:16的所有系统日志 journalctl --since "10:14" --until "10:16" -p warning
第四步：保存证据，便于深入分析
bash
# 将关键时间段的日志导出为文本文件，方便分享和深入分析 journalctl --since "10:00" --until "10:20" > /tmp/incident_log.txt
六、本篇小结
三大日志来源：
| 来源 | 工具 | 最适合 |
|---|---|---|
| /var/log/文本文件 | tail、grep | 日常快速浏览 |
| journald | journalctl | 精确过滤、时间范围查询 |
| 内核环缓冲区 | dmesg | 硬件和驱动问题 |
journalctl速查：
| 需求 | 命令 |
|---|---|
| 看某服务日志 | journalctl -u 服务名 |
| 看最近N条 | journalctl -n N |
| 只看错误 | journalctl -p err |
| 实时跟踪 | journalctl -f |
| 指定时间段 | journalctl --since .. --until .. |
| 清理旧日志 | journalctl --vacuum-time=7d |
核心排查思维：
确定时间段 → 2. 选择目标服务 → 3. 按优先级过滤 → 4. 时间对齐分析
动手练习
bash
# 1. 查看最近30分钟的系统日志 journalctl --since "30 min ago" | tail -50 # 2. 查看SSH服务的日志（包括登录记录） journalctl -u sshd --since today # 3. 模拟一次失败的登录（用错误的密码SSH本机），然后立即查看日志 ssh nonexistent@localhost journalctl -u sshd -n 5 # 4. 查看内核启动日志中关于内存的信息 dmesg | grep -i memory # 5. 检查当前日志占用磁盘空间 journalctl --disk-usage # 6. 导出最近1小时的错误日志 journalctl -p err --since "1 hour ago" > /tmp/recent_errors.txt cat /tmp/recent_errors.txt
七、下篇预告
“这个网站怎么打不开了？”——这是运维被问最多的问题。
下一篇我们将进入网络配置基础，学习Linux网络排查的“四件套”：ip addr查看网卡信息、ping测试连通性、traceroute追踪路由、ss查看端口和连接。这些命令是排查“连不上”“响应慢”等网络问题的第一道防线。
延伸思考：你有两台服务器A和B，A可以ping通B，但B无法ssh连接A。你应该按什么顺序排查？提示：先从最简单的开始——A的SSH服务在运行吗？防火墙放行端口了吗？网络策略允许吗？日志里有什么？下一篇我们将系统学习这种分层排查的思路。
