阿里妹導讀：來自阿里云RDS團隊的論文“TcpRT: Instrument and Diagnostic Analysis System for Service Quality of Cloud Databases at Massive Scale in Real-time” （TcpRT：面向大規(guī)模海量云數(shù)據(jù)庫的服務質(zhì)量實時采集與診斷系統(tǒng)）被數(shù)據(jù)庫頂會SIGMOD 2018接收，會議將于6/10在美國休斯敦召開。

TcpRT論文介紹了RDS天象系統(tǒng)在云數(shù)據(jù)庫SLA數(shù)據(jù)采集、服務質(zhì)量指標計算、異常檢測、故障根因分析領域的創(chuàng)新工作，以及大規(guī)模部署自動化的服務各類云上客戶的實踐經(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ù)庫，已成為各大云計算公司增長最快的在線服務業(yè)務。作為中國第一大云數(shù)據(jù)庫廠商，我們RDS團隊致力于為用戶提供穩(wěn)定的云數(shù)據(jù)庫服務。從本質(zhì)上看，RDS是一個多租戶DBaaS平臺，利用輕量級KVM、Docker鏡像等資源隔離技術將用戶所購買的數(shù)據(jù)庫實例部署在物理機上，按需分配資源并進行自動升降級，實現(xiàn)一套完全自動化的智能運維管理。

云數(shù)據(jù)庫對客戶業(yè)務的穩(wěn)定性至關重要，因此快速發(fā)現(xiàn)云數(shù)據(jù)庫性能出現(xiàn)異常，及時定位異常原因是云數(shù)據(jù)庫廠商的一個挑戰(zhàn)。TcpRT是阿里云數(shù)據(jù)庫用來監(jiān)控和診斷數(shù)據(jù)庫服務質(zhì)量的一個基礎設施。TcpRT從主機TCP/IP協(xié)議棧的壅塞控制采集trace數(shù)據(jù)，計算數(shù)據(jù)庫延遲和網(wǎng)絡異常，在后臺流式計算平臺進行大規(guī)模實時數(shù)據(jù)分析和聚合，通過統(tǒng)計指標歷史數(shù)據(jù)的柯西分布發(fā)現(xiàn)異常點，并通過同一臺主機、交換機、proxy下所有實例一致性趨勢的比例來計算不同組件發(fā)生異常的概率。

到目前為止，TcpRT以每秒采集2千萬條原始trace數(shù)據(jù)、每天后臺處理百億吞吐數(shù)據(jù)、秒級檢測異常的卓越性能在阿里云持續(xù)穩(wěn)定運行三年。

本文貢獻：

• 提出了一種新的對數(shù)據(jù)庫服務質(zhì)量進行采集的方法，基于內(nèi)核壅塞模塊實現(xiàn)，可以非侵入性、低代價的采集基于停等協(xié)議的關系數(shù)據(jù)庫的per connection的延遲、帶寬，分析用戶使用數(shù)據(jù)庫的模型（短連接和長連接），并且可以端到端的記錄和量化基礎網(wǎng)絡服務質(zhì)量對數(shù)據(jù)庫服務質(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ù)庫的服務質(zhì)量有無異常，并且對異常事件的根因進行定位。

  
  

問題

從網(wǎng)絡架構上看，RDS由控制層和數(shù)據(jù)鏈路層兩個部分組成，如上圖所示。其中，控制層包括一系列管理模塊，比如資源管理器，HA管理器，遷移管理器等。資源管理器負責將實例的不同副本分配在獨立的物理主機上。當實例發(fā)生故障時，HA管理器會探測到主實例的故障，并將服務連接切換到Standby節(jié)點上。而當主機負載失衡時，遷移管理器負責將數(shù)據(jù)庫實例進行遷移，保障用戶服務質(zhì)量。

數(shù)據(jù)鏈路層主要負責數(shù)據(jù)的分發(fā)和路由。通常，云用戶通過ECS和RDS實現(xiàn)業(yè)務上云。他們將業(yè)務部署在ECS上，并通過VPC和RDS數(shù)據(jù)庫實例進行交互。數(shù)據(jù)包通過駐留在用戶VPC網(wǎng)絡中的vSwitch進行打包／解包并路由。而SLB負責將這些數(shù)據(jù)包進行解析，并將DBaaS IP映射到真實服務器上。目前，SLB同時支持FNAT和DNAT兩種模式。由于出流量數(shù)據(jù)不經(jīng)過SLB， DNAT比FNAT呈現(xiàn)出更好的性能。除此之外，我們引入NGLB進行優(yōu)化。在Proxy中，我們解析客戶端/服務端協(xié)議，并提取查詢，將讀寫進行分離，同時支持橫向分區(qū)和連接池的功能。

