凌晨两点DBA 电话把你吵醒说数据库连接数被打满应用侧全部超时。你揉着眼睛上服务器CPU 不高、内存还有余量MySQL 进程明明活着但就是连不进去。折腾二十分钟后你才想起来去看/var/log/messages里面早就写满了同一条报错——文件句柄不够。如果能早十分钟打开日志这个问题十分钟就能解决。这是我职业生涯里真实发生过的事也是我为什么一直强调Linux 系统日志不只是给“出事了以后”用的它是你第一时间定位问题、做安全审计、甚至复盘整个攻击路径的第一手材料。这篇文章我就不讲那些“日志很重要”的废话了直接按“故障排查、安全审计、渗透复盘”三个用途把 Linux 系统日志的核心文件、关键命令、典型场景串一遍。无论你是刚入行的运维、写后端的开发还是做安全的同学照着这篇文章翻日志效率至少翻一倍。1. 先搞清楚Linux 日志到底是怎么流转的很多新手一上来就背文件名什么/var/log/messages、/var/log/secure背了一堆真遇到问题还是不知道看哪里。原因很简单你没搞懂日志是从哪来的、经过谁、最后写到哪个文件。就像你只知道冰箱里有菜但不知道菜是谁买的、怎么放进去的做饭的时候照样抓瞎。1.1 日志的产生、收集与落盘的完整链路Linux 系统里的日志来源其实就三大类内核、系统服务、应用进程。内核日志主要由printk产生服务和应用则通过标准库的syslog()函数把日志发出来。这些日志消息会按照 syslog 协议打上标签标签分两部分一个叫 facility设施一个叫 severity级别。facility 决定这条日志属于哪个子系统比如authpriv是认证相关的cron是计划任务相关的kern是内核的severity 决定严重程度从debug、info、notice、warning、error、crit、alert到emerg级别依次升高。这俩标签就是后续日志怎么分流、怎么过滤的依据。到了 systemd 时代系统里会同时存在两个日志采集者systemd-journald和rsyslogd。systemd-journald是 systemd 自带的它把所有日志收进内存或磁盘的二进制循环缓冲区里这也是为什么你在 CentOS 7 以后的系统上能用journalctl看到很多日志但/var/log/messages里反而没有。rsyslogd则会读取这些事件再按/etc/rsyslog.conf里的规则把它们写到不同的文本文件里。所以你在排查问题的时候最好两条线一起查journalctl看全量、看实时/var/log/下的文本日志看历史、做精确分析。只盯一条线很容易漏信息。1.2 /var/log 目录地图哪个文件解决什么问题我把常用的日志文件整理成了一张表。你不需要全背但心里要有这张地图出问题的时候能快速定位到“该看哪个文件”。日志文件记录内容读取方式典型场景/var/log/messages系统整体运行事件、服务输出、内核消息的汇总cat/tail/grep故障排查首选入口/var/log/secure认证与授权日志SSH 登录、sudo、su 等cat/tail/grep安全审计、暴力破解分析/var/log/boot.log系统启动过程的输出cat启动到哪个服务卡住/var/log/dmesg内核环形缓冲区消息硬件、驱动、OOMdmesg 命令硬件识别失败、驱动加载异常/var/log/cron计划任务执行记录cat/tailcrontab 任务没执行、执行报错/var/log/maillog邮件系统收发日志cat/tailpostfix/sendmail 排查/var/log/lastlog每个用户最后一次登录时间lastlog 命令账号被异地登录的初筛/var/log/wtmp成功登录/退出记录last 命令谁在什么时间从哪登录/var/log/btmp失败登录记录lastb 命令暴力破解来源 IP 分析/var/log/audit/audit.logauditd 审计日志ausearch/aureport文件被谁改、命令被谁执行这里面有两个容易踩的坑第一wtmp、btmp、lastlog这三个是二进制文件直接cat会看到一堆乱码必须用last、lastb、lastlog命令来读第二不同发行版文件名可能有差异比如 Debian/Ubuntu 系列有些发行版没有/var/log/secure认证日志会写到/var/log/auth.log。你接手一套新系统先看一眼/var/log/目录里实际有什么再下结论。2. 核心日志逐个过哪些文件管什么事这一节我把主力日志文件拿出来细讲重点不是让你背格式而是告诉你每一类日志实际排查时怎么用、常见坑在哪里。2.1 messages 与 secure最常出错的两份“主力日志”/var/log/messages是一般系统事件的汇总池从内核到用户态程序只要没有专门分流日志基本都会在这里留下一笔。它的每一行结构大概是这样的Jan 12 14:33:21 web01 kernel: TCP: time wait bucket table overflow Jan 12 14:33:21 web01 sshd[2345]: pam_unix(sshd:auth): authentication failure; logname uid0 euid0 ttyssh ruser rhost192.168.1.10 userroot从左到右依次是时间戳、主机名、产生日志的程序名方括号里是 PID、消息内容。排查故障时我的习惯是先用时间窗口做粗筛再按程序和关键字做精筛。比如怀疑网络连接有问题就grep -i tcp\|time wait /var/log/messages怀疑 SSH 有问题就grep sshd /var/log/messages或/var/log/secure。/var/log/secure就特殊在它记录的是认证授权事件SSH 的登录成功与失败、sudo 提权、su 切换用户、用户增删改。安全审计时这份文件是第一位要看的。举个最典型的查询统计暴力破解的源 IP。grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -nr这个命令的意思是把所有失败登录记录里倒数第 4 个字段源 IP提出来统计出现次数并降序排列。一下就能看出哪些 IP 在持续打你。如果发现某个 IP 失败次数特别高再看一眼同一时间段里有没有Accepted password如果有那就说明账号已经被撞库成功了需要立刻改密码、清登录记录、查后续操作。2.2 dmesg 与 boot.log启动过程与内核级故障系统启动不了、开机黑屏、外接显示器没画面、硬件驱动加载失败这些问题的答案通常不在 messages 里而在内核日志里。dmesg命令读的是内核环形缓冲区它能告诉你磁盘有没有被识别、网卡驱动有没有加载成功、内存条有没有报错、有没有发生 OOM killer。dmesg | grep -i error dmesg | grep -i fail dmesg | grep -i usb dmesg -T | tail -n 100注意dmesg -T是让时间戳显示成可读的人类时间格式默认显示的是开机以来的秒数。我之前排查过一台机器外接显示器无画面dmesg里直接看到了显卡驱动的固件加载失败跟着提示升级驱动版本就解决了。如果你连图形界面都没进去journalctl -xb可以看本次启动的全部日志-x是附加解释-b是本次启动配合systemctl status看是哪个服务卡住启动类问题基本能定位。游戏闪退这类应用层问题虽然系统日志不能直接告诉你游戏崩溃的完整堆栈但驱动崩溃、显卡重置、显存分配失败这类底层原因一定会先出现在dmesg或/var/log/messages里。我之前遇到过 Steam 游戏闪退最后在 dmesg 里看到是 NVIDIA 驱动跟新版内核不兼容触发了一连串的 Xid 错误。这个信息在游戏自己的日志里是看不到的必须在系统层面找。2.3 二进制日志wtmp/btmp/lastlog 的意义这三个文件很多人会忽略但它们恰恰是安全审计的第一道防线。lastlog记录每个用户最近一次登录时间wtmp记录所有成功登录和注销的会话btmp记录所有失败的登录尝试。它们全是二进制必须用对应命令读。last -20 lastlog lastb | head -n 30安全审计时有个非常实用的组合先用lastlog全局扫一遍看有没有哪个账号的最近登录时间异常再用last看具体会话来源 IP最后用lastb看有没有人在尝试爆破你。如果last里出现一个你根本不认识的 IP 成功登录过而且用的还是 root 账号那基本可以断定已经被入侵了接下来要立刻断网、保留现场、备份日志然后按下一节的思路去做深度的痕迹排查。3. 故障排查实战报错之后我一般怎么定位日志用得最多的场景还是故障排查。这一节我分享一个我自己一直在用的定位套路再配合三个高频问题的完整排查案例你直接照着操作就行。3.1 标准排查流程时间窗口、日志级别、服务关联不管什么故障我翻日志都遵循一个固定顺序。第一步确认时间和时区避免被日志的时间误导。第二步锁定时间窗口用journalctl --since和--until把范围框住。第三步按服务和级别过滤把无关信息剔掉。这套流程走完90% 的问题都能找到线索。举个例子nginx 起不来了你会怎么做直接systemctl start nginx看报错。但更高效的是先看日志journalctl -u nginx.service --since 5 minutes ago -p err-u指定服务单元-p err表示只看 error 及以上级别。如果这里没信息再放低级别看 notice、warning或者直接去 nginx 自身日志/var/log/nginx/error.log。我自己遇到过一个场景nginx 始终报地址被占用系统日志和 nginx 错误日志都没直接写死原因最后发现是另一个进程占用了 80 端口。排查端口冲突用ss -tlnp就能看到但我当时要是第一时间把journalctl -u nginx的完整上下文和ss的输出对照起来能省半小时。看日志有一个很重要的原则不要只看 error 级别。很多关键信息是前一行或后十行给你的比如“连接被拒绝”之前往往有“listening socket 创建失败”的 warning。所以我会用journalctl -u 服务名 --since 10 minutes ago把完整上下文拉出来而不是只过滤 err。3.2 高频故障一文件删了但磁盘空间没释放这个坑在运维面试里都快被问烂了但实际操作中依然有很多人掉进去。现象是df -h显示/或/var已经 100%但du -sh /var/log/*挨个看哪个文件都不大。原因通常是有进程一直持有某个已删除文件的句柄文件虽然从目录里消失了但磁盘块还没被释放。排查命令是lsof L1L1表示列出所有 link count 为 0 的文件。找到被删除但还打开着的文件后有两种处理方式如果是日志文件比如被 logrotate 切走但进程仍在写旧句柄直接 /proc/PID/fd/fd清空文件内容或重启持有句柄的服务。空间会立刻释放。注意杀了正在写的进程如果业务无状态重启一下问题不大如果是数据库这类别乱杀先看能不能平滑 reload。这个场景放在日志专题里讲是因为 logrotate 配置不当是最常见的诱因之一。默认配置下 logrotate 会创建新文件、通知服务重新打开句柄但有些服务不响应信号就会一直写旧文件。如果你发现一个应用服务日志文件删了空间不释放重点排查它是否支持 logrotate 的create模式不支持就改成copytruncate。3.3 高频故障二日志刷爆磁盘怎么办日志量突增导致磁盘写满是生产环境的高频故障。处理顺序我建议这样先止血再排查原因。止血命令是df -h du -sh /var/log/* 2/dev/null | sort -rh | head -n 10找到最大的日志文件后如果是 messages 或 secure先确认是不是有程序在疯狂刷异常再决定是清空还是轮转。清空大日志文件用 /var/log/messages或truncate -s 0 /var/log/messages千万别用rm因为删除后占用文件的进程还在写空间会继续慢慢涨而且你再也追不到完整的现场了。止完血之后去看 logrotate 为什么没生效。cat /var/lib/logrotate/logrotate.status可以查每个日志文件最近轮转时间logrotate -d /etc/logrotate.conf可以调试看它会执行什么操作。常见问题有三个日志文件太大超过 logrotate 的执行周期还没来得及切配置里daily但 cron 任务没跑或者某个日志文件增长速度超过了保留份数能覆盖的容量。3.4 高频故障三系统时间不对导致日志窗口错乱这个故障特别坑因为它不是“没有日志”而是“日志全乱了”。系统重启后时间回到了过去新日志的时间戳可能跑到旧日志前面你用journalctl --since 1 hour ago搜怎么都搜不到东西。我一直强调排查前先看时间就是吃过这个亏。检查时间同步用timedatectl看 NTP synchronized 状态配置时间同步用chronyc sources -v看时间源是否正常。生产环境我建议把 logrotate、cron 任务都建立在系统时间准确的基础上一旦发现时间跳变立刻先同步时间再结合stat看文件 mtime 去对齐真实发生的时间线。4. 安全审计日志里那些容易被忽略的“犯罪现场”故障排查是“现在还在发生的事”安全审计则是“已经发生过的事”。日志在这里扮演的角色是犯罪现场还原。这一节我从登录、用户权限、关键文件监控三个层面讲怎么从日志里发现问题。4.1 登录异常与暴力破解识别从 last 到 secure 的完整链路安全审计第一件事是把所有登录行为过一遍。我用一套固定组合拳# 1. 查看所有用户的最近登录时间 lastlog # 2. 查看最近成功登录会话 last -50 # 3. 查看最近失败登录尝试 lastb -30 # 4. 统计暴力破解源 IP grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -n 20单看/var/log/secure里的字段你会发现一条典型的 SSH 登录成功记录长这样Jan 12 14:33:21 web01 sshd[2345]: Accepted password for root from 192.168.1.10 port 52340 ssh2这里要注意两个字段from后面的 IP 是登录来源port是客户端的随机端口不是服务端端口。如果你发现某个 IP 既在Failed password列表里高频出现又在Accepted password记录里出现那基本就是暴力破解撞库成功了必须立即处置。审计时还要注意sshd服务接受连接但认证失败的记录格式通常是authentication failure加rhost来源。这种记录能帮你发现攻击者可能已经拿到了用户名列表正在做密码喷洒。建议把MaxAuthTries 3、LoginGraceTime 30这类 SSH 安全参数设好减少日志噪音的同时也降低被爆破的概率。4.2 用户、权限、计划任务与可疑进程的排查登录记录之外入侵者更常做的事情是留后门。后门的形式很多常见的有四种新增一个 UID 为 0 的用户、往/root/.ssh/authorized_keys写入公钥、在 crontab 里加任务、替换常见系统命令。排查这些痕迹我用这几条命令# 1. 查找所有 UID 为 0 的用户root 权限账号 awk -F: $3 0 {print $1:$3} /etc/passwd # 2. 检查 root 账号的 SSH 信任公钥 cat /root/.ssh/authorized_keys # 3. 列出所有用户 crontab 和系统计划任务 for user in $(cut -f1 -d: /etc/passwd); do crontab -u $user -l 2/dev/null | grep -v ^#; done ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/ # 4. 检查系统命令文件是否被篡改以 ls 为例关键看 mtime stat /bin/ls /usr/bin/sshd /etc/ssh/sshd_configawk -F: $3 0的意思是以冒号分隔第三个字段是用户 UID等于 0 的账号全部列出来。正常系统里应该只有 root 一个如果多出别的账号基本可以确定被留了后门。stat看 mtime 是审计的常用手段正常系统命令的 mtime 往往和系统安装时间一致如果/bin/ls的修改时间比系统安装晚很多就值得警惕。我之前处理过一个被入侵的机器攻击者替换了/bin/ls来隐藏自己的工具文件最后就是靠stat发现时间戳异常才顺藤摸瓜找到完整后门包。4.3 auditd给关键文件装上“监控探头”如果只有secure和messages你只能看到登录和基础事件。想做到细粒度的行为审计比如“谁改了/etc/passwd”“谁执行了chmod s”需要用 auditd。它是内核级的审计组件能记录系统调用的执行者、执行的命令、操作的文件、最终结果。启用和配置非常简单systemctl start auditd systemctl enable auditd auditctl -w /etc/passwd -p wa -k passwd_watch auditctl -w /etc/sudoers -p wa -k sudoers_watch auditctl -w /etc/ssh/sshd_config -p wa -k sshd_watch-w指定监控路径-p wa表示监控写和属性修改-k是定义一个关键字方便查询。配置完之后如果有人改了这些文件会立刻在/var/log/audit/audit.log里留痕。查询方式ausearch -k passwd_watch -ts today aureport --file --successausearch -k按关键字查询-ts today限定今天aureport --file汇总文件访问审计报告。我在安全评估时习惯给核心服务器都会加这套监控相当于给关键文件装了个摄像头谁伸手都能看到。5. 渗透复盘攻击痕迹与反清理的那些事故障排查是为了恢复安全审计是为了发现渗透复盘则是假设已经被攻破站在对手视角把整个攻击路径走一遍。这个环节最依赖日志但也最容易被攻击者干扰因为专业攻击者第一步往往就是清日志。5.1 日志为什么会“断片”常见干扰手段还原做复盘时你会发现有时候日志文件的时间线是断裂的某天某个时间段/var/log/secure静悄悄的一条记录都没有这在正常高流量服务器上几乎不可能。出现这种“断片”大概率是日志被清理或暂停过。最常见的干扰手段有几种清空history记录、删除或截断/var/log/secure和/var/log/messages、用touch -r把日志文件的 mtime 改成旧时间模拟没被动过、修改 rsyslog 配置让日志不再落盘、甚至故意写满磁盘让所有日志写入失败。防御方在复盘时必须意识到本地日志是天然不可完全信任的因为 root 用户有权限改一切文件。这也是我反复强调“日志要异地存储、要设置只追加、要启用独立审计”的原因。只依赖本地一份日志复盘时很容易走进死胡同。5.2 蓝队的反制只追加、远程转发、审计隔离既然 root 可以改任何文件那我们就要让日志“改了也没用”。三个手段组合起来非常有效。第一给日志文件加 append-only 属性。chattr a /var/log/secure之后日志只能追加写入不能删除和截断连 root 也不能直接破坏想解除需要chattr -a会留下操作痕迹。对/var/log/messages、/var/log/secure、/var/log/cron这些关键文件我都建议加上。第二配置远程日志转发。把 rsyslog 的日志实时发送到一台独立的日志服务器本地日志被清了远程还有一份完整副本。远程转发配置在/etc/rsyslog.conf里加一行*.* 192.168.1.100:514表示 UDP表示 TCP。日志服务器上还要开启 imudp 或 imtcp 模块来接收。这一步做到位攻击者清本机日志基本等于白费力气因为远程日志服务器一般不会跟生产机器共享账号。第三把 auditd 日志和 syslog 日志隔离开。auditd 默认写到/var/log/audit/audit.log单独的分区和独立的权限能避免它跟着 messages 一起被清掉。有条件的话audit 日志最好也做远程转发。5.3 复盘检查单从日志中发现提权与后门复盘时我习惯按下面的检查单逐项过每一步都对应具体的日志或文件检查项日志/文件位置典型异常特征SSH 登录记录/var/log/secure、last、lastb成功登录来源 IP 异常、大量失败记录后出现成功记录sudo 提权记录/var/log/secureroot 用户频繁执行 sudo、切换用户命令新增用户/提权账号/etc/passwd、/etc/shadowUID 为 0 的非 root 账号SSH 信任关系后门/root/.ssh/authorized_keys出现未知公钥计划任务后门crontab、/etc/cron.*不明脚本、频繁执行下载命令systemd 服务后门/etc/systemd/system/、systemctl list-units不明服务单元、启动时间异常内核模块提权/proc/modules、lsmod不明内核模块文件时间戳异常stat /bin/ls /usr/bin/sshdmtime 晚于系统装机时间针对 Linux 提权行为的复盘日志里最有价值的线索是sudoers文件或用户组的变更。如果你发现某用户突然被加进了wheel或sudo组或者/etc/sudoers的 mtime 有变动一定要顺着时间线查这个账号之前的所有登录会话。再配合journalctl _COMMsudo查看 sudo 命令执行历史基本能还原攻击者在系统内做了什么。6. 日志配置与常见问题速查前面讲了很多“怎么查”但日志这东西等出事了再去配置就晚了。这一节我把长期运维中觉得最值得做的配置和一张速查表放出来建议你直接抄作业。6.1 rsyslog 配置按等级转发与自定义文件rsyslog 的默认配置已经够用但我会额外加两条规则一是把认证日志单独再复制一份到独立文件二是把系统关键告警转发到集中日志服务器。在/etc/rsyslog.conf里authpriv.*默认已经写到了 secure你可以再加一行authpriv.* /var/log/auth_extra.log这样相当于多了一份冗余安全审计时多一个对照依据。生产环境我还建议加一个*.crit到独立文件专门收集内核、硬件等关键错误减少排查时被海量 info 日志淹没的烦恼。6.2 logrotate日志轮转与保留策略日志无限增长是磁盘告警的第一大原因。/etc/logrotate.conf和/etc/logrotate.d/下的配置就是解决这个问题的。最核心的参数是daily、rotate、compress、create、copytruncate。我建议对容易产生大日志的服务使用copytruncate/var/log/nginx/*.log { daily rotate 14 compress delaycompress copytruncate missingok notifempty }copytruncate的原理是先复制当前文件内容到新文件再清空原文件进程句柄始终没变所以不需要服务配合 reload。缺点是复制和清空之间可能有少量日志丢失但对于大多数应用场景可接受。如果服务支持信号重开日志文件比如 nginx 的USR1用create模式更优不会丢日志。两种模式选哪个取决于服务是否支持信号通知。6.3 常见问题速查表最后把我实际工作中遇到的高频问题和对应排查命令整理成一张表建议收藏备用。问题现象排查入口核心命令服务起不来journald、应用自身日志systemctl status 服务名、journalctl -u 服务名 -p err --since 10 min ago磁盘空间满messages、dmesg、logrotatedf -h、du -sh /var/log/*、lsof L1登录被拒绝/密码对但进不去secure、btmptail -f /var/log/secure、lastb系统启动卡住boot.log、journaldjournalctl -xb、systemctl list-jobs硬件/驱动异常dmesg、messagesdmesg -T | grep -i error、lsmod时间不同步timedatectl、messagestimedatectl、chronyc sources -v暴力破解secure、btmplastb、grep Failed password /var/log/secure文件被篡改auditdausearch -k 关键字 -ts today外接显示器无画面dmesgdmesg -T | grep -i drm、dmesg -T | grep -i fail最后再分享两个我自己的习惯。一是每次登录服务器我会先花十秒看timedatectl和df -h确认时间同步正常、磁盘没满再干别的。二是把常用的日志排查命令写成 shell 函数放到~/.bashrc里比如logj快速打开 journalctl、failip快速统计暴力破解 IP。日志排查这件事靠的不是突发灵感而是平时把工具和习惯都准备好出问题时不慌不乱一条命令一条命令地定位。希望这篇内容能帮你把 Linux 系统日志从“看不懂的文件”变成真正的排查利器。