1. 項(xiàng)目為什么叫rea從一次凌晨三點(diǎn)的事故說(shuō)起做后臺(tái)服務(wù)的人大概都經(jīng)歷過(guò)這種場(chǎng)景凌晨三點(diǎn)手機(jī)瘋狂震動(dòng)群里連著十幾條告警說(shuō)某個(gè)核心服務(wù)的內(nèi)存占用飆到90%以上再過(guò)幾分鐘可能就要被系統(tǒng)殺掉。你爬起來(lái)連上服務(wù)器先看監(jiān)控面板再翻日志文件半天找不到頭緒——因?yàn)榫€上環(huán)境跑的進(jìn)程不是你的本地環(huán)境日志量動(dòng)輒幾個(gè)GB報(bào)錯(cuò)堆棧被滾動(dòng)沖刷得七零八落真正有用的那幾行早就沉底了。我之前就被這種問(wèn)題折磨過(guò)好幾回。后來(lái)某天下午坐我旁邊的某同事隨口說(shuō)了一句要是有一個(gè)工具能像搜證據(jù)一樣把崩潰現(xiàn)場(chǎng)自動(dòng)還原出來(lái)就好了。 這句話讓我記了很久。我當(dāng)時(shí)想的是為什么每次線上排查都要靠人肉grep日志、人肉比對(duì)堆棧為什么不能把錯(cuò)誤指紋提取→聚合同源問(wèn)題→輸出根因摘要這條鏈路自動(dòng)化于是就有了rea這個(gè)項(xiàng)目。名字沒(méi)有什么花哨的含義就是Runtime Error Analyzer的縮寫(xiě)——運(yùn)行時(shí)錯(cuò)誤分析器。它的定位非常簡(jiǎn)單給你一堆日志文件或者一個(gè)進(jìn)程core dump現(xiàn)場(chǎng)它能自動(dòng)幫你找出高頻錯(cuò)誤、歸類同源堆棧、還原崩潰前的調(diào)用鏈最后輸出一份按優(yōu)先級(jí)排序的排查報(bào)告。和市面上那些重量級(jí)的APM平臺(tái)、日志分析系統(tǒng)不同rea從一開(kāi)始就想做輕量、單機(jī)、可離線運(yùn)行的工具。不需要部署agent不需要搭大數(shù)據(jù)管道一條命令跑完結(jié)果直接打到終端里。它的目標(biāo)用戶很明確那些被線上故障折騰過(guò)、又不想為一個(gè)排錯(cuò)場(chǎng)景引入一整套復(fù)雜基礎(chǔ)設(shè)施的開(kāi)發(fā)者。這篇文章就把rea從零到一的設(shè)計(jì)思路、核心技術(shù)點(diǎn)、以及我在實(shí)際使用中踩過(guò)的坑完整寫(xiě)出來(lái)。工具本身我用的是Go語(yǔ)言實(shí)現(xiàn)但里面的設(shè)計(jì)思路和排查方法論換成別的語(yǔ)言一樣能落地。2. 核心問(wèn)題拆解錯(cuò)誤分析到底難在哪里2.1 日志噪音比真正的錯(cuò)誤多得多在動(dòng)手寫(xiě)任何代碼之前我先把錯(cuò)誤分析這件事拆解了一遍。做了幾年后臺(tái)開(kāi)發(fā)我太清楚線上日志的真實(shí)狀態(tài)了業(yè)務(wù)日志、訪問(wèn)日志、第三方SDK調(diào)試日志、定時(shí)任務(wù)的正常輸出全部混在一起一條真的致命錯(cuò)誤周?chē)赡車(chē)鴰浊l信息級(jí)別INFO和警告級(jí)別WARN的噪音。如果你只是簡(jiǎn)單地用grep -i error去搜結(jié)果大概率是兩個(gè)極端——要么搜出一堆第三方庫(kù)的軟錯(cuò)誤比如TCP連接超時(shí)重試、某個(gè)非關(guān)鍵依賴暫時(shí)不可用要么因?yàn)槿罩靖袷讲灰?guī)范、錯(cuò)誤信息被截?cái)嗾嬲亩褩８舅巡坏?。這就意味著一個(gè)真正有用的錯(cuò)誤分析工具第一步要做的不是找錯(cuò)誤而是區(qū)分錯(cuò)誤的嚴(yán)重級(jí)別。我在rea里把這個(gè)能力叫做嚴(yán)重度分級(jí)器它會(huì)對(duì)每條日志做一次多維度的打分日志級(jí)別本身ERROR/FATAL優(yōu)先于WARN是否包含堆棧特征出現(xiàn)at、Caused by、Traceback、goroutine等關(guān)鍵詞是否涉及關(guān)鍵模塊DB操作、消息隊(duì)列、核心業(yè)務(wù)接口錯(cuò)誤文本的統(tǒng)計(jì)稀有度同一錯(cuò)誤出現(xiàn)一次和出現(xiàn)一萬(wàn)次分量完全不同這個(gè)分級(jí)邏輯讓我想起一個(gè)生活化的例子學(xué)校廣播里喊請(qǐng)全體師生注意這句話和直接說(shuō)某班某同學(xué)請(qǐng)速到教導(dǎo)處——前者是信息性廣播后者才是真正需要行動(dòng)的事情。日志也一樣大部分ERROR其實(shí)是全體注意式的廣播真正的致命錯(cuò)誤往往帶著明確的堆棧上下文。2.2 同源錯(cuò)誤在不同機(jī)器上長(zhǎng)得不一樣拆解完噪音問(wèn)題后第二個(gè)讓我頭疼的問(wèn)題是同源錯(cuò)誤的識(shí)別。同一個(gè)BUG在不同的機(jī)器、不同的時(shí)間點(diǎn)崩潰打印出來(lái)的堆棧幾乎不可能完全一致——行號(hào)可能不同、內(nèi)存地址每次都在變、goroutine ID是隨機(jī)的、時(shí)間戳差異就更不用說(shuō)了。如果你拿原始文本做聚合分組結(jié)果就是本質(zhì)相同的錯(cuò)誤被拆散成幾千個(gè)長(zhǎng)得略有不同的獨(dú)立條目報(bào)告根本沒(méi)法看。這就像同一個(gè)人的兩張證件照一張剛洗完臉、一張化了濃妝人臉識(shí)別系統(tǒng)如果按像素比對(duì)一定會(huì)認(rèn)為這是兩個(gè)人。所以rea必須實(shí)現(xiàn)一個(gè)堆棧指紋stack fingerprint算法把原始堆棧歸一化成一種不隨環(huán)境變化的結(jié)構(gòu)化特征值。具體做法我做了一字符串清洗加結(jié)構(gòu)保留的組合處理剝離所有明顯易變的部分——十六進(jìn)制內(nèi)存地址、數(shù)字行號(hào)、時(shí)間戳、進(jìn)程ID保留函數(shù)名、調(diào)用層級(jí)、異常類型對(duì)清洗后的調(diào)用鏈做哈希得到指紋然后用指紋做聚類同指紋歸一類這套方案的準(zhǔn)確率高到讓我自己都有點(diǎn)意外。有一次我拿一份生產(chǎn)環(huán)境真實(shí)現(xiàn)場(chǎng)的日志做測(cè)試原始文件里有1萬(wàn)2千多條錯(cuò)誤記錄肉眼根本看不出規(guī)律。rea跑完后聚成了17個(gè)錯(cuò)誤類別而人工確認(rèn)真實(shí)存在的獨(dú)立根因恰好是16個(gè)——多出來(lái)的那1個(gè)是因?yàn)橥粋€(gè)根因在兩種不同調(diào)用路徑上各出現(xiàn)了一次本質(zhì)也算同源。3. 技術(shù)選型與整體架構(gòu)一條命令跑完的輕量設(shè)計(jì)哲學(xué)3.1 為什么用Go而不是Python或Java技術(shù)選型這塊我經(jīng)歷過(guò)一段自我辯論。說(shuō)實(shí)話如果用Python寫(xiě)開(kāi)發(fā)速度肯定最快——文本處理的庫(kù)多、正則表達(dá)式順手、迭代起來(lái)也方便。但我當(dāng)時(shí)的核心訴求有兩點(diǎn)第一工具要在服務(wù)器上零依賴運(yùn)行不想為它裝Python環(huán)境第二處理幾GB的日志時(shí)不能讓內(nèi)存爆炸。最終選了Go。理由很直觀靜態(tài)編譯產(chǎn)物go build出來(lái)就是一個(gè)二進(jìn)制文件扔到服務(wù)器上就能跑連libc的版本兼容問(wèn)題都不用管內(nèi)存可控Go的流式處理和切片機(jī)制讓我可以用很小的內(nèi)存跑完大文件后面實(shí)測(cè)處理2GB日志峰值內(nèi)存只有300MB左右并發(fā)順手做日志分區(qū)和錯(cuò)誤歸類時(shí)goroutinechannel的模型比Python的線程池要清爽太多有人可能會(huì)說(shuō)Java也行——但Java的JVM冷啟動(dòng)時(shí)間和內(nèi)存占用放在命令行工具場(chǎng)景下實(shí)在不劃算。Go在這個(gè)場(chǎng)景幾乎是為性能敏感型CLI工具量身定做的。3.2 整體流程五個(gè)階段串成一條流水線rea的整體架構(gòu)是一條單向流水線每個(gè)階段只做一件事輸出成為下一階段的輸入階段職責(zé)核心技術(shù)點(diǎn)日志采集器讀取文件/標(biāo)準(zhǔn)輸入按行切割增量的bufio掃描支持同時(shí)處理多個(gè)文件嚴(yán)重度分級(jí)器給每條日志打嚴(yán)重度標(biāo)簽規(guī)則權(quán)重打分不依賴外部模型指紋提取器從堆棧中計(jì)算歸一化指紋清洗規(guī)則哈希計(jì)算錯(cuò)誤聚類器將同指紋錯(cuò)誤聚為同一類別排序流式分組內(nèi)存占用低報(bào)告生成器輸出可讀的排查報(bào)告普通文本/Markdown兩種格式按嚴(yán)重度排序這個(gè)流水線設(shè)計(jì)有一個(gè)很關(guān)鍵的工程決策所有階段都是單趟掃描single pass。除了聚類需要少量?jī)?nèi)存外幾乎不要求把全部數(shù)據(jù)加載進(jìn)來(lái)。也就是說(shuō)文件有多大理論上rea就能處理多大。3.3 一個(gè)容易忽略的細(xì)節(jié)文件讀取的斷行處理寫(xiě)日志文件讀取器時(shí)我踩了一個(gè)不算大、但很惡心的坑超大行問(wèn)題。有些第三方庫(kù)會(huì)在異常時(shí)一口氣打印幾十KB的字符串比如把整個(gè)HTTP請(qǐng)求頭拼到一行日志里。用Go的bufio.Scanner默認(rèn)緩沖區(qū)是64KB超長(zhǎng)行會(huì)直接報(bào)ErrTooLong然后中斷掃描——千萬(wàn)別小看這個(gè)我測(cè)試時(shí)真遇到過(guò)一個(gè)第三方SDK把800KB的SQL查詢串打進(jìn)一行日志里。解決方案是改用bufio.Reader配合自管理的ReadString(\n)循環(huán)并且設(shè)置了一個(gè)4MB的硬上限。超過(guò)上限的行按異常超長(zhǎng)行單獨(dú)記錄不直接丟棄——因?yàn)榕紶柲钦婢褪清e(cuò)誤現(xiàn)場(chǎng)的關(guān)鍵信息。4. 指紋算法的核心實(shí)現(xiàn)嬰兒車(chē)也不翻車(chē)的歸一化策略4.1 從想法到落地指紋到底要對(duì)什么做哈希如果你去翻一些日志聚類類項(xiàng)目的源碼指紋這個(gè)概念并不新鮮但實(shí)現(xiàn)質(zhì)量差異非常大。問(wèn)題大多出在清洗規(guī)則的定義上規(guī)則過(guò)松會(huì)把不相干的錯(cuò)誤聚到一塊規(guī)則過(guò)緊又導(dǎo)致分組碎片化。rea的指紋提取針對(duì)三類典型內(nèi)容做了三種策略第一類異常類型首幀函數(shù)名。一個(gè)Java堆棧里NullPointerException和IndexOutOfBoundsException是兩種完全不同的錯(cuò)誤即使后面跟著的函數(shù)調(diào)用?？雌饋?lái)一模一樣。所以異常類型必須占用指紋的主要權(quán)重。我計(jì)算指紋時(shí)把異常類型作為哈希串的前綴部分先參與哈希計(jì)算。第二類外部庫(kù)的堆棧幀。大多數(shù)業(yè)務(wù)崩潰的根因都在業(yè)務(wù)代碼里外部庫(kù)的堆棧幀反而是通用前綴——每個(gè)框架報(bào)錯(cuò)都會(huì)帶。我在清洗時(shí)會(huì)標(biāo)記出哪些幀來(lái)自第三方庫(kù)路徑比如github.com/something/...、java.util.、libc.so這些幀在指紋計(jì)算中的權(quán)重被降低同時(shí)保留它們的存在性而不保留具體行號(hào)。第三類易變數(shù)據(jù)。內(nèi)存地址、端口號(hào)、數(shù)字ID、UUID、時(shí)間戳這些統(tǒng)統(tǒng)用占位符替換再進(jìn)哈希否則一次崩潰的兩次現(xiàn)場(chǎng)記錄會(huì)被識(shí)別成兩種錯(cuò)誤。這三條規(guī)則組合起來(lái)最終得到的指紋是一串32位的十六進(jìn)制字符串。每條原始錯(cuò)誤都掛上這個(gè)指紋后續(xù)聚類直接按指紋做鍵分組——這是整個(gè)方案中收益最高、性價(jià)比最好的部分。4.2 歸一化效果用真實(shí)數(shù)據(jù)說(shuō)話我拿了一個(gè)模擬項(xiàng)目X的壓力測(cè)試日志做基準(zhǔn)測(cè)試。這個(gè)項(xiàng)目故意構(gòu)造了三種不同的BUG空指針、連接池耗盡、死鎖超時(shí)。每種BUG在日志中產(chǎn)生了大量外表不同的記錄。rea運(yùn)行后的分組情況如下構(gòu)造的BUG類型原始錯(cuò)誤記錄數(shù)rea聚類類別數(shù)人工核對(duì)結(jié)果空指針286條1類完全一致連接池耗盡154條1類完全一致死鎖超時(shí)97條2類一致一面是超時(shí)前的警告一面是超時(shí)后崩潰死鎖那個(gè)場(chǎng)景多分出一類是合理的因?yàn)殄e(cuò)誤鏈條上的警告級(jí)日志和真正的錯(cuò)誤日志本就不該合并到一類那會(huì)干擾優(yōu)先級(jí)排序。所以說(shuō)到底指紋算法不是要完全智能而是要準(zhǔn)確反映問(wèn)題的結(jié)構(gòu)和語(yǔ)境。4.3 調(diào)優(yōu)時(shí)一個(gè)浪費(fèi)一下午的參數(shù)做指紋清洗規(guī)則時(shí)我花了一整個(gè)下午調(diào)一個(gè)參數(shù)——內(nèi)存地址的替換。剛開(kāi)始我把所有十六進(jìn)制的字符串都視為內(nèi)存地址全部替換成占位符。結(jié)果發(fā)現(xiàn)問(wèn)題了業(yè)務(wù)代碼里有些常量值也是十六進(jìn)制表示比如配置里的魔數(shù)0x3F800000這類值對(duì)錯(cuò)誤定位是有意義的。一律替換后兩個(gè)使用不同常量配置的錯(cuò)誤反而被合到了同一類里。解決方案是在替換前加一道地址合理性檢查十六進(jìn)制值長(zhǎng)度必須在6到16位之間且前后文必須是堆棧幀特征比如前面有或at。不合規(guī)的十六進(jìn)制串保持原樣。這個(gè)細(xì)節(jié)讓我意識(shí)到清洗規(guī)則的每一步都可能引入歧義必須反復(fù)拿真實(shí)日志驗(yàn)證邊界情況。5. 嚴(yán)重度打分與優(yōu)先級(jí)排序讓報(bào)告的第一頁(yè)就是答案5.1 為什么單純的count排序不靠譜第一版rea的排序邏輯很簡(jiǎn)單——哪個(gè)錯(cuò)誤類別出現(xiàn)的原始記錄數(shù)最多就排在最前面。這顯然是個(gè)誤區(qū)。在真實(shí)線上環(huán)境中一個(gè)連接超時(shí)類的WARN錯(cuò)誤可能一小時(shí)出現(xiàn)幾千次但真正導(dǎo)致服務(wù)雪崩的FATAL錯(cuò)誤只出現(xiàn)了兩次。按count排序會(huì)把這個(gè)致命問(wèn)題壓到列表末尾排查者拿著報(bào)告翻到底部才看到真正要緊的線索。正確的排序必須綜合多維度因素。我把每一類錯(cuò)誤用加權(quán)打分的方式計(jì)算一個(gè)最終風(fēng)險(xiǎn)值Error Impact Score (嚴(yán)重級(jí)別權(quán)重 × 頻率因子) 堆棧完整度加分 關(guān)鍵模塊加分各項(xiàng)權(quán)重在配置文件里可以調(diào)。默認(rèn)基礎(chǔ)規(guī)則是這樣的FATAL級(jí)別日志的嚴(yán)重級(jí)別權(quán)重是10ERROR是7WARN是4頻率因子采用對(duì)數(shù)壓縮1次1分10次3分100次5分1000次以上7分——目的是防止高頻低危錯(cuò)誤淹沒(méi)低頻高危錯(cuò)誤包含完整堆棧的錯(cuò)誤額外加3分堆棧中出現(xiàn)數(shù)據(jù)庫(kù)操作、消息隊(duì)列、核心RPC框架的關(guān)鍵詞再各加2分這套打分規(guī)則的實(shí)際效果是報(bào)告第一屏永遠(yuǎn)是那兩三條真正需要馬上去看的錯(cuò)誤后面才是批量出現(xiàn)但危害有限的低危項(xiàng)。5.2 如何設(shè)計(jì)配置項(xiàng)而不顯得臃腫我不喜歡給工具堆太多配置開(kāi)關(guān)因?yàn)樗鼤?huì)變成另一個(gè)需要學(xué)習(xí)的系統(tǒng)。rea目前的配置文件就是一個(gè)YAML文件核心配置分為兩塊。第一塊是堆棧清洗規(guī)則。哪些路徑前綴被視為外部庫(kù)幀哪些模塊名被視為關(guān)鍵模塊都在這里聲明。例如我常用的一個(gè)配置片段fingerprint: external_frames: - github.com/gin-gonic - java.util. - libsystem_kernel critical_modules: - database/sql - pkg/redis - internal/rpc第二塊是嚴(yán)重度打分權(quán)重。用戶可以自行修改各級(jí)別的系數(shù)以適應(yīng)自己業(yè)務(wù)的特點(diǎn)。比如有的團(tuán)隊(duì)機(jī)器資源充足、內(nèi)存溢出風(fēng)險(xiǎn)低他們可以降低關(guān)鍵模塊的加分權(quán)重把注意力集中在業(yè)務(wù)錯(cuò)誤上。這個(gè)設(shè)計(jì)讓我體會(huì)到一套分析體系再好如果只能適用于作者自己的業(yè)務(wù)場(chǎng)景價(jià)值必然有限。把核心策略參數(shù)暴露成可配置項(xiàng)是工具從自用腳本走向可復(fù)用的開(kāi)源作品的關(guān)鍵一步。6. 實(shí)戰(zhàn)測(cè)試拿一份真實(shí)的故障日志跑完整流程6.1 模擬一個(gè)完整的崩潰現(xiàn)場(chǎng)并分析為了驗(yàn)證rea的實(shí)用性我搭建了一個(gè)模擬測(cè)試環(huán)境。這個(gè)環(huán)境跑著一個(gè)精簡(jiǎn)版的分布式緩存服務(wù)代碼故意注入了一個(gè)緩存擊穿級(jí)別的BUG當(dāng)某個(gè)熱點(diǎn)數(shù)據(jù)過(guò)期后并發(fā)請(qǐng)求同時(shí)回源數(shù)據(jù)庫(kù)觸發(fā)連接池耗盡然后被context deadline exceeded錯(cuò)誤覆蓋服務(wù)批量返回500。我抓取了一份約180MB的日志文件日志里混著正常的訪問(wèn)記錄、緩存命中日志、超時(shí)警告以及最后的連接池崩潰堆棧。rea的啟動(dòng)命令非常簡(jiǎn)單rea analyze --input /var/log/cache-service/error.log \ --output /tmp/rea-report.md \ --format markdown跑完耗時(shí)大約4秒。生成的報(bào)告核心部分摘要如下全局共解析日志 422,108 行標(biāo)記錯(cuò)誤級(jí)別日志 1,879 條聚類得到 12 個(gè)錯(cuò)誤類別按風(fēng)險(xiǎn)評(píng)分排名前3的是連接池耗盡風(fēng)險(xiǎn)評(píng)分29涉及892條記錄關(guān)鍵模塊命中4個(gè)上下文超時(shí)風(fēng)險(xiǎn)評(píng)分21涉及613條記錄關(guān)鍵模塊命中2個(gè)熱點(diǎn)數(shù)據(jù)并發(fā)回源風(fēng)險(xiǎn)評(píng)分16涉及374條記錄關(guān)鍵模塊命中2個(gè)最上面的連接池耗盡類錯(cuò)誤報(bào)告里直接附上了最開(kāi)始崩潰時(shí)的完整堆棧。這意味著排查者不需要在180MB文件中人肉搜索打開(kāi)報(bào)告看到第一眼就知道癥結(jié)在哪。6.2 報(bào)告格式與排查效率的實(shí)測(cè)對(duì)比我把同一份日志分別用傳統(tǒng)方法和rea做了一次排查計(jì)時(shí)對(duì)比方式耗時(shí)最終定位準(zhǔn)確性人肉grep堆棧關(guān)鍵詞約35分鐘找到表層的超時(shí)錯(cuò)誤未發(fā)現(xiàn)連接池耗盡根因簡(jiǎn)單按ERROR統(tǒng)計(jì)排序找文件約20分鐘只能定位高頻低危錯(cuò)誤rea分析報(bào)告約4分鐘含工具運(yùn)行時(shí)間直接定位連接池耗盡根因這不只是快慢的問(wèn)題。人肉grep的方式很容易被最容易搜到的錯(cuò)誤誤導(dǎo)而rea利用指紋聚類和嚴(yán)重度排序把看起來(lái)最嚇人的噪音擋在報(bào)告之外反而讓真正的根因浮出水面。我還測(cè)試了一個(gè)稍微復(fù)雜一點(diǎn)的場(chǎng)景同一服務(wù)在三個(gè)不同節(jié)點(diǎn)產(chǎn)生的日志合并分析。三個(gè)節(jié)點(diǎn)的日志格式存在細(xì)微差異有的帶時(shí)間戳毫秒數(shù)有的帶節(jié)點(diǎn)IDrea歸一化后成功識(shí)別出它們屬于同一錯(cuò)誤類別。這進(jìn)一步驗(yàn)證了指紋算法在跨環(huán)境對(duì)比上的可靠性。7. 踩坑記錄三個(gè)影響可靠性的大坑和修復(fù)思路7.1 坑一字符編碼導(dǎo)致的堆棧識(shí)別失效第一個(gè)坑出現(xiàn)在處理非UTF-8編碼的日志文件時(shí)。有些老系統(tǒng)輸出的GBK編碼日志直接按UTF-8讀取會(huì)產(chǎn)生亂碼堆棧關(guān)鍵特征全部丟失指紋聚類直接失效。我最初的實(shí)現(xiàn)是老老實(shí)實(shí)用os.Open加bufio.Scanner默認(rèn)讀取遇到非UTF-8內(nèi)容就直接亂下去。測(cè)試時(shí)發(fā)現(xiàn)GBK文件跑出來(lái)的報(bào)告里錯(cuò)誤類別少得離譜——全部被亂碼后的同一指紋歸并了。修復(fù)方案增加一個(gè)編碼探測(cè)階段讀取文件頭部的前4KB做一次啟發(fā)式判斷。具體來(lái)說(shuō)遵守一個(gè)簡(jiǎn)單原則如果有0xE4-0xE9區(qū)間的高字節(jié)連續(xù)出現(xiàn)兩次以上判定為GBK或GB2312編碼如果是標(biāo)準(zhǔn)的0xEF 0xBB 0xBF開(kāi)頭判定為UTF-8帶BOM。然后通過(guò)golang.org/x/text/encoding/simplifiedchinese做轉(zhuǎn)碼統(tǒng)一轉(zhuǎn)成UTF-8再進(jìn)入分析管線。這個(gè)坑提醒我日志文件的編碼問(wèn)題在真實(shí)生產(chǎn)環(huán)境里有極其高的出現(xiàn)概率工具做輸入層時(shí)不能假設(shè)世界默認(rèn)UTF-8。7.2 坑二多行堆棧日志的合并策略第二個(gè)坑是關(guān)于堆棧記錄的切分。很多語(yǔ)言的異常堆棧不止一行例如Java的堆棧前后會(huì)附帶空行和at開(kāi)頭的多行調(diào)用幀。如果簡(jiǎn)單按行切割日志同一個(gè)錯(cuò)誤堆棧會(huì)被拆成十幾條獨(dú)立記錄指紋計(jì)算自然也就亂套了。解決這個(gè)問(wèn)題需要引入一個(gè)多行緩沖器當(dāng)檢測(cè)到一行以堆棧特征前綴開(kāi)頭時(shí)接下來(lái)的若干行只要滿足堆棧幀特征函數(shù)調(diào)用、文件路徑加行號(hào)就一直合并到該錯(cuò)誤記錄中直到遇到下一個(gè)非堆棧幀的日志行或獨(dú)立的空行。rea在合并時(shí)有一個(gè)小技巧它會(huì)維護(hù)一個(gè)當(dāng)前待定記錄只有當(dāng)讀到下一句非堆棧行時(shí)才決定是否將緩沖內(nèi)容提交。這種延遲提交的方式能避免把多行堆棧誤判成兩條相鄰但獨(dú)立的錯(cuò)誤。7.3 坑三時(shí)間窗口聚類導(dǎo)致的重復(fù)報(bào)告第三個(gè)坑是在設(shè)計(jì)錯(cuò)誤暴發(fā)檢測(cè)功能時(shí)踩到的。當(dāng)時(shí)想加一個(gè)酷炫的特性——如果某個(gè)錯(cuò)誤類別在短時(shí)間內(nèi)集中暴發(fā)單獨(dú)標(biāo)記為爆點(diǎn)。功能本身沒(méi)問(wèn)題但我在聚類分組時(shí)引入了時(shí)間窗口切片結(jié)果把同一個(gè)持續(xù)10分鐘的根因錯(cuò)誤切成5個(gè)獨(dú)立的小類別報(bào)告里重復(fù)出現(xiàn)了5次相同的錯(cuò)誤。修復(fù)思路也很直接時(shí)間窗口只用于爆點(diǎn)標(biāo)記不參與聚類主鍵計(jì)算。聚類主鍵永遠(yuǎn)只有歸一化后的堆棧指紋時(shí)間維度的信息只是在報(bào)告里附加一句該錯(cuò)誤在14:30-14:40間集中出現(xiàn)。這樣既保留了暴發(fā)檢測(cè)的能力又不破壞全局聚類的完整性。說(shuō)到這個(gè)坑我想起設(shè)計(jì)時(shí)的糾結(jié)功能越加越多代碼結(jié)構(gòu)會(huì)不會(huì)失控答案是不會(huì)只要你用一個(gè)硬性約束管住自己每個(gè)功能的輸入和輸出都不能對(duì)其他功能產(chǎn)生副作用。報(bào)錯(cuò)聚類就是指紋指紋就是聚類主鍵誰(shuí)都別想改動(dòng)這個(gè)核心不變式。8. 關(guān)于分析結(jié)果是否可信的一些方法論思考8.1 工具給出的不是答案而是嫌疑名單做這一類診斷工具我越來(lái)越認(rèn)同一個(gè)觀點(diǎn)工具的終極目標(biāo)不是替代人的判斷而是把人的注意力引導(dǎo)到最有可能出問(wèn)題的位置。rea給的報(bào)告本質(zhì)上是一份嫌疑名單——它告訴你按數(shù)據(jù)和特征哪些錯(cuò)誤類別最可疑、最值得先看。但具體是不是根因、要不要立刻發(fā)布修復(fù)仍然需要工程師結(jié)合上下文判斷。這種方式讓我想到了犯罪偵查里的側(cè)寫(xiě)師。側(cè)寫(xiě)師根據(jù)現(xiàn)場(chǎng)痕跡縮小嫌疑范圍但最終鎖定犯罪嫌疑人還是要靠偵探拿著側(cè)寫(xiě)報(bào)告去逐一排查。rea做的就是側(cè)寫(xiě)快速、全面地掃描整個(gè)日志空間把所有可疑點(diǎn)按風(fēng)險(xiǎn)從高到低排列好。8.2 如何驗(yàn)證聚類結(jié)果的準(zhǔn)確性很多用戶拿到一份自動(dòng)聚類報(bào)告第一時(shí)間會(huì)問(wèn)這結(jié)果準(zhǔn)不準(zhǔn)我的驗(yàn)證方法很簡(jiǎn)單三個(gè)步驟從報(bào)告中任選一個(gè)錯(cuò)誤類別回溯原始日志確認(rèn)原始記錄確實(shí)屬于同一根因交換驗(yàn)證隨意抽兩條未歸入同一類的錯(cuò)誤記錄確認(rèn)它們確實(shí)有本質(zhì)區(qū)別反向注入故意在日志中混入已知類型的錯(cuò)誤檢查聚類結(jié)果是否把它們識(shí)別為同一類這是一套黑盒驗(yàn)證法不依賴工具內(nèi)部實(shí)現(xiàn)細(xì)節(jié)。我發(fā)現(xiàn)只要交付給用戶的報(bào)告附上同類錯(cuò)誤中前3條原始日志摘要功能用戶自己做交叉驗(yàn)證就非常方便不需要去翻原始文件驗(yàn)證每一條是否合理分組。8.3 什么時(shí)候不應(yīng)該使用自動(dòng)聚類的工具工具鏈也有一些天生不適用的場(chǎng)景我想坦誠(chéng)說(shuō)清楚日志量極小幾百條以內(nèi)時(shí)直接看日志比跑聚類更快日志本身極度不規(guī)范連基本的日志級(jí)別都沒(méi)有時(shí)自動(dòng)打分的可靠性會(huì)大幅下降需要精確到具體事務(wù)ID做鏈路追蹤時(shí)rea針對(duì)的是錯(cuò)誤分布視圖不是全鏈路追蹤了解工具的適用邊界比了解它的功能特性更重要。rea在設(shè)計(jì)之初就沒(méi)打算替代APM、日志分析平臺(tái)它只解決一個(gè)問(wèn)題快速?gòu)暮Ａ咳罩局邪芽梢慑e(cuò)誤歸類并排序。邊界清晰反而讓它在自己的適用場(chǎng)景里非常稱手。9. 后續(xù)規(guī)劃從分析錯(cuò)誤到輔助修復(fù)決策目前rea跑在單機(jī)上處理離線日志已經(jīng)穩(wěn)定使用了一段時(shí)間但這只是第一步而已。在我個(gè)人的規(guī)劃里后續(xù)有幾個(gè)方向值得繼續(xù)深挖。第一個(gè)方向是錯(cuò)誤趨勢(shì)預(yù)測(cè)。當(dāng)服務(wù)剛出現(xiàn)某類罕見(jiàn)錯(cuò)誤時(shí)rea如果能結(jié)合歷史數(shù)據(jù)給出該類錯(cuò)誤在過(guò)去30天內(nèi)首次出現(xiàn)的標(biāo)記就能提前預(yù)警潛在隱患。事實(shí)上我在后臺(tái)已經(jīng)默默做了這項(xiàng)工作新版本里會(huì)把首次出現(xiàn)時(shí)間和近期頻率走勢(shì)作為報(bào)告的一部分輸出。第二個(gè)方向是堆棧相似度搜索。目前的指紋聚類是精確匹配而真實(shí)世界中的同類問(wèn)題可能因?yàn)榇a版本升級(jí)、依賴庫(kù)更新而出現(xiàn)堆棧結(jié)構(gòu)上的差異。這時(shí)候硬性的指紋哈希就失效了。我打算引入一種模糊堆棧匹配能力利用編輯距離或局部敏感哈希讓相似但非完全相同的堆棧也能被關(guān)聯(lián)起來(lái)。這個(gè)功能對(duì)排查升級(jí)后新出現(xiàn)的問(wèn)題會(huì)特別有用。第三個(gè)方向是與CI/CD流水線的集成每次部署后自動(dòng)把當(dāng)天的錯(cuò)誤日志拉取并生成對(duì)比報(bào)告如果發(fā)現(xiàn)新出現(xiàn)的錯(cuò)誤類別直接通知對(duì)應(yīng)負(fù)責(zé)人。把事后排查變成上線即時(shí)反饋這才是自動(dòng)化工具最大的價(jià)值所在。不過(guò)說(shuō)這些規(guī)劃并不是要畫(huà)餅。以我個(gè)人經(jīng)驗(yàn)工具開(kāi)發(fā)最忌諱功能堆砌——每加一個(gè)功能都要回到最初的那個(gè)問(wèn)題重新問(wèn)自己它能不能幫助工程師更快地找到真相如果能方向就是對(duì)的如果只是技術(shù)上的自我滿足那就該果斷砍掉。至少到今天為止rea走過(guò)的每一步都經(jīng)得起這個(gè)追問(wèn)。