摘要：為了讓大交通下的各業(yè)務(wù)線都能夠通過(guò)報(bào)警盡早發(fā)現(xiàn)問(wèn)題解決問(wèn)題，進(jìn)而提升業(yè)務(wù)系統(tǒng)的服務(wù)質(zhì)量，我們決定構(gòu)建統(tǒng)一的監(jiān)控報(bào)警系統(tǒng)。本文主要介紹馬蜂窩大交通業(yè)務(wù)監(jiān)控報(bào)警系統(tǒng)的定位整體架構(gòu)設(shè)計(jì)，以及我們?cè)诼涞貙?shí)踐過(guò)程中的一些踩坑經(jīng)驗(yàn)。

部門的業(yè)務(wù)線越來(lái)越多，任何一個(gè)線上運(yùn)行的應(yīng)用，都可能因?yàn)楦鞣N各樣的原因出現(xiàn)問(wèn)題：比如業(yè)務(wù)層面，訂單量比上周減少了，流量突然下降了；技術(shù)層面的問(wèn)題，系統(tǒng)出現(xiàn) ERROR ，接口響應(yīng)變慢了。拿大交通業(yè)務(wù)來(lái)說(shuō)，一個(gè)明顯的特點(diǎn)是依賴很多供應(yīng)商的服務(wù)，所以我們還需要關(guān)注調(diào)用供應(yīng)商接口是否出現(xiàn)異常等等。

為了讓大交通下的各業(yè)務(wù)線都能夠通過(guò)報(bào)警盡早發(fā)現(xiàn)問(wèn)題、解決問(wèn)題，進(jìn)而提升業(yè)務(wù)系統(tǒng)的服務(wù)質(zhì)量，我們決定構(gòu)建統(tǒng)一的監(jiān)控報(bào)警系統(tǒng)。一方面在第一時(shí)間發(fā)現(xiàn)已經(jīng)出現(xiàn)的系統(tǒng)異常，及時(shí)解決；另一方面盡早發(fā)現(xiàn)一些潛在的問(wèn)題，比如某個(gè)系統(tǒng)目前來(lái)看沒(méi)有影響業(yè)務(wù)邏輯的正常運(yùn)轉(zhuǎn)，但是一些操作耗時(shí)已經(jīng)比較長(zhǎng)等，這類問(wèn)題如果不及時(shí)處理，將來(lái)就很可能影響業(yè)務(wù)的發(fā)展。

本文主要介紹馬蜂窩大交通業(yè)務(wù)監(jiān)控報(bào)警系統(tǒng)的定位、整體架構(gòu)設(shè)計(jì)，以及我們?cè)诼涞貙?shí)踐過(guò)程中的一些踩坑經(jīng)驗(yàn)。

我們希望監(jiān)控報(bào)警系統(tǒng)主要具備以下三個(gè)能力：

1. 常用組件自動(dòng)報(bào)警：對(duì)于各業(yè)務(wù)系統(tǒng)常用的框架組件（如 RPC ，HTTP 等）創(chuàng)建默認(rèn)報(bào)警規(guī)則，來(lái)方便框架層面的統(tǒng)一監(jiān)控。

2. 業(yè)務(wù)自定義報(bào)警：業(yè)務(wù)指標(biāo)由業(yè)務(wù)開發(fā)自定義埋點(diǎn)字段，來(lái)記錄每個(gè)業(yè)務(wù)和系統(tǒng)模塊的特殊運(yùn)行狀況。

3. 快速定位問(wèn)題：發(fā)現(xiàn)問(wèn)題并不是目的，解決才是關(guān)鍵。我們希望在完成報(bào)警消息發(fā)送后，可以讓開發(fā)者一目了然地發(fā)現(xiàn)問(wèn)題出現(xiàn)在什么地方，從而快速解決。

在這樣的前提下，報(bào)警中心的整體架構(gòu)圖和關(guān)鍵流程如下圖所示：

縱向來(lái)看，Kafka 左側(cè)是報(bào)警中心，右側(cè)是業(yè)務(wù)系統(tǒng)。

報(bào)警中心的架構(gòu)共分為三層，最上層是 WEB 后臺(tái)管理頁(yè)面，主要完成報(bào)警規(guī)則的維護(hù)和報(bào)警記錄的查詢；中間層是報(bào)警中心的核心；最下面一層是數(shù)據(jù)層。業(yè)務(wù)系統(tǒng)通過(guò)一個(gè)叫做 mes-client-starter 的 jar 包完成報(bào)警中心的接入。

