【51CTO.com原創(chuàng)稿件】阿里巴巴的監(jiān)控平臺經(jīng)歷了多次迭代與更替，在曲折發(fā)展中慢慢從簡單的自動化轉(zhuǎn)換為頗具智能化的系統(tǒng)運(yùn)維。

[[238108]]

2018 年 5 月 18-19 日，由 51CTO 主辦的全球軟件與運(yùn)維技術(shù)峰會在北京召開。

在“容器下的 AIOps”分論壇上，來自阿里巴巴集團(tuán)監(jiān)控負(fù)責(zé)人程超就《自動化到智能化的阿里監(jiān)控發(fā)展之路》主題進(jìn)行了精彩演講。

本文將從如下三個(gè)部分來分享阿里構(gòu)建超大規(guī)模的秒級監(jiān)控平臺的最佳實(shí)踐：

• 打怪升級
• 修煉內(nèi)功
• 仰望星空

打怪升級

和大部分的公司類似，阿里巴巴最初也采用的是 Nagios+Cacti 的開源模式。

該組合的最大問題是：不能規(guī)?；坏?shù)據(jù)量達(dá)到規(guī)模級別之后，就會出現(xiàn)各式各樣的問題。

另外，由于我們對該開源的組合未做深入研究，因此無法對它們進(jìn)行定制與修改。到了 2009 年，我們決定廢棄該組合，準(zhǔn)備自行搭建一套監(jiān)控系統(tǒng)。

如上圖所示，該自建系統(tǒng)支撐了阿里巴巴后續(xù)的五年發(fā)展，部分功能仍沿用至今。

由于引入了域的概念，即：Monitor Domain。該監(jiān)控系統(tǒng)的亮點(diǎn)是解決了數(shù)據(jù)量的問題，并能夠支持水平擴(kuò)展。

在數(shù)據(jù)庫方面，由于當(dāng)時(shí)尚無 HBase 和 NoSQL 等解決方案，因此我們采用的是 MySQL。但是眾所周知，MySQL 對于監(jiān)控方面的支持并不好。

例如：當(dāng)我們需要將一個(gè)新的監(jiān)控項(xiàng)的數(shù)據(jù)插入到數(shù)據(jù)庫時(shí)，我們就必須依次去建庫、建表，這顯然相當(dāng)繁瑣。

后來，在 HBase 成熟之后，我們就把整個(gè)數(shù)據(jù)庫切換到了 HBase 之上。這對開發(fā)團(tuán)隊(duì)而言，帶來了許多便利，同時(shí)整個(gè)系統(tǒng)的監(jiān)控質(zhì)量也提升了不少。

上圖是阿里巴巴如今最新的一代、也是最重要的監(jiān)控平臺 Sunfire。在存儲方面，我們之前用的是 HBase，現(xiàn)在則轉(zhuǎn)為 HiTSDB（High-Performance Time Series Database，高性能時(shí)間序列數(shù)據(jù)庫）。

另外在數(shù)據(jù)采集方面，原來采用是在機(jī)器上安裝 Agent 的方式，而現(xiàn)在的系統(tǒng)則主要采集的是日志，包括：業(yè)務(wù)方的日志、系統(tǒng)的日志、消息隊(duì)列的日志等。

通過對接 SQL，我們將數(shù)據(jù)接入層抽象出來，同時(shí)保持上層的不變，此舉的好處在于體現(xiàn)了“租戶”的概念。

和許多采用推（Push）數(shù)據(jù)方式的監(jiān)控系統(tǒng)不同，我們的這套架構(gòu)是從上往下進(jìn)行拉（Pull）數(shù)據(jù)的。

這一點(diǎn)，我們和普羅米修斯系統(tǒng)（Prometheus，它支持多維度的指標(biāo)數(shù)據(jù)模型，服務(wù)端通過 HTTP 協(xié)議定時(shí)拉取數(shù)據(jù)的方式，靈活進(jìn)行查詢，從而實(shí)現(xiàn)監(jiān)控目的）有著相似之處，不過我們在后臺上會略強(qiáng)一些。

