我今天分享的內(nèi)容是：怎么在萬億交易量下實現(xiàn)足夠?qū)崟r的秒級監(jiān)控？

我先來介紹一下監(jiān)控系統(tǒng) Sunfire，它是阿里集團的業(yè)務監(jiān)控系統(tǒng)，前身是螞蟻的 xflush，它支持應用標準化監(jiān)控，如操作系統(tǒng)，JVM，中間件等。

除此之外還有更強大的日志監(jiān)控能力，大多數(shù)業(yè)務的監(jiān)控指標都從應用的日志中抽取。目前覆蓋了集團幾乎所有 BU 和絕大多數(shù)業(yè)務，每分鐘處理 TB 級日志。

下面我將從以下四個方面進行講解：

• 架構
• 規(guī)模與挑戰(zhàn)
• 技術選擇
• 方向

架構

每分鐘處理這么大的 TB 級日志量，我們是怎么設計架構去實現(xiàn)它的呢？

傳統(tǒng)日志監(jiān)控

上圖是傳統(tǒng)的日志監(jiān)控，現(xiàn)在大多數(shù)監(jiān)控平臺采用的一個方案。

Agent 檢測日志變化增量推送，經(jīng)過消息中間件如 kafka，流式計算引擎如 Jstorm/flink 去消費 kafka 產(chǎn)生出來的數(shù)據(jù)，中間的流式計算可能有多步的處理，***流向 DB，這是很傳統(tǒng)的架構。

這種架構會有一個問題就是：某一分鐘的數(shù)據(jù)，何時可以發(fā)報警？

流式計算的問題

Process Time 超過 Event Time Window，我們最早嘗試了上面?zhèn)鹘y(tǒng)的架構，但是有一個問題，我到底什么時候這個數(shù)據(jù)才能發(fā)報警呢？

因為這個架構最麻煩的是我不知道什么時候數(shù)據(jù)已經(jīng)全部到齊了。如果機器很多，Agent 返回數(shù)據(jù)的時間并不確定, 要保證所有機器日志采齊了數(shù)據(jù)才準確，這在流式計算里很難處理。

這是個經(jīng)典的問題，有兩篇文章很詳細的講解了流式計算中如何解決這種問題：

https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101

https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-102

但是數(shù)據(jù)丟了就是丟了, 無論怎么樣就是不準了，也很難拍出一個 delay 的時間確保數(shù)據(jù)可以用來發(fā)報警, 那么當數(shù)據(jù)不準時, 我們能不能知道不準了呢？

為了解決這個問題我們走了另一條路線：讓主動權留在服務端。

Sunfire 功能結構

這是 Sunfire 的功能結構，圖中比較重要的是 Sunfire-lika 模塊，它是用來支撐整個計算框架的，就是線程模型、消息調(diào)度處理、故障自愈恢復都是通過這個模塊實現(xiàn)的。

Sunfire 架構

上圖是 Sunfire 的架構圖，這個架構圖是怎么工作的呢？

首先有三個角色 Brain、Reduce 和 Map，這三個角色我們統(tǒng)稱為計算模塊。

ConfigDB 里面配置了監(jiān)控項。監(jiān)控項會定義配置需要從哪個應用、哪個路徑采集日志、采集回來的日志應該做哪些的處理、根據(jù)什么樣的規(guī)則進行計算。

Brain 會按照周期從 ConflgDB 里讀取配置，生成拓撲。然后安裝到 Reduce 上面，Reduce 把拓撲再分解成它的子任務，再安裝到 Map 上面，*** Map 去拉日志。

這里畫了兩個租戶，租戶 A 和共享租戶，其實就是資源是獨享的還是共用的。

因為我們有一些核心的交易監(jiān)控，也有一些不太重要的，還有很多邊緣業(yè)務。

如果是很重要的用戶，比如說交易，我們就單獨給它一個租戶，它的所有計算資源都是它自己獨享的。

對于一些邊緣的業(yè)務是可以共用服務器的。我們現(xiàn)在有 80 多個租戶，基本上一個租戶對應一個大的業(yè)務。

