程序員你爲何這麼累【續】:編碼習慣之日誌建議

轉自:https://mp.weixin.qq.com/s?__biz=MzAxODcyNjEzNQ==&mid=2247484164&idx=1&sn=8351e9fb42e6471e31d1c060d46bfafa&chksm=9bd0ae9caca7278a0941e8044a042775a707ec0dc8873f4da4bc1a7628f2462a10085a83206c&mpshare=1&scene=23&srcid=0924D5ojSzBQKv8V7EmXAqxs#rdnginx

 

——請先閱讀這3篇文章:程序員

開發中日誌這個問題,每一個公司都強調,也制定了一大堆規範,但根據實際狀況看,效果不是很明顯,主要是這個東西很差測試和考覈,沒有日誌功能同樣跑啊。架構

但編程活久見,開發久了,總會遇到「這個問題生產環境上能重現,可是沒有日誌,業務很複雜,不知道哪一步出錯了?」 這個時候,怎麼辦? 還能怎麼辦,發個版本,就是把全部地方加上日誌,沒有任何新功能,而後在讓用戶重現一遍,拿下日誌來看,哦,原來是這個問題。app

有沒有很熟悉的感受?微服務

還有一種狀況,咱們系統有3*5=15個節點,出了問題找日誌真是痛苦,一個一個機器翻,N分鐘後終於找到了,找到了後發現好多類似日誌,一個一個排查;日誌有了,發現邏輯很複雜,不知道走到哪一個分支,只能根據邏輯分析,半天過去了,終於找到了緣由。。。一個問題定位就過去了2個小時,變動時間過去了一半。。。post

因此我對日誌的最少有如下2點要求:性能

  1. 能找到那個機器

  2. 能找到用戶作了什麼

針對第一點,我修改了一下nginx的配置文件,讓返回頭裏面返回是哪一個機器處理的。

nginx的基本配置,你們查閱一下資料就知道。簡單配置以下(生產環境比這個完善)

效果如圖,返回了處理的節點:

第二點,要知道用戶作了什麼。用戶信息是很重要的一個信息,能幫助海量日誌裏面能快速找到目標日誌。一開始要求開發人員打印的時候帶上用戶,可是發現這個落地不容易,開發人員打印日誌都常常忘記,更加不用說日誌上加上用戶信息,我也不可能每天看代碼。因此找了一下log4j的配置,果真log4j有個叫MDC(Mapped Diagnostic Context)的類(技術上使用了ThreadLocal實現,重點技術)。具體使用方法請自行查詢。具體使用以下:

filter中獲得用戶信息,並放入MDC,記住filter後要清理掉(由於tomcat線程池線程重用的緣由)。

用戶信息放入MDC:

log4j配置,增長用戶信息變量:

我作好上面2步後,對開發人員的日誌只有3點要求:

1. 修改(包括新增)操做必須打印日誌

大部分問題都是修改致使的。數據修改必須有據可查。

2. 條件分支必須打印條件值,重要參數必須打印

尤爲是分支條件的參數,打印後就不用分析和猜想走哪一個分支了,很重要!以下面代碼裏面的userType,必定要打印值,由於他決定了代碼走哪一個分支。

3. 數據量大的時候須要打印數據量

先後打印日誌和最後的數據量,主要用於分析性能,能從日誌中知道查詢了多少數據用了多久。這點是建議。本身視狀況而決定是否打印,我通常建議打印。

加上一篇AOP,最後的日誌以下:

其實日誌的級別我到不是很關注,尚未到關注這步到時候。開發組長鬚要作好後勤工做(前面2步),而後制定簡單規則,規則太多太能落實了。

日誌這個東西,更可能是靠自覺,項目組這麼多人,我也不可能一個一個給你們看代碼,而後叫你加日誌。我分析了一下,爲何有些人沒有打印日誌的習慣,說了屢次都改不過來。我建議你們養成下面的習慣,這樣你的日誌就會改善多了!

1. 不要依賴debug,多依賴日誌。

別人面對對象編程,你面對debug編程。有些人不管什麼語言,最後都變成了面對debug編程。哈哈。這個習慣很是很是很差!debug會讓你寫代碼的時候偷懶不打日誌,並且很浪費時間。改掉這個惡習。

2. 代碼開發測試完成以後不要急着提交,先跑一遍看看日誌是否看得懂。

日誌是給人看的,只要熱愛編程的人才能成爲合格程序員,不要匆匆忙忙寫完功能測試ok就提交代碼,日誌也是功能的一部分。要有精益求精的工匠精神!

日誌規範想不到寫了這麼多,不容易啊。以爲有幫助請點贊加關注,其餘規範敬請期待!更多內容請持續關注!

推薦閱讀

相關文章
相關標籤/搜索