当前位置：首页>Linux>Linux 系统日志怎么看

Linux 系统日志怎么看

  • 2026-09-10 01:23:00
Linux 系统日志怎么看

上一篇讲 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 改成 persistent

  • journal 是二进制格式，不能直接 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 个级别，从严重到一般：

数字
字母
含义
0
emerg
系统不可用
1
alert
必须立即处理
2
crit
严重
3
err
错误
4
warning
警告
5
notice
一般但重要
6
info
信息
7
debug
调试
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
综合日志，啥都有（Ubuntu 是 syslog，RHEL 系是 messages）
/var/log/secure
 或 /var/log/auth.log
认证日志：SSH 登录、sudo、PAM
/var/log/dmesg
启动时的内核消息（dmesg 命令的初始内容）
/var/log/cron
crontab 执行日志
/var/log/yum.log
 / /var/log/dpkg.log
软件包安装记录
/var/log/boot.log
开机引导日志
/var/log/nginx/
nginx access + error
/var/log/mysql/
MySQL 错误日志、慢查询
/var/log/journal/
systemd-journald 持久化目录（二进制）

几个特别重要的

/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 之后追加两件事：

  1. 看上下文，谁先把内存吃光了？OOM Killer 选中的不一定是凶手，可能是受害者。dmesg | grep -B 30 "Killed process" 看前面的内存压力日志
  2. 配监控告警，让内存到 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}

常用指令速查：

指令
含义
daily
 / weekly / monthly
切割周期
size 100M
按大小切（和周期取或）
rotate N
保留 N 份历史
compress
老日志压缩成 .gz
delaycompress
上次切的不压缩，再上次的才压
copytruncate
不删原文件，复制+清空（适合不能重开日志的程序）
notifempty
空日志不切
dateext
切出来的文件名带日期，不再是 .1 .2
postrotate
 … endscript
切完执行的命令

手动测试 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" 查 OOM
  • SSH 暴破、安全审计看 /var/log/secure
  • 切日志 90% 是 logrotate，不生效大概率是应用没重新打开 fd，配 postrotate 或用 copytruncate
  • 应用日志统一走 stdout，让 journal 或者容器 runtime 收，别再自己折腾日志文件

日志这东西，平时养成顺手看一眼的习惯，故障时才能凭直觉定位。每天上线后随手 journalctl -p err -b 扫一眼，能提前发现一堆潜在问题，比事故复盘时再翻日志省心多了。

本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：596563534@qq.com 。

linux内核——调度系统——代理执行 (SCHED_PROXY_EXEC)

kali-linux-2026.1-installer-amd64.iso|官方安装镜像,纯净可定制

最新文章

随机文章