時序圖

用時序圖的視角看一下上面的任務。這個拓撲包括了配置，也包括這個拓撲任務從多少個服務器，到底從哪些服務器上去采集日志，都是在這個拓撲里面完成的。

有了這個拓撲，才有了節(jié)點故障時候，恢復它的前提條件。因為拓撲里面包含了所有信息，無論是哪個節(jié)點掛掉了，上游都能用它來恢復下游節(jié)點。

把這個拓撲安裝到一臺 Reduce 上面去，然后 Reduce 會把它分解掉。假如我有 1 臺 Reduce，有 100 個 Map，Reduce 會把這個任務分解成 100 個 Map。

如果這時候有 1000 個 Agent，有可能每個 Map 會采集 10 個 Agent 的日志，最終 Map 去 Agent 拉取日志。

然后再一步步往回走，Map 做初步的計算，Reduce 再做進一步的聚合存入到 HBase，然后最終返回給 Brain，告訴它這個任務完成了。

這里面存在很多可能會出問題的點，因為集群非常龐大，跑著跑著機器可能就掛掉了，這對我們來說是很正常的，一天掛掉十幾臺機器也是常有的事。

下面說一下怎么解決可靠性的問題。

關鍵點

上面架構有兩個關鍵點：

Preload

就是任務是提前注冊的，它不是在需要的時候才生成任務。我們把任務提前下發(fā)下去了，有什么好處呢？

假如集群有一些壞掉的機器可能網(wǎng)絡很慢也可能連不上，在這個階段就可以提前發(fā)現(xiàn)這些機器屏蔽掉，在后面真正去做任務的時候，延遲就會相應的降低很多，因為不需要再去等去重試了。

同時，Preload 是輸入共享的前提，因為不同的人會配同樣的日志，并且規(guī)則可能也是類似的，我們在這里會做輸入共享，去共享日志的采集來減少帶寬和 CPU 的消耗，也會共享中間一部分計算的結果。

Pull

主動權控制在服務端，就是服務端發(fā)現(xiàn)數(shù)據(jù)拉不上來，想要放棄還是重試，可以由自己做出決定了。

最終服務端會決定多長的時間內(nèi)，一定把這些全部都處理完，而不會過了很長一段時間還有數(shù)據(jù)突然推上來的問題了。

還有就是 push 時，有可能遇到網(wǎng)絡抖動，導致失敗，重試也不成功，但在 pull 模式下，相當于把 Agent 作為 hadoop 中的 hdfs 節(jié)點，只要日志還在，我們就有補數(shù)據(jù)的機會。

另外，降低用戶開銷對我們來說也是比較重要的，像雙十一場景，交易的應用開銷非常大，我們一定要盡量降低它們的開銷。比如占了 10% 的 CPU，交易的用戶就受不了這個開銷。

因此，所有的計算都是在服務端完成，也使得我們的集群規(guī)模非常大。

規(guī)模與挑戰(zhàn)

挑戰(zhàn)

挑戰(zhàn)主要來自于如圖中的這四個方面，都是因為規(guī)模而引起的挑戰(zhàn)。

規(guī)模

現(xiàn)在有 80 多個租戶，基本上一個租戶對應一個大的業(yè)務，比如交易是一個租戶，阿里媽媽是一個租戶，高德是一個租戶。

部署機器最多的時候有 6000 多臺，上面的應用有 8000 多個，每分鐘處理的日志量在 3000GB 以上，這只是常態(tài)化的日志量并不是***峰的日志量。

這么大的日志量用一個消息中間件去承載也是很困難的，這也是我們沒用流式計算的原因之一。

場景挑戰(zhàn)

場景挑戰(zhàn)主要有如下幾個方面：

某應用有上萬臺服務器，每分鐘產(chǎn)生的日志量近 1T，如何在秒級完成采集并輸出準確的結果？

假如有很多人配置了基于該日志的監(jiān)控項，如何降低開銷？

假如過程中有服務器宕機了，怎么辦？

快速

