微服務業務監控和行爲分析怎麼作？試試日誌埋點

1、說明

互聯網公司通常都會有專門的數據團隊對公司的一些業務指標負責；爲了拿到這些基本的業務指標，通常也要工程團隊去配合作一些數據採集工做，因而埋點誕生了。
 

埋點的方式有不少種，本文主要介紹 日誌埋點 這種方式以及實現思路和案例。

日誌埋點 就是經過程序打印 log 日誌的方式進行業務/行爲數據的記錄

 

2、整體架構

經過 日誌埋點 來實現業務監控和行爲分析主要須要如下4個步驟

1. 數據生成(埋點)
2. 數據收集
3. 數據解析(結構化)
4. 數據落盤
5. 數據使用(展現/分析)

 

3、方案說明

3.1. 數據生成

日誌數據的生成直接使用 Logback 等日誌框架就能夠了，能夠本身封裝公共方法、aop、註解等方式來生成指定的埋點日誌

可是爲了便於後面的數據解析，日誌數據須要規範先行

• 全部的埋點日誌必需約定好統一的格式，例如：{時間}|{來源}|{對象id}|{類型}|{對象屬性(以&分割)}

按上面的格式生成的日誌爲：
2019-11-07 10:32:01|api-gateway|1|request-statistics|ip=171.221.203.106&browser=CHROME&operatingSystem=WINDOWS_10

• 避免埋點的日誌文件和系統自己輸出的日誌混淆

埋點的日誌輸出的目錄、文件等須要和應用自己的日誌分離，經過 Logback 的配置就能實現

 

埋點案例

生成日誌

網關埋點用戶請求

 

3.2. 數據收集

關於日誌數據的收集可選擇的中間件比較多，除了圖中的 FileBeat 以外還有 Flume、Fluentd、rsyslog 等；須要每臺服務器都部署一個收集中間件。

每臺服務器部署一個就好了，就算一臺服務器中啓了多個微服務也是能夠一齊收集

PS：日誌收集後面的 消息隊列 並非必需的能夠去掉，可是增長 消息隊列 後有如下兩個優勢

1. 削峯填谷：減輕後面日誌解析的壓力
2. 數據共享：日誌數據除了提供給日誌系統以外，能夠增長消費端的同時提供給其餘地方使用，如流計算等

 

3.3. 數據解析

使用 Logstash 的grok表達式解析日誌數據並結構化，以上面的日誌數據爲例

2019-11-07 10:32:01|api-gateway|1|request-statistics|ip=171.221.203.106&browser=CHROME&operatingSystem=WINDOWS_10

結構化後的日誌數據爲：

{
    timestamp: '2019-11-07 10:32:01',
    appName: 'api-gateway',
    resouceid: '1',
    type: 'request-statistics',
    ip: '171.221.203.106',
    browser: 'CHROME',
    operatingSystem: 'WINDOWS_10'
}

 

3.4. 數據落盤

經過 Logstash 能自動建立 Elasticsearch 索引並以天爲單位分片

能夠經過索引模板來指定每一個字段的類型和分詞器等屬性

 

3.5. 數據使用

日誌數據落盤到 Elasticsearch 後，就能夠經過聚合查詢等方式實時顯示監控數據或者分析日誌數據

監控案例

聚合查詢邏輯可參考 https://gitee.com/zlt2000/microservices-platform

 

4、總結

日誌埋點 只是其中一種埋點手段而已，優勢是系統無入侵且靈活；日誌收集、解析、落盤等均可以靈活搭配選擇不一樣的中間件，而且不須要修改源系統的代碼；而且能夠方便對接其餘分析平臺(例如: 大數據平臺)

PS：業務監控是否能夠不作日誌埋點，直接查詢業務的數據庫呢？(不建議這樣作)

1. 使用日誌埋點能實現監控數據與業務數據分離，監控平臺不會影響或增長業務數據庫的壓力
2. 使用日誌埋點能方便實現實時業務數據預警

舉個栗子：日誌收集後面添加 流計算中間件，計算某個時間窗口內優惠卷日誌的數量或者金額大於某個閥值，則發出預警

 

推薦閱讀

• 日誌排查問題困難？分佈式日誌鏈路跟蹤來幫你
• zuul集成Sentinel最新的網關流控組件
• Spring Cloud開發人員如何解決服務衝突和實例亂竄？
• Spring Cloud同步場景分佈式事務怎樣作？試試Seata
• Spring Cloud異步場景分佈式事務怎樣作？試試RocketMQ
• Spring Cloud Gateway的動態路由怎樣作？集成Nacos實現很簡單

 
掃碼關注有驚喜！