1. 为什么学Linux总卡在“会用但不懂”很多人学Linux都有一个共同的困惑命令背了一堆跟着教程敲了一遍当时觉得全会了过几天再碰又觉得手生。我也经历过这个阶段而且时间不短。直到后来做了一次系统性的实战整理把零散的知识点串成一条线才发现问题不在记性而在学习方式。这套“小柏实战学习Linux”系列就是围绕真实操作场景来组织的。每一篇都从实际需求出发先搞清楚“要解决什么问题”再一步步落地命令和配置。这一篇是第八讲重点聚焦在文本处理、进程管理、网络排查和磁盘操作这四个方向。这些内容看起来基础但恰恰是日常使用频率最高、最容易出错的环节。如果你已经在用Linux但总觉得命令是死记硬背、换个环境就发蒙这一篇可以帮你把思路理清楚。如果你刚入门跟着实操走一遍也能避开不少我当年踩过的坑。2. 四个高频场景为什么值得花时间拆解2.1 文本处理日志排查和配置修改的日常功课Linux系统里几乎所有配置都是文本文件日志也是文本。所以文本处理能力直接决定了你排查问题的效率。很多新手只会用cat把文件全打出来日志一大就刷屏根本看不过来。真正干活的时候需要的是精确抽取、过滤、统计和格式化输出。这篇里的文本处理部分用的是awk、sed、grep、sort、uniq这几个命令的组合拳。它们各自负责一件事串联起来就能完成从“原始日志”到“结论”的完整链路。2.2 进程管理系统卡顿和异常排查的入口服务器卡了、CPU飙高了、某个服务挂了第一件事就是看进程。ps只能看静态快照top能实时刷新配合kill、nice、renice这些控制命令才能完整管理一个进程的整个生命周期。我在实操中特别加了按线程维度排查CPU占用的小例子因为生产环境里很多性能问题都藏在多线程进程的某个线程里只看进程级数据往往定位不到根因。2.3 网络排查服务连不上的时候靠它救命网络问题是最让人头疼的。域名解析对不对、端口通不通、数据包丢没丢、路由怎么走的每层问题都需要不同工具。ping和telnet只能做最初步的连通性测试真正深入还得靠ss、traceroute、tcpdump这些工具。2.4 磁盘操作从分区到挂载的完整流程磁盘操作属于平时用不到、一旦要用就容错率很低的操作。分区表、文件系统、挂载点每一步都有讲究。这篇的disk案例里我完整走了一遍“识别磁盘-分区-格式化-挂载-验证”的流程并且特别强调了数据备份的问题。场景涉及命令典型痛点文本处理awk、sed、grep、sort、uniq日志太大、格式不统一进程管理ps、top、kill、nice、reniceCPU飙高、找不到进程网络排查ping、ss、traceroute、tcpdump端口不通、连接超时磁盘操作lsblk、fdisk、mkfs、mount分区误操作、挂载失败这四个场景有一个共同特点都离不开“观察-定位-动手-验证”的循环。观察靠查看类命令定位靠过滤和分析动手靠控制类命令验证靠再次查看。理解了这条循环遇到新工具也能快速上手。3. 文本处理三件套grep、awk、sed的配合实战3.1 grep先筛行快速划定范围grep的核心逻辑是按行匹配模式把符合条件的行打印出来。排查日志时第一步永远是先用grep把相关行捞出来缩小范围。假设有一个名为“app.log”的日志文件里面有大量访问记录和错误信息。最常见的操作是:grep ERROR app.log这只是最简单的用法。实际排查中更常用的是加参数grep -n ERROR app.log # 显示行号 grep -i error app.log # 忽略大小写 grep -v DEBUG app.log # 反向匹配排除调试日志这里有个很容易忽略的点如果日志文件很大比如几个GB直接用grep全量扫描会慢。可以先按时间段粗筛比如日志名按日期滚动类似app-20250601.log这样的命名或者在日志里先截取某个时间窗口后再继续处理。实际生产环境里日志文件基本都做了轮转切割直接找到对应时段的文件比在一个大文件里硬翻效率高得多。3.2 awk取列和统计结构化整理数据grep筛完行之后很多场景需要进一步提取特定列。awk就是干这个的。它按分隔符把每一行拆成字段默认按空格或制表符分割用$1、$2……引用对应列。接着上面的场景假设日志格式是“时间 IP 请求路径 状态码”想找出所有返回5xx错误的请求路径awk $4 ~ /^5[0-9][0-9]$/ {print $3, $4} app.log这条命令的意思是第四列以5开头、后面跟两位数字的把第三列和第四列打出来。这里$4是状态码$3是请求路径。awk真正的威力在于它是一门小型编程语言支持变量、循环、条件判断。比如统计每个IP的请求次数awk {count[$2]} END {for (ip in count) print ip, count[ip]} app.log | sort -k2 -nr | head这条命令是awk和sort、head的组合。count数组统计第二列每个IP的出现次数END块在读完所有行之后执行把统计结果打印出来再交给sort按第二列数值从大到小排最后取前10条。这就是把“原始日志”变成“结论”的典型过程。注意awk里的数组下标如果列里包含重复值会被折叠统计所以这一步之前最好确认列内容是否符合预期。我遇到过日志中IP列偶发为空的情况统计结果里多出一个空字符串的“IP”排查了半小时才发现是脏数据。3.3 sed精准替换修改配置不用开编辑器sed按行处理文本可以做替换、删除、插入。最常用的替换场景是批量改配置。比如把配置文件里所有监听8080端口的配置改成9090sed -i s/8080/9090/g nginx.conf这个命令的读法是-i表示直接修改文件s表示替换8080是查找模式9090是替换内容g表示全局替换不只是在每行第一次出现时替换。有几个坑要提醒-i参数在修改前最好先不加直接跑一遍看输出对不对确认无误再加-i真正写回文件。如果配置文件里有多种8080含义比如注释里也提到了8080建议先grep确认所有出现位置再决定替换范围。sed的正则用的是基础正则和grep的扩展正则、awk的正则都有细微差别同样一个表达式在不同工具里可能含义不同。比如在基础正则里是普通字符要加反斜杠转义为\才表示“一个或多个”。3.4 sort、uniq做去重统计数据收口靠它俩sort给行排序uniq去除相邻重复行。注意uniq只能去重相邻的重复行所以必须先sort再uniq这俩几乎总是连着用。日志去重统计的标准三连sort access.log | uniq -c | sort -rn | head -20先排序再去重并显示每行重复次数-c再按次数从大到小排列-rn最后取前20条。这个组合在分析日志里“哪些错误反复出现”时非常高效。4. 进程管理的实操复盘4.1 ps和top静态与动态结合看ps -ef和ps aux是日常查看进程最常用的两条命令。它们的区别在于输出格式不同前者偏向显示父子关系和完整命令行后者偏向显示CPU和内存占用。排查CPU飙高的标准流程我一般这样走top -b -n 1这个命令用批处理模式跑一次并退出避免动态刷新带来的干扰。在脚本或排查记录时比直接交互式top更好用。如果看到某个进程CPU占用率接近100%再深入一步看它的线程分布top -H -p PID-H参数按线程展示-p指定进程ID。这一步非常关键因为Java、Python这类多线程应用进程整体CPU高但具体是哪个线程在“烧”CPU必须切到线程级才看得清。我曾经排查过一个服务偶发卡顿进程CPU看起来才60%但切到线程视图后立刻看到一个线程占用打满最后定位到是某个异步任务的死循环。4.2 kill与其他信号不是只有强杀kill默认发送TERM信号15请求进程正常退出。如果进程不响应才会用到KILL信号9强制终止。除这两个之外常见信号还有信号数值作用HUP1挂断常用于重读配置文件INT2键盘中断等价于CtrlCTERM15默认终止信号进程可自行清理KILL9强制终止不可捕获不可忽略STOP19暂停进程不终止CONT18继续已暂停的进程实际运维中改完nginx配置后让配置立即生效不需要重启进程只需要发送HUP信号kill -HUP [nginx的PID]这个操作的原理是nginx主进程收到HUP信号后会重新读取配置文件并拉起新的worker进程比stop再start快而且不会中断正在处理的连接。这个技巧比直接重启优雅得多也是老运维和新人之间一个很小的分水岭。4.3 nice和renice让进程按优先级跑Linux的CPU调度是按优先级抢占的优先级数值范围是-20到19数值越小优先级越高。普通用户只能调高nice值降低优先级只有root能调低nice值提高优先级。启动一个新任务时指定优先级nice -n 10 ./backup_script.sh对已经运行的进程调整优先级renice -n 10 -p PID一个典型场景是白天业务高峰期不要跑全量备份脚本但如果非要跑就把它nice调高一些让它把CPU让给业务进程。我当时的实操环境里跑过一次全量数据导出把进程nice设为10之后业务侧高负载时的响应延迟明显比默认优先级的情况好。这个细节在高负载服务器上非常实用。5. 网络排查与磁盘操作的踩坑实录5.1 从ping到traceroute层层逼近问题点ping测通不代表网络“没问题”它只能说明ICMP协议在目标主机和源主机之间可达。很多服务器禁ping所以ping不通不一定服务不可用。判断一个服务是否正常关键要看TCP端口是否连通。我习惯用ss命令替代老旧的netstat前者更快输出也更清晰ss -ltn这条命令列出所有监听的TCP端口。-l是只看监听状态-t是TCP协议-n是不解析域名直接显示IP端口。如果能看到目标端口处于LISTEN状态说明本机服务正常。如果本机端口正常但外部连接失败大概率是防火墙或云安全组拦截了。路由追踪用traceroutetraceroute -n 目标IP它逐跳打印从本机到目标IP经过的路由节点。如果某一段出现星号或者延迟暴涨说明这一段网络有拥塞或丢包。注意traceroute输出里的每一跳代表一个路由器接口不代表一台独立机器。5.2 tcpdump抓包看真相网络排查的最后一步往往要用tcpdump抓包确认数据包是否到达本机、是否发出响应。它需要root权限非常强大也容易产生大量输出所以抓包必须指定过滤条件。最常见的抓包方式tcpdump -i eth0 port 8080 -c 100-i指定网卡port指定端口-c限定抓取100个包后自动停止。如果要保存抓包结果以便后续用图形化工具分析加-w参数tcpdump -i eth0 port 8080 -w /tmp/capture.pcap抓完的pcap文件可以用Wireshark打开分析。注意tcpdump抓包时如果流量本身就很大不加过滤条件会直接打满磁盘。我第一次实操时忘记加-c限制抓了十几分钟磁盘空间告急紧急用CtrlC终止才算没把系统搞挂。养成“先加过滤条件、再加包数量限制”的习惯能避免很多麻烦。5.3 磁盘分区和挂载的完整流程虚拟机里新增了一块磁盘系统里看不到第一步要确认系统是否识别到lsblklsblk列出所有块设备包括磁盘、分区、挂载点和容量。如果新磁盘出现了但没有任何分区接着用fdisk分区fdisk /dev/sdb进入fdisk交互界面后按n新建分区按p选主分区后续一路默认值即可最后按w写入分区表。分区完成后分区表里会出现类似sdb1的条目。接下来格式化mkfs.ext4 /dev/sdb1创建ext4文件系统。其他常用格式还有xfsCentOS/RHEL默认、btrfs等按发行版习惯选择。格式化之后才能挂载mkdir /data mount /dev/sdb1 /data挂载后还要让开机自动挂载就得改/etc/fstab文件。手动挂载和开机挂载必须保持一致否则重启后目录是空的。修改fstab的关键一行/dev/sdb1 /data ext4 defaults 0 0写完fstab后强烈建议先验证一遍mount -a这条命令会重新读取fstab并挂载其中所有条目。如果fstab写错了mount -a会直接报错可以在重启前及时修正。这个验证步骤能避免一次服务器重启后找不到文件系统的惨剧。注意云服务器里的数据盘某些场景建议用文件系统的UUID而不是/dev/sdX这种设备名来挂载。因为设备名在系统重启后可能变化比如sdb变成sdc但UUID不会变。用blkid命令可以查到每个文件系统的UUIDfstab里写UUID更稳。5.4 我踩过的坑格式化前没确认盘符新磁盘的分区、格式化、挂载这套流程本身不难真正危险的是在执行命令时找错了磁盘。我实操时遇到过一个很惊险的瞬间明明以为在操作/dev/sdc后来用lsblk复查才发现系统里还挂着一个数据盘/dev/sdb两者块大小和容量极其相似。从那以后我养成一个习惯任何磁盘操作前先跑lsblk和blkid把设备名、容量、已有分区、挂载点全部确认一遍再用df -h复查一遍现有磁盘状态确保自己不会把已有数据的磁盘格式化掉。磁盘操作的容错率极低多花两分钟确认对比可能的灾难性损失非常划算。6. 日志分析组合拳一个完整案例走查6.1 场景描述和原始日志为把前面的命令串起来我在本机搭了一个模拟场景。有一个访问日志文件access.log内容格式是“时间 客户端IP 请求方法 路径 状态码 耗时ms”我拿它做了完整分析。日志内容大约几百行其中混着正常请求和错误请求。先看文件整体情况wc -l access.log假设输出是342行说明日志不大可以直接处理。如果日志有几十万行就要谨慎设计命令避免一次扫描太久。6.2 先整体后细节状态码分布第一步先看整体状态码分布awk {print $5} access.log | sort | uniq -c | sort -rn这里$5是状态码字段。输出结果会像这样280 200 42 404 12 500 8 502看到200占绝大多数但500和502加起来有20条说明服务确实存在不稳定情况。这一步的价值在于不需要逐条看日志就能对系统整体健康状况有个基本判断。6.3 定位错误集中在哪些路径上接下来精确定位哪些请求路径返回5xx错误awk $5 500 {print $3, $5, $6} access.log | sort | uniq -c | sort -rn这条命令把状态码大于等于500的行拿出来打印请求方法、状态码、耗时然后统计排序。实际操作中大多错误路径会集中在两三个接口上这样排查方向就很明确了。如果还怀疑错误是否随时间集中出现可以加时间段分析awk $5 500 {print $1} access.log | cut -c12-19 | sort | uniq -c这里的$1是时间字段cut -c12-19截取出时分秒部分。通过统计各时间段的错误条数能看出错误是持续存在还是集中在某个时间窗口后者往往指向定时任务或流量高峰。6.4 综合判断加验证分析完日志接着用ss确认相关服务端口状态ss -ltn | grep 8080然后通过进程列表确认服务进程在跑ps aux | grep [服务名]这里多提一句grep加方括号的写法grep [服]务名是为了避免grep进程本身匹配到自己。如果不加方括号ps输出里的那一行grep命令也会被自己匹配到干扰判断。这是很多教程不会特意提的小细节但实际排查时很实用。至此这轮日志排查就完成了一个闭环从原始日志到状态码分布从错误集中路径到时间窗口再结合端口和进程状态基本能确定问题方向。7. 高频报错和排查速查实操过程中一定会遇到报错这里把我遇到过且典型的几个列出来方便对照排查。7.1 “Permission denied”类文件或目录权限不足。先用ls -l看权限位再用id确认当前用户是否属于目标文件的所有者或所属组。ls -l /path/to/file id如果确认权限没问题但还是拒绝访问检查SELinux是否拦截用getenforce查看状态。SELinux开启且策略不匹配时即使权限位完全正确服务也可能无法读取文件。这种情况在CentOS系系统上尤其常见。7.2 “command not found”类命令不在PATH路径里或者包未安装。先which看命令是否存在再用包管理器安装。which tcpdump无输出说明没装CentOS系用yum install tcpdumpDebian系用apt install tcpdump。注意某些基础命令在不同发行版里归属不同包比如ifconfig在较新系统中可能不存在需要改用ip命令。7.3 “Address already in use”类端口被占用。用ss -ltn找到占用端口的进程再决定是kill进程还是换端口。ss -ltnp | grep 8080-p参数会显示对应进程PID和名称。拿到PID后用ps确认是什么程序确认可以停止后kill掉。如果端口被系统随机分配给某个内核线程占用排查起来更麻烦但多数场景就是某个旧进程没退干净。7.4 系统命令超时或无响应这种情况多发生在负载过高时。先看load averageuptime三列数字分别代表1分钟、5分钟、15分钟平均负载。如果15分钟负载都比CPU核数高很多说明系统长时间处于高负载状态。此时再配合top看具体是哪个进程吃资源确认后用kill或renice处理。报错场景检查命令处理思路权限拒绝ls -l、id、getenforce权限位、用户归属、SELinux命令找不到which确认是否存在按发行版安装端口被占用ss -ltnp确认进程停止或换端口系统无响应uptime、top看负载定位吃资源的进程8. 自定义脚本串起日常巡检8.1 脚本思路和核心命令组合把日志分析、进程检查、磁盘查询整合成一个快速巡检脚本是我觉得实战价值最大的一步。这个脚本不复杂但能一次性输出系统关键状态。脚本思路分四块系统负载、内存余量、磁盘占用、监听端口。核心命令组合如下#!/bin/bash echo 系统负载 uptime echo 内存 free -h echo 磁盘 df -h echo 监听端口 ss -ltn这里每条命令的输出都经过格式化方便快速阅读。脚本可以保存在/usr/local/bin/下并加执行权限后续直接调用名字就能跑。注意脚本里的命令路径建议用绝对路径或者确保PATH环境变量在非交互式Shell下包含了这些命令路径。cron执行脚本时PATH环境变量往往比交互式Shell精简很多直接写命令名有时会找不到。用which uptime查到的绝对路径写进脚本更稳。8.2 保存日志和告警日常巡检光打印到屏幕不够还要留痕。可以把输出重定向到日志文件并加时间戳echo $(date %Y-%m-%d %H:%M:%S) /var/log/syscheck.log uptime /var/log/syscheck.log free -h /var/log/syscheck.log如果希望异常时提醒可以对关键指标做判断。比如磁盘使用率超过90%时输出成警告disk_usage$(df / | awk NR2 {print $5} | sed s/%//) if [ $disk_usage -gt 90 ]; then echo 磁盘使用率过高: $disk_usage% /var/log/syscheck.log fi这里的逻辑是df /取根分区使用率awk取第五列的百分比sed把百分号去掉然后再和90做数值比较。这个脚本可以放到crontab里定时执行实现每天固定时间的自动巡检。8.3 定时任务注意事项配置croncrontab -e添加一行0 2 * * * /usr/local/bin/syscheck.sh这样每天凌晨2点执行一次巡检。放在凌晨是为了避开业务高峰期避免脚本本身的系统资源占用影响业务。我的体会是这类巡检脚本不需要很复杂关键是能把高频检查项固化下来。真遇到问题的时候先跑一遍巡检脚本拿到整体状态再针对异常项深入排查效率远比一条条敲命令高得多。9. 一些值得长期坚持的习惯实操多了以后我发现真正拉开效率差距的不是某个神级技巧而是一系列小习惯。第一命令先想清楚再执行尤其是删除、格式化、覆盖这类不可逆操作。Linux命令一旦执行没有“撤销”按键。我会在关键命令前先跑一遍dry run或先echo打印命令本身确认无误再真正执行。第二每学到一条新命令随手记下适用场景和注意事项而不是只记命令拼写。命令拼写可以查手册使用场景和踩过的坑往往查不到。我自己维护了一个Markdown笔记按“文本处理”“进程管理”“网络排查”分类遇到问题先翻笔记已经解决过的问题不再需要重新排查一遍。第三保持“验证”的习惯。任何修改配置的操作执行后都要用查看类命令确认生效。改完fstab跑mount -a改完nginx配置kill -HUP后再用curl验证响应改完防火墙规则后用ss或telnet验证端口仍然正常。验证这一步看似多余实际上能挡住大部分低级错误。第四日志和输出要留痕。日常排查的现场输出如果数据量大不要只靠肉眼翻养成输出到文件再分析的习惯。很多问题需要对比前后变化留有原始输出就是留下了对比的基准线。第五模板化。像巡检脚本这种重复性工作一定要模板化、脚本化。人总会疲劳脚本不会。把判断逻辑写进脚本既统一了检查口径也避免了临场手忙脚乱。 Linux实战：从文本处理到磁盘管理的高频命令详解
1. 为什么学Linux总卡在“会用但不懂”很多人学Linux都有一个共同的困惑命令背了一堆跟着教程敲了一遍当时觉得全会了过几天再碰又觉得手生。我也经历过这个阶段而且时间不短。直到后来做了一次系统性的实战整理把零散的知识点串成一条线才发现问题不在记性而在学习方式。这套“小柏实战学习Linux”系列就是围绕真实操作场景来组织的。每一篇都从实际需求出发先搞清楚“要解决什么问题”再一步步落地命令和配置。这一篇是第八讲重点聚焦在文本处理、进程管理、网络排查和磁盘操作这四个方向。这些内容看起来基础但恰恰是日常使用频率最高、最容易出错的环节。如果你已经在用Linux但总觉得命令是死记硬背、换个环境就发蒙这一篇可以帮你把思路理清楚。如果你刚入门跟着实操走一遍也能避开不少我当年踩过的坑。2. 四个高频场景为什么值得花时间拆解2.1 文本处理日志排查和配置修改的日常功课Linux系统里几乎所有配置都是文本文件日志也是文本。所以文本处理能力直接决定了你排查问题的效率。很多新手只会用cat把文件全打出来日志一大就刷屏根本看不过来。真正干活的时候需要的是精确抽取、过滤、统计和格式化输出。这篇里的文本处理部分用的是awk、sed、grep、sort、uniq这几个命令的组合拳。它们各自负责一件事串联起来就能完成从“原始日志”到“结论”的完整链路。2.2 进程管理系统卡顿和异常排查的入口服务器卡了、CPU飙高了、某个服务挂了第一件事就是看进程。ps只能看静态快照top能实时刷新配合kill、nice、renice这些控制命令才能完整管理一个进程的整个生命周期。我在实操中特别加了按线程维度排查CPU占用的小例子因为生产环境里很多性能问题都藏在多线程进程的某个线程里只看进程级数据往往定位不到根因。2.3 网络排查服务连不上的时候靠它救命网络问题是最让人头疼的。域名解析对不对、端口通不通、数据包丢没丢、路由怎么走的每层问题都需要不同工具。ping和telnet只能做最初步的连通性测试真正深入还得靠ss、traceroute、tcpdump这些工具。2.4 磁盘操作从分区到挂载的完整流程磁盘操作属于平时用不到、一旦要用就容错率很低的操作。分区表、文件系统、挂载点每一步都有讲究。这篇的disk案例里我完整走了一遍“识别磁盘-分区-格式化-挂载-验证”的流程并且特别强调了数据备份的问题。场景涉及命令典型痛点文本处理awk、sed、grep、sort、uniq日志太大、格式不统一进程管理ps、top、kill、nice、reniceCPU飙高、找不到进程网络排查ping、ss、traceroute、tcpdump端口不通、连接超时磁盘操作lsblk、fdisk、mkfs、mount分区误操作、挂载失败这四个场景有一个共同特点都离不开“观察-定位-动手-验证”的循环。观察靠查看类命令定位靠过滤和分析动手靠控制类命令验证靠再次查看。理解了这条循环遇到新工具也能快速上手。3. 文本处理三件套grep、awk、sed的配合实战3.1 grep先筛行快速划定范围grep的核心逻辑是按行匹配模式把符合条件的行打印出来。排查日志时第一步永远是先用grep把相关行捞出来缩小范围。假设有一个名为“app.log”的日志文件里面有大量访问记录和错误信息。最常见的操作是:grep ERROR app.log这只是最简单的用法。实际排查中更常用的是加参数grep -n ERROR app.log # 显示行号 grep -i error app.log # 忽略大小写 grep -v DEBUG app.log # 反向匹配排除调试日志这里有个很容易忽略的点如果日志文件很大比如几个GB直接用grep全量扫描会慢。可以先按时间段粗筛比如日志名按日期滚动类似app-20250601.log这样的命名或者在日志里先截取某个时间窗口后再继续处理。实际生产环境里日志文件基本都做了轮转切割直接找到对应时段的文件比在一个大文件里硬翻效率高得多。3.2 awk取列和统计结构化整理数据grep筛完行之后很多场景需要进一步提取特定列。awk就是干这个的。它按分隔符把每一行拆成字段默认按空格或制表符分割用$1、$2……引用对应列。接着上面的场景假设日志格式是“时间 IP 请求路径 状态码”想找出所有返回5xx错误的请求路径awk $4 ~ /^5[0-9][0-9]$/ {print $3, $4} app.log这条命令的意思是第四列以5开头、后面跟两位数字的把第三列和第四列打出来。这里$4是状态码$3是请求路径。awk真正的威力在于它是一门小型编程语言支持变量、循环、条件判断。比如统计每个IP的请求次数awk {count[$2]} END {for (ip in count) print ip, count[ip]} app.log | sort -k2 -nr | head这条命令是awk和sort、head的组合。count数组统计第二列每个IP的出现次数END块在读完所有行之后执行把统计结果打印出来再交给sort按第二列数值从大到小排最后取前10条。这就是把“原始日志”变成“结论”的典型过程。注意awk里的数组下标如果列里包含重复值会被折叠统计所以这一步之前最好确认列内容是否符合预期。我遇到过日志中IP列偶发为空的情况统计结果里多出一个空字符串的“IP”排查了半小时才发现是脏数据。3.3 sed精准替换修改配置不用开编辑器sed按行处理文本可以做替换、删除、插入。最常用的替换场景是批量改配置。比如把配置文件里所有监听8080端口的配置改成9090sed -i s/8080/9090/g nginx.conf这个命令的读法是-i表示直接修改文件s表示替换8080是查找模式9090是替换内容g表示全局替换不只是在每行第一次出现时替换。有几个坑要提醒-i参数在修改前最好先不加直接跑一遍看输出对不对确认无误再加-i真正写回文件。如果配置文件里有多种8080含义比如注释里也提到了8080建议先grep确认所有出现位置再决定替换范围。sed的正则用的是基础正则和grep的扩展正则、awk的正则都有细微差别同样一个表达式在不同工具里可能含义不同。比如在基础正则里是普通字符要加反斜杠转义为\才表示“一个或多个”。3.4 sort、uniq做去重统计数据收口靠它俩sort给行排序uniq去除相邻重复行。注意uniq只能去重相邻的重复行所以必须先sort再uniq这俩几乎总是连着用。日志去重统计的标准三连sort access.log | uniq -c | sort -rn | head -20先排序再去重并显示每行重复次数-c再按次数从大到小排列-rn最后取前20条。这个组合在分析日志里“哪些错误反复出现”时非常高效。4. 进程管理的实操复盘4.1 ps和top静态与动态结合看ps -ef和ps aux是日常查看进程最常用的两条命令。它们的区别在于输出格式不同前者偏向显示父子关系和完整命令行后者偏向显示CPU和内存占用。排查CPU飙高的标准流程我一般这样走top -b -n 1这个命令用批处理模式跑一次并退出避免动态刷新带来的干扰。在脚本或排查记录时比直接交互式top更好用。如果看到某个进程CPU占用率接近100%再深入一步看它的线程分布top -H -p PID-H参数按线程展示-p指定进程ID。这一步非常关键因为Java、Python这类多线程应用进程整体CPU高但具体是哪个线程在“烧”CPU必须切到线程级才看得清。我曾经排查过一个服务偶发卡顿进程CPU看起来才60%但切到线程视图后立刻看到一个线程占用打满最后定位到是某个异步任务的死循环。4.2 kill与其他信号不是只有强杀kill默认发送TERM信号15请求进程正常退出。如果进程不响应才会用到KILL信号9强制终止。除这两个之外常见信号还有信号数值作用HUP1挂断常用于重读配置文件INT2键盘中断等价于CtrlCTERM15默认终止信号进程可自行清理KILL9强制终止不可捕获不可忽略STOP19暂停进程不终止CONT18继续已暂停的进程实际运维中改完nginx配置后让配置立即生效不需要重启进程只需要发送HUP信号kill -HUP [nginx的PID]这个操作的原理是nginx主进程收到HUP信号后会重新读取配置文件并拉起新的worker进程比stop再start快而且不会中断正在处理的连接。这个技巧比直接重启优雅得多也是老运维和新人之间一个很小的分水岭。4.3 nice和renice让进程按优先级跑Linux的CPU调度是按优先级抢占的优先级数值范围是-20到19数值越小优先级越高。普通用户只能调高nice值降低优先级只有root能调低nice值提高优先级。启动一个新任务时指定优先级nice -n 10 ./backup_script.sh对已经运行的进程调整优先级renice -n 10 -p PID一个典型场景是白天业务高峰期不要跑全量备份脚本但如果非要跑就把它nice调高一些让它把CPU让给业务进程。我当时的实操环境里跑过一次全量数据导出把进程nice设为10之后业务侧高负载时的响应延迟明显比默认优先级的情况好。这个细节在高负载服务器上非常实用。5. 网络排查与磁盘操作的踩坑实录5.1 从ping到traceroute层层逼近问题点ping测通不代表网络“没问题”它只能说明ICMP协议在目标主机和源主机之间可达。很多服务器禁ping所以ping不通不一定服务不可用。判断一个服务是否正常关键要看TCP端口是否连通。我习惯用ss命令替代老旧的netstat前者更快输出也更清晰ss -ltn这条命令列出所有监听的TCP端口。-l是只看监听状态-t是TCP协议-n是不解析域名直接显示IP端口。如果能看到目标端口处于LISTEN状态说明本机服务正常。如果本机端口正常但外部连接失败大概率是防火墙或云安全组拦截了。路由追踪用traceroutetraceroute -n 目标IP它逐跳打印从本机到目标IP经过的路由节点。如果某一段出现星号或者延迟暴涨说明这一段网络有拥塞或丢包。注意traceroute输出里的每一跳代表一个路由器接口不代表一台独立机器。5.2 tcpdump抓包看真相网络排查的最后一步往往要用tcpdump抓包确认数据包是否到达本机、是否发出响应。它需要root权限非常强大也容易产生大量输出所以抓包必须指定过滤条件。最常见的抓包方式tcpdump -i eth0 port 8080 -c 100-i指定网卡port指定端口-c限定抓取100个包后自动停止。如果要保存抓包结果以便后续用图形化工具分析加-w参数tcpdump -i eth0 port 8080 -w /tmp/capture.pcap抓完的pcap文件可以用Wireshark打开分析。注意tcpdump抓包时如果流量本身就很大不加过滤条件会直接打满磁盘。我第一次实操时忘记加-c限制抓了十几分钟磁盘空间告急紧急用CtrlC终止才算没把系统搞挂。养成“先加过滤条件、再加包数量限制”的习惯能避免很多麻烦。5.3 磁盘分区和挂载的完整流程虚拟机里新增了一块磁盘系统里看不到第一步要确认系统是否识别到lsblklsblk列出所有块设备包括磁盘、分区、挂载点和容量。如果新磁盘出现了但没有任何分区接着用fdisk分区fdisk /dev/sdb进入fdisk交互界面后按n新建分区按p选主分区后续一路默认值即可最后按w写入分区表。分区完成后分区表里会出现类似sdb1的条目。接下来格式化mkfs.ext4 /dev/sdb1创建ext4文件系统。其他常用格式还有xfsCentOS/RHEL默认、btrfs等按发行版习惯选择。格式化之后才能挂载mkdir /data mount /dev/sdb1 /data挂载后还要让开机自动挂载就得改/etc/fstab文件。手动挂载和开机挂载必须保持一致否则重启后目录是空的。修改fstab的关键一行/dev/sdb1 /data ext4 defaults 0 0写完fstab后强烈建议先验证一遍mount -a这条命令会重新读取fstab并挂载其中所有条目。如果fstab写错了mount -a会直接报错可以在重启前及时修正。这个验证步骤能避免一次服务器重启后找不到文件系统的惨剧。注意云服务器里的数据盘某些场景建议用文件系统的UUID而不是/dev/sdX这种设备名来挂载。因为设备名在系统重启后可能变化比如sdb变成sdc但UUID不会变。用blkid命令可以查到每个文件系统的UUIDfstab里写UUID更稳。5.4 我踩过的坑格式化前没确认盘符新磁盘的分区、格式化、挂载这套流程本身不难真正危险的是在执行命令时找错了磁盘。我实操时遇到过一个很惊险的瞬间明明以为在操作/dev/sdc后来用lsblk复查才发现系统里还挂着一个数据盘/dev/sdb两者块大小和容量极其相似。从那以后我养成一个习惯任何磁盘操作前先跑lsblk和blkid把设备名、容量、已有分区、挂载点全部确认一遍再用df -h复查一遍现有磁盘状态确保自己不会把已有数据的磁盘格式化掉。磁盘操作的容错率极低多花两分钟确认对比可能的灾难性损失非常划算。6. 日志分析组合拳一个完整案例走查6.1 场景描述和原始日志为把前面的命令串起来我在本机搭了一个模拟场景。有一个访问日志文件access.log内容格式是“时间 客户端IP 请求方法 路径 状态码 耗时ms”我拿它做了完整分析。日志内容大约几百行其中混着正常请求和错误请求。先看文件整体情况wc -l access.log假设输出是342行说明日志不大可以直接处理。如果日志有几十万行就要谨慎设计命令避免一次扫描太久。6.2 先整体后细节状态码分布第一步先看整体状态码分布awk {print $5} access.log | sort | uniq -c | sort -rn这里$5是状态码字段。输出结果会像这样280 200 42 404 12 500 8 502看到200占绝大多数但500和502加起来有20条说明服务确实存在不稳定情况。这一步的价值在于不需要逐条看日志就能对系统整体健康状况有个基本判断。6.3 定位错误集中在哪些路径上接下来精确定位哪些请求路径返回5xx错误awk $5 500 {print $3, $5, $6} access.log | sort | uniq -c | sort -rn这条命令把状态码大于等于500的行拿出来打印请求方法、状态码、耗时然后统计排序。实际操作中大多错误路径会集中在两三个接口上这样排查方向就很明确了。如果还怀疑错误是否随时间集中出现可以加时间段分析awk $5 500 {print $1} access.log | cut -c12-19 | sort | uniq -c这里的$1是时间字段cut -c12-19截取出时分秒部分。通过统计各时间段的错误条数能看出错误是持续存在还是集中在某个时间窗口后者往往指向定时任务或流量高峰。6.4 综合判断加验证分析完日志接着用ss确认相关服务端口状态ss -ltn | grep 8080然后通过进程列表确认服务进程在跑ps aux | grep [服务名]这里多提一句grep加方括号的写法grep [服]务名是为了避免grep进程本身匹配到自己。如果不加方括号ps输出里的那一行grep命令也会被自己匹配到干扰判断。这是很多教程不会特意提的小细节但实际排查时很实用。至此这轮日志排查就完成了一个闭环从原始日志到状态码分布从错误集中路径到时间窗口再结合端口和进程状态基本能确定问题方向。7. 高频报错和排查速查实操过程中一定会遇到报错这里把我遇到过且典型的几个列出来方便对照排查。7.1 “Permission denied”类文件或目录权限不足。先用ls -l看权限位再用id确认当前用户是否属于目标文件的所有者或所属组。ls -l /path/to/file id如果确认权限没问题但还是拒绝访问检查SELinux是否拦截用getenforce查看状态。SELinux开启且策略不匹配时即使权限位完全正确服务也可能无法读取文件。这种情况在CentOS系系统上尤其常见。7.2 “command not found”类命令不在PATH路径里或者包未安装。先which看命令是否存在再用包管理器安装。which tcpdump无输出说明没装CentOS系用yum install tcpdumpDebian系用apt install tcpdump。注意某些基础命令在不同发行版里归属不同包比如ifconfig在较新系统中可能不存在需要改用ip命令。7.3 “Address already in use”类端口被占用。用ss -ltn找到占用端口的进程再决定是kill进程还是换端口。ss -ltnp | grep 8080-p参数会显示对应进程PID和名称。拿到PID后用ps确认是什么程序确认可以停止后kill掉。如果端口被系统随机分配给某个内核线程占用排查起来更麻烦但多数场景就是某个旧进程没退干净。7.4 系统命令超时或无响应这种情况多发生在负载过高时。先看load averageuptime三列数字分别代表1分钟、5分钟、15分钟平均负载。如果15分钟负载都比CPU核数高很多说明系统长时间处于高负载状态。此时再配合top看具体是哪个进程吃资源确认后用kill或renice处理。报错场景检查命令处理思路权限拒绝ls -l、id、getenforce权限位、用户归属、SELinux命令找不到which确认是否存在按发行版安装端口被占用ss -ltnp确认进程停止或换端口系统无响应uptime、top看负载定位吃资源的进程8. 自定义脚本串起日常巡检8.1 脚本思路和核心命令组合把日志分析、进程检查、磁盘查询整合成一个快速巡检脚本是我觉得实战价值最大的一步。这个脚本不复杂但能一次性输出系统关键状态。脚本思路分四块系统负载、内存余量、磁盘占用、监听端口。核心命令组合如下#!/bin/bash echo 系统负载 uptime echo 内存 free -h echo 磁盘 df -h echo 监听端口 ss -ltn这里每条命令的输出都经过格式化方便快速阅读。脚本可以保存在/usr/local/bin/下并加执行权限后续直接调用名字就能跑。注意脚本里的命令路径建议用绝对路径或者确保PATH环境变量在非交互式Shell下包含了这些命令路径。cron执行脚本时PATH环境变量往往比交互式Shell精简很多直接写命令名有时会找不到。用which uptime查到的绝对路径写进脚本更稳。8.2 保存日志和告警日常巡检光打印到屏幕不够还要留痕。可以把输出重定向到日志文件并加时间戳echo $(date %Y-%m-%d %H:%M:%S) /var/log/syscheck.log uptime /var/log/syscheck.log free -h /var/log/syscheck.log如果希望异常时提醒可以对关键指标做判断。比如磁盘使用率超过90%时输出成警告disk_usage$(df / | awk NR2 {print $5} | sed s/%//) if [ $disk_usage -gt 90 ]; then echo 磁盘使用率过高: $disk_usage% /var/log/syscheck.log fi这里的逻辑是df /取根分区使用率awk取第五列的百分比sed把百分号去掉然后再和90做数值比较。这个脚本可以放到crontab里定时执行实现每天固定时间的自动巡检。8.3 定时任务注意事项配置croncrontab -e添加一行0 2 * * * /usr/local/bin/syscheck.sh这样每天凌晨2点执行一次巡检。放在凌晨是为了避开业务高峰期避免脚本本身的系统资源占用影响业务。我的体会是这类巡检脚本不需要很复杂关键是能把高频检查项固化下来。真遇到问题的时候先跑一遍巡检脚本拿到整体状态再针对异常项深入排查效率远比一条条敲命令高得多。9. 一些值得长期坚持的习惯实操多了以后我发现真正拉开效率差距的不是某个神级技巧而是一系列小习惯。第一命令先想清楚再执行尤其是删除、格式化、覆盖这类不可逆操作。Linux命令一旦执行没有“撤销”按键。我会在关键命令前先跑一遍dry run或先echo打印命令本身确认无误再真正执行。第二每学到一条新命令随手记下适用场景和注意事项而不是只记命令拼写。命令拼写可以查手册使用场景和踩过的坑往往查不到。我自己维护了一个Markdown笔记按“文本处理”“进程管理”“网络排查”分类遇到问题先翻笔记已经解决过的问题不再需要重新排查一遍。第三保持“验证”的习惯。任何修改配置的操作执行后都要用查看类命令确认生效。改完fstab跑mount -a改完nginx配置kill -HUP后再用curl验证响应改完防火墙规则后用ss或telnet验证端口仍然正常。验证这一步看似多余实际上能挡住大部分低级错误。第四日志和输出要留痕。日常排查的现场输出如果数据量大不要只靠肉眼翻养成输出到文件再分析的习惯。很多问题需要对比前后变化留有原始输出就是留下了对比的基准线。第五模板化。像巡检脚本这种重复性工作一定要模板化、脚本化。人总会疲劳脚本不会。把判断逻辑写进脚本既统一了检查口径也避免了临场手忙脚乱。