【51CTO.com原創稿件】阿里巴巴的監控平臺經歷了多次迭代與更替，在曲折發展中慢慢從簡單的自動化轉換為頗具智能化的系統運維。
2018 年 5 月 18-19 日，由 51CTO 主辦的全球軟件與運維技術峰會在北京召開。
在“容器下的 AIOps”分論壇上，來自阿里巴巴集團監控負責人程超就《自動化到智能化的阿里監控發展之路》主題進行了精彩演講。
本文將從如下三個部分來分享阿里構建超大規模的秒級監控平臺的最佳實踐：
- 打怪升級
- 修煉內功
- 仰望星空
打怪升級
和大部分的公司類似，阿里巴巴最初也採用的是 Nagios+Cacti 的開源模式。
該組合的最大問題是：不能規模化，一旦數據量達到規模級別之後，就會出現各式各樣的問題。
另外，由於我們對該開源的組合未做深入研究，因此無法對它們進行定製與修改。到了 2009 年，我們決定廢棄該組合，準備自行搭建一套監控系統。
如上圖所示，該自建系統支撐了阿里巴巴後續的五年發展，部分功能仍沿用至今。
由於引入了域的概念，即：Monitor Domain。該監控系統的亮點是解決了數據量的問題，並能夠支持水平擴展。
在數據庫方面，由於當時尚無 HBase 和 NoSQL 等解決方案，因此我們採用的是 MySQL。但是眾所周知，MySQL 對於監控方面的支持並不好。
例如：當我們需要將一個新的監控項的數據插入到數據庫時，我們就必須依次去建庫、建表，這顯然相當繁瑣。
後來，在 HBase 成熟之後，我們就把整個數據庫切換到了 HBase 之上。這對開發團隊而言，帶來了許多便利，同時整個系統的監控質量也提升了不少。
上圖是阿里巴巴如今最新的一代、也是最重要的監控平臺 Sunfire。在存儲方面，我們之前用的是 HBase，現在則轉為 HiTSDB（High-Performance Time Series Database，高性能時間序列數據庫）。
另外在數據採集方面，原來採用是在機器上安裝 Agent 的方式，而現在的系統則主要採集的是日誌，包括：業務方的日誌、系統的日誌、消息隊列的日誌等。
通過對接 SQL，我們將數據接入層抽象出來，同時保持上層的不變，此舉的好處在於體現了“租戶”的概念。
和許多采用推（Push）數據方式的監控系統不同，我們的這套架構是從上往下進行拉（Pull）數據的。
這一點，我們和普羅米修斯系統（Prometheus，它支持多維度的指標數據模型，服務端通過 HTTP 協議定時拉取數據的方式，靈活進行查詢，從而實現監控目的）有著相似之處，不過我們在後臺上會略強一些。
這套系統當前的規模反映在如下方面：
- 內部租戶數為 90 多個。這裡的租戶是指：天貓、淘寶、盒馬、優酷、高德等應用系統。
- 機器數為 4000 多臺。這是去年雙十一時的數量，其中後臺並非純粹是物理機，而是大多數為 4 核 8G 的虛擬機。
- 應用數為 11000 多個。
- 處理能力為每分鐘大概 2 個 T 的數據量。當然，這同樣也是去年雙十一的數值。
修煉內功
下面我們來看看阿里巴巴現役監控系統的具體特徵和能夠解決的業務痛點：
Zero-Copy
根據過往的監控經歷，當業務方發現採集到的 CPU 抖動指標居然是監控系統所致的話，他們會寧可不要監控系統。
因此我們通過優化，讓各臺受監控主機上的 Agent，不再調用任何業務資源、也不做任何處理，直接將原始數據匯聚並“拉”到中心節點。“用帶寬換CPU”這就是我們在設計監控系統的 Agent 時的一個原則。
而且，我們甚至都不會對日誌進行壓縮，因為壓縮操作同樣也會用到各個主機的 CPU。
Light-Akka
在框架方面，考慮到 Akka 先進的設計理念和不錯的性能，我們曾使用它來進行構建。
但是後來發現由於它是用 Scala 語言編寫的，消息不能“有且只有一次”進行傳遞，即無法保證 100% 可達。因此我們將自己最需要的部分抽取出來，用 Java 重新予以了實現。
Full-Asynchronous
由於數據量比較大，監控系統在運行的時候，任何一個節點一旦出現阻塞都是致命的。
我們通過將任務下發到 RegisterMapper，來“異步化”該架構的關鍵核心鏈路。
為了使得監控系統的全鏈路都實現“異步化”核心操作，我們可以使用網絡傳輸中的 Unity 和 Java 的異步 Http Client 等技術。大家只要稍作修改，便可達到全異步的效果。
LowPower-Agent
由於 Agent 的主要任務就是獲取日誌，因此我們通過不斷地猜測日誌的週期，根據上一次日誌所記錄的“遊標”，以時序的方式記住它們，便可大幅減少 CPU 的消耗，從而實現低功耗的 Agent。
上圖中 MQL 和 Self-Ops 也是兩個重要的方面，我們來繼續深入討論：
由於各種服務的功能眾多，需要監控的數據量巨大，而且數據種類與格式也都比較複雜，因此大家異曲同工地採用了各種 API 的調用方式。
對於阿里巴巴而言，我們在內部按照標準的 SQL 語法，做了一套監控數據的查詢語言：Monitor Query Language–MQL。它可以統一不同種類的需求，進而實現對所有監控系統的查詢。
從理論上說，無論請求有多複雜，MQL 都可以用一種 SQL 語言來表達。而且語法是由我們自行定義的，如上圖中白色文字所示。
上圖的下方是一個真實的例子，它查詢的是從 1 小時前開始，時間窗口為 5 分鐘間隔的 CPU 數據。
可見它實現起來非常簡單，大家一目瞭然。熟悉 SQL 的人基本上不學都會寫。
上圖是 Self-Ops 的界面，由於它是我們內部自用的，因此略顯有些粗糙。
對於每天 4000 臺機器的運維工作量，雖然不同的業務系統都有各自不同的監控工具，但是我們覺得有必要將自己的監控做成一個可自運維的系統。
因此，我們從機器的管理角度出發，自行建立了內部的 CMDB，其中包括軟件版本控制、發佈打包等功能。
籍此，我們不再依賴於各種中間件等組件，同時也奠定了監控系統的整體穩定性。另外，該系統也給我們帶來了一些額外的好處。
例如：阿里巴巴可以通過它很容易地“走出去”，接管那些海外收購公司（如 Lazada）的系統。
眾所周知，監控系統一般是在業務系統之後才建立起來的，不同的業務有著不同種類的日誌，而日誌中的相同特徵也會有不盡相同的格式表示。
因此，我們在 Agent 上下了不少的功夫，讓自己的系統能夠兼容各種可能性。例如：對於一個日期的表達，不同的系統就有著非常多的可能性。
所以我們在此兼容了七種常用和不常用的日期格式。同時，我們也能兼容不同的日誌目錄的寫法。
可見，大家在準備 Agent 時，不要老想著讓業務方來適應自己，而是要通過適應業務，來體現整套監控系統的核心價值。
如前所述，我們實現了自己的 MQL，而後端卻仍使用的是 HBase。雖然 HBase 非常穩定，但是在面對進一步開發時，就有些“乏力”了。它對於二級緩存的支持十分費勁，更別提各種維度的聚合了。
因此，為了讓 MQL 發揮作用，我們就需要切換到阿里巴巴內部基於 OpenTSDB 規範所實現的一種 TSDB 數據庫 HiTSDB 之上。
為了適應大規模的監控，我們如今正在努力不斷地去優化 HiTSDB，並預計能在今年的雙十一之前完成。
上面就是一個整體的框架圖，我們的監控平臺位於其中上部。當然在阿里巴巴的內部實際上有著多套不同的監控系統，它們在自己的垂直領域都有其獨特的價值。
鑑於我們的這套系統體量最大，因此我們希望將監控平臺下面的各種技術組件都統一起來。
如圖中紅色的“計算框架”部分所示，它在整個結構中的佔比非常大，因此我們將容災、性能監控、以及異步化等全都做到了裡面。
阿里巴巴如今已經出現了某個單應用涉及到超過一萬臺虛擬機的情況，那麼我們負責收集日誌事件的幾千臺監控機，在收集到該應用的指標之後，又將如何進行 Map，以及直接存入 HBase 中呢？
就現在的交易模式而言，每一條交易都會產生一行日誌。我們在一分鐘之內會採集到海量的日誌信息。
為了將它們最終轉變成交易數字，大家通常做法是像 Hadoop 的“兩步走”那樣在 Map 層把數字抽取出來，然後在 Reduce 層進行聚合。
例如：原來在一萬臺機器裡面有著好幾個單元的維度，如今要再增加一個單元的維度，那麼由於在 Reduce 層上代碼是被“寫死”的，因此我們要做相應的代碼修改。
在完成之後，我們才能按照機房、應用、分組的維度聚合出來，並放到 HBase 之中。
如今有了 HiTSDB 的解決方案，我們就只要做一次 Map，將日誌數據轉換成為 Key/Value，然後直接扔進 HiTSDB 之中便可，因此也就不再需要 Reduce 層了。
此舉的好處在於：通過省略其他的步驟，並僅使用 MQL 的 API，我們就能實現簡單的統計。
總結起來叫做：“把前面做輕，把後面做重”。這也是我們在架構上的一項鉅變。
上圖是普羅米修斯的架構圖，它與我們的 Sunfire 大同小異，操作理念都是“拉”的方式。
因此，我們正在努力去全面兼容普羅米修斯的前臺生態，而不是它的後臺。
如圖右側所示，普羅米修斯的前臺提供了大量的 Exporters，甚至還有針對 IoT 的 Exporter。由於同屬拉的方式，因此我們兼容起來並不費勁。
前面提到過我們用 4000 臺機器來進行監控系統，這是一大筆開銷。而兼容的另一個好處就是節省成本。
過去那種原封不動地拉取日誌的模式，既消耗帶寬資源，又耗費中心計算的成本。
如今根據普羅米修斯的概念則是：統計值，即它只統計單位時間的交易量，因此數據在總量上減少了許多。
對於報警與通知層面，我們通過“切出”的嘗試，實現瞭如下兩方面的效果：
- 粗剪掉報警和通知裡的誤報。
- 抑制報警和通知的爆發，避免出現報警風暴。
仰望星空
我們希望通過全方位、全鏈路的圖表將各個系統關聯起來。我認為業務的鏈路並非自動化產生的。
如上圖所反映的就是應用與機器之間的關係。但是由於該圖過於複雜、細節化、且沒有分層，因此大多數的應用開發人員都不喜歡使用這張圖。
於是，我們請來業務方人員進行人工繪製，詳略得反映出了他們的關注點。根據他們給出的手繪圖，我們再去做了上面的 Demo 圖。在今年的 618 大促時，我們就是跟據此圖實施的各種系統監控。
雖然我們從事監控工作的，多數出身於原來在運維中做開發、寫腳本的人員，但是大家不要侷限於僅解決眼前的各種運維問題，而應當多關心一些業務的方面。
去年阿里巴巴拆掉了整個運維團隊，並將運維融入了開發之中。通過 DevOps，我們將各個平臺層面、工具層面、自動化、智能等方面都追加了上來。
沒有了保姆式的運維服務，工具團隊和開發團隊需要自行開發出一套工具，該工具在橫向上是全方位維度+全鏈路的模式。
而在縱向上則包括：網絡質量、應用、線路指標、APM、網絡本身、IDC、以及數據。而這張圖就能起到很好的“串聯”作用。
如果您仔細觀察就會發現：在上圖中，每個方塊下方的指標都是一模一樣的。這是為什麼呢？
在《SRE：Google運維解密》一書的監控章節中，它提出了“黃金四指標”，即流量、延遲、成功率、飽和度。
那麼不管是業務、系統、還是應用，我們都可以運用這四個指標來進行判斷和解決。
所以在此，我們也將這四個指標當做業務方和應用方的標準，來衡量各種業務上出現的問題。
例如，在數據層面的標準化方面，我們從前年開始就嘗試著做了一個與 AI 沾點邊的“智能基線”。
不知大家是否注意到，其實淘寶的交易量具有著一定規律：晚上睡覺、吃飯時交易量會比較低；而八點鐘後，交易量會有所上升；另外白天十點鐘的聚划算也會拉高交易量。
因此智能基線就是要把這個曲線給模擬出來，進而能夠預測往後半小時的變化走勢。
通過該曲線，不管是業務方、開發、運維、還是運營，都能夠配置出自己的報警規則。
例如，我們可以配置為：在凌晨 2 點～4 點時段，如果真實的交易數據相對於基線下跌超過 20% 就執行報警（晚上交易量比較低，一旦波動就會很明顯）；白天則在與基線相差 5% 時予以報警。
以此類推，我們相繼開發出了上千條智能基線，並將它們作為基礎規範，運用到智能的監控場景中，最終將準確率提升到了 80% 以上。
可見，通過對業務指標的標準化，我們從成功率的指標出發，就能夠衡量和計算出來系統所碰到的問題。
說到 AI，我認為我們還處在“弱智能”的階段，而且是不能直接一步邁到強 AI 狀態的。
有一種說法是：“如今弱智能其實比強智能的需求更多”，可見我們需要有一個過渡的階段。
如果我們將前一頁圖中的那些小方塊的下方點擊開來的話，就會看到出現這張圖（當然真實場景會比該圖更為複雜）。該圖反映了業務指標和系統指標，而右側是做出的智能分析。
在前面“全方位全鏈路”的圖中，曾出現了一張紅色的定單。在傳統模式下，開發人員會在自己的腦子中產生一個排障的流程：從某個指標入手進行檢查，如果它顯示為正常的話，則迅速切換到下一個指標，以此類推下去。
那麼，我們的系統就應該能夠幫助開發人員，將其腦子裡針對某個問題的所有可能性，即上圖中各個相關的指標或框圖，按照我們既定的算法掃描一遍，以檢索出故障點。
此舉雖然簡單，甚至稱不上智能，但著實有效。這也就是我所稱之為的“弱智能”，而且今年我們將會大規模地上線該服務。
可見，此處體現出了“弱智能”比“強智能”更為重要的特點，這也是 AI 在監控領域落地的一個實例。
最後，我希望大家在日常腳踏實地從事開發與運維工作的同時，也能夠抬頭仰望星空。
在此，我給大家準備了一張圖，它是從一幅巨大，鉅細的總圖中截取出來的。我曾用它向老闆彙報 CMDB 的價值所在，且十分有效。
如圖所示，你可以假設自己是一個企業的老闆，試著從老闆的角度思考對於企業來說，特別是對 IT 而言，如何拉高營收和降低成本。
例如：在一般情況下，監控是不會在阿里雲上產生直接價值的，這體現的就是營收的維度。而我們要度量的成本還會包括額外成本，即圖中所顯示的“EX成本”。
例如：我們可以考慮是否真的需要用 4000 多臺機器的成本來做監控系統？
因此，“仰望星空”的“觀測點”可從圖中的三個綠色的點出發，即 MTTR（平均故障恢復時間）、預防和度量。
這些都是企業運營者最為關心的方面。同時，圖中的其他節點，大家也可以發散性地仔細思考一番。
十多年運維繫統開發經驗，現任職於阿里巴巴基礎設施事業群，負責阿里巴巴集團監控。主導構建第一代的阿里巴巴 CMDB 系統。現負責的監控業務覆蓋阿里巴巴全部事業群。
閱讀更多 51CTO傳媒 的文章
