002_阿里監控平臺的「打怪升級」之路

阿里巴巴監控平臺通過了這麼多年的發展，與時俱進從最開始的簡單自動化到如今的人工智能的系統運維。在這我的叫作容器下的 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

所以咱們經過優化，讓各臺受監控主機上的 Agent，再也不調用任何業務資源、也不作任何處理，直接將原始數據匯聚並「拉」到中心節點。「用帶寬換CPU」這就是咱們在設計監控系統的 Agent 時的一個原則。

 

根據過往的監控經歷，當業務方發現採集到的 CPU 抖動指標竟然是監控系統所致的話，他們會寧肯不要監控系統。並且，咱們甚至都不會對日誌進行壓縮，由於壓縮操做一樣也會用到各個主機的 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 中呢？

現在有了 HiTSDB 的解決方案，咱們就只要作一次 Map，將日誌數據轉換成爲 Key/Value，而後直接扔進 HiTSDB 之中即可，所以也就再也不須要 Reduce 層了。總結起來叫作：「把前面作輕，把後面作重」。這也是咱們在架構上的一項鉅變。

就如今的交易模式而言，每一條交易都會產生一行日誌。咱們在一分鐘以內會採集到海量的日誌信息。爲了將它們最終轉變成交易數字，你們一般作法是像 Hadoop 的「兩步走」那樣在 Map 層把數字抽取出來，而後在 Reduce 層進行聚合。

上圖是普羅米修斯的架構圖，它與咱們的 Sunfire 大同小異，操做理念都是「拉」的方式。過去那種原封不動地拉取日誌的模式，既消耗帶寬資源，又耗費中心計算的成本。現在根據普羅米修斯的概念則是：統計值，即它只統計單位時間的交易量，所以數據在總量上減小了許多。

對於報警與通知層面，咱們經過「切出」的嘗試，實現了以下兩方面的效果：

• 粗剪掉報警和通知裏的誤報。

• 抑制報警和通知的爆發，避免出現報警風暴。

仰望星空

咱們但願經過全方位、全鏈路的圖表將各個系統關聯起來。我認爲業務的鏈路並不是自動化產生的。

如上圖所反映的就是應用與機器之間的關係。可是因爲該圖過於複雜、細節化、且沒有分層，所以大多數的應用開發人員都不喜歡使用這張圖。

因而，咱們請來業務方人員進行人工繪製，詳略得反映出了他們的關注點。根據他們給出的手繪圖，咱們再去作了上面的 Demo 圖。在今年的 618 大促時，咱們就是跟據此圖實施的各類系統監控。

雖然咱們從事監控工做的，多數出身於原來在運維中作開發、寫腳本的人員，可是你們不要侷限於僅解決眼前的各類運維問題，而應當多關心一些業務的方面。

去年阿里巴巴拆掉了整個運維團隊，並將運維融入了開發之中。經過 DevOps，咱們將各個平臺層面、工具層面、自動化、智能等方面都追加了上來。

而在縱向上則包括：網絡質量、應用、線路指標、APM、網絡自己、IDC、以及數據。而這張圖就能起到很好的「串聯」做用。

 

說到 AI，我認爲咱們還處在「弱智能」的階段，並且是不能直接一步邁到強 AI 狀態的。

有一種說法是：「現在弱智能其實比強智能的需求更多」，可見咱們須要有一個過渡的階段。

若是咱們將前一頁圖中的那些小方塊的下方點擊開來的話，就會看到出現這張圖（固然真實場景會比該圖更爲複雜）。該圖反映了業務指標和系統指標，而右側是作出的智能分析。

在前面「全方位全鏈路」的圖中，曾出現了一張紅色的定單。在傳統模式下，開發人員會在本身的腦子中產生一個排障的流程：從某個指標入手進行檢查，若是它顯示爲正常的話，則迅速切換到下一個指標，以此類推下去。

那麼，咱們的系統就應該可以幫助開發人員，將其腦子裏針對某個問題的全部可能性，即上圖中各個相關的指標或框圖，按照咱們既定的算法掃描一遍，以檢索出故障點。

此舉雖然簡單，甚至稱不上智能，但着實有效。這也就是我所稱之爲的「弱智能」，並且今年咱們將會大規模地上線該服務。

可見，此處體現出了「弱智能」比「強智能」更爲重要的特色，這也是 AI 在監控領域落地的一個實例。

最後，我但願你們在平常腳踏實地從事開發與運維工做的同時，也可以擡頭仰望星空。

在此，我給你們準備了一張圖，它是從一幅巨大，鉅細的總圖中截取出來的。我曾用它向老闆彙報 CMDB 的價值所在，且十分有效。

如圖所示，你能夠假設本身是一個企業的老闆，試着從老闆的角度思考對於企業來講，特別是對 IT 而言，如何拉高營收和下降成本。

在通常狀況下，監控是不會在阿里雲上產生直接價值的，這體現的就是營收的維度。而咱們要度量的成本還會包括額外成本，即圖中所顯示的「EX成本」。所以，「仰望星空」的「觀測點」可從圖中的三個綠色的點出發，即 MTTR（平均故障恢復時間）、預防和度量。