簡介：?在云原生和DevOps研發(fā)模式的挑戰(zhàn)下，一個系統(tǒng)從開發(fā)、測試、到上線的整個過程中，會產(chǎn)生大量的日志、指標(biāo)、事件以及告警等數(shù)據(jù)，這也給企業(yè)質(zhì)量平臺建設(shè)帶來了很大的挑戰(zhàn)。本議題主要通過可觀測性的角度來討論基于海量日志和時序數(shù)據(jù)的質(zhì)量建設(shè)最佳實踐。

作者 | 寂之
來源 | 阿里技術(shù)公眾號

一 前言

在云原生和DevOps研發(fā)模式的挑戰(zhàn)下，一個系統(tǒng)從開發(fā)、測試、到上線的整個過程中，會產(chǎn)生大量的日志、指標(biāo)、事件以及告警等數(shù)據(jù)，這也給企業(yè)質(zhì)量平臺建設(shè)帶來了很大的挑戰(zhàn)。本議題主要通過可觀測性的角度來討論基于海量日志和時序數(shù)據(jù)的質(zhì)量建設(shè)最佳實踐。

二 質(zhì)量建設(shè)痛點

眾所周知，在云原生開發(fā)模式下，可觀測性是非常重要的一部分，它通過日志、指標(biāo)、Trace等數(shù)據(jù)，讓我們可以深入了解系統(tǒng)的運行狀態(tài)和健康程度。在 CNCF Landscape大圖中，可觀測性也占據(jù)了相當(dāng)大的一塊位置。

然而在實際使用過程中，許多人對可觀測性的關(guān)注，主要集中在系統(tǒng)上線之后。這當(dāng)然是沒有問題的，但實際上，從一個系統(tǒng)開發(fā)開始，一直到線上運行，都是可以從可觀測的角度來對系統(tǒng)的質(zhì)量進(jìn)行評估和衡量，我們可以稱之為對質(zhì)量的觀測。

下圖比較概括地描述了一個系統(tǒng)的質(zhì)量觀測完整生命周期，大體上可以分為如下四個階段，并且在每個階段都有需要特別關(guān)注的一些數(shù)據(jù)和指標(biāo)：

• 開發(fā)階段：重點需要關(guān)注代碼的質(zhì)量，例如靜態(tài)代碼掃描以及依賴檢查會發(fā)現(xiàn)潛在的代碼缺陷和安全風(fēng)險，由此我們可以統(tǒng)計千行代碼缺陷率或者嚴(yán)重缺陷比例，從而來衡量一個系統(tǒng)的代碼質(zhì)量是否符合要求
• 測試階段：在此階段需要重點關(guān)注測試的質(zhì)量，例如測試覆蓋率，以及測試用例的失敗率等指標(biāo)
• 灰度驗證：需要關(guān)注系統(tǒng)的穩(wěn)定性以及不同版本之間的差異，因此也會有一系列的業(yè)務(wù)指標(biāo)，例如HTTP Error 比例，不同版本的延遲等指標(biāo)的對比
• 線上運行：此時需要重點關(guān)注系統(tǒng)的穩(wěn)定性以及業(yè)務(wù)的穩(wěn)定性，因此各種線上的性能指標(biāo)、業(yè)務(wù)指標(biāo)、應(yīng)用日志、Trace等各種數(shù)據(jù)都是非常重要的

在整個質(zhì)量觀測的生命周期中，除了各種各樣的數(shù)據(jù)，我們也會涉及到各種各樣的系統(tǒng)，例如 GitLab、sonarqube、Allure、JMeter、Jenkins、Travis CI、Argo CD 等等。這些不同的系統(tǒng)作用于不同的階段，會產(chǎn)生大量的異構(gòu)數(shù)據(jù)，如何對這些數(shù)據(jù)進(jìn)行合理的管理和使用，從而可以比較方便地挖掘出其中的數(shù)據(jù)價值（不局限于軟件質(zhì)量方面），對我們來說是一個比較大的挑戰(zhàn)。

基于上述的討論，我們可以大體總結(jié)出質(zhì)量觀測的幾個痛點：

