前言
最近老黃一直在弄雙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，用日誌服務做統計肯定是不成問題的，難度相對比較低。
下面是具體的效果。
打碼比較多，將就一下。
由於控制檯上面提供了自動重新整理和全屏的功能，所以掛皮膚出來的時候就可以省去人工的干預了。
總結
週一晚上被投訴，週二上午出方案，週二下午開搞，週三出結果，這一波操作真的是猛如虎。
不得不說，阿里雲的日誌服務確實是簡化了很多繁瑣的操作。
但是抽取日誌的方式還有待完善，有點彆扭。