摘要：每秒實時處理超過萬項監(jiān)控指標，讓異常無所遁形。此外，對于復(fù)雜數(shù)據(jù)庫故障事后排查故障根源現(xiàn)場還原歷史事件追蹤也迫使我們建設(shè)一個覆蓋線上所有環(huán)境數(shù)據(jù)庫實例事件的監(jiān)控系統(tǒng)，做到覆蓋阿里全球子公司所有機房。所有性能指標做到秒級連續(xù)不間斷監(jiān)控。

摘要： 2017雙11再次創(chuàng)下了32.5萬筆/秒交易創(chuàng)建的紀錄，在這個數(shù)字后面，更是每秒多達幾千萬次的數(shù)據(jù)庫寫入，如何大規(guī)模進行自動化操作、保證數(shù)據(jù)庫的穩(wěn)定性、快速發(fā)現(xiàn)問題是一個巨大的難題， 這也是數(shù)據(jù)庫管控平臺要完成的任務(wù)。

作者：吳必良（未立）

前言
2017雙11再次創(chuàng)下了32.5萬筆/秒交易創(chuàng)建的紀錄，在這個數(shù)字后面，更是每秒多達幾千萬次的數(shù)據(jù)庫寫入，如何大規(guī)模進行自動化操作、保證數(shù)據(jù)庫的穩(wěn)定性、快速發(fā)現(xiàn)問題是一個巨大的難題， 這也是數(shù)據(jù)庫管控平臺要完成的任務(wù)。

隨著阿里巴巴數(shù)據(jù)庫規(guī)模的不斷擴大，我們建設(shè)數(shù)據(jù)庫管控平臺也經(jīng)歷了很多階段，從腳本化、工具化、平臺化到目前的DBPaaS，DBPaaS在今年雙11中， 首次全面覆蓋集團、各子公司下的本地數(shù)據(jù)庫、公有云、混合云等多種場景。今年雙11，數(shù)據(jù)庫已經(jīng)全面實現(xiàn)容器化部署，彈性使用離線資源、公有云資源支持大促。全面優(yōu)化的監(jiān)控采集鏈路，實現(xiàn)了全網(wǎng)所有數(shù)據(jù)庫實例的秒級采集、監(jiān)控、展現(xiàn)、診斷。每秒實時處理超過1000萬項監(jiān)控指標，讓異常無所遁形。DBPaaS也持續(xù)在數(shù)據(jù)庫管理的自動化、規(guī)模化、數(shù)字化、智能化等方向進行突破。

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

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

覆蓋阿里全球子公司所有機房。
覆蓋阿里生態(tài)包含新零售、新金融、新制造、新技術(shù)、新能源所有業(yè)務(wù)。
覆蓋所有數(shù)據(jù)庫主機、操作系統(tǒng)、容器、數(shù)據(jù)庫、網(wǎng)絡(luò)。
所有性能指標做到1秒級連續(xù)不間斷監(jiān)控。
全天候持續(xù)穩(wěn)定運行。
DBPaaS監(jiān)控雙11運行概況
2017年雙11，DBPaaS平臺秒級監(jiān)控系統(tǒng)每秒平均處理1000萬項性能指標，峰值處理1400萬項性能指標，為線上分布在中國、美國、歐洲、東南亞的、所有數(shù)據(jù)庫實例健康運行保駕護航。做到了實時秒級監(jiān)控，也就是說，任何時候，DBA同學可以看到任何數(shù)據(jù)庫實例一秒以前的所有性能趨勢。

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

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

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

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

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

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

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

最后，系統(tǒng)整體讀寫能力也不高，而且不具備水平擴展性。

以上所有原因催生了第二代監(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ù)紻ataHub，采集Agent不需要關(guān)心性能數(shù)據(jù)存在哪里。DataHub作為承上啟下的節(jié)點，實現(xiàn)了采集與存儲的解耦。第一，它對采集Agent屏蔽了數(shù)據(jù)存儲細節(jié)，僅暴露最簡單數(shù)據(jù)投遞接口；第二，DataHub收到根據(jù)存儲引擎特性使用最優(yōu)寫入模型，比如使用批量寫入、壓縮等方式；第三，使用LVS、LSB技術(shù)可以實現(xiàn)DataHub水平擴展。分布式文檔數(shù)據(jù)庫部分了解決擴展性問題，水平擴容用于解決存儲容量不足的問題，schema free的特性可以性能指標擴展性問題。

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

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

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

所以，我們把目光投向列式數(shù)據(jù)庫，監(jiān)控性能指標讀寫特征非常合適列式數(shù)據(jù)庫，以O(shè)penTSDB為代表的時序數(shù)據(jù)庫，進入我們考察視野。OpenTSDB用時間線來描述每一個帶有時間序列的特定對象，時間線的讀寫都是獨立的。

