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