1. 程式人生 > >基於阿里雲日誌服務快速打造簡版業務監控看板

基於阿里雲日誌服務快速打造簡版業務監控看板

## 前言 最近老黃一直在弄雙11相關的東西,所以部落格和github都沒怎麼更新,這期間在公司也弄了不少東西。 下面就簡單分享一下業務監控相關的吧。 先來說一下背景吧。 某業務在雙11第一波大促的時候因為沒有提供實時的業務看板,總結會的時候技術同事被相關領導和業務人員投訴,說是沒辦法清晰的瞭解到當時的情況,不能及時有效的調整對應的策略。 事後老黃了解到,那個業務是比較老的業務了,資源比較緊張,不敢去實時懟資料庫(單點),怕資料庫掛了,業務就全涼了。 為了避免尷尬的現狀,不想再一次挨批,只能搞呀。 ## 分析現狀 3個應用,.NET Framework的專案,都是windows伺服器,沒有容器化。 離雙11只有幾天,不能改動太大,而且還要應對業務部門新的需求。 當時能想到的方案 1. 業務埋點,接入prometheus,結合grafana 2. 業務發MQ,消費資料到ES,前端做個面板 3. 業務埋點,接入日誌服務,結合儀盤表 大致分析 - 方案1,業務團隊對prometheus幾乎是0認知,瞭解相關概念都要花不少時間,pass - 方案2,MQ目前用的是騰訊雲的CMQ,被坑過2次了,也不能很好的hold住ES,pass - 方案3,有按內部規範打日誌,業務方只要在關鍵地方加一行對應的日誌,然後交由logtail去採集,上傳到日誌服務 所以在這三種方案中,老黃還是選了方案三。 首先日誌服務在內部各個系統都已經接入過了,也算是團隊裡面比較熟悉的了,其次是不會影響主業務,只在關鍵地方埋點,加日誌。 雖說對業務程式碼有侵入性,但無疑這是現階段一個最優解吧。 整體實現邏輯如下。 ![](https://img2020.cnblogs.com/blog/558945/202011/558945-20201108134052475-736558694.png) ## 業務埋點 業務埋點,其實是一個非常簡單,也是最為重要的一步。 我們有對應的日誌幫助類,所以這裡要處理的只是日誌的內容。 ```cs SerilogHelper.Info($"[field1] [field2] [field3]", "metrics_name"); ``` 老黃這裡給的約定是,欄位內容放在`[]`裡面,每個欄位要用空格隔開。 然後就會把日誌落盤到具體的某個目錄,等著被Logtail採集到日誌服務了。 當然這裡有遇到一個問題,就是日誌檔案的格式,之前指定的是`UTF-8`,結果生成的檔案是 `UTF-8 with bom`格式的。 這個會導致第一行日誌不能被正確解析,所以要特別注意。 ![](https://img2020.cnblogs.com/blog/558945/202011/558945-20201108134106600-257845209.png) ## 資料接入與展示 程式碼層面在上面一步已經搞定了,下面要做的就是日誌的接入了。 根據業務場景,目前是一個應用一個指標,所以要建立三個日誌庫,按需選擇儲存時間,預設是永久。 建好日誌庫後要接入資料來源,這裡老黃選的是**正則-文字日誌**。 ![](https://img2020.cnblogs.com/blog/558945/202011/558945-20201108134128448-194264922.png) 然後就是一堆常規配置了。 ![](https://img2020.cnblogs.com/blog/558945/202011/558945-20201108134138827-1502128700.png) 最重要的是`Logtail配置`這一步。 ![](https://img2020.cnblogs.com/blog/558945/202011/558945-20201108134148147-1047647607.png) 日誌路徑,就是程式日誌輸出的路徑,這樣logtail才會去設定的路徑採集。 正則是一個比較重要的內容,logtail會根據這個正則去解析日誌,提取成一個個的欄位,這樣會比較方便後面的查詢。 接下來是查詢分析的配置了。 ![](https://img2020.cnblogs.com/blog/558945/202011/558945-20201108134201108-757832500.png) 這裡就是要把統計的欄位指定一下,還有一個是關掉全文索引,因為這種場景下,開全文索引意義不大,浪費錢。 到這一步,我們就可以把資料採集上來了。 ![](https://img2020.cnblogs.com/blog/558945/202011/558945-20201108134213929-325030704.png) 最後要做的就是查詢結果了。只要會簡單的sql,用日誌服務做統計肯定是不成問題的,難度相對比較低。 下面是具體的效果。 ![](https://img2020.cnblogs.com/blog/558945/202011/558945-20201108134225439-402978605.png) 打碼比較多,將就一下。 由於控制檯上面提供了自動重新整理和全屏的功能,所以掛麵板出來的時候就可以省去人工的干預了。 ## 總結 週一晚上被投訴,週二上午出方案,週二下午開搞,週三出結果,這一波操作真的是猛如虎。 不得不說,阿里雲的日誌服務確實是簡化了很多繁瑣的操作。 但是抽取日誌的方式還有待完善,有點