作為客戶業(yè)務的核心組件，保障云數(shù)據(jù)庫7/24的穩(wěn)定至關重要。我們通過對用戶承諾數(shù)據(jù)庫SLA服務等級協(xié)議，來保障用戶的權益。然而，云數(shù)據(jù)庫的服務質(zhì)量受各種因素影響，例如突發(fā)性連接斷開、數(shù)據(jù)庫延遲發(fā)生抖動、吞吐驟然下降等，都有可能帶來用戶業(yè)務指標的下降。因此，快速發(fā)現(xiàn)云數(shù)據(jù)庫性能異常，及時定位根因是云數(shù)據(jù)庫廠商的一個挑戰(zhàn)。

可能造成云數(shù)據(jù)庫的服務質(zhì)量下降的原因很多，例如網(wǎng)絡上的異常，比如DB主機的上聯(lián)交換機tor發(fā)生丟包，或者load balaner出現(xiàn)TCP incast問題；或者用戶側的問題，用戶端網(wǎng)絡異常或者丟包；或者多租戶機制，DB主機內(nèi)核缺陷、硬件上SSD的硬件異常等等都會引起。在出現(xiàn)問題時，快速診斷定位解決問題是關鍵的問題。

傳統(tǒng)數(shù)據(jù)庫性能采集只需要采集DBMS內(nèi)部處理SQL請求的延遲就夠了，但云數(shù)據(jù)庫需要end-end數(shù)據(jù)。因為對云上用戶而言，他看到的云數(shù)據(jù)庫的延遲是終端的延遲。真實的場景對trace工具提出這些需求，因此很關鍵的是要采集end-to-end數(shù)據(jù)，以及鏈路每段的延遲，終端用戶感受到的延遲是所有路徑上每個節(jié)點處理延遲以及網(wǎng)絡上所有延遲的總和，不僅僅要采集DB上的延遲，還要采集proxy上看到的延遲。這需要在鏈路上引入trace。還要采集網(wǎng)絡上的數(shù)據(jù)，主機上其實可以看到的上行亂序和下行的重傳，這個信息對推測網(wǎng)絡有無異常非常重要。發(fā)送和接收會走不同的網(wǎng)絡路徑。

傳統(tǒng)的trace手段需要入侵式地在業(yè)務代碼中添加埋點。第一，我們不能在客戶端埋點，因為客戶基本上都使用標準數(shù)據(jù)庫客戶端來訪問，沒有嵌入打點代碼，我們也不能期望客戶會修改自己的業(yè)務代碼，加入打點邏輯，并將打點數(shù)據(jù)采集交給我們。因此我們需要一種非侵入式的方法來獲取end-to-end性能數(shù)據(jù)。第二在服務器端埋點也有問題，應用層無法感知真正的數(shù)據(jù)接收和發(fā)送時間。應用層記錄的時間是內(nèi)核把數(shù)據(jù)交付給應用層和應用層把數(shù)據(jù)交付給內(nèi)核的時間。在系統(tǒng)負載很高，應用層進程調(diào)度需要花費大量時間的場景下，會導致請求的實際處理時間計算不準確；應用層無法感知到網(wǎng)絡鏈路質(zhì)量。在網(wǎng)絡出現(xiàn)擁塞，大量的重傳報文，導致數(shù)據(jù)發(fā)送和接收過程大大延長，無法區(qū)分出是對端響應緩慢還是網(wǎng)絡鏈路質(zhì)量不佳。

在這種挑戰(zhàn)下，TcpRT——阿里云數(shù)據(jù)庫監(jiān)控和診斷服務質(zhì)量系統(tǒng)，孕育而生。

TcpRT從主機TCP/IP協(xié)議棧的擁塞控制采集trace數(shù)據(jù)，用于監(jiān)測數(shù)據(jù)庫延遲和網(wǎng)絡異常，并利用先進的流技術，在后臺實時計算平臺上進行大規(guī)模在線數(shù)據(jù)分析，結合離線模型，通過實時異常事件判定，以及RDS網(wǎng)絡關系圖譜中的趨勢一致性概率探測，快速診斷出性能異常并定位原因。

