原創(chuàng) 2017-08-29 曉風輕 程序猿DD
——請先閱讀這3篇文章:
程序員你為什么這么累？
我的編碼習慣 - Controller規(guī)范
開發(fā)中日志這個問題，每個公司都強調，也制定了一大堆規(guī)范，但根據(jù)實際情況看，效果不是很明顯，主要是這個東西不好測試和考核，沒有日志功能一樣跑啊。
但編程活久見，開發(fā)久了，總會遇到“這個問題生產(chǎn)環(huán)境上能重現(xiàn)，但是沒有日志，業(yè)務很復雜，不知道哪一步出錯了？” 這個時候，怎么辦？ 還能怎么辦，發(fā)個版本，就是把所有地方加上日志，沒有任何新功能，然后在讓用戶重現(xiàn)一遍，拿下日志來看，哦，原來是這個問題。
有沒有很熟悉的感覺？
還有一種情況，我們系統(tǒng)有3*5=15個節(jié)點，出了問題找日志真是痛苦，一個一個機器翻，N分鐘后終于找到了，找到了后發(fā)現(xiàn)好多相似日志，一個一個排查；日志有了，發(fā)現(xiàn)邏輯很復雜，不知道走到哪個分支，只能根據(jù)邏輯分析，半天過去了，終于找到了原因。。。一個問題定位就過去了2個小時，變更時間過去了一半。。。
所以我對日志的最少有以下2點要求：
能找到那個機器
能找到用戶做了什么
針對第一點，我修改了一下nginx的配置文件，讓返回頭里面返回是哪個機器處理的。
nginx的基本配置，大家查閱一下資料就知道。簡單配置如下（生產(chǎn)環(huán)境比這個完善）
效果如圖，返回了處理的節(jié)點：
第二點，要知道用戶做了什么。用戶信息是很重要的一個信息，能幫助海量日志里面能快速找到目標日志。一開始要求開發(fā)人員打印的時候帶上用戶，但是發(fā)現(xiàn)這個落地不容易，開發(fā)人員打印日志都經(jīng)常忘記，更加不用說日志上加上用戶信息，我也不可能天天看代碼。所以找了一下log4j的配置，果然log4j有個叫MDC(Mapped Diagnostic Context)的類（技術上使用了ThreadLocal實現(xiàn)，重點技術）。具體使用方法請自行查詢。具體使用如下：
filter中得到用戶信息，并放入MDC，記住filter后要清理掉（因為tomcat線程池線程重用的原因）。
用戶信息放入MDC：
log4j配置，增加用戶信息變量：
我做好上面2步后，對開發(fā)人員的日志只有3點要求：
1. 修改（包括新增）操作必須打印日志
大部分問題都是修改導致的。數(shù)據(jù)修改必須有據(jù)可查。
2. 條件分支必須打印條件值，重要參數(shù)必須打印
尤其是分支條件的參數(shù)，打印后就不用分析和猜測走哪個分支了，很重要！如下面代碼里面的userType，一定要打印值，因為他決定了代碼走哪個分支。
3. 數(shù)據(jù)量大的時候需要打印數(shù)據(jù)量
前后打印日志和最后的數(shù)據(jù)量，主要用于分析性能，能從日志中知道查詢了多少數(shù)據(jù)用了多久。這點是建議。自己視情況而決定是否打印，我一般建議打印。
加上一篇AOP，最后的日志如下：
其實日志的級別我到不是很關注，還沒有到關注這步到時候。開發(fā)組長需要做好后勤工作（前面2步），然后制定簡單規(guī)則，規(guī)則太多太能落實了。
日志這個東西，更多是靠自覺，項目組這么多人，我也不可能一個一個給大家看代碼，然后叫你加日志。我分析了一下，為什么有些人沒有打印日志的習慣，說了多次都改不過來。我建議大家養(yǎng)成下面的習慣，這樣你的日志就會改善多了！
1. 不要依賴debug，多依賴日志。
別人面對對象編程，你面對debug編程。有些人無論什么語言，最后都變成了面對debug編程。哈哈。這個習慣非常非常不好！debug會讓你寫代碼的時候偷懶不打日志，而且很浪費時間。改掉這個惡習。
2. 代碼開發(fā)測試完成之后不要急著提交，先跑一遍看看日志是否看得懂。
日志是給人看的，只要熱愛編程的人才能成為合格程序員，不要匆匆忙忙寫完功能測試ok就提交代碼，日志也是功能的一部分。要有精益求精的工匠精神！
日志規(guī)范想不到寫了這么多，不容易啊。覺得有幫助請點贊加關注，其他規(guī)范敬請期待！更多內容請持續(xù)關注！
推薦閱讀
程序員你為什么這么累？
Logback+ELK+SpringMVC搭建日志收集服務器
