主動做了業務監控，產品經理對我豎起大拇指
本文轉載自微信公眾號「猿天地」，作者尹吉歡 。轉載本文請聯系猿天地公眾號。
監控，一直是個可以聊很久的話題。除了系統監控，還有一個往往容易被忽略，今天我們就來聊聊這個容易忽略的業務監控。
監控什么?
作為開發人員，不僅僅是把功能開發出來就行了，對于你負責的產品或者模塊，你需要對它有足夠的了解，時時刻刻需要關注著，要有初戀的那種感覺才行。
以電商最常見的下單功能來說，比如我想知道下單的成功率多少，下單的平均耗時，下單失敗中有多少是因為庫存不足下單失敗的等等這類相關的信息。
有了這些業務指標信息，你就能知道你負責的產品現狀是什么樣的，以及你需要做哪些改進。
至于要監控哪些指標，得跟著你的業務走。目的很明確，就是需要知道業務的狀況，并在某些時候能夠觸發告警。
實現方式
基于埋點的方式來進行數據的記錄，記錄到本地磁盤文件中，然后通過統一的日志收集程序收集存儲，統計展示以及告警。
之所以基于埋點的方式實現是因為需要知道每個業務接口的執行結果，成功還是失敗，失敗的原因是什么。我們對于每個異常都定義了業務碼，可以根據業務碼知道異常原因。
如果用寫日志的方式輸出數據，記得將業務日志的數據文件單獨出來，不要和系統的日志輸出在一起，否則不好收集解析。
用logback可以單獨配置一個appender，我這邊只輸出了我埋點的業務數據，Json格式的。
- <appender name="BIZ_FILE_APPENDER" class="ch.qos.logback.core.rolling.RollingFileAppender">
- <encoder>
- <pattern>%m%n${LOG_EXCEPTION_CONVERSION_WORD:-%wEx}</pattern>
- </encoder>
- <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
- <FileNamePattern>${LOG_HOME_PATH_BIZ}/${APP_NAME}.%d{yyyy-MM-dd}.log</FileNamePattern>
- <MaxHistory>7</MaxHistory>
- </rollingPolicy>
- <filter class="ch.qos.logback.classic.filter.LevelFilter">
- <onMatch>ACCEPT</onMatch>
- <onMismatch>DENY</onMismatch>
- </filter>
- </appender>
日志文件內容：
- {"biz":"confirm","bizCode":500,"domain":"storeOrder","bizId":"86081301","execTime":3,"count":"1","storeId":"1","userId":"740942"}
- {"biz":"confirm","bizCode":500,"domain":"storeOrder","bizId":"86081301","errorMessage":"/ by zero","execTime":14,"count":"1","storeId":"1","userId":"740942"}
注解埋點
BizLog注解用于業務監控埋點，里面具體配置字段說明如下：
- domain: 領域，比如 order,pay
- biz: 業務，比如 createOrder,cancelOrder
- bizId: 業務ID，比如 orderId
- addition: 擴展信息
addition可以配置多個additionField獲取想要埋點的數據，數據可以從請求參數中獲取，也可以從相應參數中獲取，比如訂單創建成功后，會返回訂單ID, 那么bizId就是從響應參數中獲取。
代碼埋點
某些場景(支付回調，JOB任務等)下不太好通過注解方式埋點我們可以采用代碼埋點的方式來實現。
日志收集
我們用的是阿里云的日志服務，直接配置logtail即可完成收集工作，界面操作，非常方便。
指標展示
埋點原始數據
圖表統計展示
指標告警
數據都收集上來了，想要關注哪些指標，想要在什么時候告警，就變得很容易了。比如說某分鐘內下單頻繁失敗，這個時候你就可以配置告警失敗次數>N 觸發告警，當收到告警時，就馬上去排查為什么會下單失敗了。
關于作者：尹吉歡，簡單的技術愛好者，《Spring Cloud微服務-全棧技術與案例解析》, 《Spring Cloud微服務 入門 實戰與進階》作者, 公眾號猿天地發起人。