我們可以將報(bào)警中心的工作劃分為五個(gè)模塊：

我們采用指標(biāo)采集上報(bào)的方式來(lái)發(fā)現(xiàn)系統(tǒng)問(wèn)題，就是將系統(tǒng)運(yùn)行過(guò)程中我們關(guān)注的一些指標(biāo)進(jìn)行記錄和上傳。上傳的方式可以是日志、 UDP 等等。

首先數(shù)據(jù)收集模塊我們沒(méi)有重復(fù)造輪子，可是直接基于 MES （馬蜂窩內(nèi)部的大數(shù)據(jù)分析工具）來(lái)實(shí)現(xiàn)，主要考慮下面幾個(gè)方面的原因：一來(lái)數(shù)據(jù)分析和報(bào)警在數(shù)據(jù)來(lái)源上是相似的；二來(lái)可以節(jié)省很多開發(fā)成本；同時(shí)也方便報(bào)警的接入。

那具體應(yīng)該采集哪些指標(biāo)呢？以大交通業(yè)務(wù)場(chǎng)景下用戶的一次下單請(qǐng)求為例，整個(gè)鏈路可能包括 HTTP 請(qǐng)求、Dubbo 調(diào)用、SQL 操作，中間可能還包括校驗(yàn)、轉(zhuǎn)換、賦值等環(huán)節(jié)。一整套調(diào)用下來(lái)，會(huì)涉及到很多類和方法，我們不可能對(duì)每個(gè)類、每個(gè)方法調(diào)用都做采集，既耗時(shí)也沒(méi)有意義。

為了以最小的成本來(lái)盡可能多地發(fā)現(xiàn)問(wèn)題，我們選取了一些系統(tǒng)常用的框架組件自動(dòng)打點(diǎn)，比如 HTTP、SQL、我們使用的 RPC 框架 Dubbo ，實(shí)現(xiàn)框架層面的統(tǒng)一監(jiān)控。

而對(duì)于業(yè)務(wù)來(lái)說(shuō)，每個(gè)業(yè)務(wù)系統(tǒng)關(guān)注的指標(biāo)都不一樣。對(duì)于不同業(yè)務(wù)開發(fā)人員需要關(guān)注的不同指標(biāo)，比如支付成功訂單數(shù)量等，開發(fā)人員可以通過(guò)系統(tǒng)提供的 API 進(jìn)行手動(dòng)埋點(diǎn)，自己定義不同業(yè)務(wù)和系統(tǒng)模塊需要關(guān)注的指標(biāo)。

對(duì)于采集上來(lái)的動(dòng)態(tài)指標(biāo)數(shù)據(jù)，我們選擇使用 Elasticsearch 來(lái)存儲(chǔ)，主要基于兩點(diǎn)原因：

一是動(dòng)態(tài)字段存儲(chǔ)。每個(gè)業(yè)務(wù)系統(tǒng)關(guān)注的指標(biāo)可能都不一樣，每個(gè)中間件的關(guān)注點(diǎn)也不同，所以埋哪些字段、每個(gè)字段的類型都無(wú)法預(yù)知，這就需要一個(gè)可以動(dòng)態(tài)添加字段的數(shù)據(jù)庫(kù)來(lái)存儲(chǔ)埋點(diǎn)。Elasticsearch 不需要預(yù)先定義字段和類型，埋點(diǎn)數(shù)據(jù)插入的時(shí)候可以自動(dòng)添加。

二是能夠經(jīng)得起海量數(shù)據(jù)的考驗(yàn)。每個(gè)用戶請(qǐng)求進(jìn)過(guò)每個(gè)監(jiān)控組件都會(huì)產(chǎn)生多條埋點(diǎn)，這個(gè)數(shù)據(jù)量是非常龐大的。Elasticsearch 可以支持大數(shù)據(jù)量的存儲(chǔ)，具有良好的水平擴(kuò)展性。

此外，Elasticsearch 還支持聚合計(jì)算，方便快速執(zhí)行 count , sum , avg 等任務(wù)。

有了埋點(diǎn)數(shù)據(jù)，下一步就需要定義一套報(bào)警規(guī)則，把我們關(guān)注的問(wèn)題量化為具體的數(shù)據(jù)來(lái)進(jìn)行檢查，驗(yàn)證是否超出了預(yù)設(shè)的閾值。這是整個(gè)報(bào)警中心最復(fù)雜的問(wèn)題，也最為核心。

