建站
咨詢
售后
建站咨詢
新聞中心
來自阿里云RDS團隊的論文“TcpRT: Instrument and Diagnostic Analysis System for Service Quality of Cloud Databases at Massive Scale in Real-time” （TcpRT：面向大規(guī)模海量云數(shù)據(jù)庫的服務(wù)質(zhì)量實時采集與診斷系統(tǒng)）被數(shù)據(jù)庫頂會SIGMOD 2018接收，會議將于6/10在美國休斯敦召開。
商南網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)公司,商南網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為商南1000+提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站制作要多少錢，請找那個售后服務(wù)好的商南做網(wǎng)站的公司定做！
TcpRT論文介紹了RDS天象系統(tǒng)在云數(shù)據(jù)庫SLA數(shù)據(jù)采集、服務(wù)質(zhì)量指標(biāo)計算、異常檢測、故障根因分析領(lǐng)域的創(chuàng)新工作，以及大規(guī)模部署自動化的服務(wù)各類云上客戶的實踐經(jīng)驗。評委評價“I have plenty of experience with manual anomaly detection. That has wasted much time for me at work, so I liked what you described.”
簡介
隨著企業(yè)上云趨勢的日益熱化，作為產(chǎn)業(yè)核心組件的數(shù)據(jù)庫，已成為各大云計算公司增長最快的在線服務(wù)業(yè)務(wù)。作為中國第一大云數(shù)據(jù)庫廠商，我們RDS團隊致力于為用戶提供穩(wěn)定的云數(shù)據(jù)庫服務(wù)。從本質(zhì)上看，RDS是一個多租戶DBaaS平臺，利用輕量級KVM、Docker鏡像等資源隔離技術(shù)將用戶所購買的數(shù)據(jù)庫實例部署在物理機上，按需分配資源并進行自動升降級，實現(xiàn)一套完全自動化的智能運維管理。
云數(shù)據(jù)庫對客戶業(yè)務(wù)的穩(wěn)定性至關(guān)重要，因此快速發(fā)現(xiàn)云數(shù)據(jù)庫性能出現(xiàn)異常，及時定位異常原因是云數(shù)據(jù)庫廠商的一個挑戰(zhàn)。TcpRT是阿里云數(shù)據(jù)庫用來監(jiān)控和診斷數(shù)據(jù)庫服務(wù)質(zhì)量的一個基礎(chǔ)設(shè)施。TcpRT從主機TCP/IP協(xié)議棧的壅塞控制采集trace數(shù)據(jù)，計算數(shù)據(jù)庫延遲和網(wǎng)絡(luò)異常，在后臺流式計算平臺進行大規(guī)模實時數(shù)據(jù)分析和聚合，通過統(tǒng)計指標(biāo)歷史數(shù)據(jù)的柯西分布發(fā)現(xiàn)異常點，并通過同一臺主機、交換機、proxy下所有實例一致性趨勢的比例來計算不同組件發(fā)生異常的概率。
到目前為止，TcpRT以每秒采集2千萬條原始trace數(shù)據(jù)、每天后臺處理百億吞吐數(shù)據(jù)、秒級檢測異常的卓越性能在阿里云持續(xù)穩(wěn)定運行三年。
本文貢獻：
- 提出了一種新的對數(shù)據(jù)庫服務(wù)質(zhì)量進行采集的方法，基于內(nèi)核壅塞模塊實現(xiàn)，可以非侵入性、低代價的采集基于停等協(xié)議的關(guān)系數(shù)據(jù)庫的per connection的延遲、帶寬，分析用戶使用數(shù)據(jù)庫的模型（短連接和長連接），并且可以端到端的記錄和量化基礎(chǔ)網(wǎng)絡(luò)服務(wù)質(zhì)量對數(shù)據(jù)庫服務(wù)質(zhì)量的影響，包括丟包率、重傳率。
- 我們開發(fā)了一套對采集的原始數(shù)據(jù)進行數(shù)據(jù)清洗、過濾、聚合、分析的流式計算系統(tǒng)，系統(tǒng)可以做到水平擴展、容錯性、實時性、Exactly Once，具有和其他大數(shù)據(jù)平臺例如EMR、MaxCompute進行數(shù)據(jù)交換的能力。
- 我們提出了一個新的算法對TcpRT數(shù)據(jù)進行分析，來發(fā)現(xiàn)數(shù)據(jù)庫的服務(wù)質(zhì)量有無異常，并且對異常事件的根因進行定位。
問題
從網(wǎng)絡(luò)架構(gòu)上看，RDS由控制層和數(shù)據(jù)鏈路層兩個部分組成，如上圖所示。其中，控制層包括一系列管理模塊，比如資源管理器，HA管理器，遷移管理器等。資源管理器負(fù)責(zé)將實例的不同副本分配在獨立的物理主機上。當(dāng)實例發(fā)生故障時，HA管理器會探測到主實例的故障，并將服務(wù)連接切換到Standby節(jié)點上。而當(dāng)主機負(fù)載失衡時，遷移管理器負(fù)責(zé)將數(shù)據(jù)庫實例進行遷移，保障用戶服務(wù)質(zhì)量。
數(shù)據(jù)鏈路層主要負(fù)責(zé)數(shù)據(jù)的分發(fā)和路由。通常，云用戶通過ECS和RDS實現(xiàn)業(yè)務(wù)上云。他們將業(yè)務(wù)部署在ECS上，并通過VPC和RDS數(shù)據(jù)庫實例進行交互。數(shù)據(jù)包通過駐留在用戶VPC網(wǎng)絡(luò)中的vSwitch進行打包／解包并路由。而SLB負(fù)責(zé)將這些數(shù)據(jù)包進行解析，并將DBaaS IP映射到真實服務(wù)器上。目前，SLB同時支持FNAT和DNAT兩種模式。由于出流量數(shù)據(jù)不經(jīng)過SLB， DNAT比FNAT呈現(xiàn)出更好的性能。除此之外，我們引入NGLB進行優(yōu)化。在Proxy中，我們解析客戶端/服務(wù)端協(xié)議，并提取查詢，將讀寫進行分離，同時支持橫向分區(qū)和連接池的功能。
作為客戶業(yè)務(wù)的核心組件，保障云數(shù)據(jù)庫7/24的穩(wěn)定至關(guān)重要。我們通過對用戶承諾數(shù)據(jù)庫SLA服務(wù)等級協(xié)議，來保障用戶的權(quán)益。然而，云數(shù)據(jù)庫的服務(wù)質(zhì)量受各種因素影響，例如突發(fā)性連接斷開、數(shù)據(jù)庫延遲發(fā)生抖動、吞吐驟然下降等，都有可能帶來用戶業(yè)務(wù)指標(biāo)的下降。因此，快速發(fā)現(xiàn)云數(shù)據(jù)庫性能異常，及時定位根因是云數(shù)據(jù)庫廠商的一個挑戰(zhàn)。
可能造成云數(shù)據(jù)庫的服務(wù)質(zhì)量下降的原因很多，例如網(wǎng)絡(luò)上的異常，比如DB主機的上聯(lián)交換機tor發(fā)生丟包，或者load balaner出現(xiàn)TCP incast問題；或者用戶側(cè)的問題，用戶端網(wǎng)絡(luò)異常或者丟包；或者多租戶機制，DB主機內(nèi)核缺陷、硬件上SSD的硬件異常等等都會引起。在出現(xiàn)問題時，快速診斷定位解決問題是關(guān)鍵的問題。
傳統(tǒng)數(shù)據(jù)庫性能采集只需要采集DBMS內(nèi)部處理SQL請求的延遲就夠了，但云數(shù)據(jù)庫需要end-end數(shù)據(jù)。因為對云上用戶而言，他看到的云數(shù)據(jù)庫的延遲是終端的延遲。真實的場景對trace工具提出這些需求，因此很關(guān)鍵的是要采集end-to-end數(shù)據(jù)，以及鏈路每段的延遲，終端用戶感受到的延遲是所有路徑上每個節(jié)點處理延遲以及網(wǎng)絡(luò)上所有延遲的總和，不僅僅要采集DB上的延遲，還要采集proxy上看到的延遲。這需要在鏈路上引入trace。還要采集網(wǎng)絡(luò)上的數(shù)據(jù)，主機上其實可以看到的上行亂序和下行的重傳，這個信息對推測網(wǎng)絡(luò)有無異常非常重要。發(fā)送和接收會走不同的網(wǎng)絡(luò)路徑。
傳統(tǒng)的trace手段需要入侵式地在業(yè)務(wù)代碼中添加埋點。第一，我們不能在客戶端埋點，因為客戶基本上都使用標(biāo)準(zhǔn)數(shù)據(jù)庫客戶端來訪問，沒有嵌入打點代碼，我們也不能期望客戶會修改自己的業(yè)務(wù)代碼，加入打點邏輯，并將打點數(shù)據(jù)采集交給我們。因此我們需要一種非侵入式的方法來獲取end-to-end性能數(shù)據(jù)。第二在服務(wù)器端埋點也有問題，應(yīng)用層無法感知真正的數(shù)據(jù)接收和發(fā)送時間。應(yīng)用層記錄的時間是內(nèi)核把數(shù)據(jù)交付給應(yīng)用層和應(yīng)用層把數(shù)據(jù)交付給內(nèi)核的時間。在系統(tǒng)負(fù)載很高，應(yīng)用層進程調(diào)度需要花費大量時間的場景下，會導(dǎo)致請求的實際處理時間計算不準(zhǔn)確；應(yīng)用層無法感知到網(wǎng)絡(luò)鏈路質(zhì)量。在網(wǎng)絡(luò)出現(xiàn)擁塞，大量的重傳報文，導(dǎo)致數(shù)據(jù)發(fā)送和接收過程大大延長，無法區(qū)分出是對端響應(yīng)緩慢還是網(wǎng)絡(luò)鏈路質(zhì)量不佳。
在這種挑戰(zhàn)下，TcpRT——阿里云數(shù)據(jù)庫監(jiān)控和診斷服務(wù)質(zhì)量系統(tǒng)，孕育而生。
TcpRT從主機TCP/IP協(xié)議棧的擁塞控制采集trace數(shù)據(jù)，用于監(jiān)測數(shù)據(jù)庫延遲和網(wǎng)絡(luò)異常，并利用流技術(shù)，在后臺實時計算平臺上進行大規(guī)模在線數(shù)據(jù)分析，結(jié)合離線模型，通過實時異常事件判定，以及RDS網(wǎng)絡(luò)關(guān)系圖譜中的趨勢一致性概率探測，快速診斷出性能異常并定位原因。
架構(gòu)
上圖是TcpRT的概要架構(gòu)圖，其中包含以下個組件：
- 內(nèi)核模塊——用于采集指標(biāo)trace數(shù)據(jù)，包括查詢延遲、Proxy節(jié)點和DB節(jié)點的連接指標(biāo)等
- 本地聚合器——負(fù)責(zé)將內(nèi)核模塊采集的trace數(shù)據(jù)進行本地聚合處理，推送至Kafka消息隊列
- 流式ETL——利用流技術(shù)，在后臺流式計算平臺上將Kafka中的時序指標(biāo)數(shù)據(jù)進行清洗、多粒度聚合及在線分析，利用冷熱技術(shù)將數(shù)據(jù)分離
- 在線異常監(jiān)測——根據(jù)時序指標(biāo)數(shù)據(jù)，擬合異常模型，通過實時異常事件判定，以及RDS網(wǎng)絡(luò)關(guān)系圖譜中的趨勢一致性概率探測，快速診斷出性能異常并定位原因
TcpRT內(nèi)核模塊
內(nèi)核模塊主要負(fù)責(zé)對網(wǎng)絡(luò)數(shù)據(jù)的傳輸進行整個生命周期的監(jiān)控。在遵守停等協(xié)議的TCP通信機制下，服務(wù)端處理每個請求的過程分成3個階段，接收階段(Receive)、處理階段(Handle)和響應(yīng)階段(Response)。如下圖所示：
鑒于此，我們需要計算如下時間：
上行時間 = T1 - T0
處理時間 = T2 - T1
下行時間 = T3 - T2
查詢時間 = T3 - T0
RTT時間 = T2 - T2'
現(xiàn)有的監(jiān)控方案，通常在業(yè)務(wù)層面埋點進行服務(wù)耗時監(jiān)控，但此方法既不能獲得真正的數(shù)據(jù)接收和發(fā)送時間、也無法感知到網(wǎng)絡(luò)鏈路的質(zhì)量，更需要在業(yè)務(wù)代碼中入侵式地添加埋點。因此，我們實現(xiàn)了一種通用、低開銷的內(nèi)核模塊進行trace監(jiān)控以得到上述時間。
首先，我們選擇修改Linux內(nèi)核的擁塞控制算法。此算法可以感知內(nèi)核發(fā)送報文的上下文，并且支持熱更新（只需增加一個驅(qū)動模塊而無需更新線上內(nèi)核）。
此外，擁塞控制算法提供了以下機制：
1. 每個TCP通信是獨立的擁塞控制算法，不存在資源競爭情況
2. 可以感知到收到的每個ACK報文的上下文
3. 在已經(jīng)發(fā)送的報文都已經(jīng)被ACK的情況下，可以感知到當(dāng)前發(fā)送的報文上下文
根據(jù)擁塞控制算法提供的事件回調(diào)，我們可以獲取到每個TCP連接下述事件：
1. 客戶端發(fā)送給服務(wù)端ACK報文
2. 在所有已經(jīng)發(fā)出去的sequence都被確認(rèn)的情況下，服務(wù)端發(fā)送報文
3. TCP連接建立
4. TCP連接斷開
內(nèi)核任何線程都可能調(diào)用到擁塞控制算法，因此為了性能，擁塞控制算法必須保證是沒有數(shù)據(jù)爭搶的。TcpRT內(nèi)核模塊保證了以下四點：
1. TcpRT所有的數(shù)據(jù)保存在每個TCP連接對象上，所有的數(shù)據(jù)讀寫都沒有跨TCP連接的共享；
2. TcpRT在每個CPU core都有獨立的寫緩沖區(qū)，防止了多個內(nèi)核線程爭搶寫緩沖區(qū)加鎖；
3. 為了避免內(nèi)存開銷，又保證實時性，TcpRT的寫緩沖區(qū)會在buffer滿或者時間到的情況下，刷新寫緩沖區(qū)到debugfs，供應(yīng)用層采集端采集。由于寫debugfs的頻率很低，debugfs的鎖爭搶幾乎不存在，最大限度保證了性能；
4. TcpRT回寫的數(shù)據(jù)，是binary格式的，對比需要format的字符格式，在實測場景可以提高20%的性能。
此外，通過給linux內(nèi)核添加setsockopt選項，通知內(nèi)核一個不需要應(yīng)答的請求交互過程已經(jīng)結(jié)束，從而支持非停等協(xié)議。
針對TcpRT內(nèi)核模塊對用戶數(shù)據(jù)庫實例的性能影響，我們基于sysbench模擬了MySQL 400個客戶端連接進行壓測，結(jié)果如下圖所示，TcpRT內(nèi)核模塊對系統(tǒng)的負(fù)載影響不到1%。
TcpRT內(nèi)核模塊，利用debugfs和用戶態(tài)通信。每秒以千萬的trace數(shù)據(jù)高速產(chǎn)出并吐入至debugfs中。為了減輕后臺在線分析任務(wù)的壓力，我們構(gòu)建本地TcpRT聚合器，實現(xiàn)本地trace秒級聚合，并將聚合結(jié)果輸出到/dev/shm中。Logagent從中讀取聚合數(shù)據(jù)，發(fā)送至Kafka，并由后臺ETL接手，進行實時數(shù)據(jù)分析，流程如下圖所示：
在本地聚合器中，聚合操作需要保證可交換且可結(jié)合，我們采用均值、最大值、請求個數(shù)的三元組聚合方法來保證延遲時間類指標(biāo)滿足這一要求。此外，我們采用每秒同客戶端出現(xiàn)的不同端口數(shù)對活躍連接數(shù)進行指標(biāo)特征提取。同時，抽取請求數(shù)作為特征，建立用戶長短連接的使用模型，進而對用戶使用數(shù)據(jù)庫實例的負(fù)載模式進行分析。根據(jù)歷史數(shù)據(jù)，當(dāng)前仍有眾多用戶采用短連接模式，這對于諸如MySQL線程網(wǎng)絡(luò)模型的DB是非常不友好的，從而激發(fā)我們提供Proxy中間件將短連接轉(zhuǎn)換為長連接服務(wù)。
為了最大化聚合效果，我們在內(nèi)存中維護最近5s的聚合結(jié)果，將5s前的數(shù)據(jù)輸出到/dev/shm的文件中。且為了提高查詢性能以及長時間段的聚合操作，我們將三種粒度1s, 5s, 1m的聚合結(jié)果存入到庫中。
TcpRT ETL
下圖描繪了ETL任務(wù)的拓?fù)浣Y(jié)構(gòu)：
在線ETL任務(wù)主要包括四個子任務(wù)：
- 數(shù)據(jù)轉(zhuǎn)換
- 數(shù)據(jù)關(guān)聯(lián)與聚合
- 數(shù)據(jù)存儲
- 以及延遲和亂序處理
其中，延遲和亂序到達(dá)的處理是一個難點。TcpRT輸出的時序數(shù)據(jù)是以SQL執(zhí)行結(jié)束時間為時間戳，如何做到實時準(zhǔn)確地對窗口內(nèi)的時序數(shù)據(jù)進行聚合并將結(jié)果刷出是一個兩難的問題。我們采用了“盡力聚合”的方法，即對窗口設(shè)定等待時間，待時間結(jié)束后將實時聚合結(jié)果刷出，若此后，還有該窗口的時序數(shù)據(jù)到來，則直接落入到數(shù)據(jù)庫中。如TcpRT聚合器中所述，所有聚合數(shù)據(jù)具有可再結(jié)合特性，這樣，我們可以對同時刻的聚合數(shù)據(jù)進行二次聚合。
在線異常監(jiān)測
組件的異常往往伴隨著相關(guān)指標(biāo)的抖動。比如主機發(fā)生IO Hang后，load、dirty、writeback、某些core的iowait、被阻塞的線程數(shù)等指標(biāo)會明顯升高，而各實例的write，CPU使用率會明顯變低，主機維度的PT指標(biāo)會明顯升高。在部分情況下，連接數(shù)會上升，長連接請求數(shù)會下降，流量會下降等。在Proxy發(fā)生異常的時候，PT可能會升高、CPU、流量、連接數(shù)均可能會下降。
傳統(tǒng)方法下，我們通過設(shè)定閾值進行指標(biāo)抖動的檢測。然而閾值的設(shè)定強依賴于專家經(jīng)驗，維護成本高，且一刀切的設(shè)定常常會“誤傷”健康指標(biāo)。比如，有些數(shù)據(jù)庫實例是專門用于OLAP，它們的SQL請求處理時間往往都是秒級的，若采用常用的SQL請求處理時間作為異常判定閾值，此類數(shù)據(jù)庫實例就會觸發(fā)報警。
鑒于此，我們需要一種通用且自適應(yīng)的智能模型來解決云數(shù)據(jù)庫的異常監(jiān)測。
為了避免人工設(shè)定閾值，我們一開始嘗試?yán)胏ontrol charts來進行判斷，根據(jù)樣本時間段的均值和標(biāo)準(zhǔn)差，預(yù)測未來時間段的置信區(qū)間。若實際值超出置信區(qū)間，則判定為異常。然而，若樣本本身為異常，則此時間段的參數(shù)均不可信。
如上圖，左上圖為(ins1,*,db1)的upsize指標(biāo)時序圖，可以看到(ins1,*,db1)的upsize指標(biāo)會有周期性的波動。左下的兩張圖分別是歷史時間窗口設(shè)定值為30min的(ins1,*,db1)的upsize指標(biāo)mean&median時序圖和SD&MAD時序圖?？梢郧宄吹剑?dāng)upsize指標(biāo)發(fā)生波動后，mean值和標(biāo)準(zhǔn)差SD值都會發(fā)生窗口時間長度的跳變，但median和MAD卻幾乎不受指標(biāo)波動的影響，顯得更平穩(wěn)、絲滑。
右上圖為（ins2,*,db2）的newConn指標(biāo)時序圖，可以看到在03:40~04:00期間，指標(biāo)發(fā)生異常，出現(xiàn)大量極端值，由于歷史的時間窗口設(shè)定值為30min，所以可以從左下的圖表中看到，很長一段時間內(nèi)樣本的均值和標(biāo)準(zhǔn)差便會發(fā)生較大的波動，而中位數(shù)和MAD指標(biāo)卻顯得平滑，對極端值并不敏感，展出超強的魯棒性。由于依賴均值和標(biāo)準(zhǔn)差進行預(yù)測，control charts具有不穩(wěn)定性，易造成誤判。這啟發(fā)我們利用中位數(shù)和MAD替代均值和標(biāo)準(zhǔn)差作為預(yù)測模型參數(shù)。
如上圖所示，通過大量觀察，我們發(fā)現(xiàn)，按（*,*,db） 和(*,*,proxy) 粒度聚合后的采樣點集合近似正態(tài)分布。但是，正態(tài)分布依賴平均值和標(biāo)準(zhǔn)差作為參數(shù)，如上文所述，這兩個參數(shù)波動大，會造成嚴(yán)重誤判。鑒于柯西分布與正態(tài)分布相似，且不依賴均值和標(biāo)準(zhǔn)差，可以使用中位數(shù)和MAD這種穩(wěn)定的統(tǒng)計指標(biāo)來進行回歸。從上上圖可以看到當(dāng)歷史時間窗口長度設(shè)定合適的時候，中位數(shù)和MAD在面對指標(biāo)波動和異常的情況下，顯得平滑且穩(wěn)定，這樣回歸出的模型具有更強的穩(wěn)定性。于是，我們使用中位數(shù)和MAD作為參數(shù)的回歸柯西分布來擬合異常診斷模型。
為了獲取回歸需要的樣本集，我們通過對過去一段時間（比如：最近一個小時）的每一個時間點做采樣，得到一段歷史窗口的數(shù)據(jù)點集合S{x0,x1,x2,……}。根據(jù)歷史窗口數(shù)據(jù)集，計算中位數(shù)M以及MAD，回歸出這個數(shù)據(jù)集的柯西概率分布D。
主機異常檢測
RDS主機上承載著眾多實例，各實例通常隸屬于不同用戶的不同業(yè)務(wù)。在主機正常工作時，由于實例相互獨立、并且對應(yīng)的指標(biāo)波動具有不確定性，所有實例呈現(xiàn)出一致性升高或降低的概率非常小。當(dāng)主機發(fā)生異常時，由于該主機上的所有實例共享同一資源，某些關(guān)鍵指標(biāo)會呈現(xiàn)出一致性趨勢。當(dāng)一臺主機發(fā)生了IO Hang，主機上大部分實例的SQL處理延遲都呈現(xiàn)出升高的趨勢，各實例的數(shù)據(jù)寫入量呈現(xiàn)出下降的趨勢。這啟發(fā)我們利用實例趨勢一致性概率來判斷主機的異常。
首先，設(shè)定函數(shù)H(curentVal, prevMideanVal，metricType)作為判斷指標(biāo)metric1是否異常的函數(shù),取值只能是－1，0，＋1。currentVal代表這一刻該指標(biāo)的值，prevMideanVal代表過去一段時間（比如：1小時）采樣點集合的中位數(shù)，metricType代表該指標(biāo)的類型（比如：rt，rtt，qps，流量等）。取值為－1代表這個指標(biāo)在跟過去一段時間指標(biāo)做對比的時候呈現(xiàn)出明顯下降的趨勢，0代表這個指標(biāo)沒有明顯波動，＋1代表這個指標(biāo)與過去一段時間相比明顯上升。
我們可以利用上文的算法來實現(xiàn)函數(shù)H，這樣我們能算出（ins,*,dstIp,metricType）級別數(shù)據(jù)的函數(shù)H值，然后在按(ins,*,dstIp,metricType)->(*,*, dstIp,metricType)做map－reduce（agg類型為sum）。算出的值s反映了這個指標(biāo)在這臺主機上的突升，突降的趨勢，用求和值s除以這個主機上的活躍實例數(shù)t得出突升／突降實例比例r，當(dāng)r大于0是，總體趨勢上升，當(dāng)r小于0是，總體趨勢下降，且絕對值越大概率越大。
那么我們?nèi)绾卫胷值來判斷主機異常呢？如果機器突然由正常變?yōu)楫惓r，各實例由于都依賴這臺機器的資源進行工作，或多或少要受其影響，因此相關(guān)指標(biāo)發(fā)生突變的實例比例將會發(fā)生突變，比如主機上cpu資源突然不足，大部分實例都會受影響，他們的處理時間會突升，流量突降，請求數(shù)突降，因此可以通過判斷r值是否突變來判斷主機異常。
我們可以利用上文的算法來對r值的突變進行判斷，對過去一段時間的每一個時間點都做這樣的計算，我們可以得到一段歷史窗口的突升／突降實例比例r行程的數(shù)據(jù)點集合S{R0,R1,R2,…}。根據(jù)歷史窗口數(shù)據(jù)集，我們算出數(shù)據(jù)集的中位數(shù)M，以及MAD值，回歸出這個數(shù)據(jù)集的柯西概率分布D。
因為比例r的取值是－1～1，而柯西概率分布D的自變量x范圍是負(fù)無窮到正無窮。我們需要對原來的比率r做轉(zhuǎn)化讓他的范圍擴充到正負(fù)無窮。通過定義的映射函數(shù)求出這一時刻下該指標(biāo)的柯西概率分布的CDF()，如果CDF()非常小，比如小于0.1%，主機hostA的指標(biāo)metric1呈現(xiàn)總體下降趨勢，或者非常大比如99.8%, 主機hostA的指標(biāo)metric1呈現(xiàn)總體上升趨勢。 但是這樣做判斷，只是判斷出了r值的突升和突降，為了減少誤判，我們還要判斷出r值的突升和突降需要落到警戒范圍。因此需要一個必要條件：r值的絕對值至少為20％。
另外，當(dāng)r值足夠高時，無論r值是否突升還是突降，都應(yīng)該認(rèn)為是異常，因此還需要一個充分條件：r值的絕對值大于AlarmRatio(主機上的活躍實例t),那么認(rèn)為是異常。根據(jù)我們自己的實際情況，AlarmRatio(t)＝0.8*Pow(0.987, t) + 0.2. 曲線如圖，當(dāng)主機上的活躍實例比較少時，AlarmRatio值比較高，這樣為了保證判斷出異常的主機上異常的實例足夠多，這樣才有較高的說服力，而隨著主機上活躍實例數(shù)變多，AlarmRatio值會相應(yīng)得變小最后收斂到0.2，這樣為了不漏掉r比較少但是異常實例數(shù)足夠多的情況。
當(dāng)r＝-1時，這臺機器hostA上所有的實例的指標(biāo)metric1都出現(xiàn)了下降趨勢，當(dāng)r=1時，hostA上所有實例的指標(biāo)metric1都出現(xiàn)了上升趨勢。除了獨占實例，一臺主機上有數(shù)十甚至上百的實例，他們分屬不同的用戶，運行著不同的業(yè)務(wù)，呈現(xiàn)出一致的趨勢概率很小，因此在正常的時候r值往往穩(wěn)定在一個較低的范圍內(nèi)，當(dāng)r值很高的時候，極有可能主機問題了。
但是這樣的判斷還不夠，因為還存在這兩種情況：1. 實例之間公用的某個組件出現(xiàn)了異常。比如網(wǎng)絡(luò)中間件引起的異常，路由器的異常等等。也會引起r值變高；2.有的主機上因為實例數(shù)比較少（比如：小于3）時，單純根據(jù)比例判斷還分辨不出是否是主機的問題，因為樣本數(shù)太少，不具有說服力。針對這兩種情況，我們還用了多種方法來提高準(zhǔn)確率，比如：
1.結(jié)合物理機的資源指標(biāo)（load，iowait，dirty，writeback等）的加權(quán)和來協(xié)助判斷。2.如果存在上游節(jié)點（比如：proxy），并且上游節(jié)點存在異常，則優(yōu)先報上游節(jié)點的異常。因為上游節(jié)點往往還連接多個下游節(jié)點，如果是某個單獨的下游節(jié)點出現(xiàn)了異常，一般上游節(jié)點是不會出現(xiàn)異常的，因為上游節(jié)點上連接的下游節(jié)點很多，這一個點并不會明顯改變整體的指標(biāo)趨勢變化，而某個節(jié)點的多個下游節(jié)點都出了問題，他們的上游節(jié)點出問題的概率更大一些。假設(shè)上游節(jié)點完全正常，下游節(jié)點近似相互獨立，一個節(jié)點出問題的概率為p，K各節(jié)點同時出問題的概率就是p^K,所以問題的原因很可能是概率更大的上游節(jié)點。
Proxy異常檢測
我們的大部分實例在訪問db前要經(jīng)過proxy的轉(zhuǎn)發(fā)，proxy可以幫用戶做短鏈接優(yōu)化，負(fù)載均衡，連接審計，注入檢測等。proxy是我們生產(chǎn)集群非常重要的組件，一個proxy節(jié)點最多會有上千個實例的請求（requests of thousands of instances）經(jīng)過。也就是說，如果一個proxy節(jié)點發(fā)生了故障，將會影響到上千個實例，這樣的故障我們需要快速準(zhǔn)確地發(fā)現(xiàn)并定位出來，否則后果不敢想象。
我們一開始對proxy的qps，連接數(shù)等設(shè)定閾值的方式來進行報警，但是由于不同分組的proxy業(yè)務(wù)量大小不一樣，因此我們需要對不同分組設(shè)定不同的閾值，而且我們的業(yè)務(wù)增長迅速，proxy會經(jīng)常進行擴容，這樣閾值又要重新調(diào)整，維護起來費時費力。
我們雖然可以利用上邊所講的判斷db主機異常一樣的算法來判斷proxy異常，但是由于proxy的處理時間包含了db本地的處理時間，應(yīng)用這種方式我們是無法評估出請求在單純在proxy中停留的時間。對于使用了proxy鏈路的用戶，由于在網(wǎng)絡(luò)中多了proxy轉(zhuǎn)發(fā)的代價，所以SQL請求的延時會稍微比不用proxy鏈路的請求要慢。因此為了不影響用戶的體驗，我們希望SQL請求在proxy節(jié)點中停留的時間越短越好。因此我們以SQL請求在proxy節(jié)點中停留和proxy與db之間的傳輸總時間prT(proxy relay time)作為衡量proxy服務(wù)質(zhì)量的重要指標(biāo)。如果實例ins1的請求在proxy節(jié)點的prT>=ProxyRelayTimeLimit，對于該請求，proxy代價時間過長。
由于有現(xiàn)成的生產(chǎn)集群上proxy節(jié)點和db節(jié)點都安裝了tcprt內(nèi)核驅(qū)動，我們打算proxy節(jié)點和db節(jié)點的tcprt數(shù)據(jù)來做類似的工作。
如圖是ins1，ins2的SQL請求在proxy節(jié)點和db節(jié)點上的鏈路活動圖。 ins1實例的一次請求時間rt1＝ t0+ t1 + t2 + t3 + t4 + t5 + t6, 其中t0是SQL請求從client端到proxy端傳輸?shù)臅r間， t1是接收client端發(fā)的請求到向db端發(fā)送所需的時間，t2是proxy1到db1的網(wǎng)絡(luò)鏈路時間，t3是db1的本地處理時間，t4是db1到proxy1的網(wǎng)絡(luò)鏈路時間，t5是接受到db1端發(fā)的SQL應(yīng)答到向client端發(fā)送的時間，t6是應(yīng)答從proxy端到client端的傳輸時間。而(ins1, *, proxy1)的tcprt處理時間proxyInTime1=t1+t2+t3+t4+t5, (ins1, proxy1, *)的tcprt處理時間proxyOutTime1=t3,通過計算diff1 = proxyInTime1-proxyOutTime1 ＝ t1+t2+t3+t5, 可以算出SQL請求在proxy節(jié)點中停留和proxy與db之間網(wǎng)絡(luò)傳輸?shù)目倳r間prT。
由于網(wǎng)絡(luò)延遲正常情況下在內(nèi)部網(wǎng)絡(luò)中比較穩(wěn)定的，如果diff1值變大了，多出的部分，往往是proxy節(jié)點貢獻的，因此我們可以大致通過diff1估計實例ins1在proxy1停留的的大致時間。對于經(jīng)過proxy的每個實例，如果prT>=ProxyRelayTimeLimit，則認(rèn)為prT過大。我們算出proxy1上的各個實例的prT值，得到prT值過長的實例數(shù)量占proxy1上活躍實例數(shù)的比例r。我們可以根據(jù)r的突升和范圍來判斷proxy及下游網(wǎng)絡(luò)鏈路是否對用戶形成影響。 為了判斷r的突升，首先，利用上面判斷db主機異常的方法，回歸出這個數(shù)據(jù)集的柯西概率分布D。
因為比例r的取值是0～1，而柯西概率分布D的自變量x范圍是負(fù)無窮到正無窮。我們需要對原來的比率r做轉(zhuǎn)化讓他的范圍擴充到正負(fù)無窮。通過映射函數(shù)，我們求出這一時刻下該指標(biāo)的柯西概率分布的CDF(x’)，由于r越小表明proxy越健康，所以只有當(dāng)r>M是才會進一步判斷proxy是否異常，如果CDF(x’)非常大比如：大于99.8%, 說明比率r突然明顯上升，需要引起注意。為了減少誤判，我們還要判斷出r值的突升和突降需要落到警戒范圍。因此需要一個必要條件：r值的絕對值至少為20％。
不過如果r本身就很大的話比如：由于proxy升級到了一個有bug的版本上，所有的實例從新版本上線后就一直慢，由于數(shù)據(jù)集的中位數(shù)變成了100%，上面的方法就無法判斷了。我們還要再加個異常的充分條件，那就是：如果r>MaxRatio(比如：80%),就判斷為異常。使用回歸分布的方法適合當(dāng)r發(fā)生巨變時來判斷異常，主要是為了找到proxy的急性?。欢蠹拥呐袛喈惓５某浞謼l件適用于當(dāng)r從一開始就不正常，或者r緩慢變成不正常的情況，是為了找到proxy的慢性病。
網(wǎng)絡(luò)異常檢測
為了容忍交換機單點故障，每個節(jié)點（代理節(jié)點和數(shù)據(jù)庫節(jié)點）會上聯(lián)到一對TOR交換機上。TOR中的高丟包率會導(dǎo)致大量TCP數(shù)據(jù)包重新傳輸，并導(dǎo)致查詢延遲變高、失敗連接增加，從而導(dǎo)致用戶數(shù)據(jù)庫性能下降。因此，在短時間內(nèi)，識別網(wǎng)絡(luò)故障并定位異常網(wǎng)絡(luò)設(shè)備，通過修復(fù)或者更換的方式去解決網(wǎng)絡(luò)異常是至關(guān)重要的。 通過TcpRT采集的TCP連接上亂序數(shù)據(jù)包，重傳數(shù)據(jù)包，RTT抖動和RST數(shù)據(jù)包的數(shù)量，可用于網(wǎng)絡(luò)故障排查。
如上圖所示，在分布式體系結(jié)構(gòu)中，每個節(jié)點相互通信，比如，Proxy節(jié)點到數(shù)據(jù)庫節(jié)點的請求重定向。我們繪制一個二分圖來表示節(jié)點之間的關(guān)系，頂點是Proxy節(jié)點和正在通信的數(shù)據(jù)庫節(jié)點，如果兩個節(jié)點存在相互通信，那么這兩個節(jié)點存在一條鏈接邊。用虛線標(biāo)記的鏈接表示在兩個節(jié)點之間觀察到大量網(wǎng)絡(luò)異常事件（無序，重傳等），否則我們使用實線代替。
根據(jù)主機到TOR交換機對的連接信息，通過把主機節(jié)點替換成相應(yīng)的TOR交換機對，我們將上圖b轉(zhuǎn)換成上圖c。直觀上，相連虛線數(shù)越多的頂點異?？赡苄栽礁?。因此，我們定義公式count^1.5/total來衡量TOR交換機對發(fā)生異常的概率，其中count表示虛線數(shù)，total表示線（虛+實）數(shù)。count^1.5/total值越大，該TOR交換機對越有可能是異常。
小結(jié)
到目前為止，TcpRT以每秒采集2千萬條原始trace數(shù)據(jù)、每天后臺處理百億吞吐數(shù)據(jù)、秒級檢測異常的卓越性能在阿里云持續(xù)穩(wěn)定運行三年。今年TcpRT的監(jiān)控能力將包裝成云產(chǎn)品開放給RDS客戶，給客戶提供更好的數(shù)據(jù)庫與應(yīng)用診斷能力。在技術(shù)上，我們也在基于TcpRT開發(fā)更多的算法，發(fā)掘更多的異常行為。
【本文為專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
文章標(biāo)題：從沒想到監(jiān)控可以這么做！阿里云RDS智能診斷系統(tǒng)首次公開
網(wǎng)站地址：http://m.fisionsoft.com.cn/article/cddgddd.html
