記錄應用系統日誌主要有三個原因：記錄操作軌跡、監控系統運行狀況、回溯系統故障。 記錄操作軌跡：可以數據化分析用户偏好，有助於優化系統業務邏輯，為用户提供個性化服務。如：通過access.log記錄用户的操作頻率和跳轉鏈接，有助於分析用户後續行為。監控系統運行狀況：全面有效的日誌系統有助於建立完善的應用監控體系。通過應用監控體系，可以實時監控系統運行狀況，及時預警，避免故障發送。系統運行狀況是指服務器的運行狀態，如內存、CPU等使用情況；應用運行狀況，如接口RT（響應時間）、QPS等。應用錯誤信息，如NPE、SQL異常、數據轉換失敗等。回溯系統故障：完整的現場日誌方便快速定位問題，並迅速處理
一、日誌的記錄點要求
在程序執行過程中，以下5類日誌記錄點必須記錄日誌：
本系統接受到外部請求時（本地入口）；
本系統調用其他模塊或系統時（調用其他）；
本系統調用其他模塊或系統結束時（調用結束）；
本系統處理結束時（本地出口）；
本系統捕捉到錯誤時（出錯時）；
初始化參數時
初始化參數在各種框架裏面可以看到一些內容，而在自己開發的業務中則使用打印業務參數閲讀相關內容 系統核心角色，組件關鍵動作 ：主要是核心業務的觸發動作，但是需要避免非常高頻率的打印，同時對於日誌進行提煉 上述日誌記錄點，除出錯時，均應該按[INFO]級別登記
二、日誌的記錄內容規則
應用程序日誌原則上使用UTF-8字符編碼，以便於將來的日誌文件分析。 不要使用系統輸出記錄日誌,如System.out.print, printStackTrace。不能將應用日誌寫入生產環境基礎系統的日誌。（如SystemErr.log、SystemOut.log）； 日誌記錄應及時、完整，日誌應該符合安全規範，不要在日誌信息裏包含安全敏感信息,敏感信息主要有客户身份信息如客户賬號、名稱、證件號、交易核心信息如交易金額、交易備註、安全控制信息如安全認證方式、密碼。
1.日誌輸出不允許影響系統正常運行。
2.日誌輸出需符合安全審計要求，不允許產生安全問題，不允許輸出敏感信息，支持保密機制。
3.日誌輸出格式嚴格按照要求、合理的打印信息，如對於交易日誌，必須記錄，對於程序調試中非關鍵節點的日誌交付前進行刪除，無需記錄
4.日誌輸出內容能夠提供開發和運維人員快速定位到故障問題原因。
5.日誌按照一定的策略支持備份，如日期、時間等。
6.最小10M，缺省情況下，每個日誌文件的大小限制為100M，超過限制，則必須寫入到另一個帶新序號的日誌文件中
7.一定要控制日誌輸出量，以免出現磁盤空間不足。同時要為日誌設置合理的生命週期，及時清理過期日誌。避免重複打印，務必在日誌配置文件中設置additivity=false
三、日誌的性能要求
1、輸出日誌記錄不能過於頻繁。一般情況下10毫秒內不能輸出3條以上日誌信息；
2、輸出的日誌內容不能過長。一般情況下每行日誌信息原則上不能超過2K字節，一條日誌輸出代碼產生的日誌內容不能超過40行；
3、輸出日誌信息的函數代碼不能包含複雜的CPU計算，導致產生過多的CPU。
4.不建議打印查詢list，尤其沒有分頁的
5.控制日誌輸出的長度在一定範圍內，比如請求參數，避免打印大量的業務日誌 如日誌layout中 msg配置為 %.-4096msg，輸出日誌長度最長為4096字節，多餘的將從後面截斷不打印;
6.【建議】在循環，響應式編程中謹慎log
7.【建議】批量任務，大量mq，不建議每行均打印
8.【建議】gateway等網關中log需謹慎， gateway默認線程數很少，等你打印io線程消耗性能，遇到上傳文件+報文解密+打印日誌的時候，併發能力下降到2位數
9.【建議】報文加/解密 前後打印log，沒必要 和第三方交互時，入參、出參可能是需要加密和解密，如果報文體積較大，明文和密文都打印沒有意義，算法測試成功後，個人認為加解密成功的情況下打印明文，計算失敗時異常中打印原文即可
10.【建議】如果開源jar包日誌需要特別注意 如shardingsphere-jdbc等，需要關閉日誌 如無法關閉，可以設置獨立的logger，和其他應用日誌分開 mybatis，eureka心跳等日誌建議分開打印，不要和業務日誌混在一起 日誌按用途劃分，避免業務日誌，框架日誌，混合，業務日誌也應分模塊打印： https://www.jb51.net/article/247048.htm，且日誌使用rolling進行分割
11.在tps有高要求的場景應該異步打印，參考:https://www.cnblogs.com/yangyongjie/p/16230247.html
四、日誌的等級分類
DEBUG 細粒度的、對出錯（debug）、以及系統調試時候輸出的信息、事件。
INFO 在正常運行狀態中，粗粒度的、關於重要流程/事件的、可用來表示系統健康度的信息、事件。在INFO級別不允許把SQL語句、報文等這些作為日誌內容輸出。
WARN 有潛在風險的、不會造成大危害的錯誤（往往由應用外部因素造成，如不正確的輸入數據）
ERROR 應用發生錯誤（包括業務錯誤和技術錯誤），但後續流程還能夠繼續進行 FATAL 應用發生嚴重錯誤（技術型異常），應用服務被終止。
五、日誌的目錄和文件名
1.應用日誌輸出至/app/logs目錄下；
2.應用日誌文件名以.log後綴結尾；
3.應用日誌中每行以LEVEL開頭；
4.把不同類型的日誌分離出去,應用中的擴展日誌（如打點、臨時監控、訪問日誌等）命名方式： appName_logType_logName.log。logType：日誌類型，如 stats/monitor/access/error 等；logName：日誌描述。這種命名的好處：通過文件名就可知道日誌文件屬於什麼應用，什 麼類型，什麼目的，也有利於歸類查找。説明：推薦對日誌進行分類，如將錯誤日誌和正常 日誌分開存放，便於開發人員查看，也便於通過日誌對系統進行及時監控。
六、日誌的大小
日誌文件的大小應該可以通過參數控制（log4j2 可配置），如果超過限制，則必須寫入到另一個帶新序號的日誌文件中,且不能超過本次磁盤預警值： 參考：log4j2官網：Log4j – Log4j 2 Appenders 下面是一個示例配置，它使用滾動文件追加器，其時間和大小都基於時間 觸發策略，將在同一天創建最多 100 個存檔 （1-100） 存儲在目錄中 根據當前年份和月份，並將壓縮每個 使用 gzip 存檔，每小時滾動一次。 在每次翻轉期間，此配置將刪除與“/app-.log.gz”匹配的文件 並且出生 30 天或以上， 但保留最近的 100 GB 或最近的 10 個文件，以先到者為準 logback：官網：Chapter 4: Appenders 譯文：第四章：Appenders - logback 中的maxHistory處 其他注意點：https://www.cnblogs.com/ZTPX/p/14090313.html
七、日誌的清理
一般情況下，日誌文件按照磁盤預警值和監控組對接需求定時清理一次，移出日誌目錄； 對於有審計需求的日誌，按照審計規定對這些文件進行歸檔，歸檔數據轉入存儲服務器。
八、日誌打印注意事項
1.記錄異常時一定要輸出異常堆棧。如下：logger.error("xxx"+e.getMessage(), e)
2.日誌中如果輸出對象實例，要確保實例類重寫了toString方法，否則只會輸出對象的hashCode值。 注：logger應被定義為static，與類綁定，防止浪費資源。 使用slf4j+日誌庫模式時，要防止日誌庫衝突，一旦發生則可能會出現日誌打印功能失效問題
3.不要在打印日誌時造成異常
4.日誌框架選型 logback、log4j2 logback：推薦，Springboot默認的日誌框架 log4j2：版本大於2.15.0
5.日誌格式 日誌輸出基本格式（有任何需求按規範添加）： •pid[級別] 時間調用鏈標識[業務標識] [線程名] [線程上線映射變量] [類名] [行號] [日誌內容] [換行] 即：[%-5p] [%d{yyyy-MM-dd HH:mm:ss,SSS}] [%t] [%-1X{變量名}] [%C:%L] [%m] %n
6.日誌級別得支持動態修改，要麼actuator通過post接口動態修改日誌級別，要麼放到配置中心來修改
7.鏈路追蹤 通過 AOP 切面，日誌框架 MDC 等技術結合，在日誌中打印traceId，而後根據traceId可檢索整個請求鏈路的日誌
1）AOP切面結合MDC方式 ①、日誌配置文件中配置traceId佔位符 Gherkin <pattern>%date{yyyy-MM-dd HH:mm:ss.SSS}|%t|%-5level|%X{traceId}|%C{0}#%M:%L|%msg%n</pattern> ②、AOP切入要增強traceId的方法 ③、在增強類中往MDC中添加traceId字段，並賦值，並在finally塊移除MDC中traceId字段
2）直接使用MDC方式
①、日誌配置文件中配置traceId佔位符，同上
②、在方法執行業務邏輯前往MDC中添加traceId字段，並賦值
③、在方法返回前移除MDC中的traceId字段
3）在線程池中沒采取阿里ttl方式做mdc前線程池必須手動使用mdc打印，防止鏈路追蹤失敗
-
不要記錄異常又拋出 記錄之後拋出異常是非常危險的操作，因為外層可能會因為內層捕獲異常之後不會再次處理，如果是自定義異常更是難以排查問題，此外這樣做法會導致堆棧二次打印，非常浪費系統性能，
-
核心功能模塊日誌 如果是核心功能模塊的日誌，其實多打印一些內容是可以接受的，但是需要注意打印的日誌必須要第一時間可以定位到問題所在。 監控系統集成：建議將日誌和監控系統打通，將日誌信息傳遞給監控系統，以便實時監控系統的運行狀態和性能指標。
- 理想的日誌中應該記錄不多不少的信息 l 不要在日誌中記錄無用的信息，實踐中常見到的無用的日誌有： 1）能夠放在一條日誌裏的東西，放在多條日誌中輸出； 2）預期會發生且能夠被正常處理的異常，打印出一堆無用的堆棧； 3）開發人員在開發過程中為了調試方便而加入的“臨時”日誌 l 對於日誌的使用者，能夠從日誌中得到所有需要的信息
