在這其中，關(guān)于數(shù)據(jù)庫(kù)監(jiān)控系統(tǒng)建設(shè)比較典型。

在業(yè)務(wù)平時(shí)運(yùn)行態(tài)，線上系統(tǒng)出現(xiàn)故障，在數(shù)萬(wàn)數(shù)據(jù)庫(kù)中，如何發(fā)現(xiàn)異常、快速診斷亦是一件非常具有挑戰(zhàn)的事情。在雙十一全鏈路壓測(cè)中，系統(tǒng)吞吐量未達(dá)預(yù)期或業(yè)務(wù)出現(xiàn)了 RT 抖動(dòng)，快速診斷定位數(shù)據(jù)庫(kù)問(wèn)題是一個(gè)現(xiàn)實(shí)課題。此外，對(duì)于復(fù)雜數(shù)據(jù)庫(kù)故障事后排查故障根源、現(xiàn)場(chǎng)還原、歷史事件追蹤也迫使我們建設(shè)一個(gè)覆蓋線上所有環(huán)境、數(shù)據(jù)庫(kù)實(shí)例、事件的監(jiān)控系統(tǒng)，

做到：

1）覆蓋阿里全球子公司所有機(jī)房。

2）覆蓋阿里生態(tài)包含新零售、新金融、新制造、新技術(shù)、新能源所有業(yè)務(wù)。

3）覆蓋所有數(shù)據(jù)庫(kù)主機(jī)、操作系統(tǒng)、容器、數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)。

4）所有性能指標(biāo)做到 1 秒級(jí)連續(xù)不間斷監(jiān)控。

5）全天候持續(xù)穩(wěn)定運(yùn)行。

DBPaaS 監(jiān)控雙 11 運(yùn)行概況

2017 年雙 11，DBPaaS 平臺(tái)秒級(jí)監(jiān)控系統(tǒng)每秒平均處理 1000 萬(wàn)項(xiàng)性能指標(biāo)，峰值處理 1400 萬(wàn)項(xiàng)性能指標(biāo)，為線上分布在中國(guó)、美國(guó)、歐洲、東南亞的、所有數(shù)據(jù)庫(kù)實(shí)例健康運(yùn)行保駕護(hù)航。做到了實(shí)時(shí)秒級(jí)監(jiān)控，也就是說(shuō)，任何時(shí)候，DBA 同學(xué)可以看到任何數(shù)據(jù)庫(kù)實(shí)例一秒以前的所有性能趨勢(shì)。

DBPaaS 監(jiān)控系統(tǒng)僅使用 0.5% 的數(shù)據(jù)庫(kù)資源池的機(jī)器，支撐整個(gè)采集鏈路、計(jì)算鏈路、存儲(chǔ)、展現(xiàn)診斷系統(tǒng)。監(jiān)控系統(tǒng)完美記錄今年每一次全鏈路壓測(cè)每個(gè) RT 抖動(dòng)現(xiàn)場(chǎng)，助力 DBA 快速診斷數(shù)據(jù)庫(kù)問(wèn)題，并為后續(xù)系統(tǒng)優(yōu)化提供建議。

在雙 11 大促保障期間，我們做到機(jī)器不擴(kuò)容、服務(wù)不降級(jí)，讓 DBA 同學(xué)們喝茶度過(guò)雙 11。在日常業(yè)務(wù)運(yùn)行保障, 我們也具備 7*24 服務(wù)能力。

我們是如何做到的

實(shí)現(xiàn)一個(gè)支持?jǐn)?shù)萬(wàn)數(shù)據(jù)庫(kù)實(shí)例的實(shí)時(shí)秒級(jí)監(jiān)控系統(tǒng)，要解決許多技術(shù)挑戰(zhàn)。都說(shuō)優(yōu)秀的架構(gòu)是演進(jìn)過(guò)來(lái)，監(jiān)控系統(tǒng)的建設(shè)也隨著規(guī)模和復(fù)雜性增加不斷迭代，到 2017 年，監(jiān)控系統(tǒng)經(jīng)歷了四個(gè)階段改進(jìn)。

