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

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

作者：吳必良（未立）

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

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

在這其中，關于數據庫監控系統建設比較典型。

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

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

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

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

我們是如何做到的
實現一個支持數萬數據庫實例的實時秒級監控系統，要解決許多技術挑戰。都說優秀的架構是演進過來，監控系統的建設也隨著規模和復雜性增加不斷迭代，到2017年，監控系統經歷了四個階段改進。

第一代監控系統
第一代監控系統架構非常簡單，采集Agent直接把性能數據寫入數據庫，監控系統直接查詢數據庫即可。

隨著數據庫集群規模擴大，簡易架構的缺點也非常明顯。

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

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

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

以上所有原因催生了第二代監控系統的誕生。

第二代監控系統
第二代監控系統引入了DataHub模塊和分布式文檔數據庫。數據鏈路變成由采集Agent到DataHub到分布式文檔數據庫，監控系統從分布式文檔。

采集Agent專注于性能數據采集邏輯，構造統一數據格式，調用DataHub接口把數據傳輸到DataHub，采集Agent不需要關心性能數據存在哪里。DataHub作為承上啟下的節點，實現了采集與存儲的解耦。第一，它對采集Agent屏蔽了數據存儲細節，僅暴露最簡單數據投遞接口；第二，DataHub收到根據存儲引擎特性使用最優寫入模型，比如使用批量寫入、壓縮等方式；第三，使用LVS、LSB技術可以實現DataHub水平擴展。分布式文檔數據庫部分了解決擴展性問題，水平擴容用于解決存儲容量不足的問題，schema free的特性可以性能指標擴展性問題。

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

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

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

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

毫無疑問，OpenTSDB成為第三代監控系統架構的一部分。

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

第三代架構相比過去有巨大的進步，在2016年雙11實現了全網數據庫10秒級監控，核心數據庫集群1秒級監控。

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

在這樣的診斷需求下，第三代監控架構有點力不從心了，主要表現在查詢：

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

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

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

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

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

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

關鍵優化點
用這么少的計算資源就實現了這么高吞吐量，必然用上了許多黑科技。

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

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