🔥🔥🔥你應該打好你的日誌,起碼避免被甩鍋🥘🥘

蓝胖子的编程梦發表於2024-03-10

大家好,我是藍胖子,相信大家或多或少都有這樣的經歷,當你負責的功能出現線上問題時,領導第一時間便是找到你詢問原因,然而有時問題的根因或許不在你這兒,只是這個功能或許依賴了第三方或者內部其他部門,這個時候快速排查問題根因就是關鍵,給領導留個快速解決問題的印象,績效也找不到理由給你打低了。

而日誌作為最簡單最直接的排查問題手段,就起到了至關重要的作用, 關於如何打日誌,我談談我的一些感悟。

日誌應該由什麼組成

首先,我們來思考下日誌應該具有哪些維度的資訊,日誌無非就是要記錄,什麼時間,什麼地點,發生了什麼事情。

針對於應用程式來說,就是哪臺主機,哪個應用服務,哪種業務,在某個時間點,出現了什麼問題

這裡要特別注意的是🔊🔊🔊,日誌應該包含業務的上下文資訊,例如,要記錄某個使用者做了支付行為,你應該要記錄使用者的id,訂單號,甚至可以更詳細點,把訂單的價格,購買的商品資訊都記錄下來,以便後續排查問題時能直接透過日誌找到使用者的支付記錄。

當然,業務的上下文資訊需要根據業務情況決定,不同業務需要考慮下需要列印的業務資訊。

列印的日誌格式,我還是建議json,畢竟json 更容易被分析,特別是如果是當用上ELK這類的日誌收集框架後,能很容易對日誌提取欄位進行分析。比如將日誌中的應用服務名稱欄位提取出來,在ELK中做聚合分析,我們能分析出某段時間內,究竟是哪個應用在瘋狂的打日誌。

甚至也可以從日誌中提取業務場景欄位,對其進行聚合分析,得出某段時間內,那種業務在瘋狂列印日誌,評估其日誌列印是否合理,如下圖所示,是在kibana上對過去15小時的日誌按業務場景對日誌量進行的分析。

image.png

我總結下,日誌的基本組成如下

{"host"="主機名",log_time="列印日誌格式",app="應用服務名稱",action="業務場景",msg="描述資訊", err="如果有錯誤列印錯誤資訊",  業務上下文資訊....} 

日誌的作用

日誌除了按上面提到的進行聚合統計分析系統日誌量情況外,還可以按業務維度的欄位進行聚合分析,比如將業務場景欄位設定為登入,利用它統計每天,每小時登入的人數。利用日誌做一些業務維度的監控

當然,日誌除了去進行分析統計外,更是為了解決問題,對出錯進行恢復,讓系統留下執行的痕跡而列印的。列印日誌前,一定要想清楚,我們需要解決的問題。

舉一個場景,藍胖子之前在服務中做過郵寄服務,由於郵寄需要依靠第三方的介面,並且整個郵寄的邏輯比較複雜,會有許多郵寄過濾條件,並且後續的產品功能持續有對這部分過濾邏輯進行修改,如何在對第三方介面進行容錯,如何後續的迭代過程中對 過濾程式碼進行容錯,保證出錯後能有辦法恢復出錯使用者的郵寄就成了要思考的問題。

其實要解決這類問題,最簡單的辦法就是將程式的執行軌跡能用日誌表示出來,有了日誌,日誌被ELK此類日誌收集元件收集後,後續就能透過ELK對日誌進行搜尋下載,進而恢復資料。所以,藍胖子在開始郵寄之前,把人員名單記錄了下來,把後續郵寄過程中出錯的人員,無論是第三方介面呼叫出錯,還是程式內部對資料庫或者快取的訪問出錯,把它們的錯誤原因和出錯時影響到的使用者名稱單都記錄了下來,並且將那些由於郵寄過濾條件過濾掉的使用者和過濾原因也記錄了下來,最後,把郵寄成功的使用者記錄下來。

可以看到,最終我只要透過日誌,就能找出最終郵寄成功的使用者,以及郵寄失敗的使用者,整個郵寄過程就變透明瞭,如果有郵寄失敗的使用者,我也可以透過日誌進行恢復。

那你可能會想,那我乾脆將程式所有介面,每步操作都打上日誌,不就好了嗎,其實也是不對的🚫🚫🚫。

1,會讓程式碼變得很臃腫😮‍💨。

2, 列印的日誌量也是很大,影響磁碟容量以及日誌分析元件收集,因為多了很多無效日誌。

所以,下面我給出幾條列印日誌的建議,

打日誌最佳實踐

☝🏻第一條,在請求第三方介面或者內部部門介面的時候,你應該要對介面引數以及返回結果進行列印。比較重要的場景甚至還需要對錯誤情況進行告警🚨。這樣起碼在介面出錯時,在第三方部門需要你提供引數時能及時撈出日誌。

第二條在程式對資料進行修改時,記錄下改動日誌,這也是為了讓程式留下執行的痕跡,有助於我們知道對資料做了哪些改動,以便後續出錯時,能透過日誌對資料進行回滾修復。甚至為了讓這個原則更加容易落地,我們可以修改資料庫的客戶端庫,通常這類庫會提供許多埋點鉤子函式,我們可以實現它們讓其在進行delete,update,insert操作時,對sql進行記錄,記錄下對資料的改動。

第三條,程式出現報錯時記錄日誌,這條基本是準則,不過就像前面提到的那樣,在記錄時除了記錄錯誤資訊,還需要記錄下錯誤的上下文,比如是哪個使用者,涉及到了哪些業務資料。

第四條,可以利用日誌做一些關鍵業務資訊的監控,特別是一些複雜的業務邏輯,透過日誌記錄來讓業務流程透明化。就像藍胖子之前提到的對接郵件服務那樣,讓郵寄過程透明化,也有利於對我們程式的出錯恢復。

最後,

自薦一波✅:

歡迎朋友們關注我的公眾號📢📢:【藍胖子的程式設計夢】!

學習容器知識🐳,效能監控🚀,Golang🐋 相關程式設計知識

相關文章