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

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

做到：

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

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

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

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

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

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

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

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

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

我們是如何做到的

實(shí)現(xiàn)一個(gè)支持?jǐn)?shù)萬數(shù)據(jù)庫實(shí)例的實(shí)時(shí)秒級監(jiān)控系統(tǒng)，要解決許多技術(shù)挑戰(zhàn)。都說優(yōu)秀的架構(gòu)是演進(jìn)過來，監(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)非常簡單，采集 Agent 直接把性能數(shù)據(jù)寫入數(shù)據(jù)庫，監(jiān)控系統(tǒng)直接查詢數(shù)據(jù)庫即可。

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

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

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

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

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

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

采集 Agent 專注于性能數(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)了采集與存儲的解耦。第一，它對采集 Agent 屏蔽了數(shù)據(jù)存儲細(xì)節(jié)，僅暴露最簡單數(shù)據(jù)投遞接口；第二，DataHub 收到根據(jù)存儲引擎特性使用最優(yōu)寫入模型，比如使用批量寫入、壓縮等方式；第三，使用 LVS、LSB 技術(shù)可以實(shí)現(xiàn) DataHub 水平擴(kuò)展。分布式文檔數(shù)據(jù)庫部分了解決擴(kuò)展性問題，水平擴(kuò)容用于解決存儲容量不足的問題，schema free 的特性可以性能指標(biāo)擴(kuò)展性問題。

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

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

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

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

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

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

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

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

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

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

2）OpenTSDB 無法支持復(fù)雜的監(jiān)控需求，比如查看集群平均 RT 趨勢，集群平均 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īng)時(shí)間太長。

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

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

DBPaaS 新一代架構(gòu)

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

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

新架構(gòu)讓我們放開雙手專注思考監(jiān)控與診斷需求，不再受存儲層的束縛。第一，為了高維度性能趨勢查詢性能，預(yù)聚合引擎做到了預(yù)先按業(yè)務(wù)數(shù)據(jù)庫集群、單元、實(shí)例把性能指標(biāo)計(jì)算好，寫入 HiTSDB。第二，建立性能指標(biāo)聚合計(jì)算函數(shù)庫，所有性能指標(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è)維度逐級聚合，每一級聚合 Bolt 各自寫入 HiTSDB。流式計(jì)算平臺的選擇是自由，目前我們的程序運(yùn)行在 JStorm 計(jì)算平臺上，JStorm 讓我們具備天生的高可用能力。

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

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

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

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

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

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

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

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

未來展望

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

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

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

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