第一代監(jiān)控系統(tǒng)

第一代監(jiān)控系統(tǒng)架構(gòu)非常簡(jiǎn)單，采集 Agent 直接把性能數(shù)據(jù)寫(xiě)入數(shù)據(jù)庫(kù)，監(jiān)控系統(tǒng)直接查詢(xún)數(shù)據(jù)庫(kù)即可。

隨著數(shù)據(jù)庫(kù)集群規(guī)模擴(kuò)大，簡(jiǎn)易架構(gòu)的缺點(diǎn)也非常明顯。

首先，單機(jī)數(shù)據(jù)庫(kù)容量擴(kuò)展性不足，隨著監(jiān)控的數(shù)據(jù)庫(kù)規(guī)模擴(kuò)大，日常性能指標(biāo)寫(xiě)入量非常大，數(shù)據(jù)庫(kù)容量捉襟見(jiàn)肘，長(zhǎng)時(shí)間積累的監(jiān)控歷史數(shù)據(jù)經(jīng)常觸發(fā)磁盤(pán)空間預(yù)警，我們經(jīng)常被迫刪除遠(yuǎn)期數(shù)據(jù)。

其次，監(jiān)控指標(biāo)的擴(kuò)展性不足。一開(kāi)始數(shù)據(jù)庫(kù)監(jiān)控項(xiàng)只有十幾項(xiàng)，但是很快就發(fā)現(xiàn)不夠用。因?yàn)榻?jīng)常有人拿著 MySQL 的文檔說(shuō)，我想看這個(gè)，我想看那個(gè)，能不能放到監(jiān)控系統(tǒng)里。性能指標(biāo)展現(xiàn)的前提是存儲(chǔ)，在存儲(chǔ)層的擴(kuò)展性缺陷讓我們頭痛不已。對(duì)于這種功能需求，無(wú)論是寬表還是窄表，都存在明顯的缺陷。如果用寬表，每新增一批性能指標(biāo)，就要執(zhí)行一次 DDL，雖然預(yù)定義擴(kuò)展字段可以緩解，但終究約束了產(chǎn)品想象空間。窄表在結(jié)構(gòu)上解決了任意個(gè)性能指標(biāo)的存儲(chǔ)問(wèn)題，但是它也帶來(lái)了寫(xiě)入數(shù)據(jù)量放大和存儲(chǔ)空間膨脹的弊病。最后，系統(tǒng)整體讀寫(xiě)能力也不高，而且不具備水平擴(kuò)展性。

以上所有原因催生了第二代監(jiān)控系統(tǒng)的誕生。

第二代監(jiān)控系統(tǒng)

第二代監(jiān)控系統(tǒng)引入了 DataHub 模塊和分布式文檔數(shù)據(jù)庫(kù)。數(shù)據(jù)鏈路變成由采集 Agent 到 DataHub 到分布式文檔數(shù)據(jù)庫(kù)，監(jiān)控系統(tǒng)從分布式文檔。

采集 Agent 專(zhuān)注于性能數(shù)據(jù)采集邏輯，構(gòu)造統(tǒng)一數(shù)據(jù)格式，調(diào)用 DataHub 接口把數(shù)據(jù)傳輸?shù)?DataHub，采集 Agent 不需要關(guān)心性能數(shù)據(jù)存在哪里。DataHub 作為承上啟下的節(jié)點(diǎn)，實(shí)現(xiàn)了采集與存儲(chǔ)的解耦。第一，它對(duì)采集 Agent 屏蔽了數(shù)據(jù)存儲(chǔ)細(xì)節(jié)，僅暴露最簡(jiǎn)單數(shù)據(jù)投遞接口；第二，DataHub 收到根據(jù)存儲(chǔ)引擎特性使用最優(yōu)寫(xiě)入模型，比如使用批量寫(xiě)入、壓縮等方式；第三，使用 LVS、LSB 技術(shù)可以實(shí)現(xiàn) DataHub 水平擴(kuò)展。分布式文檔數(shù)據(jù)庫(kù)部分了解決擴(kuò)展性問(wèn)題，水平擴(kuò)容用于解決存儲(chǔ)容量不足的問(wèn)題，schema free 的特性可以性能指標(biāo)擴(kuò)展性問(wèn)題。

