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