• 海量的異構(gòu)數(shù)據(jù)：在系統(tǒng)開發(fā)、測試、驗證、上線等各個階段產(chǎn)生了大量的日志、時序、Trace 等數(shù)據(jù)，這些數(shù)據(jù)產(chǎn)生的位置、數(shù)據(jù)格式、以及存儲的位置，都有可能是不一樣的。如何從這些數(shù)據(jù)中快速精準(zhǔn)地挖掘出潛在的質(zhì)量問題比較困難。
• 依賴規(guī)則，缺乏智能：質(zhì)量監(jiān)控比較依賴于人的經(jīng)驗，很大程度上受限于人為設(shè)定的規(guī)則和閾值，無法做到數(shù)據(jù)自適應(yīng)，因此無法發(fā)揮出真正的數(shù)據(jù)價值。另一方面就是隨著系統(tǒng)的發(fā)展和演進(jìn)，需要大量的人工干涉和不斷調(diào)整，才能夠讓監(jiān)控比較有效。
• 告警風(fēng)暴與告警誤報：為了不錯過細(xì)微的問題，我們可能會配置大量的監(jiān)控，從而導(dǎo)致在完整的軟件生命周期中可能產(chǎn)生大量的告警，難以從其中識別出有效信息。另外大量的告警也帶了很大程度上的誤報問題，從而導(dǎo)致“狼來了”效應(yīng)，于是真正的問題反而很容易又被忽略掉。這就陷入了惡性循環(huán)。

三 數(shù)據(jù)統(tǒng)一接入和管理

1 海量數(shù)據(jù)管理痛點

首先我們來探討第一個痛點，也就是如何對海量的異構(gòu)數(shù)據(jù)進(jìn)行管理。目前可觀測性相關(guān)的系統(tǒng)五花八門。

例如日志可能會使用 ELK 或者 Splunk，指標(biāo)會使用 Prometheus，Trace 使用 Skywalking、Jaeger 或者 zipkin。但太多的選擇也不見得是好事，在這種情況下，可觀測性數(shù)據(jù)的管理又給我們帶來了如下幾個痛點：

• 運維成本高：完整的質(zhì)量系統(tǒng)需要數(shù)個甚至十多個軟件的協(xié)同，從而也帶了極高的運維成本。
• 學(xué)習(xí)成本高：每個軟件都有自己的使用插件、插件系統(tǒng)，有些還會有自己的DSL語法，學(xué)習(xí)成本非常高，很難完全掌握使用。
• 擴展困難：隨著數(shù)據(jù)規(guī)模的增長，軟件的擴展能力、性能、穩(wěn)定能力等方面都會有很大的挑戰(zhàn)。
• 數(shù)據(jù)孤島：不同的數(shù)據(jù)處于不同的系統(tǒng)中，協(xié)同困難。例如想要將 ES 中的日志和 Prometheus 中的指標(biāo)進(jìn)行一個 Join 查詢就無法實現(xiàn)，除非做額外的二次開發(fā)。

2 數(shù)據(jù)統(tǒng)一接入和管理

基于上述幾個痛點，我們的解決方案是將這些異構(gòu)的數(shù)據(jù)進(jìn)行統(tǒng)一的存儲和管理，如下圖所示：

在這里，我們將日志、指標(biāo)、Trace等數(shù)據(jù)全部接入到一個統(tǒng)一的可觀測性存儲中。然后基于這個統(tǒng)一的存儲，進(jìn)行后續(xù)的查詢分析、可視化、監(jiān)控告警、AI 等上層能力，甚至還可以進(jìn)行數(shù)據(jù)的加工和規(guī)整，一站式地完成異構(gòu)數(shù)據(jù)到同構(gòu)數(shù)據(jù)的轉(zhuǎn)換過程。

基于統(tǒng)一的存儲，我們可以構(gòu)建統(tǒng)一的查詢和分析語法，從而一套語法適配不同的數(shù)據(jù)，并且讓不同的數(shù)據(jù)之間進(jìn)行聯(lián)合查詢也變成了可能。如下圖所示，我們以標(biāo)準(zhǔn) SQL 為基礎(chǔ)，進(jìn)行了部分 DSL 擴展和 SQL 函數(shù)擴展，并融合了 PromQL，從而讓不同類型的數(shù)據(jù)查詢和分析變得統(tǒng)一。

例如下面的例子：

