開發中日誌這個問題，每個公司都強調，也制定了一大堆規範，但根據實際情況看，效果不是很明顯，主要是這個東西不好測試和考核，沒有日誌功能一樣跑啊。
但程式設計活久見，開發久了，總會遇到「這個問題生產環境上能重現，但是沒有日誌，業務很複雜，不知道哪一步出錯了？」 這個時候，怎麼辦？ 還能怎麼辦，發個版本，就是把所有地方加上日誌，沒有任何新功能，然後在讓使用者重現一遍，拿下日誌來看，哦，原來是這個問題。
有沒有很熟悉的感覺？
還有一種情況，我們系統有3*5=15個節點，出了問題找日誌真是痛苦，乙個乙個機器翻，n分鐘後終於找到了，找到了後發現好多相似日誌，乙個乙個排查；日誌有了，發現邏輯很複雜，不知道走到那個分支，只能根據邏輯分析，半天過去了，終於找到了原因。。。乙個問題定位就過去了2個小時，變更時間過去了一半。。。
所以我對日誌的最少有以下2點要求：
1 能找到那個機器
2 能找到使用者做了什麼
針對第一點，我修改了一下nginx的配置檔案，讓返回頭裡面返回是那個機器處理的。
nginx的基本配置，大家查閱一下資料就知道。簡單配置如下（生產環境比這個完善）
效果如圖，返回了處理的節點：
filter中得到使用者資訊，並放入mdc，記住filter後要清理掉（因為tomcat執行緒池執行緒重用的原因）。
使用者資訊放入mdc：
log4j配置，增加使用者資訊變數：
我做好上面2步後，對開發人員的日誌只有3點要求：
1. 修改（包括新增）操作必須列印日誌
大部分問題都是修改導致的。資料修改必須有據可查。
2. 條件分支必須列印條件值，重要引數必須列印
尤其是分支條件的引數，列印後就不用分析和猜測走那個分支了，很重要！如下面**裡面的usertype，一定要列印值，因為他決定了**走那個分支
3. 資料量大的時候需要列印資料量
前後列印日誌和最後的資料量，主要用於分析效能
，能從日誌中知道查詢了多少資料用了多久。這點是建議。自己視情況而決定是否列印，我一般建議列印。
加上 我的編碼習慣 - controller規範
其實日誌的級別我到不是很關注，還沒有到關注這步到時候。開發組長需要做好後勤工作（前面2步），然後制定簡單規則，規則太多太能落實了。
日誌這個東西，更多是靠自覺，專案組這麼多人，我也不可能乙個乙個給大家看**，然後叫你加日誌。我分析了一下，為什麼有些人沒有列印日誌的習慣，說了多次都改不過來。我建議大家養成下面的習慣，這樣你的日誌就會改善多了！
1.不要依賴debug，多依賴日誌。
別人面對物件程式設計，你面對debug程式設計。有些人無論什麼語言，最後都變成了面對debug程式設計。哈哈。這個習慣非常非常不好！debug會讓你寫**的時候偷懶不打日誌，而且很浪費時間。改掉這個惡習。
2. **開發測試完成之後不要急著提交，先跑一遍看看日誌是否看得懂。
日誌是給人看的，只要熱愛程式設計的人才能成為合格程式設計師，不要匆匆忙忙寫完功能測試ok就提交**，日誌也是功能的一部分。要有精益求精的工匠精神！
**：
我的iOS高效程式設計秘訣 堅持程式設計習慣
習慣會影響乙個人做事的方式，也會直接影響效率。我經常在專案完成後自我總結，有哪些做得好的，有哪些做得不好的？然後把一些好的流程記錄下來，並且重新運用回程式設計中。那些能夠堅持去做的流程，就變成了我的程式設計習慣，這些良好的習慣就成就了我高效的程式設計效率 一 輕文件先行 什麼叫輕文件？其實輕文件指的...
我的命名習慣
1，小寫，兩個詞中使用 來連線。2，收集專業的詞語 3，固定縮寫詞 a,型別 by byty b bool w word dw dword i int l long f float d double str cstring c char sz char p pointer lp long point...
我的習慣清單
從2010年5月21日開始執行 我要養成的好習慣 我需要改掉的壞習慣 每天早晨6 40起床，看半小時與技術無關的書籍。晚上吃的多。做事不拖拉，第一次就把事情做好，做徹底，不要為沒做好的事情找藉口 理由。看電視時間過長。學會拒絕，無論是生活中 朋友中 還是同事 工作中。看電視時間過長。每天早上上班和下...