架構

上圖是TcpRT的概要架構圖，其中包含以下個組件：

• 內(nèi)核模塊——用于采集指標trace數(shù)據(jù)，包括查詢延遲、Proxy節(jié)點和DB節(jié)點的連接指標等

• 本地聚合器——負責將內(nèi)核模塊采集的trace數(shù)據(jù)進行本地聚合處理，推送至Kafka消息隊列

• 流式ETL——利用流技術，在后臺流式計算平臺上將Kafka中的時序指標數(shù)據(jù)進行清洗、多粒度聚合及在線分析，利用冷熱技術將數(shù)據(jù)分離

• 在線異常監(jiān)測——根據(jù)時序指標數(shù)據(jù)，擬合異常模型，通過實時異常事件判定，以及RDS網(wǎng)絡關系圖譜中的趨勢一致性概率探測，快速診斷出性能異常并定位原因

TcpRT內(nèi)核模塊

內(nèi)核模塊主要負責對網(wǎng)絡數(shù)據(jù)的傳輸進行整個生命周期的監(jiān)控。在遵守停等協(xié)議的TCP通信機制下，服務端處理每個請求的過程分成3個階段，接收階段(Receive)、處理階段(Handle)和響應階段(Response)。如下圖所示：

鑒于此，我們需要計算如下時間：

上行時間 = T1 - T0
處理時間 = T2 - T1
下行時間 = T3 - T2
查詢時間 = T3 - T0
RTT時間 = T2 - T2'

