“
一、什麼是業務監控
業務監控是指對企業業務流程進行實時監控和分析的一套系統。通過業務監控，企業可以實時了解業務的運作情況，及時發現異常情況并采取相應措施，避免因業務問題造成的損失和影響。業務監控主要包括監控名額的設定、監控方式的選擇、監控結果的分析和決策等環節。監控名額的設定應根據企業的業務流程和關鍵業務名額進行确定，監控方式可以采用日志監控、告警監控、流量監控等方式進行實時監控。監控結果的分析和決策則需要結合業務流程和資料分析等手段，對監控結果進行綜合分析，提供決策支援。通過業務監控，企業可以實時了解業務的運作情況，及時發現異常情況并采取相應措施，保障業務營運的穩定性和高效性。
業務監控由資料收集、存儲、展示和告警四個主要組成部分構成。資料收集負責采集來自各個業務環節的資料，包括日志、性能名額、使用者行為等，以建立全面的資料集。資料存儲環節将采集到的資料儲存在可靠的存儲系統中，如資料庫或大資料存儲解決方案。展示階段通過可視化方式将資料呈現，如儀表盤、報表或圖表，以便使用者直覺了解業務狀況。告警是監控系統的重要部分，通過監測資料變化和異常情況，及時觸發告警通知相關人員，以便快速響應和解決問題。
“
二、高途業務監控系統的發展
高途的業務監控經曆了三個階段的演進，分别是業務監控1.0、2.0和目前階段。在1.0階段，業務名額通過SDK上報至Kafka，随後存儲在ES供資料查詢和告警處理。然而，随着名額接入量的增加，ES容量和成本劣勢逐漸凸顯，于是2.0階段應運而生。在2.0階段，資料改由SDK上報至Prometheus供資料查詢和告警處理。值得注意的是，無論是1.0還是2.0階段，資料都需要使用者手動引入SDK上報，這種方式對代碼進行侵入性修改，影響了使用者的接入意願。是以，在目前階段，我們增加了主動抓取的方式擷取業務名額，使用者隻需在平台進行名額抓取和告警邏輯的配置。大大降低了使用者的接入門檻，顯著提升了業務監控的覆寫範圍。
“
三、難點
業務監控的建設面臨一系列挑戰與難點。首先，業務監控所涉及的資料多樣性是一大挑戰。它需要處理來自不同業務環節的資料，包括日志、名額、性能資料等多種形式的資訊，這些資料可能來自不同的系統和平台，是以需要整合這些異構資料，并確定其完整性和準确性。
其次，大規模資料的處理和實時性要求也是業務監控面臨的難點之一。随着業務規模的不斷擴大，監控的資料量也呈現出爆炸式增長，處理這些海量資料所需的技術和資源投入愈發凸顯，同時部分監控需求對資料的實時性有較高要求，需要及時發現和處理異常情況。
最後，有效的告警與異常識别是業務監控的關鍵。要設定有效的告警規則并準确識别異常情況是一個挑戰，需要避免誤報和漏報，確定告警的精準度和實效性。
“
四、整體方案
為了應對業務監控中多樣且異構的資料源，我們采取了适配處理的政策，将這些資料源轉換成了統一的資料模型，并存儲于一緻的資料層。這一層為我們建構上層的展示和告警應用提供了基礎。原始資料源通過适配層轉發至Kafka，在此進行高峰期的流量削峰，随後寫入Lindorm時序引擎，確定資料的高效存儲和管理。這種處理方式不僅實作了資料的整合和統一，還提升了對資料的管理和利用效率，為業務監控體系的搭建提供了可靠的基礎。
另外，為了實作主動抓取的目标，我們将在使用者配置完名額後，平台将自動生成相應的抓取任務，依據使用者的設定進行資料源的主動抓取工作。當資料抓取至存儲層後，使用者可在平台上預覽曆史資料的趨勢圖表，以便進行告警參數的配置。一旦使用者完成告警設定，平台同樣會自動生成告警任務，根據設定對資料進行分析和告警。這些告警能力基于輕舟平台已有的天眼告警能力，旨在確定系統能夠及時發現并響應潛在問題。這種智能化的配置和任務自動生成，為使用者提供了便捷的監控接入方式。
由于Kafka資料源的實時性，為了對Kafka資料進行抓取，我們的抓取任務首先會将每條Kafka消息明細抓取到一個存儲系統，這裡我們同樣選擇了Lindorm來存儲Kafka明細資料。相當于我們會有一個實時任務，不停地消費Kafka，寫入到Lindorm（該Lindorm隻存儲Kafka消息）。然後我們會根據配置的聚合邏輯，對這些消息明細進行聚合查詢和二次抓取，然後存入上面提到的統一存儲層Lindorm中。
“
五、系統優化
性能優化
為了應對不斷增長的資料量，我們實施了一系列優化措施。首先，我們采用了“預聚合”的政策，對資料進行聚合處理，以減少存儲壓力并提高查詢效率。一般的做法是按時間段對業務名額進行聚合處理。為了平衡實時性和存儲容量的需求，我們提供了從1分鐘到1小時的不同采樣間隔選項。對于類似SQL的資料源，我們為使用者提供了SQL填寫方式，友善配置聚合邏輯。而對于非SQL類的資料源，例如Kafka，我們也提供了簡單的聚合邏輯勾選配置，平台會自動實施聚合處理。這些措施旨在優化資料處理方式，提高效率，滿足不同資料源的需求。
在優化Kafka類名額方面，我們進行了大量工作。對于來自相同Topic的不同名額，我們會對多個抓取任務進行整合。不同的抓取任務會生成不同的處理器，消息隻會被消費一次，然後交給這些處理器并行處理，避免大量的重複消費。為了減少資料量，處理器會按照消息批次進行預預聚合，并根據預設配置進行過濾，同時隻保留必要的字段。
最後，盡管資料支援多Tag，但每個名額隻能按照特定的Tag組合進行告警。如果使用者需要針對不同的Tag組合告警，就需要配置重複的名額，這會導緻存儲備援。為了解決這個問題，我們引入了Lindorm類型的資料源，支援直接在已有名額上進行告警配置，避免重複抓取資料的情況。
功能優化
為了提升問題的主動發現率，我們支援了異常檢測類型的告警機制。目前，我們已經支援了4種基于統計方法的異常檢測算法，分别是适用于非周期信号的ESD算法和NSigma算法和适用于周期信号的ISTL-ESD算法和ISTL-NSigma算法。異常檢測有助于及時發現潛在的問題或異常情況。通過實時監測和資料分析，我們可以在問題擴大之前識别并定位異常，有助于提前幹預和處理，防止問題進一步惡化。這些算法的使用能夠有效地提高問題檢測的準确性和實時性。
“
六、失敗與經驗
在業務監控系統的建設過程中，我們也遇到了一些挑戰，其中一個是關于 Lindorm 時序引擎的使用。Lindorm 時序引擎與其他時序引擎類似，由 Tags 和 Timestamp 組成不同的時間線，而時間線的數量對引擎的性能影響很大。
在一次幫助業務排查資料延時問題的過程中，我們在每條 Kafka 消息中記錄了處理時間作為 Tag。然而，大約一個星期後，Lindorm 的寫入和查詢頻繁報逾時錯誤。經過排查發現，問題出在引入時間字段作為 Tag 上。由于時間無法被有效地聚合，時間線的數量随着時間的推移呈指數增長，最終影響了引擎的讀寫性能。為解決此問題，我們将處理時間改為 Field 類型存儲，有效減少了時間線的數量，進而恢複了系統的性能。
對于Lindorm的使用，我們可以得出經驗，如果字段的區分度特别大，則建議将字段設定為Field類型。另外，對于做聚合計算的的字段，則必須将字段類型設定為Tag，不然會導緻資料覆寫丢失的問題。
“
七、成果
在資料源支援方面，業務監控目前支援6種類型的資料源，包括MySQL、Elasticsearch、Prometheus、JSON API、Lindorm和Kafka，完全相容1.0和2.0時代的資料源類型，覆寫電商、使用者、教研、市場和直播五大業務域，累計接入335個業務名額。
名額抓取
除了單個名額的抓取，同時支援多個名額按照Tag進行複合抓取。
名額展示
支援業務大盤和電視大屏等展示方式。
名額告警
支援門檻值條件、資料中斷、同比環比和智能檢測等4種告警類型。除此之外，提供了豐富的告警配置能力：支援按照時段進行告警、支援按照Tag進行告警、支援對過去一段時間的名額進行聚合告警、支援對延遲資料進行告警、告警預覽、曆史告警資訊查詢等。
“
八、未來發展
現階段AI發展火爆，我們未來可以基于機器學習和人工智能技術，讓監控系統将能夠預測潛在的問題，并提供預警，使企業能夠在問題發生前采取相應的措施。主要分為兩方面，一方面是智能化監控。智能化監控利用機器學習和資料挖掘技術，從大規模的監控資料中提取模式、識别規律，并根據這些模式和規律進行智能判斷。例如，基于曆史資料的模式識别，系統能夠自動學習正常運作狀态并識别異常行為。另一方面是預測性監控。預測性監控通過對曆史資料的分析，結合預測模型和算法，預測未來可能出現的問題或趨勢。這種監控能力可以幫助企業預測系統故障、資源瓶頸或異常行為的發生，并提前預警，進而減少潛在的損失和風險。
作者:郭俊
來源:微信公衆号:高途技術
出處:https://mp.weixin.qq.com/s/7-A0IyE6Ui2f23WGzyOGgA