這套系統(tǒng)當(dāng)前的規(guī)模反映在如下方面：

• 內(nèi)部租戶數(shù)為 90 多個(gè)。這里的租戶是指：天貓、淘寶、盒馬、優(yōu)酷、高德等應(yīng)用系統(tǒng)。
• 機(jī)器數(shù)為 4000 多臺。這是去年雙十一時(shí)的數(shù)量，其中后臺并非純粹是物理機(jī)，而是大多數(shù)為 4 核 8G 的虛擬機(jī)。
• 應(yīng)用數(shù)為 11000 多個(gè)。
• 處理能力為每分鐘大概 2 個(gè) T 的數(shù)據(jù)量。當(dāng)然，這同樣也是去年雙十一的數(shù)值。

修煉內(nèi)功

下面我們來看看阿里巴巴現(xiàn)役監(jiān)控系統(tǒng)的具體特征和能夠解決的業(yè)務(wù)痛點(diǎn)：

Zero-Copy

根據(jù)過往的監(jiān)控經(jīng)歷，當(dāng)業(yè)務(wù)方發(fā)現(xiàn)采集到的 CPU 抖動指標(biāo)居然是監(jiān)控系統(tǒng)所致的話，他們會寧可不要監(jiān)控系統(tǒng)。

因此我們通過優(yōu)化，讓各臺受監(jiān)控主機(jī)上的 Agent，不再調(diào)用任何業(yè)務(wù)資源、也不做任何處理，直接將原始數(shù)據(jù)匯聚并“拉”到中心節(jié)點(diǎn)。“用帶寬換CPU”這就是我們在設(shè)計(jì)監(jiān)控系統(tǒng)的 Agent 時(shí)的一個(gè)原則。

而且，我們甚至都不會對日志進(jìn)行壓縮，因?yàn)閴嚎s操作同樣也會用到各個(gè)主機(jī)的 CPU。

Light-Akka

在框架方面，考慮到 Akka 先進(jìn)的設(shè)計(jì)理念和不錯(cuò)的性能，我們曾使用它來進(jìn)行構(gòu)建。

但是后來發(fā)現(xiàn)由于它是用 Scala 語言編寫的，消息不能“有且只有一次”進(jìn)行傳遞，即無法保證 100% 可達(dá)。因此我們將自己最需要的部分抽取出來，用 Java 重新予以了實(shí)現(xiàn)。

Full-Asynchronous

由于數(shù)據(jù)量比較大，監(jiān)控系統(tǒng)在運(yùn)行的時(shí)候，任何一個(gè)節(jié)點(diǎn)一旦出現(xiàn)阻塞都是致命的。

我們通過將任務(wù)下發(fā)到 RegisterMapper，來“異步化”該架構(gòu)的關(guān)鍵核心鏈路。

為了使得監(jiān)控系統(tǒng)的全鏈路都實(shí)現(xiàn)“異步化”核心操作，我們可以使用網(wǎng)絡(luò)傳輸中的 Unity 和 Java 的異步 Http Client 等技術(shù)。大家只要稍作修改，便可達(dá)到全異步的效果。

LowPower-Agent

由于 Agent 的主要任務(wù)就是獲取日志，因此我們通過不斷地猜測日志的周期，根據(jù)上一次日志所記錄的“游標(biāo)”，以時(shí)序的方式記住它們，便可大幅減少 CPU 的消耗，從而實(shí)現(xiàn)低功耗的 Agent。

上圖中 MQL 和 Self-Ops 也是兩個(gè)重要的方面，我們來繼續(xù)深入討論：

由于各種服務(wù)的功能眾多，需要監(jiān)控的數(shù)據(jù)量巨大，而且數(shù)據(jù)種類與格式也都比較復(fù)雜，因此大家異曲同工地采用了各種 API 的調(diào)用方式。

