阿里數據庫進入全網秒級實時監控時代

本文由 「 AI前線」原創，原文連接： 阿里數據庫進入全網秒級實時監控時代
做者｜吳必良（未立）
編輯｜Emily

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

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

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

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

作到：

1） 覆蓋阿里全球子公司全部機房。

2） 覆蓋阿里生態包含新零售、新金融、新制造、新技術、新能源全部業務。

3） 覆蓋全部數據庫主機、操做系統、容器、數據庫、網絡。

4） 全部性能指標作到 1 秒級連續不間斷監控。

5） 全天候持續穩定運行。

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 提供從宏觀到微觀到診斷路徑顯得愈來愈迫切：從大盤到集羣、到單元、到實例、到主機、容器等一站式服務。

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

1） 高維度的性能診斷查詢速度慢，以集羣 QPS 爲例，因爲 OpenTSDB 裏存儲的每個實例的 QPS 數據，當須要查詢集羣維度 QPS 就須要對掃描集羣每個實例的 QPS，再 group by 時間戳 sum 全部實例 QPS。這須要掃描大量原始數據。

2） OpenTSDB 沒法支持複雜的監控需求，好比查看集羣平均 RT 趨勢，集羣平均 RT 並非 avg(全部實例的 RT)，而是 sum(執行時間)/sum(執行次數)。爲了實現目標只能查出 2 條時間線數據，在監控系統內部計算完後再展示在頁面中，用戶響應時間太長。

3） 長時間跨度的性能診斷速度慢，好比 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 趨勢曲線。

關鍵優化點

用這麼少的計算資源就實現了這麼高吞吐量，必然用上了許多黑科技。

1） 在預計算中，咱們使用增量迭代計算，不管是 5 秒精度的數據，仍是 15 分鐘精度數據，咱們不須要等時間窗口內全部的性能指標收集滿了，再開始計算，而是來多少性能數據，就算多少，僅保留中間結果，極大的節省內存。這項優化，相比常規計算方法至少節省 95% 內存。

2） 採集端，針對性能數據報文進行合併，把類似和相鄰的報文合併在一塊兒上報到 kafka，這樣可讓 JStorm 程序批量處理數據。

3） 利用流式計算的特性實現數據局部性，同一個集羣單元的實例採集到的數據在同一個 kafka 分區。這樣能夠減小計算過程的網絡傳輸及 java 序列化 / 反序列化。這一項能夠減小 50% 的網絡傳輸。有興趣的朋友能夠想一想爲何不能按實例分區或按集羣分區，會有什麼問題呢？

4） 使用 JStorm 自定義調度特性，讓具備數據相關性的計算 Bolt 調度在同一個 JVM 中，這個是爲了配合上面第二步，實現數據流轉儘可能發生在同一個 JVM 裏。

5） 對於不得不發生的 Map-Reduce 數據傳輸，儘可能使用批量傳輸，並對傳輸的數據結構進行復用、裁剪，少傳輸重複數據，減小序列化、反序列化壓力。

將來展望

阿里 DBPaaS 全網秒級監控讓數據庫管控實現了數字化，通過這一年，咱們積累了許多有價值的結構化數據。隨着大數據技術、機器學習技術的發展，爲數據庫管控進入智能化提供了可能性。

1） 智能診斷，基於現有全方位無死角的監控，結合事件追蹤，智能定位問題。

2） 調度優化，經過分析每一個數據庫實例的畫像特徵，讓資源互補性的幾個數據庫實例調度在一塊兒，最終節省成本。

3） 預算估計，經過分析數據庫歷史運行情況, 在每次大促前，根據業務交易量目標，肯定每個數據庫集羣容量需求，進而爲自動化擴容提供依據。

更多幹貨內容，可關注AI前線，ID：ai-front，後臺回覆「AI」、「TF」、「大數據」可得到《AI前線》系列PDF迷你書和技能圖譜。