我們怎么實現(xiàn)快速拉取呢？

在 server 端，其中核心的鏈路是異步的，所有的通信也是異步的，沒有一個地方允許有鎖。

這兩個是通過上面提到的 lika 框架來實現(xiàn)的，lika 框架沒有什么特別神奇的地方，把 Akka 的一些核心理念拿出來做了一個簡化的框架，更簡單更容易維護。

在 Agent 端，最重要的是用了 Zero-copy，使得讀日志不經(jīng)過任何 CPU 的處理，直接通過 socket 發(fā)送出去。這樣***的好處是對用戶開銷極小，壞處就是不能壓縮了。

RandomAccessfile 是配合動態(tài)二分法來使用的，配日志的時候沒有讓用戶指定時間字段應該在哪個位置，時間是什么格式的，這些都是我們自己判斷的。

怎么知道用戶的某個周期應該推上去的日志是哪些呢？是通過動態(tài)二分法來實現(xiàn)的。

Brain 生成拓撲的時候，是有時間戳的。Agent 拿到以后，簡單來說先看頭和尾有沒有，因為日志是不斷打出來的，采集也是不斷進行的，尾部拿到的概率特別大。

如果不在就根據(jù)這個時間去找，把它做二分查找，***找到時間。上面提到的唯一開銷就來自這里，要去猜時間在哪，在極端情況下對用戶的 CPU 也能控制在 8% 以下。

準確

準確性從這個系統(tǒng)一開始設計時就貫穿始終的，也是我們?yōu)槭裁丛谝婚_始沒有用流式計算的原因。

除了 pull 的機制來把控制權保持在服務端之外，我們還設計了齊全度，這對我們來說是非常重要的。傳統(tǒng)的監(jiān)控一個指標產(chǎn)生一個值就行了，我們每一個值還有一個相對應的齊全度。

這個齊全度代表什么意思呢？比如 1000 臺機器里面有幾臺機器的網(wǎng)絡不通或者機器掛掉了，因為機器多了什么問題都會有，這很正常。

我們會在***采集完成的時候，多打出來一個指標說 1000 臺機器采集成功 900 臺，失敗 100 臺，成功率是 90%。

這時候用戶就有參考了，如果此時發(fā)現(xiàn)交易量下跌了，一看齊全度也下跌了，基本上可以認為是采集的問題導致的下跌，有可能并不是真正的業(yè)務下跌，可以來找我們看為什么采集缺失。

因此齊全度是我們特意設計出來，為了讓用戶直觀感受到采集的完整度的一個概念。

有了上面的措施還是不能保證準確，還需要有各種各樣的測試來驗證這些設計是不是可靠的。

所以在線上搭很多環(huán)境，測試同學造了各種各樣的配置，如虛擬的應用大部分機器都是壞掉的，或者大部分機器沒有產(chǎn)生日志。再配合上各種各樣的日志計算規(guī)則，去實時校驗。

準確性回歸是我們每次發(fā)布之前都必須做的，也是自動觸發(fā)的過程。只要我們每次打包都會觸發(fā)一次準確性校驗。自灰度就是找一些小白鼠，先發(fā)布他們，再發(fā)布重要的客戶。

穩(wěn)定

上面是我列舉的一些影響系統(tǒng)穩(wěn)定性的部分問題。最常見的像下發(fā)失敗，這種好處理，直接重試就可以了。

如果已經(jīng)下發(fā)成功了，但是在做的過程中失敗的，這就很麻煩了。所以我們 lika 框架很重要的一點，就是為這個服務的。

比如 Brain 生成任務以后，它安裝成功了一個 Reduce，Brain 就會去守護這個 Reduce。

我們有一套機制來保證 Reduce 執(zhí)行成功，直到返回成功給 Brain，這個任務才結束。

如果沒返回，Brain 就會不斷探測它，一旦探測到它失敗了，比如這臺機器連不上了，或者機器是好的但是任務中間出異常掛掉了，那么 Brain 會重試它，換一臺機器繼續(xù)做這個任務。像 Reduce 安裝完 Map 后失敗了，也是類似的邏輯。

