一、前言

大約是一年多前，我加入到貨拉拉，全面負責貨拉拉的監控體系建設。今天想與大家分享交流一下貨拉拉在監控領域，特別是智能監控領域的一些工作成果。

在正式開始前，我簡要介紹一下貨拉拉的相關情況。

據公開資料，目前貨拉拉已在全國 352 座城市開展業務，月活司機66萬，月活用戶 840萬，每日單量超百萬。而貨拉拉的技術底座建設在云廠商之上，所有技術研發人數超千人。在歷史的野蠻快速發展時期過后，現在貨拉拉使用著如Java、PHP、Golang、C++等多種開發語言，每種語言中使用的開發框架也不盡相同。

其次，貨拉拉的業務場景也是多樣的，有貨運、搬家、企業版等使用場景。

因此，整體上貨拉拉技術中心的任務既包括推動業務快速發展，也需要推動自身的系統治理，實現技術統一化和規范化，而監控系統在這個過程中發揮著巨大的作用。

今天我們首先簡要地回顧AIOps與智能監控的幾個概念，其次分享一個面向智能監控的建設框架，再分享一些我們在貨拉拉中的智能監控實踐，最后提出我們在實踐過程中的經驗與反思。

二、AIOps與智能監控

AIOps、Observability、Monitoring這幾個術語的內涵，大家應該聽過很多相關的解釋與分析。

最低層次的Monitoring就是傳統的監控數據的收集和展示，人是其中重要的參與角色。而Observability則是全方面地采集和展示應用和系統各個層次的系統性的監控數據。AIOps不等價于Observability，它更側重于智能算法在運維領域的應用，實現自動化。

而“智能監控”，我認為就是可觀測性與智能運維的交集。它需要使用全方面、多層次的監控數據，利用人工智能的算法與技術，在監控領域滿足監控的需求，實現監控目的。

三、貨拉拉的智能監控建設框架

我們來看下“監控領域大圖”，從一個監控系統的業務功能、數據要素、人員組織等方面進行簡要的分析。

業務功能

從一個監控系統的功能需求上，它需要為研發人員提供應用、系統的各維度信息以進行分析和排障；它也需要提供報警功能，讓用戶能第一時間響應故障；它既能在應急處理時提供穩定可靠的監控數據支持，也在日常穩定性運營時提供應用的治理數據。

數據要素

從監控系統涉及的數據上，日志、鏈路、指標數據、事件，是它必不可少的輸入。前三者大家應該很熟悉，而事件既包括了應用的變更事件、報警事件，也可以包括業務運營側的業務調整、促銷等事件，也可以包括云廠商的運維事件、底層調整等?！笆录钡姆秶鼜V，內容多樣化，結構更復雜。

人員與組織

監控系統的使用方首先是研發和運維等日常使用者，也有在故障應急時沖在第一線的NOC團隊，也有在日常時負責應用和系統的穩定性建設的穩定性團隊，以及老板也是我們重要的使用方。

之所以特別分析我們監控的使用方，是因為他們對監控系統的需求略有差異。比如，如果我們的系統掛了，沖在最前面去解決問題的是我們的NOC和具體研發。但是希望我們系統盡快恢復的，除了我們的用戶之外，最急迫的就是老板。如果他能在手機上看到業務曲線一點一點地恢復，他的心臟或許會好受一些。因此老板會如何使用監控系統，也是我們功能設計的重點。

特性要求

從監控系統的特性要求上，要求我們的監控數據準確、報警及時有效，數據采集、上報、展示、報警等流程自動且高效，在架構設計要求系統能夠靈活響應業務系統的變化，而我們的監控數據需要開發給第三方系統，最重要的也就是監控系統要保證自身的穩定性和高可用。

我們通過上圖展示監控系統中的核心要素。除了要回答我們系統在故障層面從指標表象到問題原因的多層次問題外，應用各個層面的可觀測性數據是監控系統的核心。而我們投入大量資源與人力建設監控系統，就是希望在研發效能、系統穩定性、架構優化上有所收益。

切合今天的主題，我們如何在監控系統中集成AI的智能技術，進一步提升我們的監控能力？

我根據貨拉拉的資源與能力現狀，規劃了一份智能監控的建設框架，可以供大家與具體公司場景結合時參考。

1、數據