之前的整體架構(gòu)圖中，最核心的部分就是「規(guī)則執(zhí)行引擎」，它通過(guò)執(zhí)行定時(shí)任務(wù)來(lái)驅(qū)動(dòng)系統(tǒng)的運(yùn)行。首先，執(zhí)行引擎會(huì)去查詢所有生效的規(guī)則，然后根據(jù)規(guī)則的描述到 Elasticsearch 中進(jìn)行過(guò)濾和聚合計(jì)算，最后將上一步聚合計(jì)算得結(jié)果跟規(guī)則中預(yù)先設(shè)定的閾值做比較，如果滿足條件則發(fā)送報(bào)警消息。

這個(gè)過(guò)程涉及到了幾個(gè)關(guān)鍵的技術(shù)點(diǎn)：

1). 定時(shí)任務(wù)

為了保證系統(tǒng)的可用性，避免由于單點(diǎn)故障導(dǎo)致整個(gè)監(jiān)控報(bào)警系統(tǒng)失效，我們以「分鐘」為周期，設(shè)置每一分鐘執(zhí)行一次報(bào)警規(guī)則。這里用的是 Elastic Job 來(lái)進(jìn)行分布式任務(wù)調(diào)度，方便操控任務(wù)的啟動(dòng)和停止。

2). 「三段式」報(bào)警規(guī)則

我們將報(bào)警規(guī)則的實(shí)現(xiàn)定義為「過(guò)濾、聚合、比較」這三個(gè)階段。舉例來(lái)說(shuō)，假設(shè)這是一個(gè)服務(wù) A 的 ERROR 埋點(diǎn)日志：

app_name=B???is_error=false??warn_msg=aa???datetime=2019-04-01?11:12:00
app_name=A???is_error=false????????????????datetime=2019-04-02?12:12:00
app_name=A???is_error=true???error_msg=bb??datetime=2019-04-02?15:12:00
app_name=A???is_error=true???error_msg=bb??datetime=2019-04-02?16:12:09

報(bào)警規(guī)則定義如下：

過(guò)濾：通過(guò)若干個(gè)條件限制來(lái)圈定一個(gè)數(shù)據(jù)集。對(duì)于上面的問(wèn)題，過(guò)濾條件可能是：app_name=A , is_error=true , datetime between "2019-14-02 16:12:00" and "2019-14-02 16:13:00".

聚合：通過(guò) count,avg,sum,max 等預(yù)先定義的聚合類型對(duì)上一步的數(shù)據(jù)集進(jìn)行計(jì)算，得到一個(gè)唯一的數(shù)值。對(duì)于上面的問(wèn)題，我們選擇 count 來(lái)計(jì)算出現(xiàn) ERROR 的次數(shù)。

比較：把上一步得到的結(jié)果與設(shè)定的閾值比較。

對(duì)于一些復(fù)雜條件的報(bào)警，比如我們上邊提到的失敗率和流量波動(dòng)，應(yīng)該如何實(shí)現(xiàn)呢？

假設(shè)有這樣一個(gè)問(wèn)題：如果調(diào)用的 A 服務(wù)失敗率超過(guò) 80%，并且總請(qǐng)求量大于 100，發(fā)送報(bào)警通知。

我們知道，失敗率其實(shí)就是失敗的數(shù)量除以總數(shù)量，而失敗的數(shù)量和總數(shù)量可以通過(guò)前面提到的「過(guò)濾+聚合」的方式得到，那么其實(shí)這個(gè)問(wèn)題就可以通過(guò)如下的公式描述出來(lái)：

failedCount/totalCount>0.8&&totalCount>100

然后我們使用表達(dá)式引擎 fast-el 對(duì)上面的表達(dá)式進(jìn)行計(jì)算，得到的結(jié)果與設(shè)定的閾值比較即可。

3) 自動(dòng)創(chuàng)建默認(rèn)報(bào)警規(guī)則

對(duì)于常用的 Dubbo, HTTP 等，由于涉及的類和方法比較多，開發(fā)人員可以通過(guò)后臺(tái)管理界面維護(hù)報(bào)警規(guī)則，報(bào)警規(guī)則會(huì)存儲(chǔ)到 MySQL 數(shù)據(jù)庫(kù)中，同時(shí)在 Redis 中緩存。