現(xiàn)有的監(jiān)控方案，通常在業(yè)務層面埋點進行服務耗時監(jiān)控，但此方法既不能獲得真正的數(shù)據(jù)接收和發(fā)送時間、也無法感知到網(wǎng)絡鏈路的質(zhì)量，更需要在業(yè)務代碼中入侵式地添加埋點。因此，我們實現(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的情況下，可以感知到當前發(fā)送的報文上下文

根據(jù)擁塞控制算法提供的事件回調(diào)，我們可以獲取到每個TCP連接下述事件：
1. 客戶端發(fā)送給服務端ACK報文
2. 在所有已經(jīng)發(fā)出去的sequence都被確認的情況下，服務端發(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，供應用層采集端采集。由于寫debugfs的頻率很低，debugfs的鎖爭搶幾乎不存在，最大限度保證了性能；
4. TcpRT回寫的數(shù)據(jù)，是binary格式的，對比需要format的字符格式，在實測場景可以提高20%的性能。

此外，通過給linux內(nèi)核添加setsockopt選項，通知內(nèi)核一個不需要應答的請求交互過程已經(jīng)結束，從而支持非停等協(xié)議。

針對TcpRT內(nèi)核模塊對用戶數(shù)據(jù)庫實例的性能影響，我們基于sysbench模擬了MySQL 400個客戶端連接進行壓測，結果如下圖所示，TcpRT內(nèi)核模塊對系統(tǒng)的負載影響不到1%。

TcpRT聚合器

TcpRT內(nèi)核模塊，利用debugfs和用戶態(tài)通信。每秒以千萬的trace數(shù)據(jù)高速產(chǎn)出并吐入至debugfs中。為了減輕后臺在線分析任務的壓力，我們構建本地TcpRT聚合器，實現(xiàn)本地trace秒級聚合，并將聚合結果輸出到/dev/shm中。Logagent從中讀取聚合數(shù)據(jù)，發(fā)送至Kafka，并由后臺ETL接手，進行實時數(shù)據(jù)分析，流程如下圖所示：

在本地聚合器中，聚合操作需要保證可交換且可結合，我們采用均值、最大值、請求個數(shù)的三元組聚合方法來保證延遲時間類指標滿足這一要求。此外，我們采用每秒同客戶端出現(xiàn)的不同端口數(shù)對活躍連接數(shù)進行指標特征提取。同時，抽取請求數(shù)作為特征，建立用戶長短連接的使用模型，進而對用戶使用數(shù)據(jù)庫實例的負載模式進行分析。根據(jù)歷史數(shù)據(jù)，當前仍有眾多用戶采用短連接模式，這對于諸如MySQL線程網(wǎng)絡模型的DB是非常不友好的，從而激發(fā)我們提供Proxy中間件將短連接轉換為長連接服務。

為了最大化聚合效果，我們在內(nèi)存中維護最近5s的聚合結果，將5s前的數(shù)據(jù)輸出到/dev/shm的文件中。且為了提高查詢性能以及長時間段的聚合操作，我們將三種粒度1s, 5s, 1m的聚合結果存入到庫中。

TcpRT ETL

下圖描繪了ETL任務的拓撲結構：

在線ETL任務主要包括四個子任務：

• 數(shù)據(jù)轉換

• 數(shù)據(jù)關聯(lián)與聚合

• 數(shù)據(jù)存儲

• 以及延遲和亂序處理

其中，延遲和亂序到達的處理是一個難點。TcpRT輸出的時序數(shù)據(jù)是以SQL執(zhí)行結束時間為時間戳，如何做到實時準確地對窗口內(nèi)的時序數(shù)據(jù)進行聚合并將結果刷出是一個兩難的問題。我們采用了“盡力聚合”的方法，即對窗口設定等待時間，待時間結束后將實時聚合結果刷出，若此后，還有該窗口的時序數(shù)據(jù)到來，則直接落入到數(shù)據(jù)庫中。如TcpRT聚合器中所述，所有聚合數(shù)據(jù)具有可再結合特性，這樣，我們可以對同時刻的聚合數(shù)據(jù)進行二次聚合。

在線異常監(jiān)測

組件的異常往往伴隨著相關指標的抖動。比如主機發(fā)生IO Hang后，load、dirty、writeback、某些core的iowait、被阻塞的線程數(shù)等指標會明顯升高，而各實例的write，CPU使用率會明顯變低，主機維度的PT指標會明顯升高。在部分情況下，連接數(shù)會上升，長連接請求數(shù)會下降，流量會下降等。在Proxy發(fā)生異常的時候，PT可能會升高、CPU、流量、連接數(shù)均可能會下降。

傳統(tǒng)方法下，我們通過設定閾值進行指標抖動的檢測。然而閾值的設定強依賴于專家經(jīng)驗，維護成本高，且一刀切的設定常常會“誤傷”健康指標。比如，有些數(shù)據(jù)庫實例是專門用于OLAP，它們的SQL請求處理時間往往都是秒級的，若采用常用的SQL請求處理時間作為異常判定閾值，此類數(shù)據(jù)庫實例就會觸發(fā)報警。

鑒于此，我們需要一種通用且自適應的智能模型來解決云數(shù)據(jù)庫的異常監(jiān)測。

為了避免人工設定閾值，我們一開始嘗試利用control charts來進行判斷，根據(jù)樣本時間段的均值和標準差，預測未來時間段的置信區(qū)間。若實際值超出置信區(qū)間，則判定為異常。然而，若樣本本身為異常，則此時間段的參數(shù)均不可信。

如上圖，左上圖為(ins1,*,db1)的upsize指標時序圖，可以看到(ins1,*,db1)的upsize指標會有周期性的波動。左下的兩張圖分別是歷史時間窗口設定值為30min的(ins1,*,db1)的upsize指標mean&median時序圖和SD&MAD時序圖。可以清楚看到，當upsize指標發(fā)生波動后，mean值和標準差SD值都會發(fā)生窗口時間長度的跳變，但median和MAD卻幾乎不受指標波動的影響，顯得更平穩(wěn)、絲滑。

右上圖為（ins2,*,db2）的newConn指標時序圖，可以看到在03:40~04:00期間，指標發(fā)生異常，出現(xiàn)大量極端值，由于歷史的時間窗口設定值為30min，所以可以從左下的圖表中看到，很長一段時間內(nèi)樣本的均值和標準差便會發(fā)生較大的波動，而中位數(shù)和MAD指標卻顯得平滑，對極端值并不敏感，展出超強的魯棒性。由于依賴均值和標準差進行預測，control charts具有不穩(wěn)定性，易造成誤判。這啟發(fā)我們利用中位數(shù)和MAD替代均值和標準差作為預測模型參數(shù)。

如上圖所示，通過大量觀察，我們發(fā)現(xiàn)，按（*,*,db） 和(*,*,proxy) 粒度聚合后的采樣點集合近似正態(tài)分布。但是，正態(tài)分布依賴平均值和標準差作為參數(shù)，如上文所述，這兩個參數(shù)波動大，會造成嚴重誤判。鑒于柯西分布與正態(tài)分布相似，且不依賴均值和標準差，可以使用中位數(shù)和MAD這種穩(wěn)定的統(tǒng)計指標來進行回歸。從上上圖可以看到當歷史時間窗口長度設定合適的時候，中位數(shù)和MAD在面對指標波動和異常的情況下，顯得平滑且穩(wěn)定，這樣回歸出的模型具有更強的穩(wěn)定性。于是，我們使用中位數(shù)和MAD作為參數(shù)的回歸柯西分布來擬合異常診斷模型。

為了獲取回歸需要的樣本集，我們通過對過去一段時間（比如：最近一個小時）的每一個時間點做采樣，得到一段歷史窗口的數(shù)據(jù)點集合S{x0,x1,x2,……}。根據(jù)歷史窗口數(shù)據(jù)集，計算中位數(shù)M以及MAD，回歸出這個數(shù)據(jù)集的柯西概率分布D。

主機異常檢測

RDS主機上承載著眾多實例，各實例通常隸屬于不同用戶的不同業(yè)務。在主機正常工作時，由于實例相互獨立、并且對應的指標波動具有不確定性，所有實例呈現(xiàn)出一致性升高或降低的概率非常小。當主機發(fā)生異常時，由于該主機上的所有實例共享同一資源，某些關鍵指標會呈現(xiàn)出一致性趨勢。當一臺主機發(fā)生了IO Hang，主機上大部分實例的SQL處理延遲都呈現(xiàn)出升高的趨勢，各實例的數(shù)據(jù)寫入量呈現(xiàn)出下降的趨勢。這啟發(fā)我們利用實例趨勢一致性概率來判斷主機的異常。

首先，設定函數(shù)H(curentVal, prevMideanVal，metricType)作為判斷指標metric1是否異常的函數(shù),取值只能是－1，0，＋1。currentVal代表這一刻該指標的值，prevMideanVal代表過去一段時間（比如：1小時）采樣點集合的中位數(shù)，metricType代表該指標的類型（比如：rt，rtt，qps，流量等）。取值為－1代表這個指標在跟過去一段時間指標做對比的時候呈現(xiàn)出明顯下降的趨勢，0代表這個指標沒有明顯波動，＋1代表這個指標與過去一段時間相比明顯上升。

我們可以利用上文的算法來實現(xiàn)函數(shù)H，這樣我們能算出（ins,*,dstIp,metricType）級別數(shù)據(jù)的函數(shù)H值，然后在按(ins,*,dstIp,metricType)->(*,*, dstIp,metricType)做map－reduce（agg類型為sum）。算出的值s反映了這個指標在這臺主機上的突升，突降的趨勢，用求和值s除以這個主機上的活躍實例數(shù)t得出突升／突降實例比例r，當r大于0是，總體趨勢上升，當r小于0是，總體趨勢下降，且絕對值越大概率越大。

那么我們?nèi)绾卫胷值來判斷主機異常呢？如果機器突然由正常變?yōu)楫惓r，各實例由于都依賴這臺機器的資源進行工作，或多或少要受其影響，因此相關指標發(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范圍是負無窮到正無窮。我們需要對原來的比率r做轉化讓他的范圍擴充到正負無窮。通過定義的映射函數(shù)求出這一時刻下該指標的柯西概率分布的CDF()，如果CDF()非常小，比如小于0.1%，主機hostA的指標metric1呈現(xiàn)總體下降趨勢，或者非常大比如99.8%, 主機hostA的指標metric1呈現(xiàn)總體上升趨勢。 但是這樣做判斷，只是判斷出了r值的突升和突降，為了減少誤判，我們還要判斷出r值的突升和突降需要落到警戒范圍。因此需要一個必要條件：r值的絕對值至少為20％。

另外，當r值足夠高時，無論r值是否突升還是突降，都應該認為是異常，因此還需要一個充分條件：r值的絕對值大于AlarmRatio(主機上的活躍實例t),那么認為是異常。根據(jù)我們自己的實際情況，AlarmRatio(t)＝0.8*Pow(0.987, t) + 0.2. 曲線如圖，當主機上的活躍實例比較少時，AlarmRatio值比較高，這樣為了保證判斷出異常的主機上異常的實例足夠多，這樣才有較高的說服力，而隨著主機上活躍實例數(shù)變多，AlarmRatio值會相應得變小最后收斂到0.2，這樣為了不漏掉r比較少但是異常實例數(shù)足夠多的情況。

當r＝-1時，這臺機器hostA上所有的實例的指標metric1都出現(xiàn)了下降趨勢，當r=1時，hostA上所有實例的指標metric1都出現(xiàn)了上升趨勢。除了獨占實例，一臺主機上有數(shù)十甚至上百的實例，他們分屬不同的用戶，運行著不同的業(yè)務，呈現(xiàn)出一致的趨勢概率很小，因此在正常的時候r值往往穩(wěn)定在一個較低的范圍內(nèi)，當r值很高的時候，極有可能主機問題了。?

但是這樣的判斷還不夠，因為還存在這兩種情況：1. 實例之間公用的某個組件出現(xiàn)了異常。比如網(wǎng)絡中間件引起的異常，路由器的異常等等。也會引起r值變高；2.有的主機上因為實例數(shù)比較少（比如：小于3）時，單純根據(jù)比例判斷還分辨不出是否是主機的問題，因為樣本數(shù)太少，不具有說服力。針對這兩種情況，我們還用了多種方法來提高準確率，比如：

1.結合物理機的資源指標（load，iowait，dirty，writeback等）的加權和來協(xié)助判斷。2.如果存在上游節(jié)點（比如：proxy），并且上游節(jié)點存在異常，則優(yōu)先報上游節(jié)點的異常。因為上游節(jié)點往往還連接多個下游節(jié)點，如果是某個單獨的下游節(jié)點出現(xiàn)了異常，一般上游節(jié)點是不會出現(xiàn)異常的，因為上游節(jié)點上連接的下游節(jié)點很多，這一個點并不會明顯改變整體的指標趨勢變化，而某個節(jié)點的多個下游節(jié)點都出了問題，他們的上游節(jié)點出問題的概率更大一些。假設上游節(jié)點完全正常，下游節(jié)點近似相互獨立，一個節(jié)點出問題的概率為p，K各節(jié)點同時出問題的概率就是p^K,所以問題的原因很可能是概率更大的上游節(jié)點。

Proxy異常檢測

我們的大部分實例在訪問db前要經(jīng)過proxy的轉發(fā)，proxy可以幫用戶做短鏈接優(yōu)化，負載均衡，連接審計，注入檢測等。proxy是我們生產(chǎn)集群非常重要的組件，一個proxy節(jié)點最多會有上千個實例的請求（requests of thousands of instances）經(jīng)過。也就是說，如果一個proxy節(jié)點發(fā)生了故障，將會影響到上千個實例，這樣的故障我們需要快速準確地發(fā)現(xiàn)并定位出來，否則后果不敢想象。

我們一開始對proxy的qps，連接數(shù)等設定閾值的方式來進行報警，但是由于不同分組的proxy業(yè)務量大小不一樣，因此我們需要對不同分組設定不同的閾值，而且我們的業(yè)務增長迅速，proxy會經(jīng)常進行擴容，這樣閾值又要重新調(diào)整，維護起來費時費力。

我們雖然可以利用上邊所講的判斷db主機異常一樣的算法來判斷proxy異常，但是由于proxy的處理時間包含了db本地的處理時間，應用這種方式我們是無法評估出請求在單純在proxy中停留的時間。對于使用了proxy鏈路的用戶，由于在網(wǎng)絡中多了proxy轉發(fā)的代價，所以SQL請求的延時會稍微比不用proxy鏈路的請求要慢。因此為了不影響用戶的體驗，我們希望SQL請求在proxy節(jié)點中停留的時間越短越好。因此我們以SQL請求在proxy節(jié)點中停留和proxy與db之間的傳輸總時間prT(proxy relay time)作為衡量proxy服務質(zhì)量的重要指標。如果實例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)絡鏈路時間，t3是db1的本地處理時間，t4是db1到proxy1的網(wǎng)絡鏈路時間，t5是接受到db1端發(fā)的SQL應答到向client端發(fā)送的時間，t6是應答從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)絡傳輸?shù)目倳r間prT。

