過程
打印日志到分析查詢之間，還隔著收集、緩沖、聚合、加工、索引、存儲等若干個步驟，如下圖所示：
輸出
要是說好的日志能像文章一樣，讓人讀起來身心舒暢，這話肯定有夸大的成分，不過好的日志應(yīng)該能做到像“流水賬”一樣，可以毫無遺漏地記錄信息，格式統(tǒng)一，內(nèi)容恰當(dāng)。其中，“恰當(dāng)”是一個難點(diǎn)，它要求日志不應(yīng)該過多，也不應(yīng)該過少。
不該出現(xiàn)的內(nèi)容不要有
1、避免打印敏感信息
不用專門去提醒，我們肯定都知道不該把密碼、銀行賬號、身份證件等這些敏感信息打到日志里，但我就見過不止一個系統(tǒng)的日志中，能直接找到這些信息。一旦這些敏感信息隨日志流到了后續(xù)的索引、存儲、歸檔等步驟后，清理起來就會非常麻煩
2、避免引用慢操作
日志中打印的信息應(yīng)該是在上下文中可以直接取到的，而如果當(dāng)前的上下文中根本沒有這項(xiàng)數(shù)據(jù)，需要專門調(diào)用遠(yuǎn)程服務(wù)或者從數(shù)據(jù)庫中獲取，又或者要通過大量計(jì)算才能取到的話，那我們就應(yīng)該先考慮下，這項(xiàng)信息放到日志中是不是必要且恰當(dāng)?shù)?br>
3、避免打印追蹤診斷信
即日志中不要打印方法輸入?yún)?shù)、輸出結(jié)果、方法執(zhí)行時(shí)長之類的調(diào)試信息。這個觀點(diǎn)其實(shí)是反直覺的，不少公司甚至?xí)岢堰@一點(diǎn)作為最佳實(shí)踐，但是我仍然堅(jiān)持把它歸入反模式中。這是因?yàn)槿罩镜穆氊?zé)是記錄事件，而追蹤診斷應(yīng)該由追蹤系統(tǒng)去處理，哪怕貴公司完全沒有開發(fā)追蹤診斷方面功能的打算，我也建議使用BTrace或者Arthas這類“On-The-Fly”的工具來解決。還有，我之所以將其歸為反模式，也是因?yàn)榍懊嫠f的敏感信息、慢操作等主要源頭，就是這些原本想用于調(diào)試的日志。比如，當(dāng)前方法入口參數(shù)有個 User 對象，如果要輸出這個對象的話，常見的做法是將它序列化成 JSON 字符串，然后打到日志里。那么這個時(shí)候，User 里面的 Password 字段、BankCard 字段就很容易被暴露出來。再比如，當(dāng)前方法的返回值是個 Map，我們在開發(fā)期的調(diào)試數(shù)據(jù)只做了三五個 Entity，然后覺得遍歷一下把具體內(nèi)容打到日志里面沒什么問題。而到了生產(chǎn)期，這個 Map 里面有可能存放了成千上萬個 Entity，那么這時(shí)候打印日志就相當(dāng)于引用慢操作了。
自己思考：對外交互的接口，排開批量查詢的接口，還是建議能打則打。避免扯皮。
4、避免誤導(dǎo)他人
明明已經(jīng)在邏輯中妥善處理好了某個異常，只是偏習(xí)慣性地調(diào)用 printStackTrace() 方法，把堆棧打到日志中，那么一旦這個方法附近出現(xiàn)問題，由其他人來除錯的話，就很容易會盯著這段堆棧去找線索，從而浪費(fèi)大量時(shí)間。
該出現(xiàn)的內(nèi)容不要少
1、處理請求時(shí)的 TraceID
當(dāng)服務(wù)收到請求時(shí)，如果該請求沒有附帶 TraceID，就應(yīng)該自動生成唯一的 TraceID 來對請求進(jìn)行標(biāo)記，并使用 MDC 自動輸出到日志。TraceID 會貫穿整條調(diào)用鏈，目的是通過它把請求在分布式系統(tǒng)各個服務(wù)中的執(zhí)行過程給串聯(lián)起來。TraceID 通常也會隨著請求的響應(yīng)返回到客戶端，如果響應(yīng)內(nèi)容出現(xiàn)了異常，用戶就能通過此 ID 快速找到與問題相關(guān)的日志。這個 TraceID 其實(shí)是鏈路追蹤里的概念，類似的還有用于標(biāo)識進(jìn)程內(nèi)調(diào)用狀況的 SpanID，在 Java 程序中，這些都可以用 Spring Cloud Sleuth 來自動生成。另外，盡管 TraceID 在分布式追蹤系統(tǒng)中會發(fā)揮最大的作用，但對單體系統(tǒng)來說，將 TraceID 記錄到日志并返回給最終用戶，對快速定位錯誤也仍然十分有價(jià)值
2、系統(tǒng)運(yùn)行過程中的關(guān)鍵事件
我們都知道，日志的職責(zé)就是記錄事件，包括系統(tǒng)進(jìn)行了哪些操作、發(fā)生了哪些與預(yù)期不符的情況、在運(yùn)行期間出現(xiàn)了哪些未能處理的異?；蚓?、定期自動執(zhí)行的各種任務(wù)，等等，這些都應(yīng)該在日志中完整地記錄下來。那么原則上，程序中發(fā)生的事件只要有價(jià)值，就應(yīng)該去記錄，但我們還是要判斷清楚事件的重要程度，選定相匹配的日志的級別。至于如何快速處理大量日志，這是后面的步驟需要考慮的問題，如果輸出日志實(shí)在太頻繁，以至于影響到了性能，就應(yīng)該由運(yùn)維人員去調(diào)整全局或單個類的日志級別來解決。
3、啟動時(shí)輸出配置信息
與避免輸出診斷信息不同，對于系統(tǒng)啟動時(shí)或者檢測到配置中心變化時(shí)更新的配置，就應(yīng)該把非敏感的配置信息輸出到日志中，比如連接的數(shù)據(jù)庫、臨時(shí)目錄的路徑等等，因?yàn)槌跏蓟渲玫倪壿嬕话阒粫?zhí)行一次，不便于診斷時(shí)復(fù)現(xiàn)，所以應(yīng)該輸出到日志中。
