運(yùn)維搞久了總會(huì)碰到這種場(chǎng)景凌晨?jī)牲c(diǎn)被電話叫醒說某個(gè)服務(wù)掛了等你打開電腦連上服務(wù)器日志里清清楚楚寫著一個(gè)報(bào)錯(cuò)而這個(gè)報(bào)錯(cuò)其實(shí)半小時(shí)前就出現(xiàn)了。我后來想明白一件事——不是日志沒記錄而是沒人盯著它。日志它自己不會(huì)喊救命你得給它裝個(gè)喇叭。這就是我寫這套Python日志監(jiān)控工具的原因。它的作用很簡(jiǎn)單盯著指定位置的日志文件一旦出現(xiàn)匹配規(guī)則的內(nèi)容就通過郵件、釘釘、企業(yè)微信之類的通道把警報(bào)推出去。可以把它理解為給日志文件裝了一個(gè)24小時(shí)值班的哨兵它不睡覺、不請(qǐng)假、不玩手機(jī)只要發(fā)現(xiàn)異常就立刻喊人。這套方案適合誰如果你手里有三五臺(tái)服務(wù)器又沒有預(yù)算上商業(yè)監(jiān)控系統(tǒng)或者不想為這點(diǎn)事引入一套重量級(jí)的采集分析平臺(tái)那用Python寫一個(gè)輕量監(jiān)控腳本是性價(jià)比最高的選擇。整個(gè)過程不復(fù)雜核心邏輯就三塊讀日志、做匹配、發(fā)通知。下面我把整個(gè)設(shè)計(jì)和踩坑過程從頭到尾拆開講。1. 項(xiàng)目設(shè)計(jì)與核心思路1.1 為什么不用現(xiàn)成監(jiān)控工具很多人第一反應(yīng)是日志監(jiān)控這種事直接上現(xiàn)成的開源工具不就行了確實(shí)市面上成熟的日志采集分析方案很多功能也強(qiáng)大能聚合、能搜索、能畫圖表。但這類方案普遍有個(gè)共同點(diǎn)部署和維護(hù)成本不低。需要起服務(wù)、配采集端、調(diào)存儲(chǔ)、定期維護(hù)索引如果日志量不大、服務(wù)器也不多這種重型武器反而變成負(fù)擔(dān)。而且這類工具一般解決的是事后排查的問題——日志進(jìn)了平臺(tái)你想查的時(shí)候能查到。但實(shí)時(shí)發(fā)現(xiàn)異常并立刻通知人這件事配置起來并不像想象中那么輕松。有時(shí)候你只是想在某個(gè)應(yīng)用報(bào)錯(cuò)的時(shí)候收到一封郵件為這個(gè)搭一套平臺(tái)多少有點(diǎn)“用大炮打蚊子”。用Python寫一個(gè)幾十行的腳本就輕量得多。它能放在服務(wù)器上直接跑不依賴額外服務(wù)想改規(guī)則就改配置想加通知渠道就寫個(gè)函數(shù)完全捏在自己手里。關(guān)鍵是它的響應(yīng)路徑最短文件一有寫入腳本立刻讀到立刻做匹配立刻發(fā)通知整個(gè)過程能控制在秒級(jí)。1.2 整體架構(gòu)怎么搭這套監(jiān)控工具我拆成了四個(gè)模塊日志讀取模塊、規(guī)則匹配模塊、警報(bào)通知模塊和調(diào)度監(jiān)控模塊。每個(gè)模塊職責(zé)單一互相之間不糾纏后面想改任何一環(huán)都不會(huì)牽動(dòng)其他部分。日志讀取模塊負(fù)責(zé)從日志文件里持續(xù)讀新增內(nèi)容難點(diǎn)在于要做到“實(shí)時(shí)”又不能把文件從頭到尾反復(fù)讀。規(guī)則匹配模塊做的事很直接每一行新日志進(jìn)來跟預(yù)設(shè)的規(guī)則列表過一遍命中就觸發(fā)警報(bào)。警報(bào)通知模塊把命中的信息格式化之后推到目標(biāo)渠道。調(diào)度監(jiān)控模塊是最后一道防線——它檢查腳本本身是不是還活著同時(shí)處理并發(fā)控制這類問題。這四個(gè)模塊串起來的核心思路是讓日志從產(chǎn)生到發(fā)出警報(bào)的路徑盡可能短。日志一旦產(chǎn)生立刻被捕獲立刻做規(guī)則匹配命中后按配置走通知流程中間不做任何入庫、索引、聚合的耗時(shí)操作。這種設(shè)計(jì)針對(duì)的就是“實(shí)時(shí)告警”這個(gè)單一目標(biāo)把延遲壓到最低。2. 核心模塊解析與代碼落地2.1 日志讀取坑最多的環(huán)節(jié)日志讀取是整個(gè)項(xiàng)目里最容易寫錯(cuò)的地方也是我踩坑最多的地方。最直觀的做法是打開文件讀全部?jī)?nèi)容然后按關(guān)鍵詞搜一遍。這在文件小的時(shí)候沒問題但日志文件會(huì)增長(zhǎng)更關(guān)鍵的是如果腳本每分鐘跑一次每次都要讀整個(gè)文件性能會(huì)越來越差而且此前已經(jīng)報(bào)過的錯(cuò)還會(huì)被反復(fù)觸發(fā)。正確的讀法是用文件指針加seek的方式。每次讀取時(shí)記錄當(dāng)前讀到的文件位置下次只從這個(gè)位置往后讀新增的部分。關(guān)鍵是判斷文件是否被輪轉(zhuǎn)——很多日志系統(tǒng)比如某些服務(wù)會(huì)在文件達(dá)到一定大小后自動(dòng)重命名舊文件、創(chuàng)建新文件這個(gè)叫日志輪轉(zhuǎn)。如果腳本沒意識(shí)到日志文件已經(jīng)被替換了它還會(huì)盯著那個(gè)舊的inode讀讀到的永遠(yuǎn)是老內(nèi)容。我處理這個(gè)問題的方案是用os.fstat判斷當(dāng)前打開的文件和磁盤上的文件是不是同一個(gè)inode如果發(fā)現(xiàn)變了說明日志發(fā)生了輪轉(zhuǎn)這時(shí)候重置文件指針重新打開新文件。另外日志文件很快寫完再接著讀的時(shí)候要用follow模式逐行處理有點(diǎn)類似Linux里的tail -f效果。這段代碼承擔(dān)的是最底層的“持續(xù)跟蹤增量”任務(wù)import os import time def follow_file(file_path, start_from_beginningFalse): # 用 seek 指向文件尾部或頭部并處理文件輪轉(zhuǎn) if not os.path.exists(file_path): return if start_from_beginning: current_position 0 else: current_position os.path.getsize(file_path) file_obj open(file_path, r, encodingutf-8, errorsreplace) file_obj.seek(current_position) # 記錄當(dāng)前文件的inode用于檢測(cè)輪轉(zhuǎn) last_inode os.fstat(file_obj.fileno()).st_ino while True: line file_obj.readline() if line: yield line else: # 檢查文件是否被輪轉(zhuǎn)inode變化 try: current_inode os.stat(file_path).st_ino except FileNotFoundError: # 文件不存在了等它重新生成 time.sleep(0.5) continue if current_inode ! last_inode: file_obj.close() file_obj open(file_path, r, encodingutf-8, errorsreplace) last_inode os.fstat(file_obj.fileno()).st_ino else: time.sleep(0.2)這段代碼里有幾個(gè)細(xì)節(jié)值得說。errorsreplace這個(gè)參數(shù)是在讀取時(shí)遇到非法UTF-8字符直接用替換符處理不讓它拋異常中斷腳本。很多日志文件因?yàn)楦鞣N原因會(huì)有編碼問題如果這里不處理腳本跑一段時(shí)間就會(huì)因?yàn)橐粋€(gè)字符的錯(cuò)誤直接掛掉。2.2 規(guī)則匹配從關(guān)鍵詞到多條件邏輯日志讀進(jìn)來了下一步是判斷這一行要不要告警。最基礎(chǔ)的做法是字符串匹配如果日志里包含“ERROR”就報(bào)警。但實(shí)際用下來你會(huì)發(fā)現(xiàn)直接這么干會(huì)被煩死——有些日志里“ERROR”這個(gè)詞經(jīng)常出現(xiàn)但真正常見的自愈情況也會(huì)記錄ERROR比如“failed to connect, retrying”它瞬間就重試成功了這種你根本不想收到警報(bào)。所以規(guī)則匹配不能只做簡(jiǎn)單關(guān)鍵詞我得設(shè)計(jì)一個(gè)稍微靈活一點(diǎn)的規(guī)則系統(tǒng)。我最終用的是這樣的結(jié)構(gòu)rules: - name: 數(shù)據(jù)庫連接失敗 keywords: - database connection failed - cant connect to mysql level: critical notify: [mail, dingtalk] - name: 服務(wù)啟動(dòng)失敗 keywords: - failed to start - startup error level: critical notify: [mail]每一條規(guī)則包含名稱、關(guān)鍵詞列表、警報(bào)級(jí)別和通知渠道。匹配邏輯是一行日志里命中了這條規(guī)則下的任意一個(gè)關(guān)鍵詞就觸發(fā)這條規(guī)則。但這里還缺一個(gè)維度同樣的錯(cuò)誤在短時(shí)間內(nèi)反復(fù)出現(xiàn)要不要每次都發(fā)警報(bào)我的答案是不要。假如某個(gè)接口在五分鐘內(nèi)報(bào)錯(cuò)了一百次大部分情況都是同一個(gè)根因一口氣發(fā)一百條警報(bào)第一第二條你會(huì)看后面全都會(huì)被忽略搞不好管理員直接把通知渠道靜音了。所以我在規(guī)則匹配里加了一個(gè)“去重復(fù)”判斷。簡(jiǎn)單說就是用內(nèi)存緩存記住每條規(guī)則最近一次觸發(fā)的時(shí)間如果離上次觸發(fā)不足N秒我配置的是300秒就不再發(fā)警報(bào)只更新“命中次數(shù)”這個(gè)字段,攢到指定次數(shù)再補(bǔ)發(fā)一條。這樣一來既不會(huì)漏掉重大故障又不會(huì)被同一類報(bào)錯(cuò)轟炸。2.3 通知渠道讓警報(bào)真正找到人日志匹配到了還不夠得把警報(bào)送到該看到的人手里。我最開始只做了郵件通知因?yàn)猷]箱人人都有。但后來發(fā)現(xiàn)郵件的問題是不夠及時(shí)——人不可能時(shí)刻盯著收件箱而且有的郵件服務(wù)有延遲從發(fā)出到接收可能要幾十秒甚至幾分鐘這個(gè)延遲在故障場(chǎng)景下讓人等得心焦。所以后來我把通知拆成了兩個(gè)梯隊(duì)——緊急警報(bào)走即時(shí)通信工具普通警報(bào)發(fā)郵件。這里我以釘釘和郵件為例實(shí)現(xiàn)了一個(gè)多通道通知模塊。釘釘這邊用自定義機(jī)器人往群機(jī)器人Webhook地址發(fā)一個(gè)POST請(qǐng)求就能把消息推到群里import requests import json def send_dingtalk_message(webhook_url, content): headers {Content-Type: application/json} payload { msgtype: text, text: { content: content } } response requests.post(webhook_url, headersheaders, datajson.dumps(payload), timeout5) return response.status_code 200郵件這邊走Python標(biāo)準(zhǔn)庫smtplib不依賴第三方組件。我用的是文本格式郵件簡(jiǎn)單直接不帶花哨的HTML模板。有人會(huì)問怎么不把警報(bào)做成富文本圖表我的經(jīng)驗(yàn)是警報(bào)郵件的核心價(jià)值是信息傳達(dá)速度不是展示技術(shù)。收件人在手機(jī)上一眼能看到“哪臺(tái)機(jī)器、什么錯(cuò)誤、多久前發(fā)生的”就夠了搞一堆格式反而拖慢閱讀。import smtplib from email.mime.text import MIMEText def send_email(subject, content, to_addr, smtp_config): message MIMEText(content, plain, utf-8) message[Subject] subject message[From] smtp_config[from_addr] message[To] to_addr with smtplib.SMTP(smtp_config[server], smtp_config[port], timeout10) as server: if smtp_config.get(use_tls): server.starttls() if smtp_config.get(username): server.login(smtp_config[username], smtp_config[password]) server.send_message(message)這里要注意連接超時(shí)時(shí)間。發(fā)郵件這種事如果網(wǎng)絡(luò)有問題smtplib會(huì)一直等如果腳本被卡在這里后面的日志就處理不了了。所以一定要加timeout參數(shù)配合try-except兜底實(shí)在發(fā)不出去就記錄下來等下一輪再試。2.4 調(diào)度與部署讓腳本穩(wěn)定跑起來監(jiān)控腳本不是跑一次就完事它需要持續(xù)運(yùn)行。最直接的方案是扔到Linux的crontab里定時(shí)跑比如每分鐘跑一次。但這樣有個(gè)問題——每次運(yùn)行都是全新啟動(dòng)要從文件系統(tǒng)里找到上次讀到的位置需要額外的狀態(tài)記錄而且進(jìn)程啟動(dòng)本身也有開銷。更合適的做法是讓它像一個(gè)常駐服務(wù)一樣掛在那里。我用的方案是用systemd把這套腳本注冊(cè)成一個(gè)服務(wù)設(shè)置開機(jī)自啟掛了自動(dòng)拉起。systemd配置這樣寫[Unit] DescriptionLog Monitor Service Afternetwork.target [Service] ExecStart/usr/bin/python3 /opt/log-monitor/monitor.py WorkingDirectory/opt/log-monitor Restartalways RestartSec3 [Install] WantedBymulti-user.targetRestartalways這句很關(guān)鍵——腳本因?yàn)橐馔庠蛲顺龊髎ystemd會(huì)在3秒后把它重新拉起來不需要人工干預(yù)。這保證監(jiān)控本身不會(huì)變成無人值守的空檔。部署起來以后還有一個(gè)問題要處理——內(nèi)存占用。腳本長(zhǎng)時(shí)間跑著如果每次處理日志都往內(nèi)存里堆數(shù)據(jù)遲早會(huì)出問題。我處理的原則是每行日志處理完就釋放不做全量緩存。我維護(hù)的只是一個(gè)規(guī)則命中狀態(tài)表這個(gè)表非常小即使跑一個(gè)月內(nèi)存占用也基本穩(wěn)定在幾十MB以內(nèi)。3. 告警風(fēng)暴治理與閾值設(shè)計(jì)3.1 告警風(fēng)暴是怎么發(fā)生的告警風(fēng)暴這四個(gè)字運(yùn)維人都懂。某個(gè)服務(wù)一抖動(dòng)日志里瞬間刷出幾千條報(bào)錯(cuò)如果每條都觸發(fā)告警通知工具會(huì)被刷屏。更麻煩的是相似錯(cuò)誤在短時(shí)間內(nèi)高頻出現(xiàn)你根本看不出這次和上次有什么區(qū)別所有人看到告警的第一反應(yīng)不是處理故障而是先把消息群靜音。我一開始就沒想清楚這個(gè)問題第一版腳本上線后不到一個(gè)小時(shí)就把某工作群的通知炸了。那一夜我收到了八十多封郵件里面全是同一條錯(cuò)誤日志。那次之后我才意識(shí)到告警系統(tǒng)最大的敵人不是漏報(bào)而是誤報(bào)和重復(fù)報(bào)。3.2 滑動(dòng)時(shí)間窗口與頻率控制為了解決重復(fù)告警問題我引入了滑動(dòng)時(shí)間窗口機(jī)制。思路很簡(jiǎn)單對(duì)每條規(guī)則維護(hù)一個(gè)最近觸發(fā)時(shí)間戳如果當(dāng)前時(shí)間與上次觸發(fā)時(shí)間小于設(shè)定的窗口值這次命中只累加計(jì)數(shù)不立即發(fā)送窗口結(jié)束后如果期間累計(jì)的命中次數(shù)達(dá)到閾值才發(fā)送一條匯總告警。代碼實(shí)現(xiàn)這樣寫class AlertThrottle: def __init__(self, window_seconds300, threshold5): self.window_seconds window_seconds self.threshold threshold self.trigger_records {} def should_fire(self, rule_name, current_time): # 當(dāng)前時(shí)間大于窗口截止時(shí)間重置記錄 if current_time - self.trigger_records.get(rule_name, {}).get(last_time, 0) self.window_seconds: self.trigger_records[rule_name] {last_time: current_time, count: 1} # 首次觸發(fā)在窗口內(nèi)還需要觀察 return False record self.trigger_records[rule_name] record[count] 1 record[last_time] current_time # 達(dá)到閾值才發(fā)送 if record[count] self.threshold: self.trigger_records[rule_name] {last_time: current_time, count: 0} return True return False這個(gè)邏輯滿足了一個(gè)核心需求一條錯(cuò)誤第一次出現(xiàn)時(shí)不打擾人如果它在五分鐘內(nèi)反復(fù)出現(xiàn)并達(dá)到一定次數(shù)說明不是偶發(fā)問題值得驚動(dòng)人一次。如果只出現(xiàn)一兩次就自己消停了那算是正常波動(dòng)不需要浪費(fèi)人的注意力。3.3 分級(jí)告警與通知降噪不是所有告警都使用同一種通知方式這是后來我調(diào)整的重要思路。我按嚴(yán)重程度把告警分成了三檔緊急、重要、普通。緊急告警代表核心業(yè)務(wù)掛掉或者數(shù)據(jù)有風(fēng)險(xiǎn)必須電話加消息雙重轟炸重要告警代表某個(gè)模塊出現(xiàn)持續(xù)異常需要盡快處理普通告警則只是提醒發(fā)郵件就夠了。這個(gè)分級(jí)體現(xiàn)在配置里每條規(guī)則都可以單獨(dú)指定自己的級(jí)別和通知策略。設(shè)計(jì)的時(shí)候別嫌麻煩定義好清晰的告警級(jí)別模型后續(xù)維護(hù)規(guī)則的時(shí)候會(huì)省很多心。我的經(jīng)驗(yàn)是告警級(jí)別寧可少一點(diǎn)不要多三檔或四檔最好超過五檔的話人基本記不住每個(gè)級(jí)別該干嘛。4. 實(shí)操踩坑與排查經(jīng)驗(yàn)記錄4.1 日志文件被截?cái)啾O(jiān)控停擺運(yùn)維環(huán)境里有種常見操作叫截?cái)嗳罩竞芏嗳擞胑cho logfile這種方式把日志文件清空。這種操作不會(huì)改變文件inode但文件大小會(huì)變成0。我的腳本檢測(cè)輪轉(zhuǎn)時(shí)靠的是inode如果inode沒變指針還停留在原來的位置而文件大小已經(jīng)小于指針位置了這時(shí)候腳本會(huì)一直處于等待狀態(tài)永遠(yuǎn)讀不到新內(nèi)容。后來我加了一個(gè)檢測(cè)邏輯如果文件當(dāng)前大小比記錄的文件位置還要小說明文件被截?cái)噙^這時(shí)候把文件位置重置為0重新開始。這個(gè)坑如果在真實(shí)環(huán)境里踩一次基本都是告警系統(tǒng)靜默失效的狀態(tài)非常陰險(xiǎn)。處理代碼很簡(jiǎn)單current_size os.path.getsize(file_path) if current_size file_position: # 文件被截?cái)嘀刂弥羔樀轿募_始 file_position 0不要小看這幾行。日志監(jiān)控系統(tǒng)最怕的不是報(bào)錯(cuò)而是不報(bào)錯(cuò)它能悄無聲息地死著你以為一切正常實(shí)際上所有事件都在眼皮底下溜走。4.2 編碼問題導(dǎo)致進(jìn)程崩潰日志文件的編碼不統(tǒng)一是個(gè)隱藏殺手。有的應(yīng)用寫日志是UTF-8有的老程序還在用GBK。如果用utf-8嚴(yán)格模式讀GBK文件大概率讀到非法字節(jié)拋UnicodeDecodeError腳本當(dāng)場(chǎng)崩潰。我在讀取文件的編碼處理上做了兜底用errorsreplace把解析不了的字節(jié)替換成占位符保證進(jìn)程永遠(yuǎn)不因?yàn)榫幋a問題退出。如果你想做得更講究可以在讀取前先嘗試用utf-8解碼失敗再退回gbk但這會(huì)帶來性能損耗。實(shí)際場(chǎng)景下用一個(gè)寬容的編碼模式就足夠了畢竟日志監(jiān)控關(guān)心的是關(guān)鍵字匹配個(gè)別字符被替換成占位符不影響準(zhǔn)確度。4.3 通知服務(wù)變慢拖住主循環(huán)有一件事我印象特別深某次對(duì)接某個(gè)通知渠道的Webhook接口時(shí)那個(gè)接口響應(yīng)特別慢最長(zhǎng)一次花了20秒才返回。因?yàn)槲业拇a是在主循環(huán)里同步調(diào)用通知函數(shù)這20秒內(nèi)所有日志都堆積在緩沖區(qū)里嚴(yán)重時(shí)會(huì)導(dǎo)致告警整體延遲。排查了半天才發(fā)現(xiàn)問題根源不是網(wǎng)絡(luò)不穩(wěn)定而是代碼結(jié)構(gòu)上的同步調(diào)用形成的阻塞。后來我把通知操作全部改成獨(dú)立線程池來處理主循環(huán)只管讀日志和匹配規(guī)則通知進(jìn)去后排隊(duì)發(fā)送不阻塞主流程。這算是一個(gè)架構(gòu)層面的經(jīng)驗(yàn)監(jiān)控程序的主循環(huán)越輕越好。所有可能耗時(shí)的操作——發(fā)郵件、發(fā)HTTP請(qǐng)求、寫日志——都應(yīng)該異步化確保日志讀取速率和匹配判斷速率永遠(yuǎn)不受外部因素拖累。4.4 自監(jiān)控機(jī)制誰來看守守望者監(jiān)控腳本崩潰了怎么辦這是個(gè)容易忽略但非常重要的問題。有人覺得用了systemd的Restartalways就萬事大吉但如果腳本本身邏輯進(jìn)入死循環(huán)或者規(guī)則文件被改壞導(dǎo)致啟動(dòng)失敗restart只是在反復(fù)快速重啟一個(gè)壞掉的程序而已。后來我加了一個(gè)心跳機(jī)制在systemd服務(wù)里增加一個(gè)健康檢查定時(shí)檢查腳本的心跳文件是否更新。同時(shí)正式環(huán)境中我還會(huì)再部署一個(gè)獨(dú)立的cron任務(wù)每一分鐘檢查一下監(jiān)控進(jìn)程在不在如果不在就做一次告警。等于給監(jiān)控器自己也配了一個(gè)監(jiān)控器這一層我把它叫“自監(jiān)控”。沒有這層的話你永遠(yuǎn)不知道你的監(jiān)控已經(jīng)沉默了多久。4.5 規(guī)則集優(yōu)化的三個(gè)技巧規(guī)則文件寫多了以后麻煩事跟著來了關(guān)鍵詞太泛會(huì)誤報(bào)太具體又會(huì)漏報(bào)。我優(yōu)化規(guī)則集的過程中積累了幾個(gè)經(jīng)驗(yàn)第一關(guān)鍵詞盡量用能標(biāo)識(shí)根因的獨(dú)特文本別用單個(gè)短詞。比如“Connection refused”就比“error”好用得多它就明確指向連接失敗。第二要定期從歷史告警記錄里復(fù)盤調(diào)整規(guī)則。如果一條規(guī)則上線一個(gè)月從來沒觸發(fā)過我會(huì)考慮是不是關(guān)鍵詞太苛刻如果一條規(guī)則天天觸發(fā)但每次都是無害波動(dòng)就得考慮給這條規(guī)則升級(jí)條件或調(diào)低級(jí)別。第三規(guī)則文件設(shè)計(jì)成配置文件不要寫死在代碼里。我用了YAML這樣每次調(diào)整規(guī)則只需要改配置文件不用碰代碼邏輯也不用重啟主服務(wù)我加了一個(gè)配置文件熱加載機(jī)制。5. 工具選型解析與效果復(fù)盤5.1 技術(shù)選型為什么是Python日志監(jiān)控這個(gè)需求用其他語言也能做甚至C和Go的性能會(huì)更好。但對(duì)我而言Python是最高效的選擇。理由在于Python標(biāo)準(zhǔn)庫里的smtplib、os、time這些模塊已經(jīng)覆蓋了絕大部分需求不需要裝任何第三方包就能把整個(gè)流程跑通。加上Python做文本處理的代碼寫起來最順手正則在字符串匹配上又靈活又方便開發(fā)速度確實(shí)快。如果你非常在意性能或者是大型分布式環(huán)境里部署用Go寫一個(gè)這樣的工具會(huì)更從容但那是另一個(gè)復(fù)雜度等級(jí)的故事。單機(jī)或少量服務(wù)器的場(chǎng)景Python完全夠用實(shí)測(cè)每秒處理上千行日志不成問題這個(gè)量級(jí)對(duì)絕大多數(shù)中小業(yè)務(wù)來說綽綽有余。5.2 完整的配置模板我把最終在用的配置模板簡(jiǎn)化了一份放在這里大家可以參考修改。配置分兩部分通知渠道配置和規(guī)則集合。通知配置里可以放多個(gè)渠道規(guī)則按業(yè)務(wù)定義各自的關(guān)注點(diǎn)和觸發(fā)條件。# config.yaml notify_channels: dingtalk: webhook_url: https://oapi.dingtalk.com/robot/send?access_token你的token enabled: true mail: server: smtp.example.com port: 465 use_tls: true username: monitorexample.com password: 你的密碼 to_addrs: [opsexample.com, leadexample.com] enabled: true rules: - name: 數(shù)據(jù)庫連接失敗 file: /var/log/app/db.log keywords: [connection refused, connect timeout] exclude_keywords: [recovered] # 排除恢復(fù)信息 level: critical alert_throttle: 300 notify: [dingtalk, mail] - name: 接口異常 file: /var/log/app/api.log keywords: [internal server error, exception in handler] level: important alert_throttle: 600 notify: [mail]exclude_keywords是后來加的一個(gè)重要字段。某些錯(cuò)誤日志后面緊跟著恢復(fù)日志比如“connection refused ... recovered”這種復(fù)合場(chǎng)景下如果你的規(guī)則只看關(guān)鍵詞“connection refused”就會(huì)誤報(bào)。加上排除關(guān)鍵詞后命中間隔內(nèi)如果出現(xiàn)恢復(fù)標(biāo)志就自動(dòng)解除警報(bào)等待狀態(tài)大大降低誤報(bào)率。5.3 效果數(shù)據(jù)與維護(hù)建議這套系統(tǒng)上線之后我把它接入了三臺(tái)應(yīng)用服務(wù)器覆蓋了數(shù)據(jù)庫錯(cuò)誤、接口異常、服務(wù)重啟等十多種場(chǎng)景。運(yùn)行三個(gè)月觀察到的情況是有效告警約六十條真正需要人工介入的故障占六成左右其他四成屬于自動(dòng)恢復(fù)的波動(dòng)但這類波動(dòng)因?yàn)樽隽祟l率控制只收到一條匯總信息沒有形成騷擾。日常維護(hù)方面我會(huì)建議每個(gè)月花十分鐘做一次規(guī)則復(fù)盤。具體操作就是打開告警歷史記錄看看哪類告警占比最高、哪類告警一次都沒觸發(fā)過。高頻的告警看是否誤報(bào)低頻的告警看關(guān)鍵詞是否需要調(diào)整。這個(gè)習(xí)慣能讓告警系統(tǒng)越用越貼合業(yè)務(wù)實(shí)際而不是越用越招人煩。6. 后續(xù)演進(jìn)空間與個(gè)人心得這套系統(tǒng)跑到今天功能上已經(jīng)穩(wěn)定了但我知道它還有很多可以擴(kuò)展的地方。比如現(xiàn)在匹配規(guī)則是單行匹配如果有些異常需要跨行匹配就要引入更復(fù)雜的上下文分析。比如你已經(jīng)積累的告警記錄可以做成周報(bào)模板每周自動(dòng)匯總發(fā)送給團(tuán)隊(duì)。這些都是低成本高價(jià)值的延伸方向。最后分享一點(diǎn)個(gè)人體會(huì)。做監(jiān)控系統(tǒng)最核心的不是技術(shù)而是克制。告警這個(gè)東西不是越多越好越靈敏越好而是要恰到好處。你設(shè)計(jì)的規(guī)則要讓收到告警的人愿意看、敢相信、快速行動(dòng)如果這個(gè)目標(biāo)沒有達(dá)成你告警系統(tǒng)寫得再炫酷都沒有意義。我見過很多團(tuán)隊(duì)的告警群長(zhǎng)期被無效信息轟炸之后真正出事的時(shí)候反而沒人看了。所以我把這套系統(tǒng)設(shè)計(jì)得“保守”——寧可偶爾漏掉一個(gè)邊界情況也不要讓高頻誤報(bào)消耗掉團(tuán)隊(duì)的應(yīng)急精力。這套系統(tǒng)用到現(xiàn)在告警量一直維持在一個(gè)讓人安心的量級(jí)團(tuán)隊(duì)對(duì)每一條告警的信任度都還很高。如果讀完這篇你也準(zhǔn)備搞一套建議一開始就定好這個(gè)調(diào)子。