以 Dubbo 為例，首先通過(guò) Dubbo 的 ApplicationModel 獲取所有的 provider 和 consumer，將這些類和方法的信息與規(guī)則模板結(jié)合（規(guī)則模板可以理解為剔除掉具體類和方法信息的規(guī)則），創(chuàng)建出針對(duì)某個(gè)類下某個(gè)方法的規(guī)則。

比如：A 服務(wù)對(duì)外提供的 dubbo 接口/ order / getOrderById 每分鐘平均響應(yīng)時(shí)間超過(guò) 1 秒則報(bào)警；B 服務(wù)調(diào)用的 dubbo 接口/ train / grabTicket /每分鐘范圍 false 狀態(tài)個(gè)數(shù)超過(guò) 10 個(gè)則報(bào)警等等。

目前在報(bào)警規(guī)則觸發(fā)后主要采用兩種方式來(lái)發(fā)生報(bào)警行為：

郵件報(bào)警：通過(guò)對(duì)每一類報(bào)警制定不同的負(fù)責(zé)人，使相關(guān)人員第一時(shí)間獲悉系統(tǒng)異常。

微信報(bào)警：作為郵件報(bào)警的補(bǔ)充。

之后我們會(huì)持續(xù)完善報(bào)警行為的策略，比如針對(duì)不同等級(jí)的問(wèn)題采用不同的報(bào)警方式，使開發(fā)人員既可以迅速發(fā)現(xiàn)報(bào)警的問(wèn)題，又不過(guò)多牽扯在新功能研發(fā)上的精力。

為了能夠快速幫助開發(fā)人員定位具問(wèn)題，我們?cè)O(shè)計(jì)了命中抽樣的功能：

首先，我把命中規(guī)則的 tracer_id 提取出來(lái)，提供一個(gè)鏈接可以直接跳轉(zhuǎn)到 kibana 查看相關(guān)日志，實(shí)現(xiàn)鏈路的還原。

其次，開發(fā)人員也可以自己設(shè)置他要關(guān)注的字段，然后我會(huì)把這個(gè)字段對(duì)應(yīng)的值也抽取出來(lái)，問(wèn)題出在哪里就可以一目了然地看到。

技術(shù)實(shí)現(xiàn)上，定義一個(gè)命中抽樣的字段，這個(gè)字段里面允許用戶輸入一個(gè)或者多個(gè) dollar 大括號(hào)。比如我們可能關(guān)注某個(gè)供應(yīng)商的接口運(yùn)行情況，則命中抽樣的字段可能為下圖中上半部分。在需要發(fā)送報(bào)警消息的時(shí)候，提取出里面的字段，到 ES 中查詢對(duì)應(yīng)的值，用 freemarker 來(lái)完成替換，最終發(fā)送給開發(fā)人員的消息是如下所示，開發(fā)人員可以快速知道系統(tǒng)哪里出了問(wèn)題。

大交通業(yè)務(wù)監(jiān)控報(bào)警系統(tǒng)的搭建是一個(gè)從 0 到 1 的過(guò)程，在整過(guò)開發(fā)過(guò)程中，我們遇到了很多問(wèn)題，比如：內(nèi)存瞬間被打滿、ES 越來(lái)越慢、頻繁 Full GC ，下面具體講一下針對(duì)以上幾點(diǎn)我們的優(yōu)化經(jīng)驗(yàn)。

1. 內(nèi)存瞬間被打滿

任何一個(gè)系統(tǒng)，都有它能承受的極限，所以都需要這么一座大壩，在洪水來(lái)的時(shí)候能夠攔截下來(lái)。

報(bào)警中心也一樣，報(bào)警中心對(duì)外面臨最大的瓶頸點(diǎn)在接收 Kafka 中傳過(guò)來(lái)的 MES 埋點(diǎn)日志。上線初期出現(xiàn)過(guò)一次由于業(yè)務(wù)系統(tǒng)異常導(dǎo)致瞬間大量埋點(diǎn)日志打到報(bào)警中心，導(dǎo)致系統(tǒng)內(nèi)存打滿的問(wèn)題。

解決辦法是評(píng)估每個(gè)節(jié)點(diǎn)的最大承受能力，做好系統(tǒng)保護(hù)。針對(duì)這個(gè)問(wèn)題，我們采取的是限流的方式，由于 Kafka 消費(fèi)消息使用的是拉取的模式，所以只需要控制好拉取的速率即可，比如使用 Guava 的 RateLimiter ：

