打印優(yōu)質(zhì)日志的十條軍規(guī)
前言
去年雙十一大促，我面對監(jiān)控大屏上瘋狂跳動的紅色指標(biāo)，顫抖著打開服務(wù)器日志，看到的卻是這樣的畫面：
用戶登錄失敗
訂單創(chuàng)建出錯(cuò) null
ERROR 非法參數(shù)那一刻我突然頓悟：寫不好日志的程序員，就像不會寫病歷的醫(yī)生。
這篇文章跟大家一起聊聊打印優(yōu)質(zhì)日志的10條軍規(guī)，希望對你會有所幫助。
第1條：格式統(tǒng)一
反例（管理看到會扣錢）：
log.info("start process");
log.error("error happen");無時(shí)間戳，無上下文。
正解代碼：
<!-- logback.xml核心配置 -->
<pattern>
%d{yy-MM-dd HH:mm:ss.SSS}
|%X{traceId:-NO_ID}
|%thread
|%-5level
|%logger{36}
|%msg%n
</pattern>在logback.xml中統(tǒng)一配置了日志的時(shí)間格式、tradeId，線程、等級、日志詳情都信息。
日志的格式統(tǒng)一了，更方便點(diǎn)位問題。
圖片
第2條：異常必帶堆棧
反例（同事看了想打人）：
try {
processOrder();
} catch (Exception e) {
log.error("處理失敗");
}出現(xiàn)異常了，日志中沒打印任何的異常堆棧信息。
相當(dāng)于自己把異常吃掉了。
非常不好排查問題。
正確姿勢：
log.error("訂單處理異常 orderId={}", orderId, e); // e必須存在！日志中記錄了出現(xiàn)異常的訂單號orderId和異常的堆棧信息e。
第3條：級別合理
反面教材：
log.debug("用戶余額不足 userId={}", userId); // 業(yè)務(wù)異常應(yīng)屬WARN
log.error("接口響應(yīng)稍慢"); // 普通超時(shí)屬INFO接口響應(yīng)稍慢，打印了error級別的日志，顯然不太合理。
正常情況下，普通超時(shí)屬INFO級別。
級別定義表：
級別 | 正確使用場景 |
FATAL | 系統(tǒng)即將崩潰（OOM、磁盤爆滿） |
ERROR | 核心業(yè)務(wù)失敗（支付失敗、訂單創(chuàng)建異常） |
WARN | 可恢復(fù)異常（重試成功、降級觸發(fā)） |
INFO | 關(guān)鍵流程節(jié)點(diǎn)（訂單狀態(tài)變更） |
DEBUG | 調(diào)試信息（參數(shù)流水、中間結(jié)果） |
第4條：參數(shù)完整
反例（讓運(yùn)維罵娘）：
log.info("用戶登錄失敗");上面這個(gè)日志只打印了“用戶登錄失敗”這個(gè)文案。
誰在哪登錄失敗？
偵探式日志：
log.warn("用戶登錄失敗 username={}, clientIP={}, failReasnotallow={}",
username, clientIP, "密碼錯(cuò)誤次數(shù)超限");登錄失敗的業(yè)務(wù)場景，需要記錄哪個(gè)用戶，ip是多少，在什么時(shí)間，登錄失敗了，失敗的原因是什么。
時(shí)間在logback.xml中統(tǒng)一配置了格式。
這樣才方便快速定位問題：
圖片
第5條：數(shù)據(jù)脫敏
血淚案例：某同事打印日志泄露用戶手機(jī)號被投訴。
我在記錄的日志中，需要對一下用戶的個(gè)人敏感數(shù)據(jù)做脫敏處理。
例如下面這樣：
// 脫敏工具類
public class LogMasker {
public static String maskMobile(String mobile) {
return mobile.replaceAll("(\\d{3})\\d{4}(\\d{4})", "$1****$2");
}
}
// 使用示例
log.info("用戶注冊 mobile={}", LogMasker.maskMobile("13812345678"));第6條：異步保性能
問題復(fù)現(xiàn)某次秒殺活動中直接同步寫日志，導(dǎo)致大量線程阻塞：
log.info("秒殺請求 userId={}, itemId={}", userId, itemId);高并發(fā)下IO阻塞。
致命傷害分析：
- 同步寫日志導(dǎo)致線程上下文切換頻繁
- 磁盤IO成為系統(tǒng)瓶頸
- 高峰期日志打印耗時(shí)占總RT的25%
正確示范（三步配置法）
步驟1：logback.xml配置異步通道
<!-- 異步Appender核心配置 -->
<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
<!-- 不丟失日志的閾值：當(dāng)隊(duì)列剩余容量＜此值時(shí)，TRACE/DEBUG級別日志將被丟棄 -->
<discardingThreshold>0</discardingThreshold>
<!-- 隊(duì)列深度：建議設(shè)為 (最大并發(fā)線程數(shù) × 2) -->
<queueSize>4096</queueSize>
<!-- 關(guān)聯(lián)真實(shí)Appender -->
<appender-ref ref="FILE"/>
</appender>步驟2：日志輸出優(yōu)化代碼
// 無需前置判斷，框架自動處理
log.debug("接收到MQ消息：{}", msg.toSimpleString()); // 自動異步寫入隊(duì)列
// 不應(yīng)做復(fù)雜計(jì)算后再打印（異步前仍在業(yè)務(wù)線程執(zhí)行）
// 錯(cuò)誤做法：
log.debug("詳細(xì)內(nèi)容：{}", computeExpensiveLog());流程圖如下：
圖片
步驟3：性能關(guān)鍵參數(shù)公式
最大內(nèi)存占用 ≈ 隊(duì)列長度 × 平均單條日志大小
推薦隊(duì)列深度 = 峰值TPS × 容忍最大延遲(秒)
例如：10000 TPS × 0.5s容忍 ? 5000隊(duì)列大小風(fēng)險(xiǎn)規(guī)避策略：
- 防隊(duì)列堆積：監(jiān)控隊(duì)列使用率，達(dá)80%觸發(fā)告警
- 防OOM：嚴(yán)格約束大對象toString()的調(diào)用
- 緊急逃生：預(yù)設(shè)JMX接口用于快速切換同步模式
第7條：鏈路追蹤
混沌場景：跨服務(wù)調(diào)用無法關(guān)聯(lián)日志。
我們需要有鏈路追蹤方案。
全鏈路方案：
// 攔截器注入traceId
MDC.put("traceId", UUID.randomUUID().toString().substring(0,8));
// 日志格式包含traceId
<pattern>%d{HH:mm:ss} |%X{traceId}| %msg%n</pattern>可以在MDC中設(shè)置traceId。
后面可以通過traceId全鏈路追蹤日志。
流程圖如下：
圖片
第8條：動態(tài)調(diào)參
半夜重啟的痛：線上問題需要臨時(shí)開DEBUG日志，比如：查詢用戶的某次異常操作的日志。
熱更新方案：
@GetMapping("/logLevel")
public String changeLogLevel(
@RequestParam String loggerName,
@RequestParam String level) {
Logger logger = (Logger) LoggerFactory.getLogger(loggerName);
logger.setLevel(Level.valueOf(level)); // 立即生效
return "OK";
}有時(shí)候我們需要臨時(shí)打印DEBUG日志，這就需要有個(gè)動態(tài)參數(shù)控制了。
否則每次調(diào)整打印日志級別都需要重啟服務(wù)，可能會影響用戶的正常使用。
journey
title 日志級別動態(tài)調(diào)整
section 舊模式
發(fā)現(xiàn)問題 --> 修改配置 --> 重啟應(yīng)用 --> 丟失現(xiàn)場
section 新模式
發(fā)現(xiàn)問題 --> 動態(tài)調(diào)整 --> 立即生效 --> 保持現(xiàn)場第9條：結(jié)構(gòu)化存儲
混沌日志：
用戶購買了蘋果手機(jī) 訂單號1001 金額8999上面的日志拼接成了一個(gè)字符串，雖說中間有空格分隔了，但哪些字段對應(yīng)了哪些值，看起來不是很清楚。
我們在存儲日志的時(shí)候，需要做結(jié)構(gòu)化存儲，方便快速的查詢和搜索。
機(jī)器友好式日志：
{
"event": "ORDER_CREATE",
"orderId": 1001,
"amount": 8999,
"products": [{"name":"iPhone", "sku": "A123"}]
}這里使用了json格式存儲日志。
日志中的數(shù)據(jù)一目了然。
第10條：智能監(jiān)控
最失敗案例：某次用戶開通會員操作，錯(cuò)誤日志堆積3天才被發(fā)現(xiàn)，黃花菜都涼了。
我們需要在項(xiàng)目中引入智能監(jiān)控。
ELK監(jiān)控方案：
圖片
報(bào)警規(guī)則示例：
ERROR日志連續(xù)5分鐘 > 100條 → 電話告警
WARN日志持續(xù)1小時(shí) → 郵件通知總結(jié)
研發(fā)人員的三大境界：
- 青銅：System.out.println("error！")
- 鉆石：標(biāo)準(zhǔn)化日志 + ELK監(jiān)控
- 王者：
日志驅(qū)動代碼優(yōu)化
異常預(yù)測系統(tǒng)
根因分析AI模型
最后的靈魂拷問：下次線上故障時(shí)，你的日志能讓新人5分鐘定位問題嗎？