對于阿里巴巴而言，我們在內(nèi)部按照標(biāo)準(zhǔn)的 SQL 語法，做了一套監(jiān)控?cái)?shù)據(jù)的查詢語言：Monitor Query Language–MQL。它可以統(tǒng)一不同種類的需求，進(jìn)而實(shí)現(xiàn)對所有監(jiān)控系統(tǒng)的查詢。

從理論上說，無論請求有多復(fù)雜，MQL 都可以用一種 SQL 語言來表達(dá)。而且語法是由我們自行定義的，如上圖中白色文字所示。

上圖的下方是一個(gè)真實(shí)的例子，它查詢的是從 1 小時(shí)前開始，時(shí)間窗口為 5 分鐘間隔的 CPU 數(shù)據(jù)。

可見它實(shí)現(xiàn)起來非常簡單，大家一目了然。熟悉 SQL 的人基本上不學(xué)都會寫。

上圖是 Self-Ops 的界面，由于它是我們內(nèi)部自用的，因此略顯有些粗糙。

對于每天 4000 臺機(jī)器的運(yùn)維工作量，雖然不同的業(yè)務(wù)系統(tǒng)都有各自不同的監(jiān)控工具，但是我們覺得有必要將自己的監(jiān)控做成一個(gè)可自運(yùn)維的系統(tǒng)。

因此，我們從機(jī)器的管理角度出發(fā)，自行建立了內(nèi)部的 CMDB，其中包括軟件版本控制、發(fā)布打包等功能。

籍此，我們不再依賴于各種中間件等組件，同時(shí)也奠定了監(jiān)控系統(tǒng)的整體穩(wěn)定性。另外，該系統(tǒng)也給我們帶來了一些額外的好處。

例如：阿里巴巴可以通過它很容易地“走出去”，接管那些海外收購公司（如 Lazada）的系統(tǒng)。

眾所周知，監(jiān)控系統(tǒng)一般是在業(yè)務(wù)系統(tǒng)之后才建立起來的，不同的業(yè)務(wù)有著不同種類的日志，而日志中的相同特征也會有不盡相同的格式表示。

因此，我們在 Agent 上下了不少的功夫，讓自己的系統(tǒng)能夠兼容各種可能性。例如：對于一個(gè)日期的表達(dá)，不同的系統(tǒng)就有著非常多的可能性。

所以我們在此兼容了七種常用和不常用的日期格式。同時(shí)，我們也能兼容不同的日志目錄的寫法。

可見，大家在準(zhǔn)備 Agent 時(shí)，不要老想著讓業(yè)務(wù)方來適應(yīng)自己，而是要通過適應(yīng)業(yè)務(wù)，來體現(xiàn)整套監(jiān)控系統(tǒng)的核心價(jià)值。

[[238112]]

如前所述，我們實(shí)現(xiàn)了自己的 MQL，而后端卻仍使用的是 HBase。雖然 HBase 非常穩(wěn)定，但是在面對進(jìn)一步開發(fā)時(shí)，就有些“乏力”了。它對于二級緩存的支持十分費(fèi)勁，更別提各種維度的聚合了。

因此，為了讓 MQL 發(fā)揮作用，我們就需要切換到阿里巴巴內(nèi)部基于 OpenTSDB 規(guī)范所實(shí)現(xiàn)的一種 TSDB 數(shù)據(jù)庫 HiTSDB 之上。

為了適應(yīng)大規(guī)模的監(jiān)控，我們?nèi)缃裾谂Σ粩嗟厝?yōu)化 HiTSDB，并預(yù)計(jì)能在今年的雙十一之前完成。

上面就是一個(gè)整體的框架圖，我們的監(jiān)控平臺位于其中上部。當(dāng)然在阿里巴巴的內(nèi)部實(shí)際上有著多套不同的監(jiān)控系統(tǒng)，它們在自己的垂直領(lǐng)域都有其獨(dú)特的價(jià)值。