拉日志也會帶來一些不可控的事情，就是我不知道要拉的日志到底有多大。有可能我這邊分配的計算機器數(shù)很少，但是用戶日志量非常大，就有可能把我們打爆了。

因此我們有一系列自我保護的邏輯，會計算每個監(jiān)控項的開銷，不能高于某一個值。如果高于這個值，說明監(jiān)控項消耗資源太高了，可能配了一些極其復雜的策略，這時為了自保必須把它 kill 掉。

我們也有實現(xiàn)內(nèi)存的分配策略，就是每次拉日志的大小是計算出來的。經(jīng)過一系列的因素計算出來這次能拉多少日志。如果內(nèi)存不夠，等一會兒再去拉。

同時，我們也做了一系列的自我監(jiān)控。我們是拿自己搭的另外一套環(huán)境來監(jiān)控自己。報警也是在這上面配的，來觀察各個租戶的狀態(tài)是不是正常的。

以上這些措施構成了穩(wěn)定性的保證。

穩(wěn)定性驗收

穩(wěn)定性最終是需要驗收的，不能說我們說穩(wěn)定就穩(wěn)定。上圖是我們設計的一些場景。

比如有多少機器宕機，看宕機的過程有沒有數(shù)據(jù)丟失或者數(shù)據(jù)不準。還有網(wǎng)絡丟包，Hbase 服務中斷等等，再恢復看能不能恢復。再有像整個機房斷網(wǎng)，讓某個機房成為孤島，來驗證它的穩(wěn)定性。

成本

在成本方面，集群機器的數(shù)量比較龐大，我們一直想努力降低成本，主要通過下面三個方面來做的。

租戶間調(diào)度/輸入共享

降低成本最重要的技術手段就是做了輸入共享，輸入共享在很多情況下能減少起碼三倍或者五倍的日志拉取。因為在多數(shù)情況下一個日志會產(chǎn)出多個指標，不同的指標也可能會打到同一份日志里面。

怎么做呢？Brain 提前注冊了 Reduce，Reduce 提前注冊了 Map，Map 上有一個關系，就是這個 Map 要采集哪些機器上的哪些日志。

最終可以構建出來一個關系，就是監(jiān)控項跟機器上的日志的對應關系。比如說***個監(jiān)控項要采集 100 臺機器上的某個日志，第二個監(jiān)控項還是要采集這批機器上的同樣日志。

這兩個任務就合并掉了，最終所有的采集同一份日志的任務都會被合并掉，這是提前注冊里面可以做的事情。

關系構建好了以后，就觸發(fā)一個定時器來觸發(fā)拉取。

清理僵尸配置

我們根據(jù)某個配置它最近一段時間被多少人訪問，有沒有報警，報警后有沒有人處理，等等一系列指標計算出監(jiān)控項的健康度。如果健康度太低，就會通知用戶去清理它，減少我們配置的量。

統(tǒng)計值優(yōu)先

統(tǒng)計值優(yōu)先也是現(xiàn)在不得不做的一個優(yōu)化。因為以前很多應用打的都是流水的日志。

以交易舉例，交易有很多環(huán)節(jié)，每個環(huán)節(jié)至少有一行日志，最終有可能1億筆交易對應100億條日志。

所以會要求大的業(yè)務方，把這些值改成統(tǒng)計值，至少是每秒或者每分鐘聚合后的值打出來。

輸入共享

對于多個配置，一份日志只采集一次。

技術選擇

上圖是我們做監(jiān)控的過程中做的一些技術選擇。拉和推模式各有優(yōu)缺點，為了準確性選擇了拉的模式，不排除推的模式也能搞定準確性，還是會走到推的路線上來，因為架構總是不斷迭代的。

計算應該在 Server 端還是 Agent 端執(zhí)行呢？因為用戶接受不了 CPU 使用率過高，會影響正常業(yè)務，因此我們最終選擇所有的計算都在 Server 端完成。

