我印象最深的一次故障排查是凌晨两点生产环境所有 Web 服务突然超时登录服务器用df -h一看根分区已经 100%。当时我先按老套路du了一圈结果/var/log里没发现异常大的文件后来突然想起 journald用journalctl --disk-usage一看二进制日志直接占了十几个 G。那次之后我养成一个习惯不管是日常故障排查还是安全事件响应甚至是做完一次渗透测试后的复盘我都会先把 Linux 的日志体系从头到尾捋一遍。这篇东西就把我这些年在日志上踩过的坑和总结出来的套路一起整理出来围绕故障排查、安全审计、渗透复盘三个场景把日志怎么读、怎么查、怎么留一次说清楚。1. Linux 日志体系全景先搞清楚日志从哪来、到哪去1.1 rsyslog 和 journald两套日志系统长期并行很多人学 Linux 日志时有个误区以为日志就是/var/log底下那几个文本文件。实际上现在主流发行版里至少有两套日志体系在同时工作。一套是 rsyslog它负责把系统里各个程序产生的日志消息按照配置好的规则分类写入/var/log下的文本文件。另一套是 systemd-journald它在 systemd 生态里充当日志收集中心会把服务的标准输出、标准错误、内核消息等统一收进二进制日志里查询时用journalctl命令。这两套系统不是替代关系而是互补。journald 的优势是统一、结构化、自带索引排查单个服务问题特别方便rsyslog 的优势是规则灵活、文本格式人能直接看懂、配合 logrotate 可以做长期留存。所以实际生产环境里最常见的做法是短期排查看 journald长期留痕和安全审计看/var/log下的文本日志两边配合着用。配置层面rsyslog 的主配置文件在/etc/rsyslog.conf扩展规则放在/etc/rsyslog.d/目录下。默认规则一般会按 facility消息来源和 priority级别把日志分发到不同文件比如*.info;mail.none;authpriv.none;cron.none这种写法意思就是所有 info 级别以上的消息都写入 messages但邮件、认证、计划任务这些单独分流。journald 的配置文件在/etc/systemd/journald.conf里面Storageauto、SystemMaxUse4G这些参数直接决定日志占用多少磁盘空间。1.2 必须记下来的关键日志文件清单虽然 journald 用起来方便但安全审计和渗透复盘时/var/log下的文本日志依然是主战场。下面这张表是我平时处理问题时最常用到的几个文件建议至少把用途记熟。日志文件所属系统主要记录内容/var/log/messagesRHEL/CentOS系统整体杂项消息内核和多数服务的运行信息都会在这里出现/var/log/syslogDebian/Ubuntu对应 messages 的角色是系统级综合日志/var/log/secureRHEL/CentOSSSH 登录、sudo 提权、用户认证相关的全部记录/var/log/auth.logDebian/Ubuntu对应 secure 的角色认证和安全事件都记在这里/var/log/boot.log通用系统启动过程信息开机异常时最先看它/var/log/dmesg通用内核环形缓冲区的输出硬件识别、驱动加载、磁盘报错都在这里/var/log/cron通用cron 计划任务的执行记录/var/log/lastlog通用所有用户的最近登录时间二进制格式/var/log/wtmp通用成功登录的历史记录二进制格式last命令读它/var/log/btmp通用失败登录的历史记录二进制格式lastb命令读它这里特别提醒一点不要把所有希望都压在 messages 一个文件上。实际排查时判断问题属于哪一层就去对应文件里找。Nginx、Tomcat、MySQL 这类应用通常有自己独立的日志目录系统级日志文件里只会有启动、崩溃这类粗粒度信息。如果只盯着/var/log/messages翻很容易错过真正有价值的细节。1.3 日志轮转别让日志变成新的故障源日志文件有个天然矛盾既希望留痕完整又不能让文件无限膨胀。logrotate 就是解决这个问题的标准工具由 cron 定时触发全局配置在/etc/logrotate.conf各个程序的规则放在/etc/logrotate.d/目录下。核心参数有rotate保留几份历史日志、daily/weekly/monthly轮转周期、size超过多大触发轮转、compress压缩旧日志、missingok日志文件不存在时不报错、copytruncate先复制再清空原文件。我在实践中的建议是对写入频繁的应用日志尽量配置daily加rotate 30既避免单个文件过大也能保留一个月的留痕对一般系统日志默认weekly甚至monthly就够。容易踩坑的是copytruncate和create这两个参数的取舍。有些程序会一直持有日志文件句柄不释放必须用copytruncate原地截断但它有丢少量数据的风险如果程序支持重新打开日志文件更稳妥的是用create配合kill -HUP信号让进程重新打开新文件。判断方法很简单看程序文档有没有提到 logrotate 支持或者看/var/log下旧文件是否一直在增长。2. 故障排查日志是把模糊现象拆成具体报错的关键2.1 服务起不来journalctl 按这个顺序查排查 systemd 服务启动失败时很多人直接systemctl status xxx.service看一眼就完了其实这里的信息量远远不够。systemctl status只展示最近几行日志很多关键报错会被截掉。我习惯的顺序是先用systemctl status xxx.service看服务当前状态和大致错误再用journalctl -u xxx.service -n 200 --no-pager查看最近 200 行完整日志如果还是定位不了就journalctl -u xxx.service -f实时跟踪同时再手动启动一次服务复现问题。有一次排查 Nginx 起不来systemctl status只提示配置测试失败但具体哪里失败没有说。用journalctl -u nginx -n 50看到了完整报错精确到配置文件的第几行最后发现是多打了一个分号。日志的价值就在这里它把“服务起不来”这个模糊现象拆解成具体的报错点剩下就是按图索骥。另外journalctl的时间过滤参数非常实用。--since 2025-01-01 10:00:00、--until 2025-01-01 10:30:00可以精确拉取某个时间窗口的日志配合-p err只看 error 级别以上的消息排查效率会高很多。比如想知道某个服务最近一次崩溃前后发生了什么直接用journalctl -u xxx.service --since 30 min ago --no-pager就能把现场还原得差不多。2.2 磁盘被“隐形日志”写满的现场还原回到文章开头那次事故。根分区 100%du -sh /var/log/*没发现异常大的文件我当时一度以为是某个应用进程占用文件未释放。后来用journalctl --disk-usage才发现端倪journald 的二进制日志平时不太容易让人直观感受到体量但它确实会积累大量数据。遇到这种情况直接用journalctl --vacuum-size1G把历史日志瘦身到 1G 以内或者用journalctl --vacuum-time7d只保留最近 7 天问题立刻缓解。docker 容器日志是另一个经典的“隐形磁盘杀手”。容器默认会把标准输出写到/var/lib/docker/containers/下对应的*-json.log文件如果不限制大小大型应用跑几天就能吃掉几十 G。正确做法是在/etc/docker/daemon.json里配置 log-opts{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }配置完重启 docker 服务后新容器就会受到限制旧容器需要重建才能生效。这里要记住一个原则日志轮转的配置一定要在业务上线前做好等生产环境磁盘满了再处理往往损失已经造成了。还有一种“看不见的大文件”和进程占用有关。程序持续写入某个日志文件如果管理员用rm删掉文件但进程没有重启磁盘空间并不会释放因为文件句柄还开着。用lsof | grep deleted可以列出这类已被删除但仍被进程占用的文件。wsl 环境里删除文件后空间不释放本质上也是这个原因正确做法是找到占用进程并重启它而不是反复删除。2.3 应用日志也别忽略慢查询、binlog 与 Redis系统级日志之外应用日志在故障定位中同样关键。以 MySQL 为例慢查询日志用来记录执行时间超过阈值的 SQL配置在my.cnf里的slow_query_log、slow_query_log_file、long_query_time三个参数。线上环境我习惯把long_query_time设置为 1 秒甚至 0.5 秒配合mysqldumpslow按执行次数、总耗时排序很快就能找出拖垮数据库的罪魁祸首。很多运维对 binlog 能不能删这个问题拿不准。binlog 是 MySQL 的二进制日志承担数据恢复和主从同步两个职责。如果开了主从复制binlog 是同步链路的数据源删除前必须确认从库已经消费完可以通过SHOW SLAVE STATUS里的Read_Master_Log_Pos判断。单机环境下如果已经做过全量备份确实可以清理历史 binlog但我建议保留一定周期毕竟它是做时间点恢复的关键数据。清理时用官方命令PURGE BINARY LOGS BEFORE (NOW() - INTERVAL 7 DAY)不要直接手动删文件否则会导致日志索引混乱。Redis 日志相对简单配置在redis.conf的logfile项级别分为 debug、verbose、notice、warning。生产环境默认 notice 就够了但排查主从同步、持久化异常这类问题时我会临时把级别调成 verbose重启后复现问题定位完再改回来。日志文件的路径要根据实际部署修改没有 logfile 配置时 Redis 默认输出到标准输出在 systemd 环境下会被 journald 收走用journalctl -u redis就能看到。2.4 内核和硬件异常去 dmesg 里找答案系统运行过程中内核信息、硬件报错、网卡抖动、磁盘 I/O 错误、OOM Killer 记录都会出现在 dmesg 输出里。排查网络问题时dmesg | grep -i eth或dmesg | tail -100是常用操作。有些网卡的 receive errors、firmware warning 这类硬件层面问题用 tcpdump 抓包是抓不出来的只有在 dmesg 里才看得到线索。需要特别注意的是dmesg 的内核缓冲区大小有限制历史太久的消息会被新消息冲掉。也就是说如果系统已经连续运行很久故障发生在几天前再用 dmesg 很可能已经查不到当时的记录了。想要长期留存内核日志可以在 rsyslog 配置里单独加一条规则把内核消息写入独立文件kern.* /var/log/kern.log添加后重启 rsyslog 服务内核日志就会持续落盘这对排查偶发性硬件问题非常有用。另外一个容易忽略的点是 OOM Killer 记录当系统内存不足触发内核杀进程时dmesg 里会留下完整的进程列表和内存占用情况这是判断“为什么某个服务突然消失”的关键证据。3. 安全审计从日志还原“谁在什么时候做了什么”3.1 登录行为审计从 secure/auth.log 到 last 命令Linux 日志不像 Windows 安全日志那样自带结构化的事件 ID它更多是纯文本需要审计人员自己组织规则。好在认证相关的日志非常集中RHEL/CentOS 系看/var/log/secureDebian/Ubuntu 系看/var/log/auth.log里面记录了每一次 SSH 登录尝试包括成功的Accepted和失败的Failed password。常用的审计命令组合如下last -a -F显示最近成功登录的会话、来源 IP、登录时长lastb -a显示所有失败登录记录系统被爆破时这个文件会非常长lastlog查看每个用户最近一次登录时间who和w查看当前在线用户。用 grep 从日志里筛异常也很直接。比如统计爆破来源 IP 的 Top 榜grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head如果某个来源 IP 一次性登录失败超过几十次基本可以判定是暴力破解。这类攻击占用资源不多但对安全影响很大建议在/etc/ssh/sshd_config里设置MaxAuthTries 3更彻底的做法是禁用密码登录只保留密钥认证。auth 日志在爆破频繁时增长很快所以一定要给 secure/auth.log 单独配置 logrotate防止日志文件过大影响系统运行。3.2 sudo 与提权操作命令审计的两个层次光看登录日志还不够。用户登录后到底执行了什么命令默认情况下系统并不会完整记录。如果依赖 bash history用户完全可以自己清除。真正规范的审计方式要从两个层次入手。第一个层次是 sudo 日志。用户执行 sudo 提权时会在 secure/auth.log 里留下记录格式类似user : TTYpts/0 ; PWD/home/user ; USERroot ; COMMAND/bin/rm -f /etc/hosts审计时可以grep COMMAND /var/log/secure过滤出所有 sudo 执行的命令。不过默认 sudo 日志只记录提权操作用户在自己权限内直接执行命令是记不到的所以更严格的场景下需要启用第二个层次auditd。auditd 是 Linux 自带的审计框架配置文件在/etc/audit/auditd.conf规则放在/etc/audit/rules.d/。比如想监控/etc/passwd和/etc/shadow是否被篡改可以添加规则auditctl -w /etc/passwd -p wa -k passwd_change auditctl -w /etc/shadow -p wa -k shadow_change-w指定监控文件-p wa表示监控写和属性变更-k是自定义的过滤标签。规则加上之后任何对这两个文件的写操作都会记录到/var/log/audit/audit.log查询时用ausearch -k passwd_change就能提取相关记录。这类文件完整性监控是判断服务器是否被植入后门账号的有力证据也是渗透复盘时最可靠的数据源之一。3.3 交叉比对时间、账号、来源 IP 缺一不可实际做安全审计时只靠单一日志文件往往不够我习惯把几个维度结合着看。第一个是登录时间凌晨两三点从海外 IP 登录成功这种时间窗口本身就高度可疑。第二个是登录方式一台只配置了密钥认证的服务器突然出现密码登录成功的记录说明认证配置可能被人动过手脚。第三个是登录账号root 直接登录、新出现的用户名、以及短时间内多账号轮流尝试都是异常信号。把last、secure、audit.log三份数据交叉比对绝大多数账号失陷、越权操作都能被还原出来。这里要提一个容易忽略的点日志时区。如果服务器时间是 UTC审计人员习惯用北京时间时间对不上会错过很多线索。建议在服务器上执行timedatectl set-timezone Asia/Shanghai统一时区后再做日志分析。另外进程重启会在日志里留下明显的时间空档比如某段日志突然中断几分钟恰恰发生在敏感操作前后那段时间往往就是攻击者执行命令的窗口需要重点排查。4. 渗透复盘站在攻击者的角度重看日志痕迹4.1 攻击者最想擦掉什么以及怎么反制渗透复盘和日常审计最大的区别是视角。审计是我怀疑有问题我要找证据复盘是已知被攻击过要还原整个链路。做复盘时必须默认一个事实攻击者大概率动过日志。常见的反取证手段包括清理 bash historyhistory -c、覆盖登录日志echo /var/log/wtmp、清空 secure 日志cat /dev/null /var/log/secure、修改文件时间戳touch -r等。正因为存在这种可能日志防篡改的设计才显得重要。基础做法是把/var/log独立分区挂载避免和根目录混在一起防止根分区被写满后日志无法落盘。进阶做法是把日志实时转发到远程日志服务器这样本机被清干净也没用。作为安全从业者做被授权范围内的渗透测试时发现系统日志被篡改本身就是一个重要发现它往往意味着攻击者已经完成了更深层的入侵。反过来说如果企业从一开始就把日志异地留存做好攻击者的清理行为就很难完全抹掉痕迹。4.2 根据攻击手法的特征反查日志结合日志做渗透复盘时可以从攻击手法出发找特征。暴力破解的特征最明显secure 日志里Failed password长时间刷屏来源 IP 集中如果爆破成功Accepted 记录之后通常跟着大量命令执行痕迹。webshell 植入的特征在 Web 访问日志里Nginx 或者 Apache 的 access log 中出现异常后缀的请求比如xxx.php?acmd、xxx.jsp这类POST 请求异常频繁响应码 200 之后伴有超长响应体。提权行为的痕迹也很典型日志里出现gcc、cc、make这类编译命令或者在/tmp目录下产生文件后立即执行。shell history 和 audit.log 如果记录了cd /tmp、wget、curl下载、chmod x这一连串操作需要高度警惕。异常外连不容易直接体现在系统日志里但配合ss -tnp、防火墙日志和进程列表能形成完整证据链。复盘时我习惯把所有相关日志按时间轴排列用 grep 和 awk 把 SSH 登录、sudo 执行、文件变更、Web 请求、进程启动这些事件统一抽取出来逐小时逐分钟还原攻击路径。这样攻击者从哪个入口进来、用了什么账号、执行了什么命令、留下了什么持久化手段逻辑就清晰了。4.3 防篡改与异地留存的工程化落地比较现实的低成本方案是用 rsyslog 把日志转发到独立的日志服务器。本机 rsyslog 配置里加一行*.* 192.168.1.100:514远程日志服务器上运行 rsyslog开启 imudp 模块并监听 514 端口就能实时接收日志。配合 logrotate 的压缩和保留策略远程端的数据保存周期可以设置得更长。更进一步的方案是给日志加完整性校验比如用 auditd 自带的特性或者定期对日志文件计算哈希并存储到独立介质。--since这类查询参数在复盘时非常好用但前提是日志本身还在。4.4 复盘时的分析思路与工具选择日志分析工具的选择取决于日志量。小规模场景下grep、awk、sort、uniq的组合就已经够用命令短、灵活随时可以在终端里跑。日志量中等时我推荐lnav这个终端下的日志浏览器它能自动识别常见日志格式支持按时间排序、按关键字过滤、甚至统计直方图比单纯 grep 直观很多。日志量大的场景就要上 ELKElasticsearch Logstash Kibana这类集中式平台用 Filebeat 统一采集日志到 Elasticsearch再在 Kibana 里做检索、可视化和告警。不过我在实际复盘时十次里有六七次还是先用命令行快速筛一遍全部依赖重型平台反而会降低效率。最有效率的路径是先用 grep 定位可疑时间点和关键字再用journalctl --since和--until按时间窗口拉日志最后用 awk 做聚合统计。复盘不是把工具都堆上去而是要快速锁定攻击路径再逐个击破。5. 高频问题与避坑经验速查5.1 日志时间和时区不对日志时间对不上通常是因为系统时区没有统一。用timedatectl set-timezone Asia/Shanghai改时区再配合 chronyd 或 systemd-timesyncd 做时间同步。日志时间一旦错乱安全审计和渗透复盘时的时间线就无法对齐佐证力会大打折扣。另外还要留意日志文件里的时间戳格式有些程序默认输出 UTC 时间查看时要换算清楚。5.2 journald 日志把磁盘吃满怎么办先用journalctl --disk-usage查看用量再用journalctl --vacuum-size500M清理到指定大小以内或者用journalctl --vacuum-time7d只保留最近 7 天。如果希望从根本上限制修改/etc/systemd/journald.conf里的SystemMaxUse500M然后重启 systemd-journald 服务。要注意的是清掉的日志无法找回生产环境动手前先确认是否有合规留存要求。5.3 文件删了空间却不释放大概率是文件被进程占用。用lsof | grep deleted找到占用进程然后重启该进程磁盘空间就会释放。Java 和 Python 进程通常长时间不重启删除的日志文件容易被句柄占用。这个问题的本质是文件系统层面删除操作不会立即回收块只有等所有文件描述符关闭后才会真正释放空间。5.4 MySQL binlog 到底能不能删分场景判断。开了主从复制时先确认从库已经消费完 binlog否则删除会导致同步链路中断。单机环境且有全量备份时可以清理历史 binlog但最好保留一个周期用于时间点恢复。清理时用PURGE BINARY LOGS BEFORE或PURGE BINARY LOGS TO命令不要手动删文件。binlog 的保留策略建议在业务规划阶段就定好避免后期数据增长后无从下手。5.5 SSH 爆破日志刷屏先统计来源 IP用防火墙或安全组封锁攻击来源再考虑加固措施。系统层面建议修改 SSH 默认端口、限制可登录用户、启用密钥认证、安装 fail2ban 这类自动封禁工具。检查一下是否有账号已经被成功爆破确认没有后门再收尾。安全加固做完之后记得观察几天 secure 日志看爆破流量是否已经停止。我个人在实际操作中最深的体会是日志不是出了问题才想起来看的而是要在系统正常运行的时候就把“记什么、记多久、放哪里”都设计好。绝大多数能在一个小时内定位的线上故障靠的都是日志留得够全、路径够清晰真正耗时长的往往是那些日志被忽略、被截断、被覆盖的机器只能靠业务表象去猜。如果你读完这篇能把自己手头机器的日志轮转策略、日志留存周期、异地转发这三件事顺手做一遍后面遇到故障和安全事件时会轻松很多。还有一个小技巧每台服务器都建一个本地的日志查阅手册把关键路径和常用命令记下来等出问题的时候这份笔记比临时翻文档有用得多。
我印象最深的一次故障排查是凌晨两点生产环境所有 Web 服务突然超时登录服务器用df -h一看根分区已经 100%。当时我先按老套路du了一圈结果/var/log里没发现异常大的文件后来突然想起 journald用journalctl --disk-usage一看二进制日志直接占了十几个 G。那次之后我养成一个习惯不管是日常故障排查还是安全事件响应甚至是做完一次渗透测试后的复盘我都会先把 Linux 的日志体系从头到尾捋一遍。这篇东西就把我这些年在日志上踩过的坑和总结出来的套路一起整理出来围绕故障排查、安全审计、渗透复盘三个场景把日志怎么读、怎么查、怎么留一次说清楚。1. Linux 日志体系全景先搞清楚日志从哪来、到哪去1.1 rsyslog 和 journald两套日志系统长期并行很多人学 Linux 日志时有个误区以为日志就是/var/log底下那几个文本文件。实际上现在主流发行版里至少有两套日志体系在同时工作。一套是 rsyslog它负责把系统里各个程序产生的日志消息按照配置好的规则分类写入/var/log下的文本文件。另一套是 systemd-journald它在 systemd 生态里充当日志收集中心会把服务的标准输出、标准错误、内核消息等统一收进二进制日志里查询时用journalctl命令。这两套系统不是替代关系而是互补。journald 的优势是统一、结构化、自带索引排查单个服务问题特别方便rsyslog 的优势是规则灵活、文本格式人能直接看懂、配合 logrotate 可以做长期留存。所以实际生产环境里最常见的做法是短期排查看 journald长期留痕和安全审计看/var/log下的文本日志两边配合着用。配置层面rsyslog 的主配置文件在/etc/rsyslog.conf扩展规则放在/etc/rsyslog.d/目录下。默认规则一般会按 facility消息来源和 priority级别把日志分发到不同文件比如*.info;mail.none;authpriv.none;cron.none这种写法意思就是所有 info 级别以上的消息都写入 messages但邮件、认证、计划任务这些单独分流。journald 的配置文件在/etc/systemd/journald.conf里面Storageauto、SystemMaxUse4G这些参数直接决定日志占用多少磁盘空间。1.2 必须记下来的关键日志文件清单虽然 journald 用起来方便但安全审计和渗透复盘时/var/log下的文本日志依然是主战场。下面这张表是我平时处理问题时最常用到的几个文件建议至少把用途记熟。日志文件所属系统主要记录内容/var/log/messagesRHEL/CentOS系统整体杂项消息内核和多数服务的运行信息都会在这里出现/var/log/syslogDebian/Ubuntu对应 messages 的角色是系统级综合日志/var/log/secureRHEL/CentOSSSH 登录、sudo 提权、用户认证相关的全部记录/var/log/auth.logDebian/Ubuntu对应 secure 的角色认证和安全事件都记在这里/var/log/boot.log通用系统启动过程信息开机异常时最先看它/var/log/dmesg通用内核环形缓冲区的输出硬件识别、驱动加载、磁盘报错都在这里/var/log/cron通用cron 计划任务的执行记录/var/log/lastlog通用所有用户的最近登录时间二进制格式/var/log/wtmp通用成功登录的历史记录二进制格式last命令读它/var/log/btmp通用失败登录的历史记录二进制格式lastb命令读它这里特别提醒一点不要把所有希望都压在 messages 一个文件上。实际排查时判断问题属于哪一层就去对应文件里找。Nginx、Tomcat、MySQL 这类应用通常有自己独立的日志目录系统级日志文件里只会有启动、崩溃这类粗粒度信息。如果只盯着/var/log/messages翻很容易错过真正有价值的细节。1.3 日志轮转别让日志变成新的故障源日志文件有个天然矛盾既希望留痕完整又不能让文件无限膨胀。logrotate 就是解决这个问题的标准工具由 cron 定时触发全局配置在/etc/logrotate.conf各个程序的规则放在/etc/logrotate.d/目录下。核心参数有rotate保留几份历史日志、daily/weekly/monthly轮转周期、size超过多大触发轮转、compress压缩旧日志、missingok日志文件不存在时不报错、copytruncate先复制再清空原文件。我在实践中的建议是对写入频繁的应用日志尽量配置daily加rotate 30既避免单个文件过大也能保留一个月的留痕对一般系统日志默认weekly甚至monthly就够。容易踩坑的是copytruncate和create这两个参数的取舍。有些程序会一直持有日志文件句柄不释放必须用copytruncate原地截断但它有丢少量数据的风险如果程序支持重新打开日志文件更稳妥的是用create配合kill -HUP信号让进程重新打开新文件。判断方法很简单看程序文档有没有提到 logrotate 支持或者看/var/log下旧文件是否一直在增长。2. 故障排查日志是把模糊现象拆成具体报错的关键2.1 服务起不来journalctl 按这个顺序查排查 systemd 服务启动失败时很多人直接systemctl status xxx.service看一眼就完了其实这里的信息量远远不够。systemctl status只展示最近几行日志很多关键报错会被截掉。我习惯的顺序是先用systemctl status xxx.service看服务当前状态和大致错误再用journalctl -u xxx.service -n 200 --no-pager查看最近 200 行完整日志如果还是定位不了就journalctl -u xxx.service -f实时跟踪同时再手动启动一次服务复现问题。有一次排查 Nginx 起不来systemctl status只提示配置测试失败但具体哪里失败没有说。用journalctl -u nginx -n 50看到了完整报错精确到配置文件的第几行最后发现是多打了一个分号。日志的价值就在这里它把“服务起不来”这个模糊现象拆解成具体的报错点剩下就是按图索骥。另外journalctl的时间过滤参数非常实用。--since 2025-01-01 10:00:00、--until 2025-01-01 10:30:00可以精确拉取某个时间窗口的日志配合-p err只看 error 级别以上的消息排查效率会高很多。比如想知道某个服务最近一次崩溃前后发生了什么直接用journalctl -u xxx.service --since 30 min ago --no-pager就能把现场还原得差不多。2.2 磁盘被“隐形日志”写满的现场还原回到文章开头那次事故。根分区 100%du -sh /var/log/*没发现异常大的文件我当时一度以为是某个应用进程占用文件未释放。后来用journalctl --disk-usage才发现端倪journald 的二进制日志平时不太容易让人直观感受到体量但它确实会积累大量数据。遇到这种情况直接用journalctl --vacuum-size1G把历史日志瘦身到 1G 以内或者用journalctl --vacuum-time7d只保留最近 7 天问题立刻缓解。docker 容器日志是另一个经典的“隐形磁盘杀手”。容器默认会把标准输出写到/var/lib/docker/containers/下对应的*-json.log文件如果不限制大小大型应用跑几天就能吃掉几十 G。正确做法是在/etc/docker/daemon.json里配置 log-opts{ log-driver: json-file, log-opts: { max-size: 50m, max-file: 3 } }配置完重启 docker 服务后新容器就会受到限制旧容器需要重建才能生效。这里要记住一个原则日志轮转的配置一定要在业务上线前做好等生产环境磁盘满了再处理往往损失已经造成了。还有一种“看不见的大文件”和进程占用有关。程序持续写入某个日志文件如果管理员用rm删掉文件但进程没有重启磁盘空间并不会释放因为文件句柄还开着。用lsof | grep deleted可以列出这类已被删除但仍被进程占用的文件。wsl 环境里删除文件后空间不释放本质上也是这个原因正确做法是找到占用进程并重启它而不是反复删除。2.3 应用日志也别忽略慢查询、binlog 与 Redis系统级日志之外应用日志在故障定位中同样关键。以 MySQL 为例慢查询日志用来记录执行时间超过阈值的 SQL配置在my.cnf里的slow_query_log、slow_query_log_file、long_query_time三个参数。线上环境我习惯把long_query_time设置为 1 秒甚至 0.5 秒配合mysqldumpslow按执行次数、总耗时排序很快就能找出拖垮数据库的罪魁祸首。很多运维对 binlog 能不能删这个问题拿不准。binlog 是 MySQL 的二进制日志承担数据恢复和主从同步两个职责。如果开了主从复制binlog 是同步链路的数据源删除前必须确认从库已经消费完可以通过SHOW SLAVE STATUS里的Read_Master_Log_Pos判断。单机环境下如果已经做过全量备份确实可以清理历史 binlog但我建议保留一定周期毕竟它是做时间点恢复的关键数据。清理时用官方命令PURGE BINARY LOGS BEFORE (NOW() - INTERVAL 7 DAY)不要直接手动删文件否则会导致日志索引混乱。Redis 日志相对简单配置在redis.conf的logfile项级别分为 debug、verbose、notice、warning。生产环境默认 notice 就够了但排查主从同步、持久化异常这类问题时我会临时把级别调成 verbose重启后复现问题定位完再改回来。日志文件的路径要根据实际部署修改没有 logfile 配置时 Redis 默认输出到标准输出在 systemd 环境下会被 journald 收走用journalctl -u redis就能看到。2.4 内核和硬件异常去 dmesg 里找答案系统运行过程中内核信息、硬件报错、网卡抖动、磁盘 I/O 错误、OOM Killer 记录都会出现在 dmesg 输出里。排查网络问题时dmesg | grep -i eth或dmesg | tail -100是常用操作。有些网卡的 receive errors、firmware warning 这类硬件层面问题用 tcpdump 抓包是抓不出来的只有在 dmesg 里才看得到线索。需要特别注意的是dmesg 的内核缓冲区大小有限制历史太久的消息会被新消息冲掉。也就是说如果系统已经连续运行很久故障发生在几天前再用 dmesg 很可能已经查不到当时的记录了。想要长期留存内核日志可以在 rsyslog 配置里单独加一条规则把内核消息写入独立文件kern.* /var/log/kern.log添加后重启 rsyslog 服务内核日志就会持续落盘这对排查偶发性硬件问题非常有用。另外一个容易忽略的点是 OOM Killer 记录当系统内存不足触发内核杀进程时dmesg 里会留下完整的进程列表和内存占用情况这是判断“为什么某个服务突然消失”的关键证据。3. 安全审计从日志还原“谁在什么时候做了什么”3.1 登录行为审计从 secure/auth.log 到 last 命令Linux 日志不像 Windows 安全日志那样自带结构化的事件 ID它更多是纯文本需要审计人员自己组织规则。好在认证相关的日志非常集中RHEL/CentOS 系看/var/log/secureDebian/Ubuntu 系看/var/log/auth.log里面记录了每一次 SSH 登录尝试包括成功的Accepted和失败的Failed password。常用的审计命令组合如下last -a -F显示最近成功登录的会话、来源 IP、登录时长lastb -a显示所有失败登录记录系统被爆破时这个文件会非常长lastlog查看每个用户最近一次登录时间who和w查看当前在线用户。用 grep 从日志里筛异常也很直接。比如统计爆破来源 IP 的 Top 榜grep Failed password /var/log/secure | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head如果某个来源 IP 一次性登录失败超过几十次基本可以判定是暴力破解。这类攻击占用资源不多但对安全影响很大建议在/etc/ssh/sshd_config里设置MaxAuthTries 3更彻底的做法是禁用密码登录只保留密钥认证。auth 日志在爆破频繁时增长很快所以一定要给 secure/auth.log 单独配置 logrotate防止日志文件过大影响系统运行。3.2 sudo 与提权操作命令审计的两个层次光看登录日志还不够。用户登录后到底执行了什么命令默认情况下系统并不会完整记录。如果依赖 bash history用户完全可以自己清除。真正规范的审计方式要从两个层次入手。第一个层次是 sudo 日志。用户执行 sudo 提权时会在 secure/auth.log 里留下记录格式类似user : TTYpts/0 ; PWD/home/user ; USERroot ; COMMAND/bin/rm -f /etc/hosts审计时可以grep COMMAND /var/log/secure过滤出所有 sudo 执行的命令。不过默认 sudo 日志只记录提权操作用户在自己权限内直接执行命令是记不到的所以更严格的场景下需要启用第二个层次auditd。auditd 是 Linux 自带的审计框架配置文件在/etc/audit/auditd.conf规则放在/etc/audit/rules.d/。比如想监控/etc/passwd和/etc/shadow是否被篡改可以添加规则auditctl -w /etc/passwd -p wa -k passwd_change auditctl -w /etc/shadow -p wa -k shadow_change-w指定监控文件-p wa表示监控写和属性变更-k是自定义的过滤标签。规则加上之后任何对这两个文件的写操作都会记录到/var/log/audit/audit.log查询时用ausearch -k passwd_change就能提取相关记录。这类文件完整性监控是判断服务器是否被植入后门账号的有力证据也是渗透复盘时最可靠的数据源之一。3.3 交叉比对时间、账号、来源 IP 缺一不可实际做安全审计时只靠单一日志文件往往不够我习惯把几个维度结合着看。第一个是登录时间凌晨两三点从海外 IP 登录成功这种时间窗口本身就高度可疑。第二个是登录方式一台只配置了密钥认证的服务器突然出现密码登录成功的记录说明认证配置可能被人动过手脚。第三个是登录账号root 直接登录、新出现的用户名、以及短时间内多账号轮流尝试都是异常信号。把last、secure、audit.log三份数据交叉比对绝大多数账号失陷、越权操作都能被还原出来。这里要提一个容易忽略的点日志时区。如果服务器时间是 UTC审计人员习惯用北京时间时间对不上会错过很多线索。建议在服务器上执行timedatectl set-timezone Asia/Shanghai统一时区后再做日志分析。另外进程重启会在日志里留下明显的时间空档比如某段日志突然中断几分钟恰恰发生在敏感操作前后那段时间往往就是攻击者执行命令的窗口需要重点排查。4. 渗透复盘站在攻击者的角度重看日志痕迹4.1 攻击者最想擦掉什么以及怎么反制渗透复盘和日常审计最大的区别是视角。审计是我怀疑有问题我要找证据复盘是已知被攻击过要还原整个链路。做复盘时必须默认一个事实攻击者大概率动过日志。常见的反取证手段包括清理 bash historyhistory -c、覆盖登录日志echo /var/log/wtmp、清空 secure 日志cat /dev/null /var/log/secure、修改文件时间戳touch -r等。正因为存在这种可能日志防篡改的设计才显得重要。基础做法是把/var/log独立分区挂载避免和根目录混在一起防止根分区被写满后日志无法落盘。进阶做法是把日志实时转发到远程日志服务器这样本机被清干净也没用。作为安全从业者做被授权范围内的渗透测试时发现系统日志被篡改本身就是一个重要发现它往往意味着攻击者已经完成了更深层的入侵。反过来说如果企业从一开始就把日志异地留存做好攻击者的清理行为就很难完全抹掉痕迹。4.2 根据攻击手法的特征反查日志结合日志做渗透复盘时可以从攻击手法出发找特征。暴力破解的特征最明显secure 日志里Failed password长时间刷屏来源 IP 集中如果爆破成功Accepted 记录之后通常跟着大量命令执行痕迹。webshell 植入的特征在 Web 访问日志里Nginx 或者 Apache 的 access log 中出现异常后缀的请求比如xxx.php?acmd、xxx.jsp这类POST 请求异常频繁响应码 200 之后伴有超长响应体。提权行为的痕迹也很典型日志里出现gcc、cc、make这类编译命令或者在/tmp目录下产生文件后立即执行。shell history 和 audit.log 如果记录了cd /tmp、wget、curl下载、chmod x这一连串操作需要高度警惕。异常外连不容易直接体现在系统日志里但配合ss -tnp、防火墙日志和进程列表能形成完整证据链。复盘时我习惯把所有相关日志按时间轴排列用 grep 和 awk 把 SSH 登录、sudo 执行、文件变更、Web 请求、进程启动这些事件统一抽取出来逐小时逐分钟还原攻击路径。这样攻击者从哪个入口进来、用了什么账号、执行了什么命令、留下了什么持久化手段逻辑就清晰了。4.3 防篡改与异地留存的工程化落地比较现实的低成本方案是用 rsyslog 把日志转发到独立的日志服务器。本机 rsyslog 配置里加一行*.* 192.168.1.100:514远程日志服务器上运行 rsyslog开启 imudp 模块并监听 514 端口就能实时接收日志。配合 logrotate 的压缩和保留策略远程端的数据保存周期可以设置得更长。更进一步的方案是给日志加完整性校验比如用 auditd 自带的特性或者定期对日志文件计算哈希并存储到独立介质。--since这类查询参数在复盘时非常好用但前提是日志本身还在。4.4 复盘时的分析思路与工具选择日志分析工具的选择取决于日志量。小规模场景下grep、awk、sort、uniq的组合就已经够用命令短、灵活随时可以在终端里跑。日志量中等时我推荐lnav这个终端下的日志浏览器它能自动识别常见日志格式支持按时间排序、按关键字过滤、甚至统计直方图比单纯 grep 直观很多。日志量大的场景就要上 ELKElasticsearch Logstash Kibana这类集中式平台用 Filebeat 统一采集日志到 Elasticsearch再在 Kibana 里做检索、可视化和告警。不过我在实际复盘时十次里有六七次还是先用命令行快速筛一遍全部依赖重型平台反而会降低效率。最有效率的路径是先用 grep 定位可疑时间点和关键字再用journalctl --since和--until按时间窗口拉日志最后用 awk 做聚合统计。复盘不是把工具都堆上去而是要快速锁定攻击路径再逐个击破。5. 高频问题与避坑经验速查5.1 日志时间和时区不对日志时间对不上通常是因为系统时区没有统一。用timedatectl set-timezone Asia/Shanghai改时区再配合 chronyd 或 systemd-timesyncd 做时间同步。日志时间一旦错乱安全审计和渗透复盘时的时间线就无法对齐佐证力会大打折扣。另外还要留意日志文件里的时间戳格式有些程序默认输出 UTC 时间查看时要换算清楚。5.2 journald 日志把磁盘吃满怎么办先用journalctl --disk-usage查看用量再用journalctl --vacuum-size500M清理到指定大小以内或者用journalctl --vacuum-time7d只保留最近 7 天。如果希望从根本上限制修改/etc/systemd/journald.conf里的SystemMaxUse500M然后重启 systemd-journald 服务。要注意的是清掉的日志无法找回生产环境动手前先确认是否有合规留存要求。5.3 文件删了空间却不释放大概率是文件被进程占用。用lsof | grep deleted找到占用进程然后重启该进程磁盘空间就会释放。Java 和 Python 进程通常长时间不重启删除的日志文件容易被句柄占用。这个问题的本质是文件系统层面删除操作不会立即回收块只有等所有文件描述符关闭后才会真正释放空间。5.4 MySQL binlog 到底能不能删分场景判断。开了主从复制时先确认从库已经消费完 binlog否则删除会导致同步链路中断。单机环境且有全量备份时可以清理历史 binlog但最好保留一个周期用于时间点恢复。清理时用PURGE BINARY LOGS BEFORE或PURGE BINARY LOGS TO命令不要手动删文件。binlog 的保留策略建议在业务规划阶段就定好避免后期数据增长后无从下手。5.5 SSH 爆破日志刷屏先统计来源 IP用防火墙或安全组封锁攻击来源再考虑加固措施。系统层面建议修改 SSH 默认端口、限制可登录用户、启用密钥认证、安装 fail2ban 这类自动封禁工具。检查一下是否有账号已经被成功爆破确认没有后门再收尾。安全加固做完之后记得观察几天 secure 日志看爆破流量是否已经停止。我个人在实际操作中最深的体会是日志不是出了问题才想起来看的而是要在系统正常运行的时候就把“记什么、记多久、放哪里”都设计好。绝大多数能在一个小时内定位的线上故障靠的都是日志留得够全、路径够清晰真正耗时长的往往是那些日志被忽略、被截断、被覆盖的机器只能靠业务表象去猜。如果你读完这篇能把自己手头机器的日志轮转策略、日志留存周期、异地转发这三件事顺手做一遍后面遇到故障和安全事件时会轻松很多。还有一个小技巧每台服务器都建一个本地的日志查阅手册把关键路径和常用命令记下来等出问题的时候这份笔记比临时翻文档有用得多。