隨著監(jiān)控系統(tǒng)持續(xù)運(yùn)行，數(shù)據(jù)庫(kù)實(shí)例規(guī)模擴(kuò)大，性能指標(biāo)持續(xù)增加，監(jiān)控系統(tǒng)用戶擴(kuò)大，又遇到新的問(wèn)題。第一，DBA 同學(xué)常常需要查看數(shù)據(jù)庫(kù)跨越數(shù)月的性能趨勢(shì)，以預(yù)估數(shù)據(jù)庫(kù)流量未來(lái)趨勢(shì)，這時(shí)系統(tǒng)查詢(xún)速度基本不可用。第二，存儲(chǔ)長(zhǎng)達(dá)一年的全量性能數(shù)據(jù)，成本變得越來(lái)越不可承受，每年雙 11 壓測(cè)時(shí)，DBA 同學(xué)總會(huì)問(wèn)起去年雙 11 的性能趨勢(shì)。第三，DataHub 存在丟失采集數(shù)據(jù)的隱患，由于采集原始數(shù)據(jù)是先 buffer 在 DataHub 內(nèi)存中，只要進(jìn)程重啟，內(nèi)存中的采集數(shù)據(jù)就會(huì)丟失。

第三代監(jiān)控系統(tǒng)

關(guān)于查詢(xún)速度慢的問(wèn)題，文檔型數(shù)據(jù)庫(kù)和關(guān)系型數(shù)據(jù)庫(kù)一樣，都是面向行的數(shù)據(jù)庫(kù)，即讀寫(xiě)的基本數(shù)據(jù)，每一秒的性能數(shù)據(jù)存儲(chǔ)一行，一行 N 個(gè)性能指標(biāo)，性能指標(biāo)被存儲(chǔ)在以時(shí)間為 key 的一個(gè)表格中。雖然同一時(shí)刻的所有性能指標(biāo)被存在同一行，但是它們的關(guān)系卻沒(méi)那么緊密。因?yàn)榈湫偷谋O(jiān)控診斷需求是查同一個(gè)或幾個(gè)指標(biāo)在一段時(shí)間的變化趨勢(shì)，而不是查同一時(shí)刻的指標(biāo)（瞬時(shí)值），比如這樣的：

數(shù)據(jù)庫(kù)存儲(chǔ)引擎為了查出某個(gè)指標(biāo)的性能趨勢(shì)，卻要掃描所有指標(biāo)的數(shù)據(jù)，CPU 和內(nèi)存都開(kāi)銷(xiāo)巨大，顯而易見(jiàn)，這些都是在浪費(fèi)。雖然 Column Family 技術(shù)可以在一定程度上緩解上面說(shuō)的問(wèn)題，但是如何設(shè)定 Column Family 是個(gè)巨大挑戰(zhàn)，難道要存儲(chǔ)層的策略要和監(jiān)控診斷層的需求耦合嗎？這看起來(lái)不是好辦法。

所以，我們把目光投向列式數(shù)據(jù)庫(kù)，監(jiān)控性能指標(biāo)讀寫(xiě)特征非常合適列式數(shù)據(jù)庫(kù)，以 OpenTSDB 為代表的時(shí)序數(shù)據(jù)庫(kù)，進(jìn)入我們考察視野。OpenTSDB 用時(shí)間線來(lái)描述每一個(gè)帶有時(shí)間序列的特定對(duì)象，時(shí)間線的讀寫(xiě)都是獨(dú)立的。毫無(wú)疑問(wèn)，OpenTSDB 成為第三代監(jiān)控系統(tǒng)架構(gòu)的一部分。