鑒于我們的這套系統(tǒng)體量最大，因此我們希望將監(jiān)控平臺下面的各種技術(shù)組件都統(tǒng)一起來。

如圖中紅色的“計(jì)算框架”部分所示，它在整個(gè)結(jié)構(gòu)中的占比非常大，因此我們將容災(zāi)、性能監(jiān)控、以及異步化等全都做到了里面。

阿里巴巴如今已經(jīng)出現(xiàn)了某個(gè)單應(yīng)用涉及到超過一萬臺虛擬機(jī)的情況，那么我們負(fù)責(zé)收集日志事件的幾千臺監(jiān)控機(jī)，在收集到該應(yīng)用的指標(biāo)之后，又將如何進(jìn)行 Map，以及直接存入 HBase 中呢？

就現(xiàn)在的交易模式而言，每一條交易都會產(chǎn)生一行日志。我們在一分鐘之內(nèi)會采集到海量的日志信息。

為了將它們最終轉(zhuǎn)變成交易數(shù)字，大家通常做法是像 Hadoop 的“兩步走”那樣在 Map 層把數(shù)字抽取出來，然后在 Reduce 層進(jìn)行聚合。

例如：原來在一萬臺機(jī)器里面有著好幾個(gè)單元的維度，如今要再增加一個(gè)單元的維度，那么由于在 Reduce 層上代碼是被“寫死”的，因此我們要做相應(yīng)的代碼修改。

在完成之后，我們才能按照機(jī)房、應(yīng)用、分組的維度聚合出來，并放到 HBase 之中。

如今有了 HiTSDB 的解決方案，我們就只要做一次 Map，將日志數(shù)據(jù)轉(zhuǎn)換成為 Key/Value，然后直接扔進(jìn) HiTSDB 之中便可，因此也就不再需要 Reduce 層了。

此舉的好處在于：通過省略其他的步驟，并僅使用 MQL 的 API，我們就能實(shí)現(xiàn)簡單的統(tǒng)計(jì)。

總結(jié)起來叫做：“把前面做輕，把后面做重”。這也是我們在架構(gòu)上的一項(xiàng)巨變。

上圖是普羅米修斯的架構(gòu)圖，它與我們的 Sunfire 大同小異，操作理念都是“拉”的方式。

因此，我們正在努力去全面兼容普羅米修斯的前臺生態(tài)，而不是它的后臺。

如圖右側(cè)所示，普羅米修斯的前臺提供了大量的 Exporters，甚至還有針對 IoT 的 Exporter。由于同屬拉的方式，因此我們兼容起來并不費(fèi)勁。

前面提到過我們用 4000 臺機(jī)器來進(jìn)行監(jiān)控系統(tǒng)，這是一大筆開銷。而兼容的另一個(gè)好處就是節(jié)省成本。

過去那種原封不動地拉取日志的模式，既消耗帶寬資源，又耗費(fèi)中心計(jì)算的成本。

如今根據(jù)普羅米修斯的概念則是：統(tǒng)計(jì)值，即它只統(tǒng)計(jì)單位時(shí)間的交易量，因此數(shù)據(jù)在總量上減少了許多。

對于報(bào)警與通知層面，我們通過“切出”的嘗試，實(shí)現(xiàn)了如下兩方面的效果：

• 粗剪掉報(bào)警和通知里的誤報(bào)。
• 抑制報(bào)警和通知的爆發(fā)，避免出現(xiàn)報(bào)警風(fēng)暴。

仰望星空

我們希望通過全方位、全鏈路的圖表將各個(gè)系統(tǒng)關(guān)聯(lián)起來。我認(rèn)為業(yè)務(wù)的鏈路并非自動化產(chǎn)生的。