• 我們可以通過標(biāo)準(zhǔn) SQL 語句對日志進(jìn)行分析
• 還可以通過 PromQL 擴展的 SQL 函數(shù)對指標(biāo)數(shù)據(jù)進(jìn)行分析
• 還可以通過嵌套查詢，對指標(biāo)數(shù)據(jù)的分析結(jié)果進(jìn)行再聚合
• 此外還可以再通過機器學(xué)習(xí)函數(shù)，給查詢和分析賦予 AI 的能力

基于上述統(tǒng)一的數(shù)據(jù)存儲和查詢分析，我們可以非常輕松地實現(xiàn)統(tǒng)一的可視化和監(jiān)控。如下圖所示，雖然不同階段的數(shù)據(jù)產(chǎn)生自不同的系統(tǒng)，也有著不同的格式，但是由于它們的存儲和分析是一致的，因此我們可以構(gòu)建出統(tǒng)一的報表來查看各個階段的軟件質(zhì)量，以及統(tǒng)一進(jìn)行監(jiān)控的配置和告警的管理，而無需將這些分散到各個不同的系統(tǒng)中，脫離例如 ES + Kibana、Prometheus + Grafana 等組合。

四 智能巡檢

1 傳統(tǒng)監(jiān)控的困難和挑戰(zhàn)

接下來我們來看如何基于這些數(shù)據(jù)，讓監(jiān)控更加智能。傳統(tǒng)的監(jiān)控大多是基于一些固定的閾值，或者同環(huán)比。但是在很多場景下，這種模式存在著諸多問題。例如：

• 監(jiān)控對象爆炸式增長：隨著云原生的普及，服務(wù)部署越來越從以“主機”為中心向“容器化”方向轉(zhuǎn)化，容器本身的輕量化以及短生命周期等特點，導(dǎo)致監(jiān)控對象和監(jiān)控指標(biāo)急劇增加。如果要全方位的覆蓋這些監(jiān)控對象和指標(biāo)，需要配置大量的監(jiān)控規(guī)則，并且它們的閾值也可能是各不相同的，因此會有很大的工作量。

• 監(jiān)控規(guī)則無法自適應(yīng)：基于人為定義的閾值，很大程度上依賴于人的經(jīng)驗，隨著系統(tǒng)的演化和業(yè)務(wù)的發(fā)展，這些規(guī)則往往不能很好地適應(yīng)，由此不可避免地導(dǎo)致漏報、誤報等問題。無法做到數(shù)據(jù)的自適應(yīng)，因此需要人為介入，不斷調(diào)整閾值。例如下圖：

  • 上面是一個指標(biāo)，有規(guī)則性的毛刺。如果通過閾值來判斷是否需要告警，當(dāng)一個毛刺點異常的時候，可能由于不滿足閾值，導(dǎo)致告警漏報。
  • 下面是另一個指標(biāo)，可能隨著系統(tǒng)的進(jìn)化，新版本發(fā)布之后，該指標(biāo)的值會發(fā)生一個陡增。此時如果是固定閾值告警的話，會將陡增之后的所有數(shù)據(jù)都認(rèn)為是異常點，導(dǎo)致告警頻繁觸發(fā)。此時需要人為介入去調(diào)整閾值。

• 監(jiān)控規(guī)則泛化能力弱：不同的業(yè)務(wù)、甚至同一業(yè)務(wù)的不同版本，指標(biāo)的規(guī)律性、閾值都有可能是不同的。因此我們需要為不同的業(yè)務(wù)、不同的版本去做監(jiān)控規(guī)則的適配。例如下圖，雖然兩個指標(biāo)整體上有著比較相似的波動規(guī)律，但是由于它們的取值范圍、以及局部的抖動情況會有差異，因此需要分別去做監(jiān)控。

2 智能巡檢

基于上述痛點，我們提出了智能巡檢的方案。它具備以下幾個優(yōu)勢：

