做運維和架構這行時間久了都會有一個感覺日志分析這件事真正的門檻不在命令背得熟不熟而在策略。命令是死的grep、awk、journalctl 就那些參數(shù)任何人花兩周都能背下來但面對一臺故障機器、幾 G 日志文件的時候先看什么、過濾掉什么、統(tǒng)計什么、把哪幾條日志串成一條完整證據(jù)鏈這套東西才是拉開差距的地方。這篇是系列第三篇。前兩篇聊了 Linux 基礎命令和幾個常見服務的日志特征這篇重點放在“策略”兩個字上日志分級怎么定、采集輪轉怎么規(guī)劃、日常排查按什么套路走、告警閾值怎么設置才有意義。文章會按“源頭治理—分析套路—告警響應—踩坑實錄”的順序展開適合正在從新手向資深運維過渡的同學也適合剛接手一套復雜業(yè)務系統(tǒng)的架構師參考。后面所有命令我都基于實際生產(chǎn)環(huán)境驗證過的寫法可以直接抄。1. 日志分析策略的第一步給日志分級并建立排查邊界1.1 日志為什么要有“策略”而不是“搜關鍵詞”很多剛入行的同事問我日志分析不就三個命令嗎t(yī)ail、grep、awk出了問題直接去日志里搜 ERROR 不就行了。理論上沒錯但現(xiàn)實往往是一搜搜出來幾千行而且一大半是無關干擾。我舉一個真實的例子。某天凌晨支付服務報“下單超時”新同事在日志文件里 grep ERROR出來 5000 多行包括各種網(wǎng)絡抖動重試、緩存超時、熔斷降級看得頭皮發(fā)麻。而我接手后做的第一件事是先把排查邊界畫出來時間邊界定在故障前 5 分鐘到故障后 10 分鐘模塊邊界定在支付接口調用鏈級別邊界只看 ERROR 和 FATAL。這么一框真正需要關注的日志就剩一小段幾分鐘就定位到是數(shù)據(jù)庫連接池被慢查詢打滿。這就好比家里接到電話說水管漏水。你不可能把整棟樓的水管都拆開查肯定先問清楚哪個房間、什么時候開始漏、漏得嚴重不嚴重。日志分析的“策略”本質就是這一套先問問題再動手的排查邏輯。沒有策略直接翻日志等于不用索引直接全表掃描運氣好能中運氣不好就淹死在日志海里。那問題來了這個“策略”到底怎么建我的建議是不要等到出故障才想而是提前把日志分級、邊界定義、分析順序這三件事固化下來變成團隊都能遵守的約定。1.2 一套通用的日志分級模型日志分級不是越細越好太細了反而沒人執(zhí)行。20 年下來我認為一套夠用的分級模型只需要四層級別典型內(nèi)容排查時的關注點ERROR / FATAL服務異常、啟動失敗、數(shù)據(jù)庫連接失敗、未捕獲異常優(yōu)先看堆棧和上下文這是故障的主戰(zhàn)場WARN / INFO重試、降級、性能退化、狀態(tài)變更主要看趨勢和頻率單條往往不是問題ACCESS / AUDIT登錄、接口調用、權限變更、敏感操作安全審計、合規(guī)留痕、異常訪問行為分析DEBUG業(yè)務細節(jié)、變量值、流程分支平時關閉出問題時臨時開啟注意一個關鍵點ERROR 之間也有區(qū)別。有的 ERROR 是業(yè)務預期內(nèi)的比如用戶取消支付、第三方回調超時有的是系統(tǒng)級故障比如磁盤滿、OOM。如果只是機械地認為 ERROR 就必須處理那告警疲勞、誤判會把人折磨到懷疑人生。正確做法是在日志格式里給錯誤分類預留字段比如[BIZ]表示業(yè)務異常[SYS]表示系統(tǒng)異常后面寫告警策略時就可以直接按字段過濾。很多 Linux 面試題里會考日志分析的常用命令但真正的工作場景里能用好分級模型的人永遠比背命令的人走得遠。分級模型定下來之后團隊里任何一個人接手排障都知道先看哪一層這就是策略的第一重價值。1.3 三個排查邊界提前畫好用起來省一半時間定完級別還要定邊界。我常用的邊界有三個每次排查前都會在腦子里過一遍。第一個是時間邊界。日志文件再大絕大多數(shù)故障都集中在某個時間窗口內(nèi)。先確定故障開始和結束的時間點然后用--since、--until或者sed -n /10:00:00/,/10:30:00/p把范圍切出來。沒有時間邊界就去翻全量日志基本等同于大海撈針。第二個是服務邊界。一臺機器上可能跑著十幾個服務日志文件也可能有幾十個。確定是哪個服務出了問題直接進對應日志目錄比在一堆文件里 grep 高效得多。多服務共用一個日志文件時就靠日志里的服務名或模塊名字段來過濾。第三個是進程或請求邊界。一個服務進程下面有好多線程一個請求會經(jīng)過接入層、業(yè)務層、存儲層。要么記住異常線程的 PID用 PID 去 grep 上下文要么利用請求 IDtrace_id / request_id把一次請求在所有日志里的痕跡串起來。邊界定得越準后面要分析的日志量就呈指數(shù)級下降。2. 日志采集與輪轉策略源頭治理比事后救火更重要2.1 journald 和文本日志怎么選很多系統(tǒng)默認用 systemd 的 journald 收集系統(tǒng)日志這個設計非常好它把內(nèi)核日志、syslog、各服務標準輸出都收攏到一起用journalctl一條命令就能查詢而且自帶結構化字段比如_PID、_SYSTEMD_UNIT、_HOSTNAME過濾起來非常方便。但 journald 也有兩個實際痛點。一是默認不持久化重啟機器后日志會丟二是日志文件存儲格式是二進制的雖然journalctl能讀但想用其他分析工具直接處理時就不太順手。所以我推薦的方式是混用系統(tǒng)服務的標準輸出交給 journald用journalctl實時查業(yè)務應用的關鍵日志單獨以文本文件落盤方便用傳統(tǒng)命令分析和后續(xù)采集。文本日志的好處是所有 Linux 系統(tǒng)都認權限管理簡單日志分析工具鏈豐富出了問題拷貝一個文件就能交給其他人排查。如果你面對的是一套老系統(tǒng)沒有結構化日志也沒關系文本日志足夠搞定絕大多數(shù)場景。不同發(fā)行版默認配置略有差異但無論 CentOS、Ubuntu 還是各種國產(chǎn)發(fā)行版底層基本都是 systemd rsyslog 這套體系規(guī)則配置思路是通用的。2.2 logrotate 配置實例與參數(shù)解釋日志文件最怕的就是無限增長。磁盤被日志打滿服務各種異常這是生產(chǎn)環(huán)境最常見的低級事故之一。好在 Linux 自帶的 logrotate 能解決這個問題但我發(fā)現(xiàn)很多人只會寫最簡單的rotate 7遇到服務仍占用舊文件句柄的問題就一頭霧水。下面這個配置是我比較常用的模板拿一個應用日志樣例來說明/var/log/myapp/app.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate create 0640 app app }逐項解釋一下關鍵參數(shù)。daily表示每天輪轉一次rotate 7表示保留 7 份歷史日志。compress將輪轉出的歷史文件壓縮成 gzdelaycompress則是延遲一天再壓縮。為什么要延遲因為有些應用進程在輪轉瞬間可能還在寫舊文件立刻壓縮會把正在寫入的數(shù)據(jù)壓壞延遲一天等文件徹底冷卻下來再壓更安全。copytruncate對某些不重開文件句柄的服務特別重要。默認 logrotate 會把舊日志改名、再新建一個同名文件但如果應用始終持有舊文件的句柄那改名后它繼續(xù)往舊文件里寫新文件反而一直空著。copytruncate會先復制一份當前內(nèi)容再把原文件截斷應用無感知不會出現(xiàn)日志漏寫的問題。代價是復制和截斷之間可能有少量日志丟失但對大多數(shù)業(yè)務日志來說完全可接受。寫完之后先測試logrotate -d /etc/logrotate.d/myapp做空跑驗證確認無誤再手動執(zhí)行一次logrotate -f /etc/lograte.d/myapp。2.3 采集側的幾個取舍輪轉只是第一步采集側的策略同樣不能忽略。第一件要做的就是對磁盤用量設置上限。journald 默認日志增長可能很恐怖建議在/etc/systemd/journald.conf里設置SystemMaxUse500M限制總占用。如果用的是 rsyslog也要在配置里加上頻率限制避免某個服務瘋狂打印日志把整個系統(tǒng)拖垮。第二件是處理多行日志。Java 異常堆棧和 Python 的 traceback 都是一行開頭、后面跟多行的形式簡單的行采集會把一條完整異常拆成幾十條碎片分析時特別頭疼。這個問題最好在采集器層面解決Filebeat 和 Logstash 都支持multiline合并規(guī)則按“下一行是否以時間戳開頭”來決定是否續(xù)接這樣能從源頭規(guī)整日志格式。第三件是敏感信息脫敏。業(yè)務日志里經(jīng)常會混入密碼、token、手機號、身份證號如果不做處理就進日志平臺等于把用戶隱私直接暴露給所有能查日志的人。建議在應用打印日志之前統(tǒng)一過濾或者在采集端用正則替換比如把密碼字段的password123456替換成password***。這類策略越早定越好出了安全事故再補就被動了。3. 一套能直接復用的日志分析實操套路journalctl grep awk3.1 journalctl 高效用法先說 journalctl因為它查系統(tǒng)服務日志確實好用。最核心的思路是“先縮小范圍再上過濾條件”而不是直接journalctl全量輸出然后慢慢翻。下面的命令組合我很常用journalctl -u nginx --since -10min -p err -x --no-pager這條命令的意思是查看 nginx 服務最近 10 分鐘內(nèi)級別在 err 及以上的日志-x自動補充日志中引用的文檔解釋--no-pager直接輸出到終端方便配合管道做后續(xù)處理。-u指定服務單位--since指定時間窗口-p指定日志級別這幾個參數(shù)配合使用絕大多數(shù)系統(tǒng)服務排查場景都能覆蓋。如果想導出結構化的 JSON 日志做統(tǒng)計加一個-o json-pretty然后直接管道給 jq 等工具處理。比如journalctl -u payment-api --since 2024-06-15 10:00:00 -o json-pretty | jq select(.PRIORITY 3) | .MESSAGE這里有個容易忽略的細節(jié)journald 記錄的時間戳默認顯示為本地時間但如果系統(tǒng)時區(qū)設置不對查出來的時間基準就是錯的。排查前先date確認一下系統(tǒng)時間否則你按“故障時間”去查日志很可能什么都查不到。3.2 文件日志的篩選與統(tǒng)計組合拳對于文本日志我的核心組合拳是“定位—上下文—統(tǒng)計”三步走。第一步用 grep 定位關鍵行注意用-E支持擴展正則避免把多個條件拆成多條管道。定位到少量目標行后用-A和-B拉出前后文grep -n ERROR /var/log/myapp/app.log | head -20 grep -n -A 20 -B 5 NullPointerException /var/log/myapp/app.log第二步是統(tǒng)計找出“到底哪里報錯最多”。比如我要看某個接口的錯誤集中在哪個模塊就先拿到日志中模塊字段對應的列然后統(tǒng)計 Top 10grep ERROR app.log | awk {print $6} | sort | uniq -c | sort -rn | head -10這條命令的邏輯先篩出所有 ERROR 行awk 取出第 6 列具體字段按實際日志格式調整sort 排序讓相同值相鄰uniq -c 做次數(shù)統(tǒng)計再按次數(shù)倒序排列取前 10。這樣一跑哪個模塊是故障熱點、哪個服務在刷屏一目了然。如果要做時間維度分析看某個時間段錯誤量的變化曲線可以用 awk 截取時間字段并按分鐘歸并awk /2024-06-15 10:/{print substr($0,1,19)} app.log | uniq -cuniq 的原理是相鄰去重所以前面必須保證時間字段已經(jīng)排好序如果原始日志亂序就先 sort 一下再 uniq -c。這個統(tǒng)計思路可以靈活改造比如把時間粒度改成小時、把過濾條件從 ERROR 改成某個業(yè)務碼就能得到完全不同的觀察角度。3.3 把日志串成證據(jù)鏈時間、PID、RequestID單條日志只是孤證真正能定位根因的是證據(jù)鏈。最常見的串聯(lián)維度有三個。第一個是時間線對齊。多服務部署時同一個故障會同時落在多個服務的日志里而且各自時間戳可能還有毫秒級偏差。我會把相關日志先按時間排序再用 grep 或 sed 把同一時間窗口的日志提取出來按時間交錯排列這樣請求鏈路的前后關系就非常清楚。純文本排序用sort -k1,2之類的參數(shù)按時間列排序即可。第二個是 PID 關聯(lián)。遇到線程池滿了、CPU 飆高這類問題先用 top 或 jstack 拿到異常線程的 PID然后直接拿去日志里過濾grep PID12345 app.log | tail -50通過 PID 能把一次線程從創(chuàng)建、執(zhí)行到報錯的完整過程還原出來。這個方法尤其適合排查 JVM 服務和 C 服務。第三個是 RequestID 追蹤?，F(xiàn)在稍微正規(guī)一點的系統(tǒng)都會在接入層生成一個 trace_id通過 HTTP 頭或日志字段向后端傳遞。只要日志里打了這個 ID無論請求經(jīng)過多少個服務都能用一條命令把整條調用鏈撈出來grep trace_id8a2f5c1e9d gateway.log | sort -k3 grep trace_id8a2f5c1e9d payment-api.log | sort -k3這里我沒法一步跨文件拼接所以通常的做法是把每個服務的匹配結果分別導出成小文件再合到一起按時間排序。遇到一次復雜的分布式調用超時這個思路能節(jié)省數(shù)小時。我印象最深的一次排障支付服務報連接池滿用 PID 關聯(lián)日志后發(fā)現(xiàn)是某個定時任務發(fā)起了一批慢 SQL把池子占滿了而請求量大只是表象。沒有證據(jù)鏈這種隱蔽根因根本挖不出來。4. 告警與響應策略從“看到日志”到“處理完故障”的最后一公里4.1 告警閾值怎么定才有意義很多人第一次寫告警規(guī)則時都會犯一個毛病只要日志里出現(xiàn) ERROR 就告警。結果一天幾百條夜里被電話轟炸很快就沒有人再認真看了。等真正出了大事故告警響了一聲沒人接反而誤了時機。正確的做法是先建立基線。統(tǒng)計過去 7 天每天同一時間窗口內(nèi) ERROR 數(shù)量算出平均值和標準差再以“平均值 N 倍標準差”作為閾值基線。比如某服務的日均 ERROR 是 100 條波動標準差是 20 條那閾值可以定在 160 條左右。低于這個數(shù)都屬于正常抖動不需要打擾任何人。更穩(wěn)的組合方式是“比例 持續(xù)時間”。比如錯誤率超過 1% 且持續(xù) 3 分鐘才觸發(fā)告警或者 5 分鐘內(nèi)錯誤數(shù)環(huán)比上升超過 200% 才觸發(fā)。用比例而非絕對值可以自動適應流量高峰和低谷的變化。我?guī)鸵患译娚陶{過支付告警原來是每天上百條誤報改成“錯誤率 持續(xù)時間”的組合策略后一周只有 3 條有效告警而且每一條都對應真實事故。4.2 告警分級與降噪策略告警必須分級否則處理人的心態(tài)永遠是“狼來了”。我習慣分成三檔級別定義響應要求P1業(yè)務不可用、數(shù)據(jù)丟失、核心服務宕機5 分鐘內(nèi)響應立即拉群、通知值班長P2核心功能受損但系統(tǒng)可用如支付成功率下降30 分鐘內(nèi)響應優(yōu)先排查P3非核心異常、潛在隱患如某接口偶發(fā)超時記錄觀察白天處理分級之后還要降噪。常用的降噪三招一是收斂通知同一個故障在告警恢復之前不重復發(fā)送避免一個人一分鐘收 10 條短信二是加白名單把已知業(yè)務預期的 ERROR 特征碼排除掉比如“用戶取消支付”這種業(yè)務事件三是確認機制告警發(fā)出后如果 10 分鐘內(nèi)無人確認自動升級到下一級。這套機制跑順之后值班同事的精神壓力會小很多真出問題的時候響應速度反而更快。4.3 從日志到處理的完整閉環(huán)日志分析的策略最終要落到“能自動處理就自動處理不能自動處理就走標準 SOP”。我見過太多團隊日志采集做得很完善告警也響得很及時但告警響應全靠某一位老師傅手忙腳亂地操作。這樣的策略算不上閉環(huán)。比較理想的閉環(huán)是告警觸發(fā)后先由腳本自動嘗試恢復。比如磁盤空間超出閾值自動清理臨時文件和過期備份進程掛了自動拉起并打印重啟原因。自動處理不成功再帶著已經(jīng)在告警信息里拼好的上下文轉人工。這樣排查時的“起跑線”就高了很多——值班人手上有的是“日志證據(jù)包加推薦處理動作”而不是一條干巴巴的告警短信。我還要求團隊每次故障處理完必須做一次日志復盤當時哪些日志信息有用哪些日志字段缺失導致多花了時間這些結論反哺到采集策略和告警規(guī)則里。做上兩三輪之后告警的準確率和排障速度都會有質的提升。5. 20年運維踩坑實錄日志分析里最容易翻車的四個細節(jié)5.1 時區(qū)與時間戳陷阱時區(qū)問題是日志分析里最隱蔽也最坑人的細節(jié)。有一次我們排查一個凌晨的支付超時業(yè)務日志顯示請求是 00:30 進來的但系統(tǒng)日志顯示同一時間服務已經(jīng)在 08:30前一天晚上就出現(xiàn)了連接異常。兩邊時間差了 8 個小時因為應用服務器時區(qū)設成了 UTC而業(yè)務日志的框架按系統(tǒng)時區(qū)打印了 UTC 時間到了人的腦子里又自動換成了北京時間導致怎么都對不上。遇到這種問題手動轉換可以用 date 命令date -d 2024-06-15 00:30:00 UTC %Y-%m-%d %H:%M:%S %Z這條命令把 UTC 時間轉成本地時區(qū)時間輸出直觀。但更根本的解決策略是所有服務器、所有應用日志統(tǒng)一使用同一時區(qū)國內(nèi)業(yè)務一般統(tǒng)一 UTC8或者在日志格式里直接寫入帶時區(qū)的 ISO8601 時間戳比如2024-06-15T00:30:0008:00。這樣不管是采集、存儲還是人工分析都不會被時區(qū)差異干擾。定這個規(guī)矩花不了十分鐘但能避免以后無數(shù)個深夜的“幽靈時間”。5.2 ANSI 顏色碼干擾統(tǒng)計結果systemd 的 journalctl 輸出默認是帶顏色高亮的如果直接管道給 grep、awk 處理問題不大但如果先把輸出重定向到文件再統(tǒng)計那些顏色轉義序列會殘留下來變成一堆[36m之類的垃圾字符。統(tǒng)計結果會莫名奇妙地偏多或偏少而且你還看不出來原因。我踩過這個坑后養(yǎng)成了習慣任何文本日志的原始文件盡量不帶 ANSI 色碼應用打印時直接關閉顏色輸出如果拿到了帶顏色的日志先統(tǒng)一清洗一遍再分析。清洗命令如下sed -r s/\x1B\[[0-9;]*[mK]//g dirty.log clean.log\x1B是 ESC 字符后面的[0-9;]*[mK]匹配顏色代碼序列。文件名帶顏色碼的日志先過一遍這條命令再去 grep 正則就準確多了。我還見過有人因為在日志里搜索[36mERROR啥都搜不到最后發(fā)現(xiàn)是顏色碼把字符串分隔開了。這種問題不大但一旦遇到會浪費半小時。5.3 大文件分析與管道緩沖問題日志文件超過幾個 G 時管道的“斷流”問題就顯現(xiàn)了。常見場景是用 grep 從大文件中篩出結果再接 head 只取前 10 行。head 讀夠 10 行就退出但 grep 還在繼續(xù)讀文件寫管道時發(fā)現(xiàn)下游沒了就會收到 SIGPIPE 信號直接被終止。這時候 shell 會報 “Broken pipe”grep 處理到一半就被殺掉了。更隱蔽的問題是你拿到了前 10 行但不確定這 10 行是否覆蓋了所有關鍵信息。解決方案是不要用 head 截斷管道而是用 grep 的-m參數(shù)直接限制匹配行數(shù)grep -m 20 FATAL app.log這樣 grep 找到 20 行后就主動停止不會浪費資源繼續(xù)掃全文件也不會觸發(fā)管道斷開。另外面對壓縮過的老日志直接zgrep、zcat就能處理不用先解壓。還有個小技巧運行grep 文件時直接傳文件名不要先cat 文件 | grep這樣能省一次大文件讀盤對幾個 G 的日志來說差別非常明顯。5.4 輪轉間隙導致留證不足有次生產(chǎn)故障我們花了一整天才定位到根因結果想回頭翻出事當天某個節(jié)點的日志時發(fā)現(xiàn) logrotate 已經(jīng)把當時的日志輪轉并清理了只剩壓縮包。壓縮包里的內(nèi)容還不全因為故障高峰期日志量巨大沒等到第二天就觸發(fā)了按大小輪轉歷史文件被覆蓋。沒有原始日志那次復盤只能靠記憶拼湊非常被動。從此我定下規(guī)矩任何一次故障響應第一件事不是分析而是先留證。哪怕是正在處理也要先執(zhí)行一條保存命令cp /var/log/myapp/app.log /var/log/myapp/archive/app.log.$(date %F_%H%M).save如果日志文件特別大來不及全量復制就用 tail 保存尾部因為大部分故障的現(xiàn)場都集中在最新的一段tail -c 200M /var/log/myapp/app.log /var/log/myapp/archive/app.log.tail.save這個習慣救過我很多次。重要的業(yè)務日志建議直接送到中心化日志平臺保留至少 30 天這樣既不怕輪轉清數(shù)據(jù)又能跨服務器檢索。本地輪轉策略解決的是磁盤風險中心化日志解決的是留證和檢索兩者配合才算完整。最后分享一個我沉淀多年的小習慣接手任何一套新系統(tǒng)第一件事不是看代碼而是花一個下午把日志的分級、輪轉、采集、告警這四件事捋一遍。磨刀不誤砍柴工策略一旦建立起來后面每一次排障都快很多。日志分析這件事你把它當搜索它就是一條命令的事你把它當策略它就是整個運維體系的指路標。這個系列后面還有一篇計劃專門寫容器和云原生場景下的日志分析差異有興趣的話可以先關注到時候對照著看收獲會更大。