監控，一直是個可以聊很久的話題。除了系統監控，還有一個往往容易被忽略，今天我們就來聊聊這個容易忽略的業務監控。
監控什麼？
作爲開發人員，不僅僅是把功能開發出來就行了，對於你負責的產品或者模塊，你需要對它有足夠的瞭解，時時刻刻需要關注着，要有初戀的那種感覺纔行。
以電商最常見的下單功能來說，比如我想知道下單的成功率多少，下單的平均耗時，下單失敗中有多少是因爲庫存不足下單失敗的等等這類相關的信息。
有了這些業務指標信息，你就能知道你負責的產品現狀是什麼樣的，以及你需要做哪些改進。
至於要監控哪些指標，得跟着你的業務走。目的很明確，就是需要知道業務的狀況，並在某些時候能夠觸發告警。
實現方式
基於埋點的方式來進行數據的記錄，記錄到本地磁盤文件中，然後通過統一的日誌收集程序收集存儲，統計展示以及告警。
之所以基於埋點的方式實現是因爲需要知道每個業務接口的執行結果，成功還是失敗，失敗的原因是什麼。我們對於每個異常都定義了業務碼，可以根據業務碼知道異常原因。
如果用寫日誌的方式輸出數據，記得將業務日誌的數據文件單獨出來，不要和系統的日誌輸出在一起，否則不好收集解析。
用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微服務 入門 實戰與進階》作者, 公衆號猿天地發起人。