1. 日志系统先弄清楚日志到底写到了哪里说到故障排查我见过太多人第一步就错了。他们拿到一台出问题的服务器第一反应是“这机器是不是坏了”然后各种乱试命令敲了一堆看着很专业的指令最后问题没解决还把现场给破坏了。真正靠谱的做法恰恰相反先冷静下来把日志系统摸透让日志替你说话。日志系统是整个Linux运维体系里最容易被忽视、却最值钱的基础设施。它本质上解决一个问题当系统或程序出现异常时你能不能按图索骥找到“发生了什么、什么时候发生的、影响范围有多大”。很多人觉得日志就是几个文本文件这没错但它背后的机制远没有看起来那么简单——信号的传递、进程的状态、文件描述符的打开情况这些信息都会在排查故障时跟日志互相印证。1.1 日志系统的分层结构与核心文件我习惯把Linux日志系统分成三层来看这样的好处是排查时可以快速定位该去看哪一层。第一层是内核日志。由内核自己维护通过dmesg或/var/log/dmesg查看记录的是硬件驱动、内存、文件系统等底层事件。比如服务器突然重启很多时候不是某个应用挂了而是内核触发了panic这类信息在普通应用日志里根本找不到必须看这一层。第二层是系统服务日志。传统Linux发行版会写到/var/log/messagesCentOS/RHEL系列或/var/log/syslogDebian/Ubuntu系列由rsyslog统一收拢。这部分记录的是系统级服务、cron任务、认证信息/var/log/secure等。现在新一点的发行版已经全面转向systemd的journald用journalctl来读取日志二进制存储带结构化字段还能按时间、服务、优先级做过滤。第三层是应用日志。这层最灵活也最考验设计功力。一个成熟的业务系统日志文件路径通常会在应用配置里显式声明比如/var/log/myapp/access.log、/var/log/myapp/error.log。如果应用是跑在容器里的那就得靠容器日志机制去收再配合ELK或者Loki这类日志平台做集中处理。排查故障时的第一判断就是先搞清问题可能发生在哪一层然后直奔那一层的日志文件。这一步做对了后面能省一半时间。1.2 日志轮转与磁盘占用不注意就会踩坑日志系统的头号杀手不是“没写日志”而是“日志写爆了磁盘”。我见过很多次线上事故罪魁祸首竟然是/var/log下某个文件撑满了整个分区导致数据库写入失败、应用无响应。Linux下负责日志轮转的工具是logrotate。它通过cron定时任务通常是/etc/cron.daily/logrotate每天执行一次按照配置文件把日志改名、压缩、清理。配置在/etc/logrotate.conf业务相关的通常在/etc/logrotate.d/下各放一个文件。这里有个常见错误如果你的日志文件是Java应用持有的直接rename旧文件再建新文件应用仍然写的是旧文件描述符指向的已被删除的文件结果就是新日志文件永远为空。解决办法是配置里加copytruncate或者用create加postrotate脚本通知应用重新打开文件。举个例子我在生产环境给某个业务服务配轮转时这样写/var/log/myapp/app.log { daily rotate 14 compress delaycompress copytruncate missingok notifempty dateext dateformat -%Y%m%d }rotate 14表示保留14个周期daily就是保留14天。compress压缩旧日志节省空间delaycompress让昨天的日志不压缩方便临时查。dateext加日期后缀避免同名覆盖。最关键的copytruncate先复制一份当前日志再清空原文件不影响应用句柄。缺点是复制期间可能有少量日志丢失但对于排查运维场景这点损失完全可以接受。1.3 应用日志的约定优于配置统一的输出才有排查价值日志系统的价值上限很大程度上取决于应用输出日志的质量。我接手过很多项目日志写得乱七八糟排查全靠肉眼从万行文本里捞字段捞完还要脑补上下文。这种痛苦凡是做过运维的人应该都懂。我自己的习惯是应用日志输出至少要满足三个约定每条日志必须带时间戳精确到毫秒且时间格式统一。没有时间戳的日志等于废品因为故障排查本质上是还原时间线。关键业务操作要有唯一标识比如订单号、请求ID方便把一次完整操作的日志串联起来。错误日志必须带堆栈或上下文不能只打“failed”三个字母。针对异常要记录输入参数和当前状态。这三个约定看着简单执行到位能省太多事。尤其是“请求ID贯穿链路”这一点在微服务架构下几乎是刚需没有这个标识前端报一个错后端几十个服务你根本对不齐日志。2. 故障排查从看到故障到定位根因的完整路径如果说日志系统是“数据库”那故障排查就是“查询分析流程”。我见过太多人一遇到线上问题就像无头苍蝇这里看一下那里试一下最后问题没定位到还把现场信息搞丢了。这里我分享一套我自己整理的排查路径从确认故障到定位根因每一步都有明确目的。2.1 先确认“是不是真的故障”用排除法减少误判很多人拿到一个“故障”提示第一反应就是“服务挂了”但实际上大量问题是假故障。比如客户说网页打不开结果是他自己断网了监控报警说CPU高登录服务器一看只是某个批处理任务跑完了正在收尾。排查的第一步永远是确认现象本身的真实性。我在实际操作中的习惯是先看现象的直接表现再根据表现决定要不要慌。以“网页打不开”为例先在本机curl一下服务地址看返回什么状态码再检查网络链路是否通最后才登录服务器看服务进程是否存活、端口是否监听。每一步都有明确证据而不是凭感觉下结论。这里送大家一个口诀链路先行状态次之日志定案。先把可能的原因范围缩小再深入日志看实锤。2.2 还原时间线用journalctl和时间戳串联线索一旦确认是真故障接下来最重要的事情是还原时间线。大多数故障都不是瞬时发生的总有征兆内存可能提前十几天就开始缓慢增长磁盘可能提前几个小时就写满了重启前的异常日志可能静静地躺在角落里。我用journalctl时习惯了这样一套组合# 查看某个服务的所有日志反向展示最新的在最上面 journalctl -u your-service -r # 限定时间窗比如今天上午9点到10点之间 journalctl -u your-service --since 2024-01-15 09:00:00 --until 2024-01-15 10:00:00 # 按日志级别过滤只看error和crit journalctl -u your-service -p err..crit如果日志是写到文件里的传统模式同样道理用grep加时间前缀过滤。关键是别只看那一条报错要把报错前五分钟、后十分钟的日志都拉出来看这样才能还原“故障发生之前系统在干嘛”的完整画像。很多新手容易犯的错是只盯着红色的ERROR看完全没有上下文概念。实际上99%的ERROR都要结合前后文理解否则你只能看到“什么坏了”看不到“为什么坏”。2.3 日志之外的重要佐证进程状态与系统负载日志是主线索但日志不是唯一证据。很多时候日志根本没有记录关键信息或者记录得太晚。这时候要学会从日志之外找佐证尤其是进程与系统状态。排查故障时我必查的几项uptime看系统负载和1/5/15分钟的平均值判断是突然飙升还是持续累积。top/htop看CPU、内存的实时占用按CPU或内存排序定位消耗大户。ps -ef看进程是否存在、父进程是谁、启动时间是什么时候。ss -tlnp看端口监听状态配合netstat传统命令做对比。df -h和inode看磁盘空间和inode是否耗尽这是两个最容易被忽视的“软性故障”。举一个典型例子服务突然不响应了日志里没有任何ERROR反而在某个时间点之后彻底沉默了。你去看磁盘发现/var目录100%占满再看进程还在但应用卡在文件写入上迟迟返回不了。这种场景下日志帮不上忙但如果懂系统状态一眼就能定位。日志不是故障排查的唯一武器它是第一件武器。你得会看日志但更得知道日志什么时候“骗”了你。3. 长时运行脚本无日志输出的排查实战说完了理论来一个真实高频场景Linux下跑了一个sh脚本执行了很多个小时窗口里却长时间没有任何日志输出。你怀疑它挂了但又不敢确定更不敢随便杀进程。这种场景在跑批处理、数据同步、长时间定时任务时特别常见。我一开始也慌过后面总结了完整排查套路今天详细拆开来说。3.1 现象复现与第一步排查脚本还活着吗先描述一下典型情况你写了一个shell脚本里面有循环处理逻辑打算输出处理进度。用nohup ./run.sh run.log 21 扔到后台跑本来预期每分钟都有输出结果跑了两个小时run.log文一寸没变。这时候你的第一反应可能是“脚本卡住了”或者“死循环了”但注意这只是一个假设还不能下结论。第一步排查就是确认进程本身是否还活着。推荐用如下组合ps -ef | grep run.sh pgrep -af run.sh不要用grep run.sh直接过滤因为很容易把grep自己匹配进去虽然可以grep -v grep规避但pgrep更干净。如果进程在看它的PID然后进一步确认它的状态。ps输出的STAT列很有讲究。R表示运行中S表示睡眠D表示不可中断睡眠Z表示僵尸T表示已停止。如果看到状态是R说明它还在消耗CPU如果是S说明它在等待某个事件如果是D大概率卡在磁盘或网络IO上动弹不得。3.2 用进程信号和后台任务定位脚本状态进程活着不代表它“干活正常”。为了搞清楚脚本到底在干嘛我用的第二招是发送信号探测。这里需要理解一个重要机制kill -0 PID不会发送任何实际信号它只检查进程是否存在、是否有权限发送信号。如果命令返回0且没有报错说明进程存在并且属于你。这是最无损的探活方式。kill -0 12345 echo 进程还在但探活只是第一步我还想看看脚本当前执行到哪一行了。这时候可以看进程的/proc目录ll /proc/12345/fd cat /proc/12345/cmdline ls -l /proc/12345/cwd/proc/PID/fd里能看到进程打开的文件描述符比如它正在写哪个日志文件、读哪个数据文件。如果fd里有文件句柄但lsof查不到说明文件可能被删了或者路径有问题。这些线索比“进程还在”有用得多。如果用了strace能看到更底层的信息strace -p 12345 -e tracewrite,read,select这会打印进程当前正在执行的系统调用。如果一直卡在read或select上说明它在等待外部输入或IO而不是在疯狂计算。如果不断输出write调用说明它其实一直在写东西只是输出没出现在预期位置那问题就转向“日志到底去哪了”。3.3 缓冲区机制为什么脚本“没输出”不等于“没运行”这是整个排查里我见过最多人踩的坑。很多情况下脚本根本没有任何问题数据也在正常处理只是你看到的文件没有及时刷新。这背后的机制是缓冲区。当标准输出被重定向到文件而不是终端时glibc会对输出做块缓冲——默认4KB大小的缓冲。也就是说程序写了几百字节的内容可能一直存在内存缓冲区里要等缓冲区满了或者程序退出时才一次性写入文件。这跟你在终端直接跑脚本时的“行缓冲”完全不同后者碰到换行符就刷一次。搞明白这个就理解为什么nohup.out或run.log长时间不更新了。你可以用几个方式验证和解决看进程的实时CPU占用确认它在干活top -p 12345如果CPU持续波动说明计算没停。在脚本里对关键输出主动加stdbuf -oL或unbuffer强制行缓冲。比如把命令改成stdbuf -oL -eL python3 run.py run.log 21 。如果是Python脚本python -u就是unbuffered模式一行输出立即刷新。Java服务则可以通过logback/log4j配置immediateFlushtrue。举个例子我用rsync同步大批量文件时也碰到过类似现象。rsync有一个--progress输出进度重定向到日志文件后日志很久都没动静看上去像卡死了。但用ps看CPUrsync进程的cpu占用一直在跳再等一会儿等到输出量达到4KB缓冲区日志文件一次性刷出一大批进度行。这就是典型的“假死”。3.4 排查流程总结一份可以直接抄的清单说了这么多我把这个场景的完整排查流程理成一份清单适合贴在手边随时翻阅第一步探活。pgrep -af run.sh确认进程存在。 第二步看状态。ps -o pid,stat,etime,cmd -p PID判断是运行、睡眠还是卡死。 第三步看行为。top -p PID确认CPU消耗strace -p PID确认系统调用。 第四步找输出。cat /proc/PID/fd确认文件句柄lsof -p PID列出打开文件。 第五步等结论。结合输出缓冲区机制判断是“真没输出”还是“没刷出来”。 第六步做决策。确认卡死才考虑杀进程先kill后kill -9否则继续等或者优化日志输出方式。这套流程最关键的一点是每一步都要基于观察结果来判断而不是凭“感觉”。我之前见过一位同事脚本跑了三个小时没输出他上来就kill -9把进程杀了后来发现数据已经处理到99%就差最后一点收尾结果全部白干。排查的时间成本永远比重跑一次低。4. 常见故障与排查技巧实录这个章节我整理一些我在一线运维中反复遇到、且很有代表性的排查场景。每个场景我都会给出具体的排查思路和命令组合方便你直接拿去参考。4.1 定时任务与日志cron脚本独特的坑点cron任务和定时任务是日志系统的高频故障点坑非常多。比如你设置了一个每小时的定时任务结果它一直没执行或执行了没效果排查难度比手动跑脚本高不少因为cron执行环境跟你手动登录的环境完全不一样。cron执行任务时不会加载用户的.bash_profile或.bashrcPATH环境变量被重置为/bin:/usr/bin这种精简状态。你在交互终端能用的命令在cron里可能找不到。这也是经典问题脚本里调用某个自定义路径下的命令手动跑正常cron跑就报command not found。解决办法是脚本开头固定好环境变量#!/bin/bash export PATH/usr/local/bin:/usr/bin:/bin export LANGen_US.UTF-8排查cron相关问题要看的日志是/var/log/cron或journalctl -u crond。这个日志会记录每一条任务的执行时间、执行命令、PID和返回状态是排查定时任务的第一入口。如果任务没有出现在日志里说明cron根本没有调度到它重点检查cron表达式和时区。如果出现在日志里但没执行结果就看任务的退出码或直接手动以cron的环境跑一遍脚本。我自己吃过一个大亏某个任务每天凌晨两点跑偶尔会失败但查cron日志显示执行正常退出码为0。后来加了输出重定向把标准输出和错误都写到文件里才发现脚本内部一条curl命令因为SSL证书过期报错但脚本没有set -e后续命令继续执行最后整体退出码仍然是0。这就是典型的“日志说正常实际有问题”。4.2 系统性能监控一下就能锁定故障源的几个指标很多故障的根源不是“某个错误”而是资源耗尽。日志里可能只有零散的连接超时但背后是文件描述符用尽或内存泄漏。学会看系统性能指标能在日志给出明确线索前提前预警。我推荐在排查故障时优先看这几个指标文件描述符cat /proc/PID/limits看进程的限制值ls /proc/PID/fd | wc -l看当前打开数量。如果接近上限服务会报“Too many open files”。内存与Swapfree -h关注available是否长期接近0swap使用率是否持续增长。这两个都是内存压力的信号。磁盘I/Oiostat -dx 1看每个磁盘的util和await如果util长期高于80%且await很高说明磁盘成了瓶颈。网络连接ss -s看连接状态统计配合ss -tn看大量TIME_WAIT或CLOSE_WAIT堆积。TIME_WAIT多可能是连接没复用CLOSE_WAIT多则多半是应用没正确关闭连接。这些指标配合日志基本能覆盖90%的线上故障场景。如果这些都没问题再去怀疑代码逻辑否则排查方向容易跑偏。4.3 我压箱底的排查命令组合平时我不太推荐“背命令”但有几条组合确实是高频使用的熟练到条件反射也不为过。这里先列几条最常用的# 查看日志尾部并且持续跟踪 tail -f /var/log/messages # 查看最近一小时内某个关键词的所有日志 journalctl --since 1 hour ago | grep 关键字 # 看服务状态和最近日志 systemctl status your-service -l # 查端口和进程关系ss比netstat快 ss -tlnp | grep 8080 # 找高消耗资源的进程 top -o %CPU -o %MEM -b -n 1 | head -30tail -f在跟踪日志时有一个细节日志文件发生轮转后tail -f不会自动跟随新文件名。这时候按CtrlC重新执行一次或者用tail -F大写F它会根据文件名重新打开文件。这个小细节我曾经在轮转日志的服务器上踩过坑当时盯着旧文件的尾部看了半天数据纹丝不动后来才发现文件早被logrotate改名了。4.4 iuv5g故障排查思路把通用方法落到具体业务系统上把上面这些通用思路落到具体业务系统中思路是完全一致的区别只是观察点不同。比如一个叫iuv5g的业务模块出现“无日志输出”的可疑故障我的排查顺序是先确认系统级资源有没有异常磁盘、内存、CPU、IO再看进程状态和相关端口最后拉业务日志还原时间线。有些人习惯一上来就翻业务日志忽略了环境因素往往会走弯路。一个统一思路是不管业务多复杂遵循从外到内、从系统到应用、从全局到局部的路径。系统的异常会先反应在日志里业务的异常则会先反应在操作体验上把这两条线交叉对齐就能定位出真正的因果链。luv5g这类业务系统往往由多个模块组成模块之间通过接口或消息通信排查时还需要关注日志里有没有跨模块的traceId或会话标识。有了这个标识才能把一条请求在多个模块间的流转过程拼出来否则每个模块的日志都是孤岛拼不出完整链路。5. 最后分享几个实操心得写到最后聊几个没有展开讲、但在实际工作中价值很高的心得。日志系统这块我越来越觉得“留痕”比“事后分析”更值得投入。很多服务上线以后日志路径都没约定好甚至有的直接打到控制台重定向都没有重启以后信息直接蒸发。我建议每个项目从第一天就把日志目录结构、命名规范、轮转策略定好宁可前期多点工作量也比故障当天满头大汗查不到日志强。排查故障时时间戳是我最依赖的锚点。无论看什么日志第一件事就是定位时间线故障影响开始的时间点、日志最后一条记录的时间点、系统负载发生变化的时间点把这三者对齐很多问题就清晰了。日志系统有没有统一记录事件时间的能力决定了排查故障时能不能快速还原现场。另外很多“疑难杂症”其实是自己制造的。比如权限不对导致日志写不进、路径写错导致日志一直在别处增长、时区没统一导致日志时间轴错位。这些问题排查起来不难但很耗时间预防的唯一办法就是规范化目录标准化、权限统一、时区强制设为UTC或本地时间并在日志格式中标明。最后想再强调一下缓冲区那个坑。sh脚本长时间不输出先别急着杀进程先确认进程状态再观察CPU和IO同时考虑输出缓冲。这种“假死”场景里多等几分钟往往就等到日志刷出来。遇到问题时多一层验证就少一分风险。这份日志系统和故障排查的思路希望能帮你在下一次踩坑时少走点弯路。