對于使用開源框架還是自研框架，我們也希望用開源框架，但如果有的地方滿足不了或者開源社區(qū)的方向跟我們期望的方向不太一致，我們可能就會基于這個框架的思想定制一個簡易的框架。

只有核心的設計，代碼體量小、維護也簡單，其實我們計算框架做出來以后，幾乎沒有產(chǎn)生過什么 Bug，因為它只做了消息分發(fā)線程池管理和故障守護這幾件事情。

在數(shù)據(jù)庫選擇上，當前我們是直接寫 Hbase，正在和 HiTSDB 團隊對接, 這是一個類 OpenTSDB 的存儲, 在阿里云上也有提供。

對于監(jiān)控來說，我們最終選擇的自運維，我們幾乎沒有強依賴任何系統(tǒng)。為什么呢？

因為我們有個理念，監(jiān)控應該是最基礎的設施，如果我們強依賴別人，我們將監(jiān)控不了它，所以我們做了一個自運維體系。

以上就是做的一些技術選擇，經(jīng)過了很多次迭代，最終走到了現(xiàn)在的路線。

方向

現(xiàn)在我們的方向是這四個：

• 標準化
• 一體化
• 服務化
• 智能化

標準化：MQL

select avg(cpu.util),max(load.load1) from system where app='AppTest' since 30mselect * from sunfire.1005_SM_13 since 30mselect * from spring filter class='classA' and method='methodB' where ip='192.168.1.1' since 1h

我們的 MQL 希望讓用戶能夠用一個通用的語法來查詢所有的監(jiān)控數(shù)據(jù)。甚至是其他監(jiān)控系統(tǒng)的數(shù)據(jù)，這樣用戶不用管數(shù)據(jù)是哪個平臺產(chǎn)生的。

MQL 在使用上也比原來的 API 更直觀一些，會是我們后面主推的提供給用戶 API 的方式。

一體化

我們還做了很多一體化的事情，比如說發(fā)現(xiàn)交易下跌了，這時候交易的應用有沒有做變更，有沒有擴容、縮容重啟的操作，這是用戶關心的。

我們統(tǒng)計出來有相當比例的故障是因為變更導致的，當業(yè)務異常的時候直觀的看到有沒有變更，可以為他省很多時間。雖然這個事情做起來很簡單，但是作用是很大的。

我們還把宿主機和網(wǎng)絡監(jiān)控也關聯(lián)起來了，現(xiàn)在用的都是容器，但有的問題可能是因為宿主機出問題了，或者上面負載太高了，用戶可以做出直觀的判斷。

同時，還把報警集成在釘釘里面完成。釘釘有什么好處呢？它跟傳統(tǒng)的短信、郵件報警不一樣，它可以有很豐富的交互。

用戶可以點擊進來看報警的詳情，甚至可以有曲線、報警的歷史，點進去還可以做一些重啟機器的操作，或者覺得這是個誤報我要關閉半個小時，都可以在這里一站式完成。這比以前用短信收報警的方式前進了一大步。

釘釘

釘釘一站式報警處理

智能化

在智能化上面我們也在做很多探索，比如智能基線。圖上有一段虛線，是通過算法預測出來這個曲線后面這段時間的走勢可能是什么樣的。

我們可以很直觀的判斷出來到底有沒有異常。進一步希望做到用戶不用配報警，自動幫它生成報警的閾值。

智能基線讓用戶只要配一個規(guī)則就可以了。原先是一天內(nèi)不同時間業(yè)務指標的范圍可能都不一樣，用戶只能根據(jù)時間段配了一堆規(guī)則。

上圖是簡化后的規(guī)則，有了智能基線以后只要配當前值和基線比超過百分之多少就報警，就這么簡單。

[[216449]]

作者：孔羅星

孔羅星（癲行），阿里研發(fā)效能事業(yè)部監(jiān)控平臺技術專家。2014 年加入阿里巴巴，曾在福建富士通開發(fā) CMDB，監(jiān)控等運維相關系統(tǒng)，有 6 年工作經(jīng)驗，從事過 DBA、SA、Python 開發(fā)、Java 開發(fā)。