在數據輸入方面，除了前面提到的“MELT”四種監控數據，還要包括海量的歷史數據和精確的實時數據，也需要應用的業務類型、重要等級、部門人員等元數據信息，應用之間調用依賴的拓撲信息，研發運維給應用標注的標簽數據，也需要對應的機器信息，應用底層的網絡、機房等云資源信息等各種各樣的數據。

2、技術

1）可視化與集成

如果把各個監控要素分開來做可視化展示，并不難。難點在于把各種數據整合在一個平臺之中，在多種使用場景下用戶都能順暢使用，并實現它的使用目的。這需要一個精心設計的統一化的監控平臺。

其次，我們的監控數據只有開放給其他系統，才能最大化地實現監控價值。例如，監控數據集成到壓測平臺、預案平臺、業務團隊自己的穩定性平臺中常見的需求。

2）報警分析

在報警分析上，我們使用了Prometheus，無論多復雜的報警規則基本都能實現報警。但是海量報警之后，如何實現降噪、報警聚合、變更事件的關聯是我們需要在報警后階段做的很多優化工作。

其次，報警閾值的趨勢預測、應用的異常檢測、報警應用的關聯檢測，也是將智能技術在監控落地的重點領域。

3）知識圖譜

知識圖譜中的內容很多，適配于監控領域的是“拓撲展示”和“知識生成”。

拓撲展示：例如，我們可以從指標、鏈路上生成應用依賴數據，再結合應用的元數據等信息，存儲到圖數據庫中，進行多層次的拓撲的查詢和展示。

• 知識生成：我們可以根據圖的信息，匹配相似路徑，生成隱含的知識，或者和我們人為的專家知識結合，生成新的關于應用的知識。

4）自然語言處理

在自然語言處理方面，我們可以針對報警的文本、應用日志，做文本本體提取，生成結構化的數據；使用文本聚類的技術上，可以將眾多異常日志歸類聚合，再將它提煉成指標，加入報警等。

3、功能

我們能借助前文提到的技術實現自動故障修復、自動監控檢測、變更檢測、故障可視化、根因分析等功能。

4、收益

我們依舊希望通過智能監控進一步提升研發效能、應急處理時效、日常運營的效率等方面。

然而，羅馬不是一天建成的，建設智能監控是一個系統性的工程，是常規監控的下一步。我們可以隨著公司的技術發展階段、整體技術體系、團隊的技術能力，分階段實現目標。

四、貨拉拉的智能監控實踐

1、貨拉拉的一站式監控平臺：Monitor

前面我們簡要回顧了AIOps與智能監控的關系，也提到了監控系統中的四個關鍵要素：指標、鏈路、日志、事件，也分享了一個貨拉拉的智能監控建設框架。目前我們有一些階段性的成果，可以分享給大家。在此之前，我需要介紹貨拉拉的一站式監控平臺——Monitor，后續智能監控的一些實現都是構建在Monitor之上的。

經過我們團隊將近兩年的建設，已經建成了覆蓋應用、中間件、機器、容器、云平臺、端上的多層次的指標監控系統；一個覆蓋了主流框架、主流中間件的全鏈路監控系統，打通了從端上到后端底層的完整鏈路；一個統一采集和展示了應用日志、訪問日志、容器日志的日志監控系統；一個提供豐富報警規則、靈活報警觸達方式、多樣化分發渠道、支持云平臺報警推送的報警系統；最終我們提供給用戶一個一站式的匯聚了指標鏈路日志報警的交互平臺，這個平臺既支持電腦端訪問，也能輕松在飛書等移動端查看；最重要的是，我們還開放了所有的監控數據，通過OpenApi提供給我們的兄弟團隊和兄弟系統使用。接下來我們來看看它的具體情況。

首先是我們日常重度使用的業務大盤，展現著詳盡的業務數據；其次是詳細的應用大盤，可以查看應用具體的HTTP、SOA、中間件、機器等詳細信息；用戶通過點擊指標就能查看到對應Trace鏈路，以及Trace拓撲。

我們也提供了所見即所得的報警配置頁面，以及報警后處理等查看頁面；開發了能集成在飛書中的移動端，剛才提到的業務大盤、應用大盤、報警事件等都能輕松查看。

整個監控系統的數據量如下：目前我們存儲著7T的指標總量，每日新增23T的鏈路數據，每日新增150T的日志數據，持續運行著7000+個自定義報警規則。監控系統的每日獨立用戶約600+人，也就是研發中心一半的同事每天都會使用我們的系統。