messageHandler?=?(message)?->?{
??RateLimiter?messageRateLimiter?=?RateLimiter.create(20000);
??final?double?acquireTime?=?messageRateLimiter.acquire();
??/**
???save..
??*/
}

2. ES 越來(lái)越慢

由于 MES 日志量比較大，也有冷熱之分，為了在保證性能的同時(shí)方便數(shù)據(jù)遷移，我們按照應(yīng)用 + 月份的粒度創(chuàng)建 ES 索引，如下所示：

3. 頻繁 Full GC

我們使用 Logback 作為日志框架，為了能夠搜集到 ERROR 和 WARN 日志，自定義了一個(gè) Appender。如果想搜集 Spring 容器啟動(dòng)之前（此時(shí)? TalarmLogbackAppender 還未初始化）的日志, Logback 的一個(gè)擴(kuò)展 jar 包中的 DelegatingLogbackAppender 提供了一種緩存的方式，內(nèi)存泄漏就出在這個(gè)緩存的地方。

正常情況系統(tǒng)啟動(dòng)起來(lái)之后，ApplicationContextHolder 中的 Spring 上下文不為空，會(huì)自動(dòng)從緩存里面把日志取出來(lái)。但是如果因?yàn)榉N種原因沒(méi)有初始化這個(gè)類 ApplicationContextHolder，日志會(huì)在緩存中越積越多，最終導(dǎo)致頻繁的 Full GC。

解決辦法：

1. 保證 ApplicationContextHolder 的初始化

2. DelegatingLogbackAppender 有三種模式：OFF SOFT ON ，如果需要打開，盡量使用 SOFT模式，這時(shí)候緩存被存儲(chǔ)在一個(gè)由 SoftReference 包裝的列表中，在系統(tǒng)內(nèi)存不足的時(shí)候，可以被垃圾回收器回收掉。

目前這個(gè)系統(tǒng)還有一些不完善的地方，也是未來(lái)的一些規(guī)劃：

更易用：提供更多的使用幫助提示，幫助開發(fā)人員快速熟悉系統(tǒng)。

更多報(bào)警維度：目前支持 HTTP，SQL， Dubbo 組件的自動(dòng)報(bào)警，后續(xù)會(huì)陸續(xù)支持 MQ，Redis 定時(shí)任務(wù)等等。

圖形化展示：將埋點(diǎn)數(shù)據(jù)通過(guò)圖形的方式展示出來(lái)，可以更直觀地展示出系統(tǒng)的運(yùn)行情況，同時(shí)也有助于開發(fā)人員對(duì)于系統(tǒng)閾值的設(shè)置。

總結(jié)起來(lái)，大交通業(yè)務(wù)監(jiān)控報(bào)警系統(tǒng)架構(gòu)有以下幾個(gè)特點(diǎn)：

?支持靈活的報(bào)警規(guī)則配置，豐富的篩選邏輯

自動(dòng)添加常用組件的報(bào)警，Dubbo、HTTP 自動(dòng)接入報(bào)警

接入簡(jiǎn)單，接入 MES 的系統(tǒng)都可以快速接入使用

線上生產(chǎn)運(yùn)維主要做 3 件事：發(fā)現(xiàn)問(wèn)題、定位問(wèn)題、解決問(wèn)題。發(fā)現(xiàn)問(wèn)題，就是在系統(tǒng)出現(xiàn)異常的時(shí)候盡快通知系統(tǒng)負(fù)責(zé)人。定位問(wèn)題和解決問(wèn)題，就是能夠?yàn)殚_發(fā)人員提供快速修復(fù)系統(tǒng)的必要信息，越精確越好。

報(bào)警系統(tǒng)的定位應(yīng)該是線上問(wèn)題解決鏈條中的第一步和入口手段。將其通過(guò)核心線索數(shù)據(jù)與數(shù)據(jù)回溯系統(tǒng)( tracer 鏈路等)，部署發(fā)布系統(tǒng)等進(jìn)行有機(jī)的串聯(lián)，可以極大提升線上問(wèn)題解決的效率，更好地為生產(chǎn)保駕護(hù)航。

不管做什么，我們最終的目標(biāo)只有一個(gè)，就是提高服務(wù)的質(zhì)量。

本文作者：宋考俊，馬蜂窩大交通平臺(tái)高級(jí)研發(fā)工程師。

（題圖來(lái)源：網(wǎng)絡(luò)）

關(guān)注馬蜂窩技術(shù)，找到更多你想要的內(nèi)容