前言

最近老黃一直在弄雙11相關的東西，所以博客和github都沒怎么更新，這期間在公司也弄了不少東西。

下面就簡單分享一下最近做的業務監控相關的內容吧。

先來說一下背景。

某業務在雙11第一波大促的時候因為沒有提供實時的業務看板，總結會的時候技術同事被相關領導和業務人員投訴，說是沒辦法清晰的了解到當時的情況，不能及時有效的調整對應的策略。

事后老黃了解到，那個業務是比較老的業務了，資源比較緊張，不敢去實時懟數據庫(單點)，怕數據庫掛了，業務就全涼了。

為了避免尷尬的現狀，不想再一次挨批，只能搞呀。

分析現狀

3個應用，.NET Framework的項目，都是windows服務器，沒有容器化。

離雙11只有幾天，不能改動太大，而且還要應對業務部門新的需求。

當時能想到的方案

業務埋點，接入prometheus，結合grafana

業務發MQ，消費數據到ES，前端做個面板

業務埋點，接入日志服務，結合儀盤表

大致分析

• 方案1，業務團隊對prometheus幾乎是0認知，了解相關概念都要花不少時間，pass

• 方案2，MQ目前用的是騰訊云的CMQ，被坑過2次了，也不能很好的hold住ES，pass

• 方案3，有按內部規范打日志，業務方只要在關鍵地方加一行對應的日志，然后交由logtail去采集，上傳到日志服務

所以在這三種方案中，老黃還是選了方案三。

首先日志服務在內部各個系統都已經接入過了，也算是團隊里面比較熟悉的了，其次是不會影響主業務，只在關鍵地方埋點，加日志。

雖說對業務代碼有侵入性，但無疑是現階段的一個最優解。

整體實現邏輯如下。

業務埋點

業務埋點，其實是一個非常簡單，也是最為重要的一步。

我們有對應的日志幫助類，所以這里要處理的只是日志的內容。

SerilogHelper.Info($"[field1]?[field2]?[field3]",?"metrics_name");

老黃這里給的約定是，字段內容放在[]里面，每個字段要用空格隔開。

然后就會把日志落盤到具體的某個目錄，等著被Logtail采集到日志服務了。

當然這里有遇到一個問題，就是日志文件的格式，之前指定的是UTF-8，結果生成的文件是 UTF-8 with bom格式的。

這個會導致第一行日志不能被正確解析，所以要特別注意。

數據接入與展示

代碼層面在上面一步已經搞定了，下面要做的就是日志的接入了。

根據業務場景，目前是一個應用一個指標，所以要建立三個日志庫，按需選擇存儲時間，默認是永久。

建好日志庫后要接入數據源，這里老黃選的是正則-文本日志。

然后就是一堆常規配置了。

最重要的是Logtail配置這一步。

日志路徑，就是程序日志輸出的路徑，這樣logtail才會去設置的路徑采集。

正則是一個比較重要的內容，logtail會根據這個正則去解析日志，提取成一個個的字段，這樣會比較方便后面的查詢。

接下來是查詢分析的配置了。

這里就是要把統計的字段指定一下，還有一個是關掉全文索引，因為這種場景下，開全文索引意義不大，浪費錢。

到這一步，我們就可以把數據采集上來了。

最后要做的就是查詢結果了。只要會簡單的sql，用日志服務做統計肯定是不成問題的，難度相對比較低。

下面是具體的效果。

打碼比較多，將就一下。

由于控制臺上面提供了自動刷新和全屏的功能，所以掛面板出來的時候就可以省去人工的干預了。

總結

周一晚上被投訴，周二上午出方案，周二下午開搞，周三出結果，這一波操作真的是猛如虎。

不得不說，阿里云的日志服務確實是簡化了很多繁瑣的操作，解決了這一次問題的痛點。

但是抽取日志的方式還有待完善，有點別扭。

總結

以上是生活随笔為你收集整理的基于阿里云日志服务快速打造简版业务监控看板的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。