那么這一套一站式的監控系統——Monitor，背后的架構是怎么樣的？

1）指標

我們基于Prometheus的生態，用戶上報指標數據，經由一層采集的轉換層之后，由Prometheus remote write到victoriametrics中?；A的報警功能我們也基于vm-alert來實現。

特別的是，我們在數據采集層和查詢層，各開發了一個transformation組件和proxy組件，前者用來剪裁用戶上報的指標數據，后者用來加速查詢和限流管控。

2）Trace鏈路

我們基于Skywalking的生態，提供給用戶Trace SDK，以字節碼注入的方式做數據埋點，中間經由Kafka，將包括AppId、時間戳、Endpoint、Tags等索引信息存儲于Elasticsearch中，鏈路原始數據存儲于HBase之中。

3）Log方面

我們使用filebeat和Logstash去采集應用主機上的日志，自研的consumer應用將日志寫入到Elasticsearch中。

4）數據查詢

每種數據對應的API服務去做讀取。

特別的是，我們最近引入了AIOps API服務，它負責利用指標、鏈路等數據構建應用拓撲，存儲于圖數據庫之中。

以上就是整體架構。其中，橙色組件是我們自研的服務，其他都是開源的組件。

2、貨拉拉的智能監控舉例

接下來，我將從一個應急處理的場景介紹智能化監控的落地實踐，這是去年常見于貨拉拉的一個場景。

如果突然有一個業務波動，它會觸發一個報警，接著應急處理人員NOC會根據報警指標關聯的App跳轉到那個App的應用大盤，他可能會發現“soa.rt”這個指標突然飆高，這意味著SOA響應時間已經惡化。

下一步，他只需要在曲線上點擊指標，就能彈出對應請求時段的Trace，從Trace鏈路上可以看到下游某個App調用超時。

它還是在這個頁面上，直接點擊日志的Link，就根據“App+TraceId”跳轉找到對應的日志。他可能通過日志，找到具體的錯誤原因：某個配置出錯了。

現在這個App的相關研發人員已經參與到故障處理的過程中來，研發說幾分鐘前，他更新了個配置。那么就可以定位，這個變更就是導致業務指標下跌的原因了。所以，人工回滾配置，就能恢復業務。

從報警觸發到故障排查的大部分流程，在我們的監控平臺Monitor上都能完成，但是仍有很多人工參與的環節，如從業務指標到AppId的SOA指標、日志的判斷、變更的關聯等。我們會自然而然地想到，如果這些流程自動運行，不就可以加快排障的速度嗎？

因此，在我們的報警系統中，在觸發報警后，我們就開始自動分析的流程。

• 它會分析報警應用的健康狀況，從異常數量、http或soa的成功率、rt、qps等多角度分析。
• 其次，檢測應用在30分鐘內有無變更操作。
• 再進一步根據應用依賴拓撲，分析下游App的健康狀態和變更。

在用戶的感受上，我們將這些分析的結果推動到飛書中。

理想情況下，我們還能針對具體的故障原因，給出具體的操作建議，甚至關聯上對應的應急預案。

剛才提到報警觸發后會自動分析應用的健康狀況。這個信息來自于我們為每個應用統一配置的報警模版，它覆蓋了rt、異常、JVM、基礎設施等幾十個報警規則。

在報警規則的閾值設置上，除了經驗值的辦法之外，我們最近也在開發基于平滑算法和機器學習的方式，以實現自適應的閾值。

在報警降噪和聚合上，我們實現了按照報警觸達的間隔抑制、按照報警的類型進行聚合、按照應用App聚合等多種方式。

從整體的智能報警的架構層次上看，我們自下而上劃分了4個層次。

• 基礎層：將降噪、靜默、發送記錄、報警變更審計等形成基本能力。

• 算法層：規劃平滑算法、無閾值算法、數據異常變化時的波動檢測算法，數據缺失時的插值算法等。

• 查詢層：既有指標、應用元數據、拓撲數據的查詢，也有緩存模塊。

• 規則層：除了剛才提到的統一的全局報警模板，也提供產研能fork出自己版本的自定義模板，以及自定義規則，產研能自己組合報警條件、報警模型等。

右側的算法中心是我們現在在建設的模塊，它會利用現有的機器學習算法，根據貨拉拉特有的業務數據，訓練出對應的報警模型。