由于網(wǎng)絡延遲正常情況下在內(nèi)部網(wǎng)絡中比較穩(wěn)定的，如果diff1值變大了，多出的部分，往往是proxy節(jié)點貢獻的，因此我們可以大致通過diff1估計實例ins1在proxy1停留的的大致時間。對于經(jīng)過proxy的每個實例，如果prT>=ProxyRelayTimeLimit，則認為prT過大。我們算出proxy1上的各個實例的prT值，得到prT值過長的實例數(shù)量占proxy1上活躍實例數(shù)的比例r。我們可以根據(jù)r的突升和范圍來判斷proxy及下游網(wǎng)絡鏈路是否對用戶形成影響。 為了判斷r的突升，首先，利用上面判斷db主機異常的方法，回歸出這個數(shù)據(jù)集的柯西概率分布D。

因為比例r的取值是0～1，而柯西概率分布D的自變量x范圍是負無窮到正無窮。我們需要對原來的比率r做轉化讓他的范圍擴充到正負無窮。通過映射函數(shù)，我們求出這一時刻下該指標的柯西概率分布的CDF(x’)，由于r越小表明proxy越健康，所以只有當r>M是才會進一步判斷proxy是否異常，如果CDF(x’)非常大比如：大于99.8%, 說明比率r突然明顯上升，需要引起注意。為了減少誤判，我們還要判斷出r值的突升和突降需要落到警戒范圍。因此需要一個必要條件：r值的絕對值至少為20％。

