一 前言在雲原生和DevOps研發模式的挑戰下，一個系統從開發、測試、到上線的整個過程中，會產生大量的日誌、指標、事件以及告警等數據，這也給企業質量平台建設帶來了很大的挑戰。本議題主要通過可觀測性的角度來討論基於海量日誌和時序數據的質量建設最佳實踐。
二 質量建設痛點眾所周知，在雲原生開發模式下，可觀測性是非常重要的一部分，它通過日誌、指標、Trace等數據，讓我們可以深入了解系統的運行狀態和健康程度。在CNCFLandscape大圖中，可觀測性也占據了相當大的一塊位置。
然而在實際使用過程中，許多人對可觀測性的關注，主要集中在系統上線之後。這當然是沒有問題的，但實際上，從一個系統開發開始，一直到線上運行，都是可以從可觀測的角度來對系統的質量進行評估和衡量，我們可以稱之為對質量的觀測。
下圖比較概括地描述了一個系統的質量觀測完整生命周期，大體上可以分為如下四個階段，並且在每個階段都有需要特別關注的一些數據和指標：
開發階段：重點需要關注代碼的質量，例如靜態代碼掃描以及依賴檢查會發現潛在的代碼缺陷和安全風險，由此我們可以統計千行代碼缺陷率或者嚴重缺陷比例，從而來衡量一個系統的代碼質量是否符合要求
測試階段：在此階段需要重點關注測試的質量，例如測試覆蓋率，以及測試用例的失敗率等指標
灰度驗證：需要關注系統的穩定性以及不同版本之間的差異，因此也會有一系列的業務指標，例如HTTP Error 比例，不同版本的延遲等指標的對比
線上運行：此時需要重點關注系統的穩定性以及業務的穩定性，因此各種線上的性能指標、業務指標、應用日誌、Trace等各種數據都是非常重要的在整個質量觀測的生命周期中，除了各種各樣的數據，我們也會涉及到各種各樣的系統，例如 GitLab、sonarqube、Allure、JMeter、Jenkins、Travis CI、Argo CD 等等。這些不同的系統作用於不同的階段，會產生大量的異構數據，如何對這些數據進行合理的管理和使用，從而可以比較方便地挖掘出其中的數據價值（不局限於軟件質量方面），對我們來說是一個比較大的挑戰。
基於上述的討論，我們可以大體總結出質量觀測的幾個痛點：
海量的異構數據：在系統開發、測試、驗證、上線等各個階段產生了大量的日誌、時序、Trace 等數據，這些數據產生的位置、數據格式、以及存儲的位置，都有可能是不一樣的。如何從這些數據中快速精準地挖掘出潛在的質量問題比較困難。
依賴規則，缺乏智能：質量監控比較依賴於人的經驗，很大程度上受限於人為設定的規則和閾值，無法做到數據自適應，因此無法發揮出真正的數據價值。另一方面就是隨着系統的發展和演進，需要大量的人工干涉和不斷調整，才能夠讓監控比較有效。
告警風暴與告警誤報：為了不錯過細微的問題，我們可能會配置大量的監控，從而導致在完整的軟件生命周期中可能產生大量的告警，難以從其中識別出有效信息。另外大量的告警也帶了很大程度上的誤報問題，從而導致「狼來了」效應，於是真正的問題反而很容易又被忽略掉。這就陷入了惡性循環。
三 數據統一接入和管理1 海量數據管理痛點首先我們來探討第一個痛點，也就是如何對海量的異構數據進行管理。目前可觀測性相關的系統五花八門。例如日誌可能會使用 ELK 或者 Splunk，指標會使用 Prometheus，Trace 使用 Skywalking、Jaeger 或者 zipkin。但太多的選擇也不見得是好事，在這種情況下，可觀測性數據的管理又給我們帶來了如下幾個痛點：
運維成本高：完整的質量系統需要數個甚至十多個軟件的協同，從而也帶了極高的運維成本。
學習成本高：每個軟件都有自己的使用插件、插件系統，有些還會有自己的DSL語法，學習成本非常高，很難完全掌握使用。
擴展困難：隨着數據規模的增長，軟件的擴展能力、性能、穩定能力等方面都會有很大的挑戰。
數據孤島：不同的數據處於不同的系統中，協同困難。例如想要將 ES 中的日誌和 Prometheus 中的指標進行一個 Join 查詢就無法實現，除非做額外的二次開發。
2 數據統一接入和管理基於上述幾個痛點，我們的解決方案是將這些異構的數據進行統一的存儲和管理，如下圖所示：
在這裡，我們將日誌、指標、Trace等數據全部接入到一個統一的可觀測性存儲中。然後基於這個統一的存儲，進行後續的查詢分析、可視化、監控告警、AI 等上層能力，甚至還可以進行數據的加工和規整，一站式地完成異構數據到同構數據的轉換過程。基於統一的存儲，我們可以構建統一的查詢和分析語法，從而一套語法適配不同的數據，並且讓不同的數據之間進行聯合查詢也變成了可能。如下圖所示，我們以標準 SQL 為基礎，進行了部分 DSL 擴展和 SQL 函數擴展，並融合了 PromQL，從而讓不同類型的數據查詢和分析變得統一。
還可以通過PromQL擴展的SQL函數對指標數據進行分析還可以通過嵌套查詢，對指標數據的分析結果進行再聚合此外還可以再通過機器學習函數，給查詢和分析賦予AI的能力
基於上述統一的數據存儲和查詢分析，我們可以非常輕鬆地實現統一的可視化和監控。如下圖所示，雖然不同階段的數據產生自不同的系統，也有着不同的格式，但是由於它們的存儲和分析是一致的，因此我們可以構建出統一的報表來查看各個階段的軟件質量，以及統一進行監控的配置和告警的管理，而無需將這些分散到各個不同的系統中，脫離例如 ES + Kibana、Prometheus + Grafana 等組合。
四 智能巡檢1 傳統監控的困難和挑戰接下來我們來看如何基於這些數據，讓監控更加智能。傳統的監控大多是基於一些固定的閾值，或者同環比。但是在很多場景下，這種模式存在着諸多問題。例如：
監控對象爆炸式增長：隨着雲原生的普及，服務部署越來越從以「主機」為中心向「容器化」方向轉化，容器本身的輕量化以及短生命周期等特點，導致監控對象和監控指標急劇增加。如果要全方位的覆蓋這些監控對象和指標，需要配置大量的監控規則，並且它們的閾值也可能是各不相同的，因此會有很大的工作量。
監控規則無法自適應：基於人為定義的閾值，很大程度上依賴於人的經驗，隨着系統的演化和業務的發展，這些規則往往不能很好地適應，由此不可避免地導致漏報、誤報等問題。無法做到數據的自適應，因此需要人為介入，不斷調整閾值。例如下圖：上面是一個指標，有規則性的毛刺。如果通過閾值來判斷是否需要告警，當一個毛刺點異常的時候，可能由於不滿足閾值，導致告警漏報。下面是另一個指標，可能隨着系統的進化，新版本發布之後，該指標的值會發生一個陡增。此時如果是固定閾值告警的話，會將陡增之後的所有數據都認為是異常點，導致告警頻繁觸發。此時需要人為介入去調整閾值。
監控規則泛化能力弱：不同的業務、甚至同一業務的不同版本，指標的規律性、閾值都有可能是不同的。因此我們需要為不同的業務、不同的版本去做監控規則的適配。例如下圖，雖然兩個指標整體上有着比較相似的波動規律，但是由於它們的取值範圍、以及局部的抖動情況會有差異，因此需要分別去做監控。
2 智能巡檢基於上述痛點，我們提出了智能巡檢的方案。它具備以下幾個優勢：
智能前置：現在有很多系統是在告警觸發後，進行智能的管理，但是這無法避免告警誤報、漏報等問題。智能巡檢可以將 AI 的能力前置到監控層，從而在源頭上避免潛在的告警問題，挖掘出真正有效的數據價值。
監控自適應：可以基於歷史數據自動學習和進化，進行動態的閾值判斷，從而讓告警更加精準。另外對數據的學習也是實時的，可以更加快速地發現異常問題。
動態反饋：除了自動學習之外，還可以通過用戶的反饋，對告警進行確認或者誤報標記，將 AI 能力與人的經驗相結合，相輔相成，進一步完善模型，減少誤報。
在一些數據波動比較大，指標沒有固定閾值的場景下（例如用戶訪問量、外賣訂單量等），智能巡檢的優勢可以得到很好的體現。例如下圖，指標本身呈現出周期性的波動，假如一個新版本上線了之後，由於bug導致網絡流量異常抖動。如果基於固定閾值來判斷，此時處於指標值的上下界範圍內，就很難發現問題；但是基於智能巡檢，就可以很容易地判定這是一個異常點。
3 智能巡檢實現思路
我們採用無監督學習算法，自動識別實體的數據特徵，根據數據特徵選取不同的算法組合，針對數據流實時建模，完成異常任務檢測。並根據用戶的打標信息（對告警進行確認或者誤報反饋），訓練監督模型，對算法進行不斷優化，從而提高監控的準確率。機器級別的監控指標的異常巡檢，例如CPU占用率、內存利用率、硬盤讀寫速率等。業務指標的異常巡檢，例如QPS、流量、成功率、延時等。適用於對具有周期性的數據序列進行巡檢，且要求數據的周期性較為明顯。例如遊戲的訪問量、客戶的訂單量。Time-SeriesEventPredictionwithEvolutionaryStateGraphRobustSTL:ARobustSeasonal-TrendDecompositionAlgorithmforLongTimeSeries五 告警智能管理1 告警管理痛點在質量觀測的完整生命周期中，會產生大量的告警。如下圖所示：
多套工具難維護：在不同的階段可能使用了不同的工具，每個工具可能都提供了一部分的告警能力，最終導致難以維護。好在通過統一的數據接入和管理，我們可以統一去配置監控和管理告警。海量告警無收斂：另一個問題就是，海量的告警難以收斂，尤其是當告警之間有相互依賴關係的時候。例如主機負載高，導致該主機上服務異常、接口延遲高、HTTP Error 報錯多等多種問題並發，從而段時間內有大量的告警觸發，以及大量的告警消息通知。缺乏合理的降噪機制。通知管理能力弱：許多告警管理系統只是簡單地將告警消息發送出去，存在着通知渠道不完善、通知內容不符合用戶需求、無法支持值班需求等等問題。2 告警智能管理我們可以通過告警智能管理來解決上述問題，如下圖所示：
自動去重：每個告警會根據告警自身的關鍵特徵計算出一個告警指紋，然後根據告警指紋自動去重。例如：某主機每一分鐘觸發CPU使用率過高告警，1小時觸發60次，但對於告警管理系統來說，這只是一個告警的60個快照，而不是60個獨立的告警；同時假如通知設置為30分鐘重複，則一共只會發送兩次通知，而不是每一分鐘就發送一次通知。路由合併：相關的告警合併起來，一併進行通知，而不是針對每個告警分別通知，從而減少通知的數量。例如：根據告警所在集群進行合併，假如某集群短時間內產生了10個告警，則只會發送一條通知，包含這10個事件。告警抑制：主要用於處理告警之間的互相影響。例如：某一k8s集群發生OOM嚴重告警，可以暫時忽略同一集群的低級別告警。告警靜默：滿足特定條件的告警無需通知。例如：測試集群在凌晨有計劃內變更，期間服務會有短暫不可用，觸發預期內告警，該告警可以忽略。多渠道：支持短信、語音、郵件、釘釘等多種通知渠道，同時還支持通過自定義 Webhook 進行擴展。同一個告警，支持同時通過多個渠道、每個渠道使用不同的通知內容進行發送。例如通過語音和釘釘來進行告警通知，既可以保證觸達強度，又可以保證通知內容的豐富程度。動態通知：可以根據告警屬性動態分派通知。例如：測試環境的告警，通過短信通知到張三，並且只在工作時間通知；而生產環境的告警，通過電話通知到張三和李四，並且無論何時，都要進行通知。通知升級：長時間未解決的告警要進行升級。例如某告警觸發後，通過短信通知到了某員工，但是該問題長時間未被處理，導致告警一直沒有恢復，此時需要通知升級，通過語音的方式通知到該員工的領導。
另外就是值班和代班機制。值班是非常常見的一個場景，通常情況下，告警不是發送給所有的負責人，而是通過輪轉的方式進行分別值班。既然有了值班，也必須要考慮特殊的場景需要代班，例如某人值班的當天，由於有事，所以讓另外一個人來代替他值班。例如下面的例子：2021年8月由張三和李四值班（每班一周，僅工作日值班），首個工作日交班；8月17日張三請假，由小明代值班。
六 總結和展望
通過將日誌、時序、Trace、事件等數據接入到統一的可觀測存儲，從而實現統一的查詢分析、可視化等功能，基於此，可以實現統一的監控和告警管理，從而賦能研發、運維、安全等各個角色。除此之外，還支持通過開放告警的功能，將其它系統（例如 Prometheus、Grafana、Zabbix 等）的告警直接接入進行告警的統一管理。
目前質量觀測，數據的統一採集和管理，分析、可視化、監控等能力已經都相對完善從監控角度來說，智能巡檢已經可以比較好的自適應數據，另外就是進行智能根因分析，自動發現問題的根源，加快問題溯源，減輕排障困難告警的智能管理，除了基於規則的降噪，還會加入更多的算法支持，根據告警內容自動進行聚類，減少告警通知風暴最後一步是問題的後續響應，目前我們已經可以通過對接自定義的Webhook來進行一些簡單的操作，後續還會加入更多自動化的能力，例如代碼故障自動修復，自動回滾變更等。隨着以上幾步的不斷建設和完善，相信對於質量的觀測和把控，會越來越朝着人性化、自動化、智能化的方向邁進。鏈接：
1、CNCF Landscape地址：https://landscape.cncf.io/
2、Time-Series Event Prediction with Evolutionary State Graph：https://dl.acm.org/doi/pdf/10.1145/3437963.3441827
3、RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series：https://ojs.aaai.org/index.php/AAAI/article/view/4480?spm=a2c4g.11186623.0.0.7b5257f1ljyL7B
數據庫常見問題排查
開發者經常會遇到些數據庫的問題，覺得無從下手，這嚴重影響了開發效率，也影響了開發者對數據庫的熱情。如何避免這樣的窘境，如何降低數據庫使用門檻以及運維的成本，如何在較短的時間內用雲數據庫的技術和理念來武裝自己，提升自己。本課程通過實際的場景以及最佳實踐出發，帶給大家一些數據庫問題的通用解決思路和方法，大家會發現數據庫不再是一個黑盒，相反它看得見，摸得着，也能夠輕鬆玩得轉。點擊閱讀原文查看詳情～
留言列表