為了消除 DataHub 穩(wěn)定性隱患，引入分布式消息隊(duì)列，起到削峰填谷作用，即使 DataHub 全線崩潰，也可以采用重新消費(fèi)消息的方式解決。分布式消息隊(duì)列，可以選擇 Kafka 或 RocketMQ，這些分布式消息隊(duì)列已經(jīng)具備了高可用能力。

第三代架構(gòu)相比過(guò)去有巨大的進(jìn)步，在 2016 年雙 11 實(shí)現(xiàn)了全網(wǎng)數(shù)據(jù)庫(kù) 10 秒級(jí)監(jiān)控，核心數(shù)據(jù)庫(kù)集群 1 秒級(jí)監(jiān)控。

隨著阿里生態(tài)擴(kuò)大，全球化深入，各類(lèi)全資子公司業(yè)務(wù)全面融合到阿里體系，除了中國(guó)大陸，還有美國(guó)、歐洲、俄羅斯、東南亞的業(yè)務(wù)。同時(shí)在阿里數(shù)據(jù)庫(kù)領(lǐng)域的新技術(shù)應(yīng)用層出不窮，單元化部署已經(jīng)成為常態(tài)，容器化調(diào)度正在覆蓋全網(wǎng)，存儲(chǔ)計(jì)算分離正在不斷推進(jìn)，同一個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)集群，在不同單元的部署策略可能也不同。與之對(duì)應(yīng)的，DBA 團(tuán)隊(duì)的規(guī)模并沒(méi)有相應(yīng)擴(kuò)大，一個(gè) DBA 同學(xué)支持多個(gè)子公司業(yè)務(wù)是常態(tài)，有的 DBA 還要兼任新技術(shù)推廣等工作。在數(shù)據(jù)庫(kù)性能診斷這個(gè)環(huán)節(jié)，必須為 DBA 爭(zhēng)效率，為 DBA 提供從宏觀到微觀到診斷路徑顯得越來(lái)越迫切：從大盤(pán)到集群、到單元、到實(shí)例、到主機(jī)、容器等一站式服務(wù)。

在這樣的診斷需求下，第三代監(jiān)控架構(gòu)有點(diǎn)力不從心了，主要表現(xiàn)在查詢(xún)：

1）高維度的性能診斷查詢(xún)速度慢，以集群 QPS 為例，由于 OpenTSDB 里存儲(chǔ)的每一個(gè)實(shí)例的 QPS 數(shù)據(jù)，當(dāng)需要查詢(xún)集群維度 QPS 就需要對(duì)掃描集群每一個(gè)實(shí)例的 QPS，再 group by 時(shí)間戳 sum 所有實(shí)例 QPS。這需要掃描大量原始數(shù)據(jù)。

2）OpenTSDB 無(wú)法支持復(fù)雜的監(jiān)控需求，比如查看集群平均 RT 趨勢(shì)，集群平均 RT 并不是 avg(所有實(shí)例的 RT)，而是 sum(執(zhí)行時(shí)間)/sum(執(zhí)行次數(shù))。為了實(shí)現(xiàn)目標(biāo)只能查出 2 條時(shí)間線數(shù)據(jù)，在監(jiān)控系統(tǒng)內(nèi)部計(jì)算完后再展現(xiàn)在頁(yè)面中，用戶響應(yīng)時(shí)間太長(zhǎng)。

3）長(zhǎng)時(shí)間跨度的性能診斷速度慢，比如 1 個(gè)月的性能趨勢(shì)，需要掃描原始的秒級(jí) 2592000 個(gè)數(shù)據(jù)點(diǎn)到瀏覽器中展現(xiàn)，考慮到瀏覽器展現(xiàn)性能，實(shí)際并不能也沒(méi)必要展現(xiàn)原始秒級(jí)數(shù)據(jù)。展示 15 分鐘時(shí)間精度的數(shù)據(jù)就夠了。

