grep命令实战详解：从文本匹配到日志排查的Linux利器

1. 先从最朴素的场景说起grep这名字可能是我日常命令行里用得最多的一个词。排查日志、过滤进程、匹配配置文件、统计接口返回几乎每天都要和它打交道。有人调侃说Linux运维有三宝grep、sed、awk。sed和awk相对复杂但grep是门槛最低、见效最快的一个学会它基本等于给命令行装了一双眼睛。这篇文章不讲什么高深理论纯粹是把grep的常用用法、关键参数、实战场景和踩坑记录整理在一起。文中所有示例我都实测过直接复制到终端里就能看到效果。适合刚接触Linux命令行的新手也适合有一定经验但有些参数总记不牢的人。搜索文本、过滤管道输出、在脚本里做条件判断这些高频场景都会覆盖到。有一点先说明白现在大部分Linux发行版里的grep其实都是GNU grep老教程里提到的egrep、fgrep这两个名字它内部已经通过-E和-F参数统一支持了。优先习惯用grep -E和grep -F不要再去写egrep或fgrep避免在别的系统上遇到命令不存在的情况。2. 理解grep的核心逻辑匹配而不是“找”很多人用grep的时候有个误区以为它在做“搜索关键词”这件事。实际上grep的工作方式是按行匹配——读入文件的每一行内容如果这一行中存在符合你指定条件的文本就把整行输出出来。它是对“行”做筛选不是对“词”做定位这一点决定了后面所有参数的设计逻辑。2.1 一次匹配一万次grep也能“读心”grep的匹配规则默认用的是基本正则表达式。听起来有点唬人但用它来搜索普通字符串时基本不需要关心正则语法直接写要查询的文字就行。最基本的用法是grep error app.log这行命令会把app.log里包含error这个字符串的所有行打印出来。注意是“包含”不是“等于”。如果一行内容是error_count10或者Failed to parse error message它同样会被匹配到。如果只想匹配完整的单词不想让error去匹配error_count里的部分就加-w参数grep -w error app.log-w表示word要求匹配的文本两边必须是单词边界简单的说就是不匹配单词的一部分。比如搜索cat时-w模式下concatenate就不会被误匹配只匹配独立的cat单词。这个技巧排查代码里某个变量名时特别实用。2.2 相关热搜词里的高频真相“-i”忽略大小写的魔力热搜词里有grep -i amd这类用法-i的意思就是ignore case忽略大小写。为什么要单独强调它因为日志里的文本大小写非常不统一error可能写成Error、ERROR、甚至eRrOr。不带-i去搜会有大量漏网。grep -i error app.log这条命令把大小写完全忽略所有包含error变体的行都会被输出。日常排查日志时我基本默认带上-i只有明确区分大小写的时候才去掉它。2.3 目录不是一个文件搜索整个项目用“-r”初学者最容易踩的坑之一就是对目录直接使用grep。grep keyword /etc/这种命令会直接报错因为grep默认只接收文件作为输入参数。想在目录里递归搜索必须加-r参数grep -r error /var/log/-r会递归进入目录下的所有子目录逐个文件扫描匹配。加上-l参数还能只显示包含匹配内容的文件名批量确认哪些文件里有关键词时非常省事grep -rl error /var/log/搜索结果只输出文件名不输出具体匹配行。排查“这段配置到底写在哪了”这类问题一条命令就能定位到文件。3. 日常最高频的几个grep参数这一部分是全文最实用的内容。我按使用频率从高到低把日常工作中真正用得上的参数逐个讲一遍配实际例子。每个参数都有特定场景大家可以按需查阅。3.1 管道过滤从海量输出里捞出关键行grep最经典的搭档是管道符|。前一个命令的输出通过管道传给grepgrep再做过滤。排查端口、查进程、看内核模块全是这个套路ps aux | grep javasystemctl status sshd | grep runningdmesg | grep -i usb这种用法不需要额外参数grep会自动从标准输入读取数据流。写脚本、做监控的时候管道过滤几乎是标配动作。3.2 反向匹配“-v”排除干扰项留下干净的输出-v的作用和正常匹配正好相反它输出不包含指定内容的所有行。排除注释、排除空行、排除某个不关心的进程都用得上。grep -v ^# /etc/ssh/sshd_config这条命令把sshd_config里的注释行全部剔除只留下实际的配置项。配置文件几百行全是注释想看真正生效的配置-v是最快的办法。还有更进阶的用法把-v和另一个管道结合过滤掉自己那个grep进程。查进程时经常出现一个现象ps aux | grep ssh结果里会带一条grep ssh自己的记录因为它也包含ssh这几个字符。有人习惯写ps aux | grep ssh | grep -v grep来排除其实还有个更干净的办法ps aux | grep [s]sh[s]sh这个写法利用正则的字符集特性既能匹配到ssh又不会匹配到grep自身的命令行。因为grep的命令行参数里写的是[s]sh字面上不是ssh。这个小技巧是排查进程时最实用的招数之一。3.3 显示行号“-n”排查日志先定位再定位-n会把匹配内容所在的行号一并输出。这个参数本身很简单但效果非常直观尤其是在日志文件、配置文件里定位问题时先拿到行号才能精准跳转。grep -n timeout /etc/nginx/nginx.conf输出格式类似23: worker_connections 1024;前面的数字就是行号。拿到行号之后用sed -n 23p nginx.conf查看具体行或者直接用vim打开跳到指定行效率比肉眼扫全文高一个量级。3.4 只输出匹配的部分“-o”提取而不是整行默认情况下grep输出整行。但有些场景只关心匹配内容本身比如从日志里抓出一段IP地址或者从一个长串文本中提取某个编号。这时候用-o。echo request_id: 8bf3a92c, latency: 120ms | grep -o [0-9a-f]\{8\}输出结果只包含8bf3a92c不会连累整行的其他文字。配合正则表达式做字段提取-o可以说是轻量数据清洗工具。3.5 统计数量“-c”不要重复数数-c用来统计匹配的总行数而不是输出具体匹配内容。排查“某个异常出现了多少次”这类问题一条命令到位grep -c OutOfMemory /var/log/app.log“有多少行包含这个关键字、这个错误重复出现的频率是多少”都用得上。注意-c统计的是行数一行里出现多次也按一行算和-o的语义不一样两者要区分清楚。3.6 加上下文“-A、-B、-C”看异常光看一行是远远不够的排查日志时经常遇到一个问题匹配到的报错行只有一行但它触发的原因可能在前几行或者引发连锁反应在后几行。单看这一行根本判断不了全貌。-A显示匹配行之后的N行-B显示匹配行之前的N行-C同时显示前后各N行grep -B 5 java.lang.NullPointerException app.loggrep -A 2 Exception app.loggrep -C 3 timeout app.log实际使用中-C 5最常用前后各看五行错误现场基本就能还原。一般情况下我默认用-C只有确定要看的内容分布时再用-A或-B。3.7 文件名过滤“--include”搜索范围越精确越好配合-r递归搜索时--include可以限定只扫指定类型的文件。整套代码库动辄几千个文件只想搜XML配置里的关键字不想看Java源码就可以这样grep -r timeout --include*.xml /opt/app/conf/grep -r -i error --include*.log /var/log/这个参数在代码级排查里很实用先限定文件类型再搜关键字输出结果干净利落不会混进来几百个无关文件。3.8 匹配“或”逻辑正则基础中的基础基本正则里|表示“或者”。匹配时有多个候选词比如要同时找error和warning可以用扩展正则grep -E error|warning app.log-E就是扩展正则的意思。基础正则里|默认不生效很多新手在基础正则下写了error|warning发现完全没匹配这中间的坑就在这里。用-E之后多个关键词用|隔开即可。类似的还有^行首匹配、$行尾匹配的组合grep -E ^ERROR|FATAL$ app.log搜索以ERROR开头或者以FATAL结尾的行。这类进阶用法并不难但需要先理解正则的几个基础元字符再配合-E使用。4. 实战现场跑通一次完整的日志排查上面讲了单个参数现在串起来跑一个比较完整的排查过程。假设线上应用日志文件路径为/var/log/app/app.log用户反馈接口变慢我来排查耗时异常的请求。4.1 第一轮全量搜索耗时记录业务日志里每行记录包含请求路径和耗时结构类似2024-06-01 10:00:01 INFO request/api/order/detail, cost2134ms 2024-06-01 10:00:05 WARN request/api/user/info, cost1850ms先找出耗时超过1秒的请求grep cost1[0-9][0-9][0-9]ms /var/log/app/app.log这里用的是正则字符集匹配1000到1999之间的耗时。但这种方法写起来不够灵活耗时超过2秒的又是另一种匹配方式。实际排查时我一般更倾向分段计数grep -c cost[2-9][0-9][0-9][0-9]ms /var/log/app/app.log统计耗时2秒以上的请求数量先判断问题规模。4.2 第二轮结合时间窗口过滤日志太大只关心最近一小时的数据。先用grep 2024-06-01 09:把时间窗口切出来再通过管道继续过滤grep 2024-06-01 09: /var/log/app/app.log | grep -c cost或者一步到位同时匹配时间和耗时条件grep -E 2024-06-01 09:.*cost /var/log/app/app.log.*在正则里代表任意字符串把两个条件连起来。前者用管道做两步过滤后者用单条正则做组合匹配两种写法各有适用场景。管道写法更容易读单条写法更高效文件特别大的时候性能差异明显。4.3 第三轮定位到具体异常源头确认问题后想打印出错现场用-C把上下文带出来grep -C 3 HTTP 500 /var/log/app/app.log | tail -n 50tail -n 50只取最后50行防止输出太多刷屏。这种“先全局计数、再按时间过滤、最后看上下文”的思路是日志排查最通用的三个步骤。一次性能定位到具体是哪个接口慢、慢在什么环节。4.4 热词里那个“lspci | grep -i amd 无反应”的问题热搜词里有一条lspci | grep -i amd 无反应这个现象很多人遇到过。grep -i amd无反应大概率不是命令挂了而是根本没有匹配到内容。grep在没有任何匹配时退出码是1但终端里不会显示任何提示输出看起来就像“卡住了一样”。排查思路是先去掉grep单独看原始输出lspci确认结果里有没有amd这个关键词。如果原始输出为空说明问题出在lspci命令本身可能是系统没有lspci工具或者需要root权限也可能是显卡设备名里压根不包含amd字样。再用which lspcilspci | grep -i vga这两条命令做定位。这种排查思路比盯着grep -i amd反复试要有用得多。grep本身不会“失灵”它没有输出基本等于没有匹配到内容先把这条基本逻辑刻在脑子里很多“命令失灵”的疑惑都会迎刃而解。5. 让grep为你上班Shell脚本里的常见用法grep不只用来在命令行里做交互过滤。放进Shell脚本里它可以作为判断条件、信息提取器、数据统计工具扮演很多不同的角色。这里挑几个最典型的场景附可直接抄的写法。5.1 用退出码判断“有没有”grep的退出码含义很明确0表示匹配到内容1表示没匹配到2表示执行出错比如文件不存在。脚本里常用这个特性做条件分支if echo $output | grep -q success; then echo 任务执行成功 else echo 任务可能失败 fi-q是quiet模式只返回退出码不输出任何内容。这个参数特别适合脚本场景因为脚本根本不需要打印匹配的实际文本只需要知道结果“有还是无”。判断某个服务是否在运行、某次执行是否成功都可以这样if ps aux | grep -q [j]ava; then echo Java进程存在 fi5.2 从命令输出中提取关键参数利用-o加正则可以从一大段输出中只捞需要的内容。比如从磁盘使用率里提取百分比数值usage$(df -h | grep /data | grep -o [0-9]\%) echo 磁盘使用率: $usage从Linux内核版本信息里提取主版本号kernel_version$(uname -r | grep -o ^[0-9]\\.[0-9]\)脚本自动化里做信息提取grep配合-o和正则的效率比用sed、awk更直观。前提是输出格式稳定一旦格式变化需要及时调整正则。5.3 数据统计利器grep和wc的组合grep输出的每一行是一条匹配记录用wc -l统计行数就能得到匹配次数count$(grep -c Exception /var/log/app/app.log)当-c不能满足需求时也可以用grep -o配合wc -l统计一行里多次出现的单词数量grep -o error /var/log/app/app.log | wc -l两者语义区别容易混淆-c统计行数一行里出现两个error只算一条-o配合wc -l统计实际出现的次数一行里出现两个error就算两条。监控告警里要看错误“次数”用第二种写法更准确。5.4 实时监控tail -f和grep的联动排查线上日志最常用的组合是tail -f加grep实时看新写入的日志里有没有目标关键字tail -f /var/log/app/app.log | grep --line-buffered error这里多加了一个--line-buffered参数。原因是grep在管道里默认使用块缓冲输出会攒一批再一次性打印。实时看日志时这个缓冲会让内容延迟出现加上--line-buffered强制按行刷新日志一出就能立刻看到。这个细节很容易被忽略但是实时监控场景下非常关键。6. 正则表达式的核心基础看懂这10个符号就够了前面提到正则也有人看到正则就头大。实际上日常排查问题用到的正则就那么几个元字符完全不需要背整张表。我把最常用的整理在下面大家用的时候对照即可。元字符含义匹配示例.任意单个字符c.t可匹配cat、cut*前一个字符重复0次或多次ab*c可匹配ac、abc、abbc^行首^ERROR只匹配以ERROR开头的行$行尾done$只匹配以done结尾的行[abc]匹配a、b、c中的任意一个[123]可匹配1、2或3[^abc]不匹配a、b、c中的任意字符[^0-9]匹配非数字字符[a-z]匹配a到z范围内的任意字符[0-9]匹配数字|基础正则或逻辑cat|dog匹配cat或dog\基础正则前一个字符重复1次或多次[0-9]\匹配一位或多位数字\(\)基础正则分组\(ab\)\匹配ab、abab这里有一个很磨人的概念需要特别说明在GNU grep默认的基础正则模式下、?、{}、|、()这些符号前面都要加反斜杠转义才能生效。比如匹配一个或多个数字要用[0-9]\而不是[0-9]。后者在基础正则下会被当作普通字符完全匹配不到想要的内容。有人觉得麻烦于是更喜欢用-E参数打开扩展正则。扩展正则模式下、?、|、()直接写原字符即可不用转义写法更自然grep -E [0-9] app.log所以我的建议很明确写稍微复杂一点的匹配时一律用grep -E。一是写法更简洁二是不容易踩转义坑。只有匹配纯字符串时可以不考虑正则符号直接裸写。7. 几个高频场景的组合命令速查表整理一份平时能用得上的速查表。每条都是一段独立命令可以直接照抄使用。需求命令排除注释和空行查看配置grep -v ^#|^$ nginx.conf递归搜索日志中的错误只显示文件名grep -rl ERROR /var/log/实时跟踪日志并按关键字过滤tail -f app.log | grep --line-buffered timeout统计某个异常出现的实际次数grep -o OutOfMemory app.log | wc -l查看配置文件中生效的端口设置grep ^port /etc/nginx/nginx.conf列出当前用户启动的进程ps aux | grep ^$USER查找目录下所有PHP文件里调用某函数的位置grep -rn functionName --include*.php /var/www/提取IP地址grep -o \([0-9]\{1,3\}\.\)\{3\}[0-9]\{1,3\} app.log最后一条提取IP地址的正则写在了基础正则模式下\{1,3\}表示重复次数。如果觉得这段写法太繁琐改用-E可以直接写成([0-9]{1,3}\.){3}[0-9]{1,3}可读性强很多。8. 常见问题与排查技巧实录这部分内容来自真实的踩坑现场。很多问题不是grep命令本身不会用而是对它的执行逻辑理解不到位。我整理了最常见的几个问题附带排查思路。8.1 为什么grep搜索中文搜不到内容grep匹配的是字节流理论上不管中文英文都能匹配。搜不到中文最常见的原因是文件编码和终端输入编码不一致。文件是GBK编码终端输入的是UTF-8编码输入的中文在文件里根本不存在对应的字节序列。排查方式file app.log查看文件编码格式。如果文件是UTF-8终端也是UTF-8那基本不会出现这个问题。如果确实有编码问题建议直接在grep里写正则匹配中文的范围或者先把文件转码再用标准方式搜索。比较麻烦但方向对了问题就能解。8.2 grep以后输出一堆“Binary file ... matches”看不到具体情况文件中包含特殊字符grep自动判定它是二进制文件于是不打印匹配内容只提示文件名。解决办法是加-a参数强制把二进制文件当文本文件处理grep -a keyword binary.log日志文件被错误判为二进制的情况很多加了-a就能直接查看匹配内容。8.3 CtrlC按了半天没反应grep卡住了文件太大或者匹配内容超级多时grep会长时间不停输出。终端被海量数据刷屏。解决办法是刚开始的时候就限制输出量grep ERROR huge.log | head -n 20先看前20行确认匹配方向正确。排查超大日志文件时我习惯先用head或tail切出文件的段落再对段落做grep比全量扫描快得多。8.4 有时终端输入grep没有反应、按键没回显这种情况一般和grep无关而是终端或者Shell本身的问题。先确认当前Shell环境是否正常执行echo test看有没有回显。如果echo也没反应问题出在终端会话而不是grep。另一种常见原因是grep卡在等待输入——grep没有指定文件参数时会从标准输入读取内容终端会等着用户敲键盘看起来也像“卡住了”。这时候输入几行文本按CtrlD结束输入或者直接按CtrlC中断。8.5 多个文件搜索时文件名和匹配内容混在一起看不清搜索多个文件时grep的默认输出格式是文件名:匹配内容内容多的时候很难分清楚。有两个办法优化grep -H keyword file1 file2-H是强制显示文件名当只有一个文件时为了统一格式也可以用。另一个办法grep --with-filename keyword *.conf输出格式带有文件名的分隔更易读。用--no-filename可以反过来只输出匹配内容不显示文件名。9. 那些藏在细节里的使用心得最后聊几点实际操作中比较有体会的细节这些内容一般文档里不会写但日常使用里非常影响体验。9.1 先理解退出码再谈自动化grep的退出码是个很有价值的特性脚本自动化时用处很大。但大多数人只在交互式终端里用它忽略了退出码的存在。每次grep执行完用echo $?看看退出码能帮你快速确认匹配情况。这个习惯培养起来之后写自动化脚本会顺手很多。9.2 尽量用单引号包住匹配模式命令行里写grep keyword和grep keyword表面看起来差不多实际上区别很大。双引号里如果出现$、反引号、反斜杠Shell会先做变量替换再传给grep。单引号则完全不做任何替换所有字符原样传递。grep $USER file这个会替换成当前用户名再匹配。如果你实际想匹配字符串$USER就必须用单引号grep $USER file正则表达式里的特殊符号很多和Shell特殊符号重叠用单引号包住可以避免绝大多数误替换问题。我的习惯是所有正则表达式一律用单引号只有不需要任何特殊处理时才用双引号。9.3 匹配模式里的空格不要忽略命令写成grep error message file时匹配的内容是两个单词之间有一个空格。文件里的多个空格会被漏匹配。排查时不确定空格数量可以用[[:space:]]或者\替代grep error[[:space:]]\message file[[:space:]]匹配任意空白字符空格、Tab等\表示一个或多个。这样写不会因为数量不定而漏掉内容。9.4 先想清楚你是在筛数据还是在查数据最后一点算是方法论层面。grep本身有两个完全不同的使用场景筛数据和查数据。筛数据是把一个批次的输出做过滤比如查看“CPU使用率超过90%的进程”查数据是定位某一条具体信息比如“找到配置文件的某一行”。两种场景虽然命令完全一样但心态和策略不同。筛数据要看全局先理解整个输出的格式和规模查数据要精确尽早确认关键字的唯一性再用上下文带出完整的现场。我见过很多新手拿着grep反复搜索但结果就是不符合预期。多数时候不是因为命令用错了而是根本没想清楚这个命令该筛什么、不该筛什么。先输出原始数据看一遍再动手过滤是排查一切问题的黄金起点。这篇文章整理到此内容覆盖了grep的基础用法、高频参数、正则基础、Shell脚本实践以及真实踩坑记录。希望读到这里的你能把grep从“一个会用的命令”升级为“一个真正用得好的工具”。