不過如果r本身就很大的話比如：由于proxy升級到了一個有bug的版本上，所有的實例從新版本上線后就一直慢，由于數(shù)據(jù)集的中位數(shù)變成了100%，上面的方法就無法判斷了。我們還要再加個異常的充分條件，那就是：如果r>MaxRatio(比如：80%),就判斷為異常。使用回歸分布的方法適合當r發(fā)生巨變時來判斷異常，主要是為了找到proxy的急性病；而后加的判斷異常的充分條件適用于當r從一開始就不正常，或者r緩慢變成不正常的情況，是為了找到proxy的慢性病。

網(wǎng)絡異常檢測

為了容忍交換機單點故障，每個節(jié)點（代理節(jié)點和數(shù)據(jù)庫節(jié)點）會上聯(lián)到一對TOR交換機上。TOR中的高丟包率會導致大量TCP數(shù)據(jù)包重新傳輸，并導致查詢延遲變高、失敗連接增加，從而導致用戶數(shù)據(jù)庫性能下降。因此，在短時間內(nèi)，識別網(wǎng)絡故障并定位異常網(wǎng)絡設備，通過修復或者更換的方式去解決網(wǎng)絡異常是至關重要的。 通過TcpRT采集的TCP連接上亂序數(shù)據(jù)包，重傳數(shù)據(jù)包，RTT抖動和RST數(shù)據(jù)包的數(shù)量，可用于網(wǎng)絡故障排查。