上述提到的預(yù)計(jì)算問(wèn)題，OpenTSDB 也意識(shí)到，其 2.4 版本開(kāi)始，具備了簡(jiǎn)陋預(yù)計(jì)算能力，無(wú)論從功能靈活性還是系統(tǒng)穩(wěn)定性、性能，OpenTSDB 都無(wú)法滿足 DBPaaS 秒級(jí)監(jiān)控需求。

DBPaaS 新一代架構(gòu)

新一代架構(gòu)，我們把 OpenTSDB 升級(jí)為更強(qiáng)勁的 HiTSDB，同時(shí)基于流式計(jì)算開(kāi)發(fā)的實(shí)時(shí)預(yù)聚合引擎代替簡(jiǎn)單的 DataHub，讓秒級(jí)監(jiān)控飛。

在職責(zé)界定上，監(jiān)控診斷需求的復(fù)雜性留給實(shí)時(shí)預(yù)聚合引擎來(lái)解決，對(duì)時(shí)序數(shù)據(jù)庫(kù)的查詢(xún)需求都限定在一條時(shí)間線內(nèi)。這要求時(shí)序數(shù)據(jù)庫(kù)必須把單一時(shí)間線性能做到極致，由兄弟團(tuán)隊(duì)開(kāi)發(fā)的阿里巴巴高性能序數(shù)據(jù)庫(kù) HiTSDB 做到了極致壓縮和極致讀寫(xiě)能力，利用時(shí)序數(shù)據(jù)等距時(shí)間戳和數(shù)值小幅變化的特征，它做了大量壓縮。同時(shí)它全面兼容 OpenTSDB 協(xié)議，已經(jīng)在阿里云公測(cè)。

新架構(gòu)讓我們放開(kāi)雙手專(zhuān)注思考監(jiān)控與診斷需求，不再受存儲(chǔ)層的束縛。第一，為了高維度性能趨勢(shì)查詢(xún)性能，預(yù)聚合引擎做到了預(yù)先按業(yè)務(wù)數(shù)據(jù)庫(kù)集群、單元、實(shí)例把性能指標(biāo)計(jì)算好，寫(xiě)入 HiTSDB。第二，建立性能指標(biāo)聚合計(jì)算函數(shù)庫(kù)，所有性能指標(biāo)的聚合計(jì)算公式都是可以配置的，實(shí)現(xiàn)了自由的設(shè)定監(jiān)控指標(biāo)。第三，事先降時(shí)間精度，分為 6 個(gè)精度：1 秒、5 秒、15 秒、1 分鐘、5 分鐘、15 分鐘。不同時(shí)間精度的性能數(shù)據(jù)，才有不同的壓縮策略。

實(shí)時(shí)計(jì)算引擎

實(shí)時(shí)計(jì)算引擎實(shí)現(xiàn)了實(shí)例、單元、集群三個(gè)維度逐級(jí)聚合，每一級(jí)聚合 Bolt 各自寫(xiě)入 HiTSDB。流式計(jì)算平臺(tái)的選擇是自由，目前我們的程序運(yùn)行在 JStorm 計(jì)算平臺(tái)上，JStorm 讓我們具備天生的高可用能力。

實(shí)時(shí)計(jì)算引擎性能

實(shí)時(shí)計(jì)算引擎使用了數(shù)據(jù)庫(kù)總機(jī)器規(guī)模 0.1% 的資源, 實(shí)現(xiàn)了全網(wǎng)秒級(jí)監(jiān)控?cái)?shù)據(jù)的計(jì)算，平均每秒處理超過(guò) 1000 萬(wàn)項(xiàng)性能指標(biāo)，平均寫(xiě)入 TPS 600 萬(wàn)，峰值 TPS 1400 萬(wàn)，下圖是雙 11 期間 HiTSDB TPS 趨勢(shì)曲線。