如上圖所反映的就是應(yīng)用與機(jī)器之間的關(guān)系。但是由于該圖過于復(fù)雜、細(xì)節(jié)化、且沒有分層，因此大多數(shù)的應(yīng)用開發(fā)人員都不喜歡使用這張圖。

于是，我們請來業(yè)務(wù)方人員進(jìn)行人工繪制，詳略得反映出了他們的關(guān)注點(diǎn)。根據(jù)他們給出的手繪圖，我們再去做了上面的 Demo 圖。在今年的 618 大促時(shí)，我們就是跟據(jù)此圖實(shí)施的各種系統(tǒng)監(jiān)控。

雖然我們從事監(jiān)控工作的，多數(shù)出身于原來在運(yùn)維中做開發(fā)、寫腳本的人員，但是大家不要局限于僅解決眼前的各種運(yùn)維問題，而應(yīng)當(dāng)多關(guān)心一些業(yè)務(wù)的方面。

去年阿里巴巴拆掉了整個(gè)運(yùn)維團(tuán)隊(duì)，并將運(yùn)維融入了開發(fā)之中。通過 DevOps，我們將各個(gè)平臺層面、工具層面、自動化、智能等方面都追加了上來。

沒有了保姆式的運(yùn)維服務(wù)，工具團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)需要自行開發(fā)出一套工具，該工具在橫向上是全方位維度+全鏈路的模式。

而在縱向上則包括：網(wǎng)絡(luò)質(zhì)量、應(yīng)用、線路指標(biāo)、APM、網(wǎng)絡(luò)本身、IDC、以及數(shù)據(jù)。而這張圖就能起到很好的“串聯(lián)”作用。

如果您仔細(xì)觀察就會發(fā)現(xiàn)：在上圖中，每個(gè)方塊下方的指標(biāo)都是一模一樣的。這是為什么呢？

在《SRE：Google運(yùn)維解密》一書的監(jiān)控章節(jié)中，它提出了“黃金四指標(biāo)”，即流量、延遲、成功率、飽和度。

那么不管是業(yè)務(wù)、系統(tǒng)、還是應(yīng)用，我們都可以運(yùn)用這四個(gè)指標(biāo)來進(jìn)行判斷和解決。

所以在此，我們也將這四個(gè)指標(biāo)當(dāng)做業(yè)務(wù)方和應(yīng)用方的標(biāo)準(zhǔn)，來衡量各種業(yè)務(wù)上出現(xiàn)的問題。

例如，在數(shù)據(jù)層面的標(biāo)準(zhǔn)化方面，我們從前年開始就嘗試著做了一個(gè)與 AI 沾點(diǎn)邊的“智能基線”。

不知大家是否注意到，其實(shí)淘寶的交易量具有著一定規(guī)律：晚上睡覺、吃飯時(shí)交易量會比較低；而八點(diǎn)鐘后，交易量會有所上升；另外白天十點(diǎn)鐘的聚劃算也會拉高交易量。

因此智能基線就是要把這個(gè)曲線給模擬出來，進(jìn)而能夠預(yù)測往后半小時(shí)的變化走勢。

通過該曲線，不管是業(yè)務(wù)方、開發(fā)、運(yùn)維、還是運(yùn)營，都能夠配置出自己的報(bào)警規(guī)則。

例如，我們可以配置為：在凌晨 2 點(diǎn)～4 點(diǎn)時(shí)段，如果真實(shí)的交易數(shù)據(jù)相對于基線下跌超過 20% 就執(zhí)行報(bào)警（晚上交易量比較低，一旦波動就會很明顯）；白天則在與基線相差 5% 時(shí)予以報(bào)警。

以此類推，我們相繼開發(fā)出了上千條智能基線，并將它們作為基礎(chǔ)規(guī)范，運(yùn)用到智能的監(jiān)控場景中，最終將準(zhǔn)確率提升到了 80% 以上。

