這期寫 grep我估計是這個系列里被催更最狠的一篇也是日常高頻到幾乎每個 Linux 從業(yè)者都繞不開的一個命令。grep 全稱是 Global Regular Expression Print翻譯成人話就是從一堆文本里按規(guī)則抓內(nèi)容然后把命中的行或者命中部分打出來。查日志、查進程、查配置、查硬件信息、刷面試題到處都有它。這篇我把 grep 拆成三塊來講參數(shù)怎么用、正則怎么寫、以及實戰(zhàn)中那些容易翻車的組合姿勢。新手可以從頭到尾敲一遍老手直接跳到自己感興趣的部分重點看看第 3 節(jié)和第 5 節(jié)里那些“你以為你懂了實際一跑就出問題”的細節(jié)。1. 先搞清楚 grep 到底能干什么1.1 一個命令撐起一半的查錯場景我經(jīng)常跟新同事說Linux 下排查問題80% 的時間都在查文本查文本的 80% 又在用 grep。你登錄一臺服務器后干的第一件事是什么多半是打開日志找異常關鍵字或者ps -ef | grep看進程在不在、跑沒跑起來。這些動作背后都是同一個核心操作從一個文本流里篩出你想要的信息。grep 之所以重要倒不是因為它的實現(xiàn)有多復雜而是因為它遵守了 Unix 哲學里“一個程序干一件事干到極致”的原則。它不關心輸入來自文件、來自標準輸出還是來自其他命令的管道只要是文本它就能幫你過濾、提取、統(tǒng)計。這看起來很簡單但配合上管道符這種組合方式它就變成了整個 Shell 生態(tài)里的“篩子”前一個命令輸出的結果在它那兒過一遍剩下的就是你要的答案。另外grep 在所有發(fā)行版和幾乎所有 Unix 系統(tǒng)里都是默認自帶的。不管你是 Ubuntu、CentOS、Debian 還是國產(chǎn)化系統(tǒng)也不管是物理機、虛擬機還是容器里只要有 Shell基本就有 grep。這意味著它不存在“環(huán)境沒有裝”的問題也不用擔心換一套環(huán)境后發(fā)現(xiàn)命令消失了。1.2 grep 的三種使用姿勢grep 的基本形態(tài)我從實際使用中總結了三種場景你可以對著理解一下第一種是直接搜文件內(nèi)容比如grep error /var/log/messages。它會把文件里所有包含 error 的行打印到終端這是最經(jīng)典的用法。第二種是搜標準輸入或管道傳過來的內(nèi)容比如ps -ef | grep java。這里 grep 接收的是前一個命令的輸出而不是某個具體文件。這種方式在我們看進程、看網(wǎng)絡連接、看磁盤信息時極其常見也是這篇文章后面大量實戰(zhàn)示例的基礎。第三種是遞歸搜目錄比如grep -r TODO src/。它會把目錄下所有文件都翻一遍把所有出現(xiàn)過 TODO 的文件和行都列出來。這個用法在項目代碼里找遺留標記、找硬編碼配置時非常省事。這三種姿勢覆蓋了絕大多數(shù)日常場景。記住一點grep 最擅長的是“從一堆東西里挑出你關心的那部分”它不擅長做復雜的文本替換和流式編輯那是 sed 和 awk 的活。搞清楚邊界用起來就順手了。2. 核心參數(shù)逐個拆解這一張表就夠用2.1 必會參數(shù)速查與手把手示例grep 的參數(shù)不算多但每個都挺常用。我按從高頻到低頻的順序整理了一份表格后面再挨個演示。參數(shù)作用典型場景-i忽略大小寫匹配 nvidia、NVIDIA、Nvidia 等不同寫法-v反向匹配取不包含模式的行過濾注釋行、排除 grep 自身進程-n顯示行號日志定位時知道具體在哪一行-c統(tǒng)計命中的行數(shù)統(tǒng)計某關鍵字在文件里出現(xiàn)多少行-l只列出包含匹配內(nèi)容的文件名在目錄里快速找出哪些文件命中了-L只列出不包含匹配內(nèi)容的文件名找出沒命中模式的文件-o只輸出匹配到的部分不輸出整行精確提取 IP、時間戳等片段-r / -R遞歸搜索目錄在項目目錄里全局查找關鍵字-w精確匹配整個單詞搜 error 時避免匹配 errors、error404-x整行精確匹配精確匹配某行內(nèi)容-E使用擴展正則使用 |、、? 等正則語法-A 數(shù)字同時顯示匹配行的后 N 行看異常日志時關注堆棧下方內(nèi)容-B 數(shù)字同時顯示匹配行的前 N 行看異常發(fā)生前上下文-C 數(shù)字同時顯示匹配行前后各 N 行一次看全上下文--include只搜索指定類型文件只搜.log、.conf、*.java--exclude排除指定類型文件跳過.tmp、.bak 等文件--exclude-dir排除某些目錄跳過 node_modules、.git 等目錄--colorauto自動高亮匹配內(nèi)容終端里直觀看到命中片段-q靜默模式只要結果狀態(tài)腳本里做判斷用-I忽略二進制文件避免日志目錄里出現(xiàn) Binary file matches我一個個舉例子。-i這個參數(shù)在查硬件信息和日志的時候救命。比如顯卡型號lspci | grep -i nvidia就能同時匹配 NVIDIA、nvidia、Nvidia你不需要去猜設備廠商在輸出里到底用了什么大小寫。-v用得也特別多。查進程的時候ps -ef | grep java會把grep java本身也撈出來這時候后面接一個| grep -v grep就能把這一行噪音過濾掉。后面第 5 節(jié)我會詳細說這個坑。-n適合排查日志。你搜索一個異常關鍵字光知道哪一行命中了還不夠還得知道它在文件里的第幾行這樣后續(xù)你想用 sed 之類的工具進一步處理就很方便。-o是提取型參數(shù)是我個人最喜歡也最容易被人忽略的一個。它的意思是只輸出匹配到的部分而不是整行。比如你想提取日志里所有的 IP 地址grep -oE ([0-9]{1,3}\.){3}[0-9]{1,3} app.log就能把所有 IP 一個個摘出來配合 wc -l 能統(tǒng)計出現(xiàn)次數(shù)配合 sort | uniq -c 能統(tǒng)計去重后的頻次。2.2 參數(shù)組合拳從日志里定位一次線上故障單個參數(shù)好理解真正體現(xiàn) grep 實力的是組合使用。我虛擬一個場景線上 Java 服務報 OOM日志文件幾百兆你不可能打開編輯器慢慢翻。第一步先找到異常出現(xiàn)的行號grep -n OutOfMemoryError app.log。如果幾百兆文件里面匹配的行很多可以再加 head 或 tail 控制范圍或者先定位首次報錯范圍。第二步看異常上下文grep -A 30 -B 5 OutOfMemoryError app.log。-A 30 表示把報錯后面 30 行堆棧打出來-B 5 表示把報錯前 5 行也打出來這樣你能看到報錯觸發(fā)前最后一次業(yè)務操作是什么以及堆棧里具體是哪個類哪一行崩了。第三步如果你想看整個文件里 OOM 出現(xiàn)了多少次可以用grep -c OutOfMemoryError app.log。這里要注意-c 統(tǒng)計的是“命中的行數(shù)”如果一行里出現(xiàn)多次 OOM它也只算一行。想精確到“出現(xiàn)了多少次”應該用grep -o OutOfMemoryError app.log | wc -l。第四步如果你懷疑某個業(yè)務接口引發(fā)的可以先把所有包含該接口路徑的日志行抓出來再做反向過濾排除健康檢查、心跳檢測等噪音grep 支付回調(diào) app.log | grep -v health | tail -50。這個組合過程其實就是 grep 在真實運維里的典型用法先擴大范圍再逐步縮小最后鎖定目標。3. 熱詞里那些 grep 組合命令到底怎么用3.1 ps -ef | grep java 查看啟動時間這里有個大坑網(wǎng)上搜“ps -ef | grep java 查看啟動時間”這個用法的人非常多因為大家確實想知道某個 Java 進程是什么時候啟動的是不是被人重啟過。但這里有一個特別容易誤導新手的地方。ps -ef 輸出里確實有一列叫 STIME表示進程啟動時間但它的精度根本不是時分秒級別而是分段的如果進程是今天啟動的顯示 HH:MM如果是今年啟動但超過了一天顯示“月日”比如 Sep08如果是更早跨了年份的直接顯示年份。所以你真想精確到秒級去看啟動時間靠 ps -ef 是不行的。我自己的做法是分兩種需求處理。如果只是想看格式化的啟動時間用ps -eo pid,lstart,cmd | grep javalstart 會輸出完整的啟動時間精確到秒。如果你想看這個進程已經(jīng)跑了多久用ps -eo pid,etime,cmd | grep javaetime 會輸出類似 02-03:15:40 這種格式表示已運行 2 天 3 小時 15 分 40 秒。這是面試里一個高頻率考點ps -ef 里的 STIME 和 ps -lstart 到底有什么區(qū)別。我建議每個用 Linux 干活的人都把這兩個命令的實際輸出跑一遍記住差異下次就不會在緊要關頭拿一個只有時分秒或只有日期的時間去跟別人對線了。3.2 lspci | grep -i nvidia、ps aux | grep -i openclaw 這類查詢套路lspci | grep -i nvidia這個組合本質(zhì)上是在查硬件設備信息。lspci 把機器上所有 PCI 總線上的設備列出來網(wǎng)卡、聲卡、顯卡、USB 控制器都在里面輸出內(nèi)容非常長直接用眼睛找很費勁。這時候 grep 就派上用場了-i nvidia是為了容錯畢竟不同機器上顯卡廠商在 lspci 輸出里的大小寫格式不完全一樣。同樣的套路還能用在很多地方。查 CPU 型號用lscpu | grep -i model name查內(nèi)存用free -h查磁盤掛載用lsblk | grep -i disk查網(wǎng)卡 IP 用ip addr | grep -i inet 。大家不妨把這個思路記下來凡是輸出結果長得比較長的命令都可以加個管道接 grep 做過濾這是 Linux 運維里的高頻肌肉記憶。ps aux | grep -i openclaw這個組合跟查硬件一樣屬于“進程查詢套路”。ps aux 會列出系統(tǒng)所有進程以及它們的用戶、CPU、內(nèi)存占用、終端、啟動時間、命令行等字段。這里要說明一下 ps aux 和 ps -ef 的區(qū)別aux 是傳統(tǒng) BSD 風格輸出里帶 %CPU、%MEM 這一列適合看資源占用-ef 是 SysV 風格帶 PPID 父進程 ID適合梳理進程父子關系。兩者日常都會用到按下需求選。grep -i openclaw的意思是不區(qū)分大小寫地查找所有名字里帶 openclaw 的進程。我自己查服務存活時最常用的就是類似寫法ps aux | grep -i java | grep -v grep。如果有人跟你說某個服務進程不見了你先跑這幾步基本就能判斷出進程到底在不在、還在不在正常占資源。3.3 ps -e | grep apt 然后 kill這個操作請千萬停手熱詞里有一條“通過 ps -e | grep apt 列出所有帶有 apt 字樣的進程然后用 kill 命令將其一一殺死”我猜提這個問題的人大概率是遇到了 apt 卡死或 dpkg 鎖的問題想用暴力方式解開。這里我必須非常認真地提醒一句這個操作千萬要謹慎盲盒式地 kill 掉所有含 apt 的進程很容易把系統(tǒng)搞出更大的麻煩。先說命令本身的原理。ps -e 等價于 ps -A列出系統(tǒng)上所有進程不含輔助信息。接了 grep apt 之后所有名字或者命令行里包含 apt 字符串的進程都會被撈出來。這包括你正在跑的 apt-get、apt還包括后臺的 aptd、apt-check以及一些系統(tǒng)組件里命令行參數(shù)恰好帶 apt 的進程。更尷尬的是grep 本身也會匹配到自己。如果你把這些 PID 全部 kill 掉最直接的后果是打斷正在進行的 apt 事務。apt 在安裝軟件時是有事務狀態(tài)的如果中途被殺很可能留下 dpkg 中斷的狀態(tài)下次再執(zhí)行安裝命令就會提示 dpkg was interrupted必須手動修復才能繼續(xù)。如果是 aptd 之類的后臺服務被殺了系統(tǒng)自動更新機制也會被連帶影響安全補丁錯過的后果在某些場景下比你現(xiàn)在想解的鎖還嚴重。那遇到 apt 卡死到底該怎么辦我的經(jīng)驗是分兩步。第一步先查看是誰鎖住了 dpkg 相關文件lsof /var/lib/dpkg/lock-frontend或者ps -ef | grep -E apt|dpkg看清楚是哪個進程在讀、在等。第二步如果確認是一個十幾分鐘沒動過的 apt-get 進程就針對它的 PID 單獨 kill或者用kill -9 PID收尾。真想按名字殺可以用pkill -x apt-get或pkill -x apt-x 表示精確匹配整個進程名不會誤殺 aptd。一句話總結grep 負責找出候選進程但“殺不殺”和“怎么殺”是你自己做的決策別讓一個篩子替你做全部判斷。4. 正則表達式grep 的靈魂學會這幾招就夠用4.1 基礎正則與擴展正則到底差在哪grep 之所以強大很大程度上歸功于它自帶正則表達式引擎。很多人以為 grep 就是關鍵字匹配其實它的模式可以是正則能匹配一類文本而不是一個字面字符串。grep 默認用的是基礎正則語法也叫 BRE。BRE 里的元字符只有^、$、.、*、[]這幾個。比如^error表示行首以 error 開頭error$表示行尾是 errorerr.表示 err 后面跟任意一個字符。問題在于BRE 對|、、?、()、{}這些更高級的語法默認不認可需要轉義才能用。比如你要在同一行里匹配 error 或 warningBRE 下得寫成grep error\|warning。這寫起來太別扭了所以我強烈建議你直接加-E參數(shù)使用擴展正則 ERE。擴展正則是正則本身更自然的一套語法加號、問號、豎線、括號、花括號都能直接用不需要轉義。我個人習慣是所有稍微復雜一點的匹配都上-E把基礎正則留給簡單場景。別小看這一點它能讓你的命令讀起來爽很多grep -E error|warning app.log比grep error\|warning app.log可讀性高一個量級。4.2 實戰(zhàn)正則抓 IP、抓時間戳、過濾空行我選幾個日常出鏡率非常高的正則寫法大家可以直接拿去用。抓 IP 地址grep -oE ([0-9]{1,3}\.){3}[0-9]{1,3} app.log。這里用到了擴展正則里的{m,n}重復計數(shù)[0-9]{1,3}表示匹配 1 到 3 位數(shù)字后面跟一個點重復 3 次最后再跟一段 1 到 3 位數(shù)字。實際場景里如果你只要公網(wǎng) IP可以對結果再過濾一下或者后續(xù)用 awk 判斷網(wǎng)段。抓時間戳日志里最常見的格式是2025-01-06 14:30:25正則可以寫成grep -oE [0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2} app.log。這個寫法很直觀年月日時分秒各占幾個數(shù)字中間用連字符和冒號分隔一眼就能看出來。過濾空行和注釋行看配置文件時我經(jīng)常用grep -Ev ^\s*$|^\s*# /etc/nginx/nginx.conf。-E 支持擴展正則^\s*$匹配全是空白的行^\s*#匹配以 # 開頭的注釋行前面可能還有空格-v 表示反向過濾。跑完之后配置文件去掉注釋空行只剩有效配置閱讀體驗直線上升。還有一個細節(jié)很實用-o配上正則后提取能力非常強。比如你想統(tǒng)計某日志里 5 開頭的狀態(tài)碼有哪些grep -oE status:5[0-9]{2} access.log | sort | uniq -c | sort -rn幾秒鐘就能得到一張頻率表排查故障時效率極高。5. 常見問題與排查技巧實錄5.1 為什么 grep 結果里老是出現(xiàn)命令自己這是每個 Linux 新手都會疑惑的問題。你執(zhí)行ps -ef | grep java結果里總會多出一行類似grep --colorauto java的進程。原因是 grep 命令在匹配時它自己的命令行參數(shù)里包含 java 這個字符串ps 輸出的內(nèi)容里自然就帶上了于是它也被自己篩出來了。解決辦法有幾種。最樸素的是在后面加一個| grep -v grep把名字里含 grep 的那一行丟掉。我見過很多老手這么干雖然多打了一段但直觀可靠。另一個更優(yōu)雅的寫法是ps -ef | grep [j]ava利用正則字符集匹配[j]去匹配字母 j而 grep 進程自己的命令行里是grep [j]ava中間的[j]并不會被[j]這個模式匹配到所以自然就不會列出自己。這個技巧在面試里偶爾會被問到原理其實很簡單記得住就行。如果只是查進程是否存在我更推薦直接上pgrep -f java。pgrep 本身不會匹配自己-f 參數(shù)支持匹配完整命令行用起來干凈利落。查完還能配合pgrep -f java | xargs ps -fp展示詳細內(nèi)容。5.2 grep 搜索卡住不動多半是沒限制范圍新手最喜歡干的一件事就是grep -r 關鍵字 /想全盤搜一遍結果命令跑半天跑不完。這其實是 grep 最常見的翻車姿勢。系統(tǒng)根目錄下有大量的二進制文件、偽文件系統(tǒng)目錄/proc、/sys、軟鏈接循環(huán)grep 引擎會在里面浪費海量時間。正規(guī)做法是給搜索范圍設置邊界。一種是用--include只搜指定類型文件grep -rn 關鍵字 /data/apps --include*.log另一種是用--exclude-dir排除大目錄grep -rn 關鍵字 / --exclude-dir{proc,sys,dev,run,tmp}。我自己的習慣是能明確范圍就先明確范圍別動不動就全盤搜如果確實要搜全盤必須加上-I忽略二進制文件并且排除關鍵虛擬目錄。如果你發(fā)現(xiàn) grep 卡住了可以先按 CtrlC 打斷確認一下是不是查了 /proc 或 /sys 這種動態(tài)目錄。這兩個目錄內(nèi)容不是真實磁盤文件而是內(nèi)核接口的實時映射數(shù)據(jù)量雖然不大但語義特殊沒必要用它做關鍵字搜索。5.3 統(tǒng)計關鍵字次數(shù)時一個經(jīng)典的語義陷阱我面試人的時候經(jīng)常問一個問題怎么統(tǒng)計一個日志文件里 error 這個單詞出現(xiàn)了多少次有相當一部分人回答grep -c error app.log。這個答案對了一半但存在一個陷阱。grep -c統(tǒng)計的是“匹配到的行數(shù)”不是“匹配到的次數(shù)”。如果某一行里同時出現(xiàn)了 5 個 errorgrep -c只會計 1。所以在真正要算“出現(xiàn)多少次”的場景里正確姿勢是grep -o error app.log | wc -l。-o 把每次匹配到的 error 單獨摘出來輸出一行wc -l 統(tǒng)計總行數(shù)這才是真正的出現(xiàn)次數(shù)。這兩個口徑在日志量小的時候差距不大但在分析大日志時差異會很顯著。大家根據(jù)自己需求選想知道多少行出了錯用 grep -c想知道總的報錯頻次用 grep -o | wc -l。6. 一些關于 grep 的個人習慣和補充技巧最后分享幾個我用 grep 時積累的小習慣沒有系統(tǒng)性但每個都是實戰(zhàn)中磨出來的。第一個是終端高亮。現(xiàn)在很多發(fā)行版默認給 grep 配了--colorauto如果你用的系統(tǒng)沒有建議在 shell 配置文件里加一個別名alias grepgrep --colorauto。別看只是加上顏色在日志里找關鍵字時視覺引導作用非常大能省不少眼睛。注意別直接用環(huán)境變量 GREP_OPTIONS那個已經(jīng)不建議使用了用 alias 是最穩(wěn)妥的方案。第二個是結合 tail -f 做實時跟蹤。調(diào)試日志時我經(jīng)常開兩個終端一個跑服務一個執(zhí)行tail -f app.log | grep --line-buffered ERROR。關鍵點在于--line-buffered參數(shù)它告訴 grep 每讀到一行就立刻輸出而不是攢一批再輸出。缺了這個參數(shù)你可能會等很久看不到實時日志還以為是系統(tǒng)卡了。這是非常實用的一個小細節(jié)。第三個是用 grep 從一個命令結果里快速提取關鍵信息后再接 awk、sort、uniq 做二次加工。比如統(tǒng)計訪問日志里哪個 IP 請求最多grep -Eo ([0-9]{1,3}\.){3}[0-9]{1,3} access.log | sort | uniq -c | sort -rn | head -10。這一條鏈路上grep 負責提取剩下的管道命令負責匯總排序。學會這種“流水線思維”很多繁瑣的統(tǒng)計任務幾句話就能解決。第四個建議是如果你在做大規(guī)模代碼搜索或日志搜索時感覺 grep 越來越力不從心可以去了解一下 ripgrep 這個現(xiàn)代替代品。它搜大目錄的速度比 grep 快很多還天然支持 Git 忽略規(guī)則。但說到底grep 依然是所有 Linux 系統(tǒng)默認自帶、任何環(huán)境都能用的底線工具你花時間學它的每一分功夫都不會浪費。寫到這里突然想到一個場景有次凌晨兩點我被叫起來查問題日志文件里全是各種無意義的基礎日志一片白噪聲。我用了grep -v health app.log | grep ERROR -B 1 -A 10 | tail -80十幾分鐘鎖定了根因。那種在混亂里用一把趁手的篩子精準撈到目標的感覺就是我一直建議大家把基礎命令訓練到肌肉記憶的原因。grep 不難難的是你對它的每一個參數(shù)和正則都有足夠清晰的邊界感。把這篇文章里的命令挨個敲一遍你會發(fā)現(xiàn)接下來的巡檢、排障、寫腳本都會順暢非常多。