程式設計師你為什麼這麼累【續】:編碼習慣之日誌建議

weixin_33968104發表於2017-09-24

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

原創 2017-08-29 曉風輕 程式猿DD
——請先閱讀這3篇文章:
程式設計師你為什麼這麼累?

我的編碼習慣 - 介面定義

我的編碼習慣 - Controller規範

開發中日誌這個問題,每個公司都強調,也制定了一大堆規範,但根據實際情況看,效果不是很明顯,主要是這個東西不好測試和考核,沒有日誌功能一樣跑啊。
但程式設計活久見,開發久了,總會遇到“這個問題生產環境上能重現,但是沒有日誌,業務很複雜,不知道哪一步出錯了?” 這個時候,怎麼辦? 還能怎麼辦,發個版本,就是把所有地方加上日誌,沒有任何新功能,然後在讓使用者重現一遍,拿下日誌來看,哦,原來是這個問題。
有沒有很熟悉的感覺?

5737996-d631dfcde997a449.jpeg

還有一種情況,我們系統有3*5=15個節點,出了問題找日誌真是痛苦,一個一個機器翻,N分鐘後終於找到了,找到了後發現好多相似日誌,一個一個排查;日誌有了,發現邏輯很複雜,不知道走到哪個分支,只能根據邏輯分析,半天過去了,終於找到了原因。。。一個問題定位就過去了2個小時,變更時間過去了一半。。。
5737996-08f387c3826d7a86.jpeg

所以我對日誌的最少有以下2點要求:
能找到那個機器

能找到使用者做了什麼

針對第一點,我修改了一下nginx的配置檔案,讓返回頭裡面返回是哪個機器處理的。
nginx的基本配置,大家查閱一下資料就知道。簡單配置如下(生產環境比這個完善)

5737996-096b915305db5cd7.png

效果如圖,返回了處理的節點:
5737996-9c6d2805c68bd63d.png

第二點,要知道使用者做了什麼。使用者資訊是很重要的一個資訊,能幫助海量日誌裡面能快速找到目標日誌。一開始要求開發人員列印的時候帶上使用者,但是發現這個落地不容易,開發人員列印日誌都經常忘記,更加不用說日誌上加上使用者資訊,我也不可能天天看程式碼。所以找了一下log4j的配置,果然log4j有個叫MDC(Mapped Diagnostic Context)的類(技術上使用了ThreadLocal實現,重點技術)。具體使用方法請自行查詢。具體使用如下:
filter中得到使用者資訊,並放入MDC,記住filter後要清理掉(因為tomcat執行緒池執行緒重用的原因)。
5737996-109cfc3c725be6ca.png

使用者資訊放入MDC:
5737996-ad7d9ef5ac913db8.png

log4j配置,增加使用者資訊變數:
5737996-6fe4af3db904f59b.png

我做好上面2步後,對開發人員的日誌只有3點要求:
1. 修改(包括新增)操作必須列印日誌
大部分問題都是修改導致的。資料修改必須有據可查。
2. 條件分支必須列印條件值,重要引數必須列印
尤其是分支條件的引數,列印後就不用分析和猜測走哪個分支了,很重要!如下面程式碼裡面的userType,一定要列印值,因為他決定了程式碼走哪個分支。
5737996-803633e823c0464e.png

3. 資料量大的時候需要列印資料量
前後列印日誌和最後的資料量,主要用於分析效能,能從日誌中知道查詢了多少資料用了多久。這點是建議。自己視情況而決定是否列印,我一般建議列印。
加上一篇AOP,最後的日誌如下:
5737996-cc09b3550bd63f46.png

其實日誌的級別我到不是很關注,還沒有到關注這步到時候。開發組長需要做好後勤工作(前面2步),然後制定簡單規則,規則太多太能落實了。
日誌這個東西,更多是靠自覺,專案組這麼多人,我也不可能一個一個給大家看程式碼,然後叫你加日誌。我分析了一下,為什麼有些人沒有列印日誌的習慣,說了多次都改不過來。我建議大家養成下面的習慣,這樣你的日誌就會改善多了!
1. 不要依賴debug,多依賴日誌。
別人面對物件程式設計,你面對debug程式設計。有些人無論什麼語言,最後都變成了面對debug程式設計。哈哈。這個習慣非常非常不好!debug會讓你寫程式碼的時候偷懶不打日誌,而且很浪費時間。改掉這個惡習。
2. 程式碼開發測試完成之後不要急著提交,先跑一遍看看日誌是否看得懂。
日誌是給人看的,只要熱愛程式設計的人才能成為合格程式設計師,不要匆匆忙忙寫完功能測試ok就提交程式碼,日誌也是功能的一部分。要有精益求精的工匠精神!
日誌規範想不到寫了這麼多,不容易啊。覺得有幫助請點贊加關注,其他規範敬請期待!更多內容請持續關注!
推薦閱讀
程式設計師你為什麼這麼累?

程式設計師你為什麼這麼累[續]:編碼習慣之介面定義

Logback+ELK+SpringMVC搭建日誌收集伺服器

在Pivotal Web Service上釋出Spring Boot應用

Spring Cloud構建微服務架構:服務閘道器(基礎)【Dalston版】

相關文章