關(guān)鍵優(yōu)化點(diǎn)

用這么少的計(jì)算資源就實(shí)現(xiàn)了這么高吞吐量，必然用上了許多黑科技。

1）在預(yù)計(jì)算中，我們使用增量迭代計(jì)算，無(wú)論是 5 秒精度的數(shù)據(jù)，還是 15 分鐘精度數(shù)據(jù)，我們不需要等時(shí)間窗口內(nèi)所有的性能指標(biāo)收集滿了，再開(kāi)始計(jì)算，而是來(lái)多少性能數(shù)據(jù)，就算多少，僅保留中間結(jié)果，極大的節(jié)省內(nèi)存。這項(xiàng)優(yōu)化，相比常規(guī)計(jì)算方法至少節(jié)省 95% 內(nèi)存。

2）采集端，針對(duì)性能數(shù)據(jù)報(bào)文進(jìn)行合并，把相似和相鄰的報(bào)文合并在一起上報(bào)到 kafka，這樣可以讓 JStorm 程序批量處理數(shù)據(jù)。

3）利用流式計(jì)算的特性實(shí)現(xiàn)數(shù)據(jù)局部性，同一個(gè)集群?jiǎn)卧膶?shí)例采集到的數(shù)據(jù)在同一個(gè) kafka 分區(qū)。這樣可以減少計(jì)算過(guò)程的網(wǎng)絡(luò)傳輸及 java 序列化 / 反序列化。這一項(xiàng)可以減少 50% 的網(wǎng)絡(luò)傳輸。有興趣的朋友可以想想為什么不能按實(shí)例分區(qū)或按集群分區(qū)，會(huì)有什么問(wèn)題呢？

4）使用 JStorm 自定義調(diào)度特性，讓具有數(shù)據(jù)相關(guān)性的計(jì)算 Bolt 調(diào)度在同一個(gè) JVM 中，這個(gè)是為了配合上面第二步，實(shí)現(xiàn)數(shù)據(jù)流轉(zhuǎn)盡量發(fā)生在同一個(gè) JVM 里。

5）對(duì)于不得不發(fā)生的 Map-Reduce 數(shù)據(jù)傳輸，盡量使用批量傳輸，并對(duì)傳輸?shù)臄?shù)據(jù)結(jié)構(gòu)進(jìn)行復(fù)用、裁剪，少傳輸重復(fù)數(shù)據(jù)，減少序列化、反序列化壓力。

未來(lái)展望

阿里 DBPaaS 全網(wǎng)秒級(jí)監(jiān)控讓數(shù)據(jù)庫(kù)管控實(shí)現(xiàn)了數(shù)字化，經(jīng)過(guò)這一年，我們積累了許多有價(jià)值的結(jié)構(gòu)化數(shù)據(jù)。隨著大數(shù)據(jù)技術(shù)、機(jī)器學(xué)習(xí)技術(shù)的發(fā)展，為數(shù)據(jù)庫(kù)管控進(jìn)入智能化提供了可能性。

1）智能診斷，基于現(xiàn)有全方位無(wú)死角的監(jiān)控，結(jié)合事件追蹤，智能定位問(wèn)題。

2）調(diào)度優(yōu)化，通過(guò)分析每個(gè)數(shù)據(jù)庫(kù)實(shí)例的畫(huà)像特征，讓資源互補(bǔ)性的幾個(gè)數(shù)據(jù)庫(kù)實(shí)例調(diào)度在一起，最終節(jié)省成本。

3）預(yù)算估計(jì)，通過(guò)分析數(shù)據(jù)庫(kù)歷史運(yùn)行狀況, 在每次大促前，根據(jù)業(yè)務(wù)交易量目標(biāo)，確定每一個(gè)數(shù)據(jù)庫(kù)集群容量需求，進(jìn)而為自動(dòng)化擴(kuò)容提供依據(jù)。