日志規(guī)范
服務指標
image.png
1.事前預防(預防降低故障幾率)
? 監(jiān)控預警
? 日常健康度巡檢
? 穩(wěn)定性checklist
? 研發(fā)規(guī)范
? 容量規(guī)劃
? 壓測
? 回滾措施
? 容錯設計
? 依賴治理
? 慢sql 治理
? 故障演練
? 應急預案
2.事中處理（處理應對，止損恢復）
? 監(jiān)控告警
? 重啟
? 回滾
? 快速擴容
? 熔斷降級
? 服務流控
? 服務補償
? 問題快速定位
? 信息同步
3.事后復盤（復盤優(yōu)化）
? 故障案例復盤
? 損失統(tǒng)計
? 系統(tǒng)優(yōu)化
? Checklist 完善
規(guī)范日志目的
為了達到發(fā)生error異常告警后，開發(fā)立馬能介入并且快速定位問題。目前監(jiān)控主要是針對error日志，其實后面將會根據(jù)情況，對關(guān)鍵接口的接口請求、耗時等等都做監(jiān)控。
目前存在的問題
- 日志打印的不是太規(guī)范，導致error太多，真正有效的信息也被淹沒了
- 沒有及時關(guān)注異常
- 日志不夠細膩，打印的太泛
改造后的要求
遇到ERROR告警必須解決，找到原因，排期上線
統(tǒng)一好工具等
全局異常攔截類對日志的打印
@ControllerAdvice的類，對于業(yè)務異常，只打印warn級別，其他的使用自帶的攔截器，需要自己排查一下項目這個全局異常攔截的打印情況異常類（BusinessException等）
使用統(tǒng)一的異常攔截類http的公共工具類，都需要支持打印返回值，方便排查
使用LocalDate, 使用
javax.validation-api對接口參數(shù)進行校驗
1.如何打好日志
INFO
- 核心的配置加載，變化等都需要打?。喝?code>kafka是否啟動，
加載xxx是否成功，定時任務是否啟動等等 - 處理
核心、重要任務時候流程中，比如在開始計算每個任務的開始信息等等。會參與計算，以及比較核心的信息都可以打出來。 -
核心、重要業(yè)務的增，刪，改在修改后都必須打印日志 - 對于
核心、重要業(yè)務在開始走流程的時候，都建議打印入?yún)?，以及開始標志，結(jié)束后打印出參，以及結(jié)束標志。耗時的話根據(jù)業(yè)務情況增加
WARN
- 對于程序出現(xiàn)異常，但是并不需要人工介入，依靠代碼容錯機制等即可恢復的就可考慮打印warn，例如：配置文件未配置，但是有默認值
- 對于業(yè)務異常，但是是屬于正常業(yè)務的范圍內(nèi)，也僅需要打warn，同時根據(jù)業(yè)務情況可以考慮不打印。
例如：- 調(diào)用參數(shù)異常
- 一些異常數(shù)據(jù)，但是這些異常數(shù)據(jù)是老的數(shù)據(jù)并不影響主流程
- 對于業(yè)務并無影響，或者就算報錯了，也沒關(guān)系，不影響其他的，可以考慮僅打印warn
ERROR
- 對于rpc，http等形式調(diào)用其他服務，都需要考慮try-catch異常，打印包括入?yún)?/strong>, 出參，返回結(jié)果等錯誤信息。
改造后需要考慮catch住異常和拋出去的區(qū)別，如果不知道有什么影響可以先catch住，打印錯誤信息后，再次拋出 - 對于業(yè)務，出現(xiàn)程序無法處理，需要人工介入才能恢復的問題，也是需要打印error日志，將詳細的參數(shù)信息打印好
告警處理
- 細分錯誤種類
- 對于已知錯誤閾值可調(diào)高（例如調(diào)用不穩(wěn)定的下游超時），配置好熔斷
- 對于未知錯誤要做到靈敏，有錯誤就解決
- 告警分組，靈敏、非核心的告警盡量只知會系統(tǒng)相關(guān)的人，出現(xiàn)大量的錯誤，嚴重的錯誤，告知范圍擴大到全組，方便所有人跟進
監(jiān)控
監(jiān)控大屏的搭建，對于一些核心指標必須有（多個維度的：業(yè)務指標、基礎組件、性能指標等等），例如：
image.png
這些指標也需要設置對應的告警，大于、小于多少的閾值，各種環(huán)比的閾值等等