如上圖所示，在分布式體系結構中，每個節(jié)點相互通信，比如，Proxy節(jié)點到數(shù)據(jù)庫節(jié)點的請求重定向。我們繪制一個二分圖來表示節(jié)點之間的關系，頂點是Proxy節(jié)點和正在通信的數(shù)據(jù)庫節(jié)點，如果兩個節(jié)點存在相互通信，那么這兩個節(jié)點存在一條鏈接邊。用虛線標記的鏈接表示在兩個節(jié)點之間觀察到大量網(wǎng)絡異常事件（無序，重傳等），否則我們使用實線代替。

根據(jù)主機到TOR交換機對的連接信息，通過把主機節(jié)點替換成相應的TOR交換機對，我們將上圖b轉換成上圖c。直觀上，相連虛線數(shù)越多的頂點異常可能性越高。因此，我們定義公式count^1.5/total來衡量TOR交換機對發(fā)生異常的概率，其中count表示虛線數(shù)，total表示線（虛+實）數(shù)。count^1.5/total值越大，該TOR交換機對越有可能是異常。

小結

到目前為止，TcpRT以每秒采集2千萬條原始trace數(shù)據(jù)、每天后臺處理百億吞吐數(shù)據(jù)、秒級檢測異常的卓越性能在阿里云持續(xù)穩(wěn)定運行三年。今年TcpRT的監(jiān)控能力將包裝成云產(chǎn)品開放給RDS客戶，給客戶提供更好的數(shù)據(jù)庫與應用診斷能力。在技術上，我們也在基于TcpRT開發(fā)更多的算法，發(fā)掘更多的異常行為。

論文作者：鳴嵩，劍川，冰豹，仲舉，淺清，望瀾，明書

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的从没想到监控可以这么做！阿里云RDS智能诊断系统首次公开的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。