可見，通過對業(yè)務(wù)指標(biāo)的標(biāo)準(zhǔn)化，我們從成功率的指標(biāo)出發(fā)，就能夠衡量和計(jì)算出來系統(tǒng)所碰到的問題。

說到 AI，我認(rèn)為我們還處在“弱智能”的階段，而且是不能直接一步邁到強(qiáng) AI 狀態(tài)的。

有一種說法是：“如今弱智能其實(shí)比強(qiáng)智能的需求更多”，可見我們需要有一個(gè)過渡的階段。

如果我們將前一頁圖中的那些小方塊的下方點(diǎn)擊開來的話，就會看到出現(xiàn)這張圖（當(dāng)然真實(shí)場景會比該圖更為復(fù)雜）。該圖反映了業(yè)務(wù)指標(biāo)和系統(tǒng)指標(biāo)，而右側(cè)是做出的智能分析。

在前面“全方位全鏈路”的圖中，曾出現(xiàn)了一張紅色的定單。在傳統(tǒng)模式下，開發(fā)人員會在自己的腦子中產(chǎn)生一個(gè)排障的流程：從某個(gè)指標(biāo)入手進(jìn)行檢查，如果它顯示為正常的話，則迅速切換到下一個(gè)指標(biāo)，以此類推下去。

那么，我們的系統(tǒng)就應(yīng)該能夠幫助開發(fā)人員，將其腦子里針對某個(gè)問題的所有可能性，即上圖中各個(gè)相關(guān)的指標(biāo)或框圖，按照我們既定的算法掃描一遍，以檢索出故障點(diǎn)。

此舉雖然簡單，甚至稱不上智能，但著實(shí)有效。這也就是我所稱之為的“弱智能”，而且今年我們將會大規(guī)模地上線該服務(wù)。

可見，此處體現(xiàn)出了“弱智能”比“強(qiáng)智能”更為重要的特點(diǎn)，這也是 AI 在監(jiān)控領(lǐng)域落地的一個(gè)實(shí)例。

最后，我希望大家在日常腳踏實(shí)地從事開發(fā)與運(yùn)維工作的同時(shí)，也能夠抬頭仰望星空。

在此，我給大家準(zhǔn)備了一張圖，它是從一幅巨大，巨細(xì)的總圖中截取出來的。我曾用它向老板匯報(bào) CMDB 的價(jià)值所在，且十分有效。

如圖所示，你可以假設(shè)自己是一個(gè)企業(yè)的老板，試著從老板的角度思考對于企業(yè)來說，特別是對 IT 而言，如何拉高營收和降低成本。

例如：在一般情況下，監(jiān)控是不會在阿里云上產(chǎn)生直接價(jià)值的，這體現(xiàn)的就是營收的維度。而我們要度量的成本還會包括額外成本，即圖中所顯示的“EX成本”。

例如：我們可以考慮是否真的需要用 4000 多臺機(jī)器的成本來做監(jiān)控系統(tǒng)？

因此，“仰望星空”的“觀測點(diǎn)”可從圖中的三個(gè)綠色的點(diǎn)出發(fā)，即 MTTR（平均故障恢復(fù)時(shí)間）、預(yù)防和度量。

這些都是企業(yè)運(yùn)營者最為關(guān)心的方面。同時(shí)，圖中的其他節(jié)點(diǎn)，大家也可以發(fā)散性地仔細(xì)思考一番。

[[238117]]

十多年運(yùn)維系統(tǒng)開發(fā)經(jīng)驗(yàn)，現(xiàn)任職于阿里巴巴基礎(chǔ)設(shè)施事業(yè)群，負(fù)責(zé)阿里巴巴集團(tuán)監(jiān)控。主導(dǎo)構(gòu)建第一代的阿里巴巴 CMDB 系統(tǒng)。現(xiàn)負(fù)責(zé)的監(jiān)控業(yè)務(wù)覆蓋阿里巴巴全部事業(yè)群。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】