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

[[238108]]

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

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

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

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

打怪升級(jí)

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

該組合的最大問(wèn)題是：不能規(guī)模化，一旦數(shù)據(jù)量達(dá)到規(guī)模級(jí)別之后，就會(huì)出現(xiàn)各式各樣的問(wèn)題。

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

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

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

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

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

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

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

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

通過(guò)對(duì)接 SQL，我們將數(shù)據(jù)接入層抽象出來(lái)，同時(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ù)端通過(guò) HTTP 協(xié)議定時(shí)拉取數(shù)據(jù)的方式，靈活進(jìn)行查詢，從而實(shí)現(xiàn)監(jiān)控目的）有著相似之處，不過(guò)我們?cè)诤笈_(tái)上會(huì)略強(qiáng)一些。

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

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

修煉內(nèi)功

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

Zero-Copy

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

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

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

Light-Akka

在框架方面，考慮到 Akka 先進(jìn)的設(shè)計(jì)理念和不錯(cuò)的性能，我們?cè)褂盟鼇?lái)進(jìn)行構(gòu)建。

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

Full-Asynchronous

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

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

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

LowPower-Agent

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

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

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

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

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

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

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

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

對(duì)于每天 4000 臺(tái)機(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)也給我們帶來(lái)了一些額外的好處。

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

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

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

所以我們?cè)诖思嫒萘似叻N常用和不常用的日期格式。同時(shí)，我們也能兼容不同的日志目錄的寫法。

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

[[238112]]

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

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

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

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

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

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

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

就現(xiàn)在的交易模式而言，每一條交易都會(huì)產(chǎn)生一行日志。我們?cè)谝环昼娭畠?nèi)會(huì)采集到海量的日志信息。

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

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

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

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

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

總結(jié)起來(lái)叫做：“把前面做輕，把后面做重”。這也是我們?cè)诩軜?gòu)上的一項(xiàng)巨變。

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

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

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

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

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

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

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

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

仰望星空

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

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

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

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

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

沒有了保姆式的運(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ì)觀察就會(huì)發(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)來(lái)進(jìn)行判斷和解決。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

這些都是企業(yè)運(yùn)營(yíng)者最為關(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)載請(qǐng)注明原文作者和出處為51CTO.com】