• 智能前置：現(xiàn)在有很多系統(tǒng)是在告警觸發(fā)后，進(jìn)行智能的管理，但是這無法避免告警誤報、漏報等問題。智能巡檢可以將 AI 的能力前置到監(jiān)控層，從而在源頭上避免潛在的告警問題，挖掘出真正有效的數(shù)據(jù)價值。
• 監(jiān)控自適應(yīng)：可以基于歷史數(shù)據(jù)自動學(xué)習(xí)和進(jìn)化，進(jìn)行動態(tài)的閾值判斷，從而讓告警更加精準(zhǔn)。另外對數(shù)據(jù)的學(xué)習(xí)也是實時的，可以更加快速地發(fā)現(xiàn)異常問題。
• 動態(tài)反饋：除了自動學(xué)習(xí)之外，還可以通過用戶的反饋，對告警進(jìn)行確認(rèn)或者誤報標(biāo)記，將 AI 能力與人的經(jīng)驗相結(jié)合，相輔相成，進(jìn)一步完善模型，減少誤報。

在一些數(shù)據(jù)波動比較大，指標(biāo)沒有固定閾值的場景下（例如用戶訪問量、外賣訂單量等），智能巡檢的優(yōu)勢可以得到很好的體現(xiàn)。例如下圖，指標(biāo)本身呈現(xiàn)出周期性的波動，假如一個新版本上線了之后，由于bug導(dǎo)致網(wǎng)絡(luò)流量異常抖動。如果基于固定閾值來判斷，此時處于指標(biāo)值的上下界范圍內(nèi)，就很難發(fā)現(xiàn)問題；但是基于智能巡檢，就可以很容易地判定這是一個異常點。

3 智能巡檢實現(xiàn)思路

智能巡檢的基本思路如下：

我們采用無監(jiān)督學(xué)習(xí)算法，自動識別實體的數(shù)據(jù)特征，根據(jù)數(shù)據(jù)特征選取不同的算法組合，針對數(shù)據(jù)流實時建模，完成異常任務(wù)檢測。并根據(jù)用戶的打標(biāo)信息（對告警進(jìn)行確認(rèn)或者誤報反饋），訓(xùn)練監(jiān)督模型，對算法進(jìn)行不斷優(yōu)化，從而提高監(jiān)控的準(zhǔn)確率。

目前異常檢測我們使用了兩種算法，它們的比較如下：

五 告警智能管理

1 告警管理痛點

在質(zhì)量觀測的完整生命周期中，會產(chǎn)生大量的告警。如下圖所示：

這導(dǎo)致的問題就是：

• 多套工具難維護(hù)：在不同的階段可能使用了不同的工具，每個工具可能都提供了一部分的告警能力，最終導(dǎo)致難以維護(hù)。好在通過統(tǒng)一的數(shù)據(jù)接入和管理，我們可以統(tǒng)一去配置監(jiān)控和管理告警。
• 海量告警無收斂：另一個問題就是，海量的告警難以收斂，尤其是當(dāng)告警之間有相互依賴關(guān)系的時候。例如主機負(fù)載高，導(dǎo)致該主機上服務(wù)異常、接口延遲高、HTTP Error 報錯多等多種問題并發(fā)，從而段時間內(nèi)有大量的告警觸發(fā)，以及大量的告警消息通知。缺乏合理的降噪機制。
• 通知管理能力弱：許多告警管理系統(tǒng)只是簡單地將告警消息發(fā)送出去，存在著通知渠道不完善、通知內(nèi)容不符合用戶需求、無法支持值班需求等等問題。

2 告警智能管理

我們可以通過告警智能管理來解決上述問題，如下圖所示：

告警智能降噪包含以下幾種機制：

• 自動去重：每個告警會根據(jù)告警自身的關(guān)鍵特征計算出一個告警指紋，然后根據(jù)告警指紋自動去重。例如：某主機每一分鐘觸發(fā)CPU使用率過高告警，1小時觸發(fā)60次，但對于告警管理系統(tǒng)來說，這只是一個告警的60個快照，而不是60個獨立的告警；同時假如通知設(shè)置為30分鐘重復(fù)，則一共只會發(fā)送兩次通知，而不是每一分鐘就發(fā)送一次通知。
• 路由合并：相關(guān)的告警合并起來，一并進(jìn)行通知，而不是針對每個告警分別通知，從而減少通知的數(shù)量。例如：根據(jù)告警所在集群進(jìn)行合并，假如某集群短時間內(nèi)產(chǎn)生了10個告警，則只會發(fā)送一條通知，包含這10個事件。
• 告警抑制：主要用于處理告警之間的互相影響。例如：某一k8s集群發(fā)生OOM嚴(yán)重告警，可以暫時忽略同一集群的低級別告警。
• 告警靜默：滿足特定條件的告警無需通知。例如：測試集群在凌晨有計劃內(nèi)變更，期間服務(wù)會有短暫不可用，觸發(fā)預(yù)期內(nèi)告警，該告警可以忽略。