毫無疑問，OpenTSDB成為第三代監(jiān)控系統(tǒng)架構(gòu)的一部分。

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

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

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

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

高維度的性能診斷查詢速度慢，以集群QPS為例，由于OpenTSDB里存儲的每一個實例的QPS數(shù)據(jù)，當需要查詢集群維度QPS就需要對掃描集群每一個實例的QPS，再group by 時間戳 sum所有實例QPS。這需要掃描大量原始數(shù)據(jù)。
OpenTSDB無法支持復(fù)雜的監(jiān)控需求，比如查看集群平均RT趨勢，集群平均RT并不是avg(所有實例的RT)，而是sum(執(zhí)行時間)/sum(執(zhí)行次數(shù))。為了實現(xiàn)目標只能查出2條時間線數(shù)據(jù)，在監(jiān)控系統(tǒng)內(nèi)部計算完后再展現(xiàn)在頁面中，用戶響應(yīng)時間太長。
長時間跨度的性能診斷速度慢，比如1個月的性能趨勢，需要掃描原始的秒級2592000個數(shù)據(jù)點到瀏覽器中展現(xiàn)，考慮到瀏覽器展現(xiàn)性能，實際并不能也沒必要展現(xiàn)原始秒級數(shù)據(jù)。展示15分鐘時間精度的數(shù)據(jù)就夠了。
上述提到的預(yù)計算問題，OpenTSDB也意識到，其2.4版本開始，具備了簡陋預(yù)計算能力，無論從功能靈活性還是系統(tǒng)穩(wěn)定性、性能，OpenTSDB都無法滿足DBPaaS秒級監(jiān)控需求。

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

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

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

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

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

關(guān)鍵優(yōu)化點
用這么少的計算資源就實現(xiàn)了這么高吞吐量，必然用上了許多黑科技。

在預(yù)計算中，我們使用增量迭代計算，無論是5秒精度的數(shù)據(jù)，還是15分鐘精度數(shù)據(jù)，我們不需要等時間窗口內(nèi)所有的性能指標收集滿了，再開始計算，而是來多少性能數(shù)據(jù)，就算多少，僅保留中間結(jié)果，極大的節(jié)省內(nèi)存。這項優(yōu)化，相比常規(guī)計算方法至少節(jié)省95%內(nèi)存。
采集端，針對性能數(shù)據(jù)報文進行合并，把相似和相鄰的報文合并在一起上報到kafka，這樣可以讓JStorm程序批量處理數(shù)據(jù)。
利用流式計算的特性實現(xiàn)數(shù)據(jù)局部性，同一個集群單元的實例采集到的數(shù)據(jù)在同一個kafka分區(qū)。這樣可以減少計算過程的網(wǎng)絡(luò)傳輸及java 序列化/反序列化。這一項可以減少50%的網(wǎng)絡(luò)傳輸。有興趣的朋友可以想想為什么不能按實例分區(qū)或按集群分區(qū)，會有什么問題呢？
使用JStorm自定義調(diào)度特性，讓具有數(shù)據(jù)相關(guān)性的計算Bolt調(diào)度在同一個JVM中，這個是為了配合上面第二步，實現(xiàn)數(shù)據(jù)流轉(zhuǎn)盡量發(fā)生在同一個JVM里。
對于不得不發(fā)生的Map-Reduce數(shù)據(jù)傳輸，盡量使用批量傳輸，并對傳輸?shù)臄?shù)據(jù)結(jié)構(gòu)進行復(fù)用、裁剪，少傳輸重復(fù)數(shù)據(jù)，減少序列化、反序列化壓力。
未來展望
阿里DBPaaS全網(wǎng)秒級監(jiān)控讓數(shù)據(jù)庫管控實現(xiàn)了數(shù)字化，經(jīng)過這一年，我們積累了許多有價值的結(jié)構(gòu)化數(shù)據(jù)。隨著大數(shù)據(jù)技術(shù)、機器學習技術(shù)的發(fā)展，為數(shù)據(jù)庫管控進入智能化提供了可能性。

智能診斷，基于現(xiàn)有全方位無死角的監(jiān)控，結(jié)合事件追蹤，智能定位問題。
調(diào)度優(yōu)化，通過分析每個數(shù)據(jù)庫實例的畫像特征，讓資源互補性的幾個數(shù)據(jù)庫實例調(diào)度在一起，最終節(jié)省成本。
預(yù)算估計，通過分析數(shù)據(jù)庫歷史運行狀況,在每次大促前，根據(jù)業(yè)務(wù)交易量目標，確定每一個數(shù)據(jù)庫集群容量需求，進而為自動化擴容提供依據(jù)。
點擊查看原文