程序員的日常離不開日志舷夺，日志就好比私人秘書猖辫，負責(zé)運行周期一切trace工作。優(yōu)秀的日志實踐能極大幫助地程序員快速定位問題伍宦，減少在線錯誤報警芽死。本文將從日志書寫時各方面來做闡述，依據(jù)日志推薦的日志等級次洼，做相應(yīng)優(yōu)秀日志實踐的推薦关贵。
一、重新認識日志
1卖毁、日志級別概述
ERROR
ERROR是最高級別錯誤揖曾，反映系統(tǒng)發(fā)生了非常嚴重的故障，無法自動恢復(fù)到正常態(tài)工作势篡，需要人工介入處理翩肌。系統(tǒng)需要將錯誤相關(guān)痕跡以及錯誤細節(jié)記錄ERROR日志中模暗，方便后續(xù)人工回溯解決禁悠。
WARN
WARN是低級別異常日志，反映系統(tǒng)在業(yè)務(wù)處理時觸發(fā)了異常流程兑宇，但系統(tǒng)可恢復(fù)到正常態(tài)碍侦，下一次業(yè)務(wù)可以正常執(zhí)行。但WARN級別問題需要開發(fā)人員給予足夠關(guān)注隶糕，往往表示有參數(shù)校驗問題或者程序邏輯缺陷瓷产，當功能邏輯走入異常邏輯時，應(yīng)該考慮記錄WARN日志枚驻。
INFO
INFO日志主要記錄系統(tǒng)關(guān)鍵信息濒旦，旨在保留系統(tǒng)正常工作期間關(guān)鍵運行指標，開發(fā)人員可以將初始化系統(tǒng)配置再登、業(yè)務(wù)狀態(tài)變化信息尔邓，或者用戶業(yè)務(wù)流程中的核心處理記錄到INFO日志中，方便日常運維工作以及錯誤回溯時上下文場景復(fù)現(xiàn)锉矢。
DEBUG
DEBUG日志是INFO日志的好幫手梯嗽，開發(fā)人員可以將各類詳細信息記錄到DEBUG里，起到調(diào)試的作用沽损，包括參數(shù)信息灯节、調(diào)試細節(jié)信息、返回值信息等。其它等級不方便顯示的信息都可以通過DEBUG日志來記錄炎疆。
2卡骂、記錄日志的時機
在看線上日志時，我們可曾陷入到日志泥潭形入？該出現(xiàn)的日志沒有偿警，無用的日志一大堆，或者需要的信息分散在各個角落唯笙，特別是遇到緊急的在線bug時螟蒸，有效的日志被大量無意義的日志信息淹沒，焦急且無奈地浪費大量精力查詢?nèi)罩颈谰颉Ｄ鞘裁词怯涗浫罩镜暮线m時機呢七嫌？
總結(jié)幾個需要寫日志的點：
編程語言提示異常：如今各類主流的編程語言都包括異常機制，業(yè)務(wù)相關(guān)的流行框架有完整的異常模塊苞慢。這類捕獲的異常是系統(tǒng)告知開發(fā)人員需要加以關(guān)注的诵原，是質(zhì)量非常高的報錯。應(yīng)當適當記錄日志挽放，根據(jù)實際結(jié)合業(yè)務(wù)的情況使用WARN或者ERROR級別绍赛。
業(yè)務(wù)流程預(yù)期不符：除開平臺以及編程語言異常之外，項目代碼中結(jié)果與期望不符時也是日志場景之一辑畦，簡單來說所有流程分支都可以加入考慮吗蚌。取決于開發(fā)人員判斷能否容忍情形發(fā)生。常見的合適場景包括外部參數(shù)不正確纯出，數(shù)據(jù)處理問題導(dǎo)致返回碼不在合理范圍內(nèi)等蚯妇。
系統(tǒng)核心角色，組件關(guān)鍵動作：系統(tǒng)中核心角色觸發(fā)的業(yè)務(wù)動作是需要多加關(guān)注的暂筝，是衡量系統(tǒng)正常運行的重要指標箩言。建議記錄INFO級別日志，比如電商系統(tǒng)用戶從登錄到下單的整個流程焕襟；微服務(wù)各服務(wù)節(jié)點交互陨收；核心數(shù)據(jù)表增刪改；核心組件運行等鸵赖，如果日志頻度高或者打印量特別大务漩，可以提煉關(guān)鍵點INFO記錄，其余酌情考慮DEBUG級別卫漫。
系統(tǒng)初始化：系統(tǒng)或者服務(wù)的啟動參數(shù)菲饼。核心模塊或者組件初始化過程中往往依賴一些關(guān)鍵配置，根據(jù)參數(shù)不同會提供不一樣的服務(wù)列赎。務(wù)必在這里記錄INFO日志宏悦，打印出參數(shù)以及啟動完成態(tài)服務(wù)表述镐确。
3、警惕日志性能代價
不管是多么優(yōu)秀的日志工具饼煞，在日志輸出時總會對性能產(chǎn)生或多或少的影響源葫，為了將影響降低到最低，有以下幾個準則需要遵守：
根本原則：有必要才記錄日志砖瞧，頻繁過量日志對性能是有損耗的息堂，并且這種風(fēng)險不常在系統(tǒng)正常時出現(xiàn)，系統(tǒng)出現(xiàn)問題時大量ERROR块促、INFO等問題相關(guān)日志有可能產(chǎn)生連鎖反應(yīng)荣堰，造成嚴重的后果。將關(guān)鍵信息保存到日志竭翠，同時考慮極端場景日志爆發(fā)振坚。
Logger獲取：根據(jù)系統(tǒng)使用的日志框架組合斋扰，確定正確的實例獲取方式渡八。在log4j的早期版本，一般要求使用static传货，而在高版本以及后來的slf4j等一些框架封裝中屎鳍，該問題已經(jīng)得到優(yōu)化，獲任试！（創(chuàng)建）logger實例的成本已經(jīng)很低逮壁。但對于多例，尤其是需要頻繁創(chuàng)建的class僻澎，推薦添加static前綴貌踏。
輸出等級校驗：在log4j 1.x版本十饥，對于可以預(yù)見的會頻繁產(chǎn)生的日志輸出窟勃，先判斷一下(logger.isXXXEnabled()，對于性能有很大提升逗堵，在其它外觀框架或者log4j 2.x中已經(jīng)自動實現(xiàn)秉氧。
輸出格式：禁止使用字符串拼接，使用參數(shù)方式蜒秤。
樣式配置：布局配置輸出的信息也會影響到性能汁咏，需要根據(jù)logger的具體使用場景來選擇輸出合適信息。
??
上述幾點可以看出作媚，核心都是減少日志量 攘滩，前兩點偏向設(shè)計，后四點偏向日志框架及習(xí)慣纸泡，并且這四點目前一些框架組合已經(jīng)能幫開發(fā)人員減少不少工作漂问，比如log4j2.x在實例獲取，輸出等級判斷都有優(yōu)化。
除開減少日志量蚤假，還需要注意多線程以及高并發(fā)情況下的日志輸出栏饮。日志輸出本身是寫磁盤操作，自然會有性能瓶頸磷仰。更多屬于日志框架選擇及優(yōu)化方面袍嬉，選擇日志框架時除了考慮正常功能使用，務(wù)必關(guān)注該日志框架影響性能的細節(jié)灶平，日志的出發(fā)點是幫助處理問題伺通，如果成為隱患就得不償失了。介紹日志框架選擇的文章很多逢享，在此就不做詳細介紹了泵殴。
二、優(yōu)秀的INFO拼苍、DEBUG實踐
INFO和DEBUG級別日志描述的是系統(tǒng)正常運行時的表征笑诅。在監(jiān)控程序正常執(zhí)行，處理客服反饋疮鲫，分析用戶行為時起到重要作用吆你。因此優(yōu)秀的INFO、DEBUG日志能幫助開發(fā)人員快速了解運行時的各個細節(jié)俊犯。
1妇多、使用場景
線上問題跟蹤
??
客服反饋或者線上問題很難解決時，需要更多細節(jié)信息燕侠，這時會尋求日志的幫助者祖，ERROR、WARN绢彤、INFO都可能對解決問題有所幫助七问。必要時還需要開啟DEBUG日志幫忙在線定位問題。
場景還原
??
隨著數(shù)據(jù)重要性越來越高茫舶，日志的作用不再單單幫助糾錯械巡，構(gòu)建上下文也成為日志大放光彩的地方。還原一個會話饶氏，需要在日志中需要加入會話標識的概念讥耗，可以是簡單的ip或者復(fù)雜會話痕跡。常見包括以下兩個角度：
模塊維度記錄：登錄模塊疹启、商品詳情模塊古程、下單模塊、支付模塊喊崖、派發(fā)模塊等挣磨；
以行為維度記錄：在什么時間菲宴，在什么地方，在干什么趋急，結(jié)果是什么樣喝峦；統(tǒng)一加上會話標識以及時間屬性即可。這也是微服務(wù)日志以及數(shù)據(jù)分析的基礎(chǔ)呜达。
監(jiān)控調(diào)優(yōu)
對于系統(tǒng)的監(jiān)控調(diào)優(yōu)也是日常工作之一谣蠢，主要通過日志進行信息記錄，主要關(guān)注以下3個部分的日志：
請求處理時間
模塊操作處理的時間
核心組件操作的時間（DB查近、緩存眉踱、磁盤IO等）
2、日志內(nèi)容
日志應(yīng)當提供如下內(nèi)容：
時間霜威，包含時區(qū)信息和毫秒谈喳，這個工作往往日志框架足以支持。核心屬性之一戈泼。
日志級別婿禽，例如DEBUG、INFO以及WARN大猛、ERROR扭倾。
會話標識，能知道是哪個客戶端或者是哪個用戶觸發(fā)挽绩、登陸賬號膛壹、seesion信息等
功能標識，功能標識的意義在于方便日志搜索唉堪，跟蹤指定功能的完整軌跡模聋，是INFO、DEBUG日志的常見技巧唠亚。跟logger分類同一道理链方，更細分功能標識則是方法標識，更多使用在DEBUG做在線調(diào)試使用趾撵。
精煉的內(nèi)容侄柔，內(nèi)容永遠是日志的核心，結(jié)合上述使用場景占调，簡單來說包括場景信息（誰，什么功能等）移剪，狀態(tài)信息(開始究珊，中斷，結(jié)束)以及重要參數(shù)纵苛。
其它信息剿涮，其它可能的有用信息包括：版本號言津、線程號等。
3取试、INFO和DEBUG的選擇
DEBUG級別比INFO低悬槽，包含調(diào)試時更詳細地了解系統(tǒng)運行狀態(tài)的東西，比如變量的值等瞬浓，都可以輸出到DEBUG日志里初婆。 INFO是在線日志默認的輸出級別，反饋系統(tǒng)的當前狀態(tài)給最終用戶看的猿棉。輸出的信息磅叛，應(yīng)該對最終用戶具有實際意義的。
從功能角度上說萨赁，INFO輸出的信息可以看作是軟件產(chǎn)品的一部分弊琴，所以需要謹慎對待，不可隨便輸出杖爽。嘗試記錄INFO日志時不妨在頭腦中模擬線上運行敲董，如果這條日志會被頻繁打印或者大部分時間對于糾錯起不到作用，就應(yīng)當考慮下調(diào)為DEBUG級別慰安。
4臣缀、注意事項
由于INFO及DEBUG日志打印量遠大于ERROR，出于前文日志性能的考慮泻帮，如果代碼為核心代碼精置，執(zhí)行頻率非常高，務(wù)必推敲日志設(shè)計是否合理锣杂，是否需要下調(diào)為DEBUG級別日志脂倦。
注意日志的可讀性，不妨在寫完代碼review這條日志是否通順元莫，能否提供真正有意義的信息赖阻。
日志輸出是多線程公用的，如果有另外一個線程正在輸出日志踱蠢，上面的記錄就會被打斷火欧，最終顯示輸出和預(yù)想的就會不一致。
線上代碼禁止出現(xiàn)各類print等
不要認為記錄DEBUG就等同于在線忽略茎截。很多情況因為擔(dān)心線上出問題時缺少有用信息而對于等級猶豫不決苇侵，擔(dān)心記錄為DEBUG對于在線調(diào)試起不到作用。你需要的不是研究日志級別企锌，而是實時日志等級調(diào)整工具榆浓。嘗試記錄為DEBUG，線上有必要使用DEBUG級別調(diào)試時再調(diào)整對應(yīng)logger級別撕攒。
三陡鹃、優(yōu)秀的WARN烘浦、ERROR實踐
1、使用時機和思路
??
當方法或者功能處理過程中產(chǎn)生不符合預(yù)期結(jié)果或者有框架報錯時可以考慮使用萍鲸，常見問題處理方法包括：
增加判斷處理邏輯闷叉，嘗試本地解決
拋出異常，交給上層邏輯解決
記錄日志脊阴，報警提醒
使用返回碼包裝錯誤做返回
2握侧、幾個成長階段
不記錄日志，順其自然蹬叭，tomcat或者框架來捕獲最后的異常
方法出入口try catch藕咏， e.printstack()， system.out秽五， log混合使用
有判斷校驗減少異衬醪椋可能性，能合理小范圍使用try catch坦喘，使用log作為唯一記錄方式
靈活運用處理辦法盲再，合理拋留異常，報警少而精
3瓣铣、方法和準則
增加邏輯判斷吞掉報警永遠是最優(yōu)選擇答朋。
不在預(yù)期范圍內(nèi)的情景，則考慮返回碼包裝或者拋出異常棠笑，需要依情況而定：
返回碼的缺點： 不直觀梦碗，不友好，處處都需要進行顯示判斷蓖救，返回碼都有具體含義洪规，但字面不體現(xiàn)，持續(xù)維護時代碼理解成本高循捺。
異常機制的缺點：
必須在系統(tǒng)內(nèi)部斩例，多系統(tǒng)交互，前后臺交互場景等無法使用从橘。
每一個異常分支都可能需要單獨一個類作為描述和控制念赶，大量錯誤類型造成代碼量增加。
一旦拋出異常恰力，必須catch處理叉谜，挑選正確方式：
打印日志：當前邏輯就能處理掉的，不需要上層再處理的牺勾，或者本身就是最上層正罢。
重拋異常：判斷異常當前無法處理，需要繼續(xù)向上拋出驻民，可以經(jīng)過異常包裝轉(zhuǎn)義翻具。需要注意當前是否為最上層。
避免過大的try塊回还，盡量保持一個try塊對應(yīng)一個或多個異常裆泳。
細化異常的類型，避免不顧細節(jié)拋出Excetpion柠硕。異常類的作用就是告訴Java編譯器我們想要處理的是哪一種異常工禾，然后針對具體的異常類進行不同的處理。
函數(shù)返回值能表達錯誤含義蝗柔，則不應(yīng)該打印ERROR日志闻葵，防止ERROR日志泛濫。錯誤不一定到邊界才能終止癣丧，只要返回到能處理它的地方就應(yīng)當終止槽畔。
4、使用WARN和統(tǒng)計報警
一般來說胁编，WARN級別不會短信報警厢钧，ERROR級別則會短信報警甚至電話報警，ERROR級別的日志意味著系統(tǒng)中發(fā)生了非常嚴重的問題嬉橙，必須有人馬上處理早直，比如數(shù)據(jù)庫不可用、系統(tǒng)的關(guān)鍵業(yè)務(wù)流程走不下去等市框。錯誤的使用反而帶來嚴重的后果霞扬，不區(qū)分問題的重要程度，只要有問題就error記錄下來枫振，其實這樣是非常不負責(zé)任的喻圃，因為對于成熟的系統(tǒng)，都會有一套完整的報錯機制蒋得，那這個錯誤信息什么時候需要發(fā)出來级及，很多都是依據(jù)單位時間內(nèi)ERROR日志的數(shù)量來確定的。因此如果我們不分輕重緩急额衙，一律ERROR對待饮焦，就會徒增報錯的頻率，久而久之窍侧，我們的救火隊員對錯誤警報就不會那么在意县踢，這個警報也就失去了原始的意義。
??
WARN代表可恢復(fù)的異常伟件，此次失敗不影響下次業(yè)務(wù)的執(zhí)行硼啤，開發(fā)人員會苦惱某些場景下幾次失敗可容忍，頻率高的時候需要提醒斧账，記錄ERROR的結(jié)果是線上時不時出現(xiàn)容忍范圍內(nèi)的報警谴返，這時報警是無意義的煞肾。但反之，不記錄ERROR日志嗓袱，真正出現(xiàn)問題則不會有實時報警籍救，錯過最佳處理時機。
請使用WARN級別配合統(tǒng)計報警渠抹，統(tǒng)計報警的實現(xiàn)方法有很多種：代碼統(tǒng)計蝙昙、腳本統(tǒng)計、Zabbix統(tǒng)計等梧却，挑選合適的統(tǒng)計方式結(jié)合WARN級別奇颠，建立頻次報警機制，做到適時放航、適量提醒烈拒。
5、強調(diào)ERROR報警
ERROR的報出應(yīng)該伴隨著業(yè)務(wù)功能受損三椿，即上面提到的系統(tǒng)中發(fā)生了非常嚴重的問題缺菌，必須有人馬上處理。
6搜锰、ERROR日志目標
給處理者直接準確的信息：ERROR信息形成自身閉環(huán)伴郁。
問題定位：發(fā)生了什么問題，哪些功能受到影響
獲取幫助信息：直接幫助信息或幫助信息的存儲位置
通過報警知道解決方案或者找何人解決
7蛋叼、實用模板
日志模板2選1：
log.error(“[接口名或操作名] [Some Error Msg] happens. [Probably Because]. [Probably need to do] [params] .”);
log.error(“[接口名或操作名] [Some Error Msg] happens. [Probably Because]. [please contact xxx@xxx] [params] .”);
請盡量按上述模板完成焊傅，如果實施起來有難度，至少ERROR日志打印時需要在做一個自我問答狈涮，能非常有效地幫助評估這條報警是否有意義：這條報警看到之后我能處理嗎狐胎？ 應(yīng)該怎么處理? 如果是同事看到能處理或者及時通知聯(lián)系人呢嗎？ 因為你不可能保證隨時都處在工作狀態(tài)歌馍，但報警時隨時有可能出現(xiàn)的握巢。
8、注意事項
參數(shù)檢查不是異常
不要將屬于你的檢查工作變成ERROR日志松却。參數(shù)檢查屬于開發(fā)人員的工作暴浦，而不是全部交給日志。
留意業(yè)務(wù)相關(guān)性
技術(shù)相關(guān)異常是你需要記錄并為此做出反應(yīng)的晓锻。比如內(nèi)存不足歌焦，接口訪問超時。涉業(yè)務(wù)過深的返回需要結(jié)合實際情況考慮砚哆，比如用戶操作錯誤大多屬于業(yè)務(wù)范疇：用戶無權(quán)限參與這次活動返回碼独撇。在大多數(shù)場景下這個日志作用不大。
異常增加結(jié)構(gòu)化參數(shù)
異常代表一類錯誤，但僅僅是異常類型無法幫助解決問題纷铣。保留異陈咽罚現(xiàn)場參數(shù)，保證所有相關(guān)的堆棧追蹤信息的開始處記錄在你的日志中关炼。
不要記錄日志又重新向外拋出
四程腹、總結(jié)
實際項目中清晰的日志能帶來的好處想必不用多說匣吊。本文除開介紹常見日志等級以及實踐準則之外儒拂，更希望DEBUG、WARN兩種級別更多色鸳、更靈活地利用起來社痛，在項目中形成完整的日志體系。
日志規(guī)約
【強制】應(yīng)用中不可直接使用日志系統(tǒng)（Log4j命雀、Logback）中的API蒜哀，而應(yīng)依賴使用日志框架SLF4J中的API，使用門面模式的日志框架吏砂，有利于維護和各個類的日志處理方式統(tǒng)一撵儿。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
private static final Logger logger = LoggerFactory.getLogger(Abc.class);
slf4j是日志門面框架，其僅提供日志記錄的API狐血，而不實現(xiàn)日志記錄的功能淀歇，slf4j需要通過適配庫適配到log4j或logback等日志系統(tǒng)來實現(xiàn)日志的記錄。使用slf4j api能夠提升代碼和應(yīng)用的可移植性匈织，在使用不同日志系統(tǒng)的應(yīng)用之間能夠做到無縫的適配浪默。同時，使用slf4j api的應(yīng)用缀匕，在切換日志系統(tǒng)時（比如從logback切換到log4j2纳决，不需要代碼改造）
【強制】日志文件推薦至少保存15天，因為有些異常具備以“周”為頻次發(fā)生的特點乡小。
【強制】應(yīng)用中的擴展日志（如打點阔加、臨時監(jiān)控、訪問日志等）命名方式：appName_logType_logName.log满钟。
logType:日志類型胜榔，推薦分類有stats/desc/monitor/visit等；
logName:日志描述零远。這種命名的好處：通過文件名就可知道日志文件屬于什么應(yīng)用苗分，什么類型，什么目的牵辣，也有利于歸類查找摔癣。
正例：mppserver應(yīng)用中單獨監(jiān)控時區(qū)轉(zhuǎn)換異常，如： mppserver_monitor_timeZoneConvert.log
說明：推薦對日志進行分類，如將錯誤日志和業(yè)務(wù)日志分開存放择浊，便于開發(fā)人員查看戴卜，也便于通過日志對系統(tǒng)進行及時監(jiān)控。
【強制】對trace/debug/info級別的日志輸出琢岩，必須使用條件輸出形式或者使用占位符的方式投剥。
說明：logger.debug("Processing trade with id: " + id + " symbol: " + symbol); 如果日志級別是warn，上述日志不會打印担孔，但是會執(zhí)行字符串拼接操作江锨，如果symbol是對象，會執(zhí)行toString()方法糕篇，浪費了系統(tǒng)資源啄育，執(zhí)行了上述操作，最終日志卻沒有打印拌消。
正例：（條件）
if (logger.isDebugEnabled()) {
logger.debug("Processing trade with id: " + id + " symbol: " + symbol);
}
正例：（占位符）
logger.debug("Processing trade with id: {} symbol : {} ", id, symbol);
占位符方式挑豌，log4j2/logback支持，log4j1.x是不直接支持的墩崩，只能通過slf4j庫適配
【強制】避免重復(fù)打印日志氓英，浪費磁盤空間，務(wù)必在log4j.xml中設(shè)置additivity=false鹦筹。
正例：
additivity默認為true铝阐，即通過該logger輸出的日志會同時輸出到root logger，如果還為該logger指定了獨立的appender盛龄，就會導(dǎo)致這部分日志重復(fù)輸出
【強制】異常信息應(yīng)該包括兩類信息：案發(fā)現(xiàn)場信息和異常堆棧信息饰迹。如果不處理，那么通過關(guān)鍵字throws往上拋出余舶。
正例：
logger.error(各類參數(shù)或者對象toString + "_" + e.getMessage(), e);
記錄異常日志的常見錯誤：
logger.error(e);
logger.error(e.getMessage());
logger.error("上下文"+e.getMessage())啊鸭；
上面這幾種都是錯的！請確保使用的是兩個入?yún)⒌腁PI匿值，如error(String s, Throwable t)
【推薦】謹慎地記錄日志赠制。生產(chǎn)環(huán)境禁止輸出debug日志；有選擇地輸出info日志挟憔；如果使用warn來記錄剛上線時的業(yè)務(wù)行為信息钟些，一定要注意日志輸出量的問題，避免把服務(wù)器磁盤撐爆绊谭，并記得及時刪除這些觀察日志政恍。
PS:如果你想成為一名優(yōu)秀的架構(gòu)師，或者在工作中遇到瓶頸达传，想跳槽加薪篙耗，面試不過迫筑，
碰到難題等等一系列問題，可以加我的架構(gòu)師群：554355695
這里有最專業(yè)的團隊為你排憂解難宗弯，有最新的學(xué)習(xí)資源為你共享脯燃。
說明：大量地輸出無效日志，不利于系統(tǒng)性能提升蒙保，也不利于快速定位錯誤點辕棚。記錄日志時請思考：這些日志真的有人看嗎？看到這條日志你能做什么邓厕？能不能給問題排查帶來好處逝嚎？不要認為日志記錄不怎么消耗性能，我見過不少事無巨細式的日志把系統(tǒng)性能嚴重拖慢的案例
【參考】可以使用warn日志級別來記錄用戶輸入?yún)?shù)錯誤的情況邑狸，避免用戶投訴時懈糯，無所適從。注意日志輸出的級別单雾，error級別只記錄系統(tǒng)邏輯出錯、異常
