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