動態(tài)分派包含如下功能：

• 多渠道：支持短信、語音、郵件、釘釘、企業(yè)微信、飛書、Slack等多種通知渠道，同時還支持通過自定義 Webhook 進(jìn)行擴展。同一個告警，支持同時通過多個渠道、每個渠道使用不同的通知內(nèi)容進(jìn)行發(fā)送。例如通過語音和釘釘來進(jìn)行告警通知，既可以保證觸達(dá)強度，又可以保證通知內(nèi)容的豐富程度。
• 動態(tài)通知：可以根據(jù)告警屬性動態(tài)分派通知。例如：測試環(huán)境的告警，通過短信通知到張三，并且只在工作時間通知；而生產(chǎn)環(huán)境的告警，通過電話通知到張三和李四，并且無論何時，都要進(jìn)行通知。
• 通知升級：長時間未解決的告警要進(jìn)行升級。例如某告警觸發(fā)后，通過短信通知到了某員工，但是該問題長時間未被處理，導(dǎo)致告警一直沒有恢復(fù)，此時需要通知升級，通過語音的方式通知到該員工的領(lǐng)導(dǎo)。

另外就是值班和代班機制。值班是非常常見的一個場景，通常情況下，告警不是發(fā)送給所有的負(fù)責(zé)人，而是通過輪轉(zhuǎn)的方式進(jìn)行分別值班。既然有了值班，也必須要考慮特殊的場景需要代班，例如某人值班的當(dāng)天，由于有事，所以讓另外一個人來代替他值班。例如下面的例子：2021年8月由張三和李四值班（每班一周，僅工作日值班），首個工作日交班；8月17日張三請假，由小明代值班。

六 總結(jié)和展望

綜合上面的討論，完整的架構(gòu)大圖如下：

通過將日志、時序、Trace、事件等數(shù)據(jù)接入到統(tǒng)一的可觀測存儲，從而實現(xiàn)統(tǒng)一的查詢分析、可視化等功能，基于此，可以實現(xiàn)統(tǒng)一的監(jiān)控和告警管理，從而賦能研發(fā)、運維、安全等各個角色。除此之外，還支持通過開放告警的功能，將其它系統(tǒng)（例如 Prometheus、Grafana、Zabbix 等）的告警直接接入進(jìn)行告警的統(tǒng)一管理。

關(guān)于對未來的展望：

• 目前質(zhì)量觀測，數(shù)據(jù)的統(tǒng)一采集和管理，分析、可視化、監(jiān)控等能力已經(jīng)都相對完善
• 從監(jiān)控角度來說，智能巡檢已經(jīng)可以比較好的自適應(yīng)數(shù)據(jù)，另外就是進(jìn)行智能根因分析，自動發(fā)現(xiàn)問題的根源，加快問題溯源，減輕排障困難
• 告警的智能管理，除了基于規(guī)則的降噪，還會加入更多的算法支持，根據(jù)告警內(nèi)容自動進(jìn)行聚類，減少告警通知風(fēng)暴
• 最后一步是問題的后續(xù)響應(yīng)，目前我們已經(jīng)可以通過對接自定義的Webhook來進(jìn)行一些簡單的操作，后續(xù)還會加入更多自動化的能力，例如代碼故障自動修復(fù)，自動回滾變更等。

隨著以上幾步的不斷建設(shè)和完善，相信對于質(zhì)量的觀測和把控，會越來越朝著人性化、自動化、智能化的方向邁進(jìn)。

鏈接：

1、CNCF Landscape地址：CNCF Cloud Native Interactive Landscape

2、Time-Series Event Prediction with Evolutionary State Graph：Time-Series Event Prediction with Evolutionary State Graph | Proceedings of the 14th ACM International Conference on Web Search and Data Mining

3、RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series：RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series| Proceedings of the AAAI Conference on Artificial Intelligence

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的基于海量日志和时序数据的质量建设最佳实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。