Linux 系统日志怎么看
- 2026-07-02 06:18:00
上一篇讲 Docker 容器排查，最后一步基本都是看日志。容器日志好查（docker logs 一把梭），主机层的日志就麻烦多了——/var/log 下七八个文件，systemd 又搞出个 journalctl，到底先看哪个？这篇按自己平时排线上问题的真实顺序，把 Linux 日志体系一次性梳理清楚。看完一篇能解决"机器变慢、服务挂了、磁盘满了"这种问题的 80% 现场。
一、Linux 日志体系：从 syslog 到 journal
老一代 Linux 全靠 syslog 协议 + rsyslogd/syslog-ng 这种守护进程把日志写到 /var/log/*.log 文本文件里。systemd 来了之后，搞了一套 journald：
┌─────────────────────┐│ kernel / dmesg │ ──┐├─────────────────────┤ ││ systemd-journald │ <─┤ 收集所有来源（内核、systemd 服务、syslog、用户应用）├─────────────────────┤ ││ 应用 stdout/stderr │ ──┤ ├─────────────────────┤ ││ syslog API 调用 │ ──┘ └─────────────────────┘ │ ├──> /run/log/journal/ （内存，重启丢） ├──> /var/log/journal/ （持久化，需要手动开） └──> 转发给 rsyslog → /var/log/messages 等老格式文件几个关键点必须知道：
journal 默认存内存（
/run/log/journal/），重启就没。要持久化得自己开：bash mkdir -p /var/log/journalsystemd-tmpfiles --create --prefix /var/log/journalsystemctl restart systemd-journald# 或者改 /etc/systemd/journald.conf 把 Storage=auto 改成 persistentjournal 是二进制格式，不能直接
cat或vim看，必须用journalctl/var/log 下传统文件还在，因为 journald 通常会转发给 rsyslogd 兼容老工具
现代发行版（CentOS 8+、Ubuntu 20+）以 journald 为主，老的 CentOS 6/7、Ubuntu 16 还是 rsyslog 为主
新人记一句：先 journalctl，再 /var/log，最后 dmesg。
二、journalctl 常用姿势
journalctl 不带参数会把所有日志从最老到最新都打出来，会卡死。下面是真正常用的几种姿势。
按时间过滤
bash # 看最近 100 行（最常用）journalctl -n 100# 跟随，类似 tail -fjournalctl -f# 最近 10 分钟journalctl --since "10 min ago"# 今天journalctl --since today# 某个具体时段journalctl --since "2024-11-08 10:00" --until"2024-11-08 10:30"# 最近一次启动以来journalctl -b# 上一次启动（重启前）journalctl -b -1
-b 这个超有用——机器昨晚重启了，怀疑是被 kernel panic 干掉的，journalctl -b -1 -p err 直接看上次启动的所有错误。
按服务过滤
bash # 看某个 systemd 服务journalctl -u nginxjournalctl -u docker# 多个服务journalctl -u nginx -u docker# 服务 + 跟随 + 最近 100 行journalctl -u nginx -n 100 -f
这个比去翻 /var/log/nginx/error.log 方便太多，所有 systemd 启动的服务都自动进 journal，统一入口。
按优先级过滤
syslog 8 个级别，从严重到一般：
bash # 只看错误及以上（err、crit、alert、emerg）journalctl -p err# 看 warning 及以上journalctl -p warning# 范围过滤（注意：范围语法是从小到大，0=emerg，7=debug）journalctl -p 1..3 # alert 到 err（数字越小越严重）
线上排查最常用 journalctl -p err -b：当前启动以来的所有错误，半屏输出能扫完。
按 PID / UID 过滤
bash # 看某个进程journalctl _PID=12345# 看某个用户journalctl _UID=1000# 内核日志（等价于 dmesg）journalctl -k
几个实用组合
bash # nginx 服务，最近 1 小时所有错误journalctl -u nginx --since "1 hour ago" -p err# 跟随某个服务的日志，过滤含 "timeout" 的行journalctl -u myapp -f | grep -i timeout# 看完整 message 不截断（有些 message 很长，默认会截断）journalctl --no-pager -u myapp -n 100# 输出成 JSON（适合喂给 jq 处理）journalctl -o json -n 100 | jq '.MESSAGE'# 反向输出（最新在最上面）journalctl -r -n 50
日志占多少空间
bash journalctl --disk-usage# Archived and active journals take up 1.2G in the file system.# 手动清理：保留最近 7 天journalctl --vacuum-time=7d# 手动清理：只保留 500MBjournalctl --vacuum-size=500M
journal 默认会自己管理大小（SystemMaxUse 默认 = 磁盘 10%，但不超过 4G；同时保留 SystemKeepFree 默认 15%），但容器化的机器、磁盘小的机器，建议明确设置上限。改 /etc/systemd/journald.conf：
ini [Journal]Storage=persistentSystemMaxUse=500MSystemMaxFileSize=50MMaxRetentionSec=1week
三、/var/log 下都有什么
journal 之外，/var/log 下的老式文件目前还广泛存在。挑常用的说：
/var/log/messages/var/log/syslog | |
/var/log/secure/var/log/auth.log | |
/var/log/dmesg | |
/var/log/cron | |
/var/log/yum.log/var/log/dpkg.log | |
/var/log/boot.log | |
/var/log/nginx/ | |
/var/log/mysql/ | |
/var/log/journal/ |
几个特别重要的
/var/log/secure（auth.log）
排查"谁动了我的服务器"必看：
bash # 看最近的 SSH 登录尝试tail -100 /var/log/secure | grep ssh# 失败的登录（被爆破常见）grep "Failed password" /var/log/secure | tail -20# 成功的登录grep "Accepted" /var/log/secure | tail -20# sudo 提权grep sudo /var/log/secure | tail -20
线上机器突然慢了，先看一眼 secure 里有没有大量 Failed password——很可能正在被暴力破解 SSH，可以用 fail2ban 自动封 IP。
/var/log/cron
cron 执行了什么、什么时候执行的、有没有报错：
bash tail -50 /var/log/cron# Nov 8 03:00:01 server CROND[12345]: (root) CMD (/data/scripts/backup.sh)# Nov 8 03:01:23 server CROND[12345]: (root) CMDEND (/data/scripts/backup.sh)
但 cron 只记录执行了什么命令，命令本身的输出要么写到文件里，要么默认发邮件给用户。不知道任务有没有跑成功？看下一节 dmesg 之外的实际排查。
四、dmesg 看内核日志：OOM、磁盘、网卡
dmesg 看内核环形缓冲区，主要是硬件、内核子系统的消息：
bash # 看最近的内核日志dmesg | tail -100# 带可读时间（新版默认就有，老版要加 -T）dmesg -T | tail -100# 跟随dmesg -w# 只看错误及以上dmesg -l err,crit,alert,emerg# 按子系统过滤dmesg -f kern
OOM Killer 真实案例
线上 Java 服务突然没了，systemd 也没记录是它主动退出，第一反应：被 OOM Killer 杀了。
bash dmesg -T | grep -i "killed process"
输出大致这样：
[Fri Nov 8 14:32:11 2024] Out of memory: Killed process 23145 (java) total-vm:8421032kB, anon-rss:3954012kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8744kB oom_score_adj:0[Fri Nov 8 14:32:11 2024] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-1.scope,task=java,pid=23145,uid=1000字段含义：
total-vm：进程占用的虚拟内存（含 swap、未真正使用的） anon-rss：实际占用的物理内存（这个才是真用了多少） oom_score_adj：OOM 时被选中的优先级调整，值越大越容易被杀
确认是 OOM 之后追加两件事：
看上下文，谁先把内存吃光了？OOM Killer 选中的不一定是凶手，可能是受害者。 dmesg | grep -B 30 "Killed process"看前面的内存压力日志配监控告警，让内存到 80% 就报，别等 OOM 才知道
磁盘错误
磁盘要挂之前，dmesg 里通常会有蛛丝马迹：
bash dmesg -T | grep -iE "I/O error|sector|sda|nvme"
类似这种就是磁盘坏道：
[Wed Nov 6 09:12:45 2024] sd 0:0:0:0: [sda] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK[Wed Nov 6 09:12:45 2024] sd 0:0:0:0: [sda] tag#0 Sense Key : Medium Error [current][Wed Nov 6 09:12:45 2024] sd 0:0:0:0: [sda] tag#0 Add. Sense: Unrecovered read error[Wed Nov 6 09:12:45 2024] critical medium error, dev sda, sector 1234567890立刻：① 把这块盘上的服务迁走 ② SMART 看一下盘的健康（smartctl -a /dev/sda） ③ 报修。
网卡问题
bash dmesg -T | grep -iE "eth|link|carrier"# [Tue Nov 5 10:23:11 2024] eth0: link down# [Tue Nov 5 10:23:13 2024] eth0: link up, 1000Mbps, full duplex
频繁 link down/up 通常是网线松了或者交换机端口在抖。
五、logrotate 配置详解 + 不生效的高频坑
应用日志写到 /var/log/myapp.log，不切割的话一天能写几个 G，磁盘很快炸。logrotate 就是干这个的，每天 cron 跑一次。
全局配置 + 服务配置
/etc/logrotate.conf # 全局默认/etc/logrotate.d/* # 各服务单独的配置文件一个典型的 nginx 配置 /etc/logrotate.d/nginx：
conf /var/log/nginx/*.log { daily # 每天切一次 rotate 30 # 保留 30 份 compress # 压缩老日志 delaycompress # 推迟一天压缩（避免正在写的文件被压） notifempty # 空文件不切 missingok # 文件不存在不报错 create 0640 nginx nginx # 切完新建空文件，指定权限和属主 sharedscripts # 多个文件共用 postrotate postrotate # 切完通知 nginx 重新打开日志文件 if [ -f /var/run/nginx.pid ]; then kill -USR1 `cat /var/run/nginx.pid` fi endscript}
常用指令速查：
dailyweekly / monthly | |
size 100M | |
rotate N | |
compress | |
delaycompress | |
copytruncate | |
notifempty | |
dateext | |
postrotateendscript |
手动测试 logrotate 配置
写完别等明天，当场测试：
bash # 干跑（不真切，只看会做什么）logrotate -d /etc/logrotate.d/nginx# 强制执行一次（无视周期）logrotate -f /etc/logrotate.d/nginx
不生效的 4 大原因
写完测试没问题，第二天发现日志还是没切，多半是下面这几个坑：
1. 应用不重新打开日志文件，继续写老 inode
logrotate 默认会 mv access.log access.log.1，但应用进程的文件描述符还指向原 inode，会继续往老文件写——表现就是新文件一直是空的，老文件一直在涨。
解决方法二选一：
配 postrotate给应用发信号让它重新打开日志（nginx 是USR1，php-fpm 是USR1，rsyslog 是HUP）用 copytruncate，不动 inode，只把文件复制走再清空原文件。但有数据丢失风险（复制和清空之间写入的内容会丢）
conf # nginx 推荐 postrotatepostrotate kill -USR1 `cat /var/run/nginx.pid`endscript# Java / Python 应用不好控制，用 copytruncatecopytruncate
2. cron / anacron 没跑
bash # 检查 logrotate 的定时任务在哪ls -l /etc/cron.daily/logrotatels -l /etc/anacrontab# 看上次跑的时间cat /var/lib/logrotate/logrotate.status | head -20# 如果状态文件里时间是几天前，说明 cron 根本没在跑systemctl status crond # RHEL/CentOS 系默认 cronsystemctl status anacron # Debian/Ubuntu 系默认 anacron（机器关机过会补跑任务）
3. 文件权限 / 属主不对
日志文件属主是 appuser，logrotate 是 root 跑的，切完用 create 0640 root root 新建——结果新文件 root 用户拥有，应用进程没权限写，服务直接挂。
conf # 切完新建的文件必须保持原属主create 0640 appuser appuser# 或者用 su 指定身份su appuser appuser
4. 文件路径里有通配，但目录被锁定
/data/logs/*.log 这种路径如果目录 mode 是 700 且 logrotate 没权限读，会静默跳过。logrotate -d 干跑会提示。
六、应用日志怎么接入 journal
两种方式，强烈推荐第一种：
方法 1：直接输出到 stdout/stderr
只要服务由 systemd 启动，stdout 自动进 journal。Service 文件不用任何特殊配置：
ini [Service]ExecStart=/usr/local/bin/myappStandardOutput=journalStandardError=journal# 默认就是 journal，可以不写
应用代码层面只要 print() / log.info() / console.log() 输出到 stdout 就行，别写文件、别配复杂 appender。然后用 journalctl -u myapp -f 看日志，体验和 docker logs 一样好。
方法 2：用 syslog API
老应用、二进制工具一般都支持 syslog 协议：
bash # Bash 里输出到 sysloglogger -t myapp "服务启动完成"logger -p user.warning -t myapp "出现警告"
journald 会自动收，journalctl -t myapp 能查到。
云原生时代，所有新应用一律 stdout，别再纠结日志文件路径、归档、清理这些事——交给 journal / 容器 runtime / Loki 这些组件去操心。
七、grep + awk + sed 查问题组合拳
journalctl 和 tail 取到日志后，下一步基本就是过滤和提取。下面这些是日常用得最多的几招。
grep 高频姿势
bash # 不区分大小写grep -i "error" app.log# 上下文 3 行（看错误前后发生了什么）grep -B 3 -A 3 "OutOfMemory" app.loggrep -C 3 "OutOfMemory" app.log # 上下各 3 行# 多个关键词（或）grep -E "error|exception|fail" app.log# 排除某些行grep "ERROR" app.log | grep -v "test"# 只看匹配的内容（用 -o + 正则提取）grep -oE "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" access.log | sort -u# 递归在目录里找grep -rni "todo" ./src# 只列出包含的文件名grep -rl "DEBUG_MODE" ./src
awk 实用一行命令
bash # 看 nginx access.log 里 PV TOP 10 的 URLawk '{print $7}' access.log | sort | uniq -c | sort -rn | head -10# 看访问最多的 IPawk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10# 统计每个状态码的数量awk '{print $9}' access.log | sort | uniq -c | sort -rn# 5xx 错误总数awk '$9 ~ /^5/' access.log | wc -l# 取特定时间段的日志（假设第 4 列是时间 [10/Nov/2024:14:00:00]）awk '$4 >= "[10/Nov/2024:14:00:00" && $4 <= "[10/Nov/2024:15:00:00"' access.log# 求和（比如统计响应体大小总和，第 10 列）awk '{sum += $10} END {print sum}' access.log
sed 常用一行命令
bash # 替换并直接修改文件sed -i 's/old/new/g' file.txt# 替换前先备份sed -i.bak 's/old/new/g' file.txt# 只输出第 100-200 行sed -n '100,200p' app.log# 删除空行sed -i '/^$/d' file.txt# 在某一行后插入sed -i '5a 这是新加的一行' file.txt
组合实战：从 nginx 日志里挖出一个慢接口
bash # nginx log_format 配了 $request_time，假设它是第 11 列# 找出响应时间 >2s 的请求awk '$11 > 2' access.log | awk '{print $7, $11}' | sort -k2 -rn | head -20# 加上时间段过滤awk '$4 >= "[10/Nov/2024:14:00:00" && $11 > 2' access.log \ | awk '{print $7, $11}' | sort | uniq -c | sort -rn | head -20
这种东西不要每次现敲，做成脚本扔到 ~/scripts/。
八、写在最后
日志相关的关键点拎出来：
排查永远是先 journalctl -u xxx，再翻/var/log/xxx，最后dmesg看内核journal默认存内存，重启就丢，生产机器一定要开持久化 服务突然没了，先 dmesg | grep -i "killed process"查 OOMSSH 暴破、安全审计看 /var/log/secure切日志 90% 是 logrotate，不生效大概率是应用没重新打开 fd，配postrotate或用copytruncate应用日志统一走 stdout，让 journal或者容器 runtime 收，别再自己折腾日志文件
日志这东西，平时养成顺手看一眼的习惯，故障时才能凭直觉定位。每天上线后随手 journalctl -p err -b 扫一眼，能提前发现一堆潜在问题，比事故复盘时再翻日志省心多了。
随机文章
-
10个月宝宝每天需要喝多少奶粉？
- Python办公自动化连载07:Pandas数据筛选、排序、条件查询
- Linux下怎么快速找1天内修改过的所有文件?我有3种方法,10秒出结果
- 微软把Linux指令搬进Windows,这叫致敬?用户不买账就对了
- 深入 Linux 内核:容器隔离的底层逻辑与逃逸本质
- 量化QMT六大常用Python三方数据库
- 嵌入式Linux,学应用还是驱动?
- llama.cpp在Linux上安装使用指南
- 如何用Python+AI打造一个能自动回复的聊天机器人?
- 【零基础玩转Python】Day42:数据排序与排名 – sort_values, rank,让数据有序竞争
- OpenAI Python SDK 实战:responses.create 和 responses.parse 到底怎么选?