前面數次提到的拓撲數據，就是我們通過AIOps-API組件，分析應用元數據、依賴數據等，按照知識圖譜的思路，生成了以App為中心的本體設計。其中存儲了14種本體，16種關系。

這一套數據生成之后，我們能夠分析出：

• 總是出故障的是哪些應用，是哪個部門的穩定性比較差，哪些研發負責的應用穩如磐石？

• 應用間相互調用的拓撲圖

• 中間件的上游的使用情況

• ……

在監控平臺的集成上，我們在應用大盤中集成了應用拓撲圖，用戶可一眼看到這個應用的依賴，以及實時的QPS和RT。在業務大盤中，我們將核心業務的實時業務數據可視化，方便業務團隊的查看。

根據我們安全生產團隊的統計數據，在核心應用的監控覆蓋率上達到了100%，報警的覆蓋率100%。根據今年 3～5月的故障數據，整體貨拉拉的服務可用性是99.98%，10+起生產故障中，100%是5分鐘通過報警發現，89%是20分鐘內定位問題，78%的案例是在25分鐘內止損恢復。

3、經驗與反思

最后，我們也分享一些踩坑后獲得的經驗。

1）最重要的是在設計埋點規范時，一定要提前設計，預留好足夠的擴展性，否則未來就要做痛苦的兼容工作。

2）要面向用戶設計。例如，對運維來說，Prometheus確實很好用。但對于研發人員就未必了，一知半解的各種指標名，好用但難于精通PromQL，更別說讓研發去手寫PromQL語句配置報警了。所以我們提供了類SQL的PromQL的查詢封裝語法、所見即所得的報警配置頁面，這些都是從用戶體驗角度出發，設計一個好用的監控系統必須考慮的。

3）要讓系統簡單透明，并告訴用戶如何自助排查各種監控問題。

4）合理取舍成本和收益。監控是有成本的，是否有必要采集所有數據、哪些是最有價值的數據，這些問題都需要我們提前規劃。

五、總結與展望

最后我也用一張圖總結一下貨拉拉在監控領域的變革歷史。

1、小廠（過去）

當我們還是小廠時，我們的研發人數不多。監控系統也是由運維團隊從零搭建起來的，想的是怎么快就用什么。所以，當時我們選用了開源的Prometheus、Skywalking、ELK、Grafana把我們的應用監控起來。因為是不同的產品，監控的各個要素分布于不同的系統上，產研在排障上體驗不好，還是手工登錄機器、或者憑經驗排查居多。

2、中廠（現在）

到了第二個階段，我們貨拉拉現在也發展成了“中廠”的規模。建設監控領域的職責，也從運維團隊轉移到了專門的監控團隊上。

監控團隊的首要任務就是要開發一個一站式的監控平臺，把下層的各個監控要素整合到同一個產品上，將信息有效整合起來，讓監控體現出真正的價值。

之前我們選用的開源產品（如Prometheus、Skywalking等）還在繼續使用，不過我們現在有了更多的技術儲備與精力去改造他們，添加和優化其中的數據處理邏輯，從監控視角上為業務的飛速發展做長期規劃。在AIOps方面，我們也結合具體需求場景做了一些嘗試。

此時，技術中心的人員結構上，運維團隊更加專注于底層運維，SRE和NOC團隊成立了之后專注于整體的系統穩定性建設。而DevOps團隊建設了強大的CMDB與云管平臺，屏蔽了底層云廠商的細節，確保我們上層的監控系統能夠快速推廣到多云環境中。

3、大廠（未來）

在不遠的“之后”，隨著貨拉拉業務的飛速發展，技術中心很可能繼續發展成若干個研發中心，那么此時更需要監控團隊把監控能力打造為一種基礎能力，使其能夠在更多差異化場景下快速復用。

這里我也預測一點變化：在技術中心擴大到一定規模后，單一的一個監控平臺無法滿足用戶多樣化的需求，很可能會分化出獨立的鏈路平臺、日志平臺、穩定性平臺等。此時也需要把監控能力視為基礎能力，其中對數據的采集、處理、分析等環節需要能復用到其他系統中。

在“未來”，我們也會有精力自研時序數據庫、鏈路和日志等系統，更好地匹配我們的業務需求。而AIOps平臺和DevOps平臺會更加豐富，實現更強的智能化、自動化。

希望貨拉拉技術團隊在監控領域的一個總結能供大家參照當前公司所處的狀態，為大家規劃監控系統發展思路時提供一些參考。?