随着企業上雲趨勢的日益熱化，作為産業核心元件的資料庫，已成為各大雲計算公司增長最快的線上服務業務。作為中國第一大雲資料庫廠商，我們RDS團隊緻力于為使用者提供穩定的雲資料庫服務。從本質上看，RDS是一個多租戶DBaaS平台，利用輕量級KVM、Docker鏡像等資源隔離技術将使用者所購買的資料庫執行個體部署在實體機上，按需配置設定資源并進行自動升降級，實作一套完全自動化的智能運維管理。
雲資料庫對客戶業務的穩定性至關重要，是以快速發現雲資料庫性能出現異常，及時定位異常原因是雲資料庫廠商的一個挑戰。TcpRT是阿裡雲資料庫用來監控和診斷資料庫服務品質的一個基礎設施。TcpRT從主機TCP/IP協定棧的壅塞控制采集trace資料，計算資料庫延遲和網絡異常，在背景流式計算平台進行大規模實時資料分析和聚合，通過統計名額曆史資料的柯西分布發現異常點，并通過同一台主機、交換機、proxy下所有執行個體一緻性趨勢的比例來計算不同元件發生異常的機率。
到目前為止，TcpRT以每秒采集2千萬條原始trace資料、每天背景處理百億吞吐資料、秒級檢測異常的卓越性能在阿裡雲持續穩定運作三年。
本文貢獻：
我們提出了一個新的算法對TcpRT資料進行分析，來發現資料庫的服務品質有無異常，并且對異常事件的根因進行定位。
問題
從網絡架構上看，RDS由控制層和資料鍊路層兩個部分組成，如上圖所示。其中，控制層包括一系列管理子產品，比如資料總管，HA管理器，遷移管理器等。資料總管負責将執行個體的不同副本配置設定在獨立的實體主機上。當執行個體發生故障時，HA管理器會探測到主執行個體的故障，并将服務連接配接切換到Standby節點上。而當主機負載失衡時，遷移管理器負責将資料庫執行個體進行遷移，保障使用者服務品質。
資料鍊路層主要負責資料的分發和路由。通常，雲使用者通過ECS和RDS實作業務上雲。他們将業務部署在ECS上，并通過VPC和RDS資料庫執行個體進行互動。資料包通過駐留在使用者VPC網絡中的vSwitch進行打包／解包并路由。而SLB負責将這些資料包進行解析，并将DBaaS IP映射到真實伺服器上。目前，SLB同時支援FNAT和DNAT兩種模式。由于出流量資料不經過SLB， DNAT比FNAT呈現出更好的性能。除此之外，我們引入NGLB進行優化。在Proxy中，我們解析用戶端/服務端協定，并提取查詢，将讀寫進行分離，同時支援橫向分區和連接配接池的功能。
作為客戶業務的核心元件，保障雲資料庫7/24的穩定至關重要。我們通過對使用者承諾資料庫SLA服務等級協定，來保障使用者的權益。然而，雲資料庫的服務品質受各種因素影響，例如突發性連接配接斷開、資料庫延遲發生抖動、吞吐驟然下降等，都有可能帶來使用者業務名額的下降。是以，快速發現雲資料庫性能異常，及時定位根因是雲資料庫廠商的一個挑戰。
可能造成雲資料庫的服務品質下降的原因很多，例如網絡上的異常，比如DB主機的上聯交換機tor發生丢包，或者load balaner出現TCP incast問題；或者使用者側的問題，使用者端網絡異常或者丢包；或者多租戶機制，DB主機核心缺陷、硬體上SSD的硬體異常等等都會引起。在出現問題時，快速診斷定位解決問題是關鍵的問題。
傳統資料庫性能采集隻需要采集DBMS内部處理SQL請求的延遲就夠了，但雲資料庫需要end-end資料。因為對雲上使用者而言，他看到的雲資料庫的延遲是終端的延遲。真實的場景對trace工具提出這些需求，是以很關鍵的是要采集end-to-end資料，以及鍊路每段的延遲，終端使用者感受到的延遲是所有路徑上每個節點處理延遲以及網絡上所有延遲的總和，不僅僅要采集DB上的延遲，還要采集proxy上看到的延遲。這需要在鍊路上引入trace。還要采集網絡上的資料，主機上其實可以看到的上行亂序和下行的重傳，這個資訊對推測網絡有無異常非常重要。發送和接收會走不同的網絡路徑。
傳統的trace手段需要入侵式地在業務代碼中添加埋點。第一，我們不能在用戶端埋點，因為客戶基本上都使用标準資料庫用戶端來通路，沒有嵌入打點代碼，我們也不能期望客戶會修改自己的業務代碼，加入打點邏輯，并将打點資料采集交給我們。是以我們需要一種非侵入式的方法來擷取end-to-end性能資料。第二在伺服器端埋點也有問題，應用層無法感覺真正的資料接收和發送時間。應用層記錄的時間是核心把資料傳遞給應用層和應用層把資料傳遞給核心的時間。在系統負載很高，應用層程序排程需要花費大量時間的場景下，會導緻請求的實際處理時間計算不準确；應用層無法感覺到網絡鍊路品質。在網絡出現擁塞，大量的重傳封包，導緻資料發送和接收過程大大延長，無法區分出是對端響應緩慢還是網絡鍊路品質不佳。
在這種挑戰下，TcpRT——阿裡雲資料庫監控和診斷服務品質系統，孕育而生。
TcpRT從主機TCP/IP協定棧的擁塞控制采集trace資料，用于監測資料庫延遲和網絡異常，并利用先進的流技術，在背景實時計算平台上進行大規模線上資料分析，結合離線模型，通過實時異常事件判定，以及RDS網絡關系圖譜中的趨勢一緻性機率探測，快速診斷出性能異常并定位原因。
架構
上圖是TcpRT的概要架構圖，其中包含以下個元件：
線上異常監測——根據時序名額資料，拟合異常模型，通過實時異常事件判定，以及RDS網絡關系圖譜中的趨勢一緻性機率探測，快速診斷出性能異常并定位原因
TcpRT核心子產品
核心子產品主要負責對網絡資料的傳輸進行整個生命周期的監控。在遵守停等協定的TCP通信機制下，服務端處理每個請求的過程分成3個階段，接收階段(Receive)、處理階段(Handle)和響應階段(Response)。如下圖所示：
鑒于此，我們需要計算如下時間：
上行時間 = T1 - T0
處理時間 = T2 - T1
下行時間 = T3 - T2
查詢時間 = T3 - T0
RTT時間 = T2 - T2'
現有的監控方案，通常在業務層面埋點進行服務耗時監控，但此方法既不能獲得真正的資料接收和發送時間、也無法感覺到網絡鍊路的品質，更需要在業務代碼中入侵式地添加埋點。是以，我們實作了一種通用、低開銷的核心子產品進行trace監控以得到上述時間。
首先，我們選擇修改Linux核心的擁塞控制算法。此算法可以感覺核心發送封包的上下文，并且支援熱更新（隻需增加一個驅動子產品而無需更新線上核心）。
此外，擁塞控制算法提供了以下機制：
1. 每個TCP通信是獨立的擁塞控制算法，不存在資源競争情況
2. 可以感覺到收到的每個ACK封包的上下文
3. 在已經發送的封包都已經被ACK的情況下，可以感覺到目前發送的封包上下文
根據擁塞控制算法提供的事件回調，我們可以擷取到每個TCP連接配接下述事件：
1. 用戶端發送給服務端ACK封包
2. 在所有已經發出去的sequence都被确認的情況下，服務端發送封包
3. TCP連接配接建立
4. TCP連接配接斷開
核心任何線程都可能調用到擁塞控制算法，是以為了性能，擁塞控制算法必須保證是沒有資料争搶的。TcpRT核心子產品保證了以下四點：
1. TcpRT所有的資料儲存在每個TCP連接配接對象上，所有的資料讀寫都沒有跨TCP連接配接的共享；
2. TcpRT在每個CPU core都有獨立的寫緩沖區，防止了多個核心線程争搶寫緩沖區加鎖；
3. 為了避免記憶體開銷，又保證明時性，TcpRT的寫緩沖區會在buffer滿或者時間到的情況下，重新整理寫緩沖區到debugfs，供應用層采集端采集。由于寫debugfs的頻率很低，debugfs的鎖争搶幾乎不存在，最大限度保證了性能；
4. TcpRT回寫的資料，是binary格式的，對比需要format的字元格式，在實測場景可以提高20%的性能。
此外，通過給linux核心添加setsockopt選項，通知核心一個不需要應答的請求互動過程已經結束，進而支援非停等協定。
針對TcpRT核心子產品對使用者資料庫執行個體的性能影響，我們基于sysbench模拟了MySQL 400個用戶端連接配接進行壓測，結果如下圖所示，TcpRT核心子產品對系統的負載影響不到1%。
TcpRT聚合器
TcpRT核心子產品，利用debugfs和使用者态通信。每秒以千萬的trace資料高速産出并吐入至debugfs中。為了減輕背景線上分析任務的壓力，我們建構本地TcpRT聚合器，實作本地trace秒級聚合，并将聚合結果輸出到/dev/shm中。Logagent從中讀取聚合資料，發送至Kafka，并由背景ETL接手，進行實時資料分析，流程如下圖所示：
在本地聚合器中，聚合操作需要保證可交換且可結合，我們采用均值、最大值、請求個數的三元組聚合方法來保證延遲時間類名額滿足這一要求。此外，我們采用每秒同用戶端出現的不同端口數對活躍連接配接數進行名額特征提取。同時，抽取請求數作為特征，建立使用者長短連接配接的使用模型，進而對使用者使用資料庫執行個體的負載模式進行分析。根據曆史資料，目前仍有衆多使用者采用短連接配接模式，這對于諸如MySQL線程網絡模型的DB是非常不友好的，進而激發我們提供Proxy中間件将短連接配接轉換為長連接配接服務。
為了最大化聚合效果，我們在記憶體中維護最近5s的聚合結果，将5s前的資料輸出到/dev/shm的檔案中。且為了提高查詢性能以及長時間段的聚合操作，我們将三種粒度1s, 5s, 1m的聚合結果存入到庫中。
TcpRT ETL
下圖描繪了ETL任務的拓撲結構：
以及延遲和亂序處理
其中，延遲和亂序到達的處理是一個難點。TcpRT輸出的時序資料是以SQL執行結束時間為時間戳，如何做到實時準确地對視窗内的時序資料進行聚合并将結果刷出是一個兩難的問題。我們采用了“盡力聚合”的方法，即對視窗設定等待時間，待時間結束後将實時聚合結果刷出，若此後，還有該視窗的時序資料到來，則直接落入到資料庫中。如TcpRT聚合器中所述，所有聚合資料具有可再結合特性，這樣，我們可以對同時刻的聚合資料進行二次聚合。
線上異常監測
元件的異常往往伴随着相關名額的抖動。比如主機發生IO Hang後，load、dirty、writeback、某些core的iowait、被阻塞的線程數等名額會明顯升高，而各執行個體的write，CPU使用率會明顯變低，主機次元的PT名額會明顯升高。在部分情況下，連接配接數會上升，長連接配接請求數會下降，流量會下降等。在Proxy發生異常的時候，PT可能會升高、CPU、流量、連接配接數均可能會下降。
傳統方法下，我們通過設定門檻值進行名額抖動的檢測。然而門檻值的設定強依賴于專家經驗，維護成本高，且一刀切的設定常常會“誤傷”健康名額。比如，有些資料庫執行個體是專門用于OLAP，它們的SQL請求處理時間往往都是秒級的，若采用常用的SQL請求處理時間作為異常判定門檻值，此類資料庫執行個體就會觸發報警。
鑒于此，我們需要一種通用且自适應的智能模型來解決雲資料庫的異常監測。
為了避免人工設定門檻值，我們一開始嘗試利用control charts來進行判斷，根據樣本時間段的均值和标準差，預測未來時間段的置信區間。若實際值超出置信區間，則判定為異常。然而，若樣本本身為異常，則此時間段的參數均不可信。
如上圖，左上圖為(ins1,*,db1)的upsize名額時序圖，可以看到(ins1,*,db1)的upsize名額會有周期性的波動。左下的兩張圖分别是曆史時間視窗設定值為30min的(ins1,*,db1)的upsize名額mean&median時序圖和SD&MAD時序圖。可以清楚看到，當upsize名額發生波動後，mean值和标準差SD值都會發生視窗時間長度的跳變，但median和MAD卻幾乎不受名額波動的影響，顯得更平穩、絲滑。
右上圖為（ins2,*,db2）的newConn名額時序圖，可以看到在03:40~04:00期間，名額發生異常，出現大量極端值，由于曆史的時間視窗設定值為30min，是以可以從左下的圖表中看到，很長一段時間内樣本的均值和标準差便會發生較大的波動，而中位數和MAD名額卻顯得平滑，對極端值并不敏感，展出超強的魯棒性。由于依賴均值和标準差進行預測，control charts具有不穩定性，易造成誤判。這啟發我們利用中位數和MAD替代均值和标準差作為預測模型參數。
如上圖所示，通過大量觀察，我們發現，按（*,*,db） 和(*,*,proxy) 粒度聚合後的采樣點集合近似正态分布。但是，正态分布依賴平均值和标準差作為參數，如上文所述，這兩個參數波動大，會造成嚴重誤判。鑒于柯西分布與正态分布相似，且不依賴均值和标準差，可以使用中位數和MAD這種穩定的統計名額來進行回歸。從上上圖可以看到當曆史時間視窗長度設定合适的時候，中位數和MAD在面對名額波動和異常的情況下，顯得平滑且穩定，這樣回歸出的模型具有更強的穩定性。于是，我們使用中位數和MAD作為參數的回歸柯西分布來拟合異常診斷模型。
為了擷取回歸需要的樣本集，我們通過對過去一段時間（比如：最近一個小時）的每一個時間點做采樣，得到一段曆史視窗的資料點集合S{x0,x1,x2,……}。根據曆史視窗資料集，計算中位數M以及MAD，回歸出這個資料集的柯西機率分布D。
主機異常檢測
RDS主機上承載着衆多執行個體，各執行個體通常隸屬于不同使用者的不同業務。在主機正常工作時，由于執行個體互相獨立、并且對應的名額波動具有不确定性，所有執行個體呈現出一緻性升高或降低的機率非常小。當主機發生異常時，由于該主機上的所有執行個體共享同一資源，某些關鍵名額會呈現出一緻性趨勢。當一台主機發生了IO Hang，主機上大部分執行個體的SQL處理延遲都呈現出升高的趨勢，各執行個體的資料寫入量呈現出下降的趨勢。這啟發我們利用執行個體趨勢一緻性機率來判斷主機的異常。
首先，設定函數H(curentVal, prevMideanVal，metricType)作為判斷名額metric1是否異常的函數,取值隻能是－1，0，＋1。currentVal代表這一刻該名額的值，prevMideanVal代表過去一段時間（比如：1小時）采樣點集合的中位數，metricType代表該名額的類型（比如：rt，rtt，qps，流量等）。取值為－1代表這個名額在跟過去一段時間名額做對比的時候呈現出明顯下降的趨勢，0代表這個名額沒有明顯波動，＋1代表這個名額與過去一段時間相比明顯上升。
我們可以利用上文的算法來實作函數H，這樣我們能算出（ins,*,dstIp,metricType）級别資料的函數H值，然後在按(ins,*,dstIp,metricType)->(*,*, dstIp,metricType)做map－reduce（agg類型為sum）。算出的值s反映了這個名額在這台主機上的突升，突降的趨勢，用求和值s除以這個主機上的活躍執行個體數t得出突升／突降執行個體比例r，當r大于0是，總體趨勢上升，當r小于0是，總體趨勢下降，且絕對值越大機率越大。
那麼我們如何利用r值來判斷主機異常呢？如果機器突然由正常變為異常時，各執行個體由于都依賴這台機器的資源進行工作，或多或少要受其影響，是以相關名額發生突變的執行個體比例将會發生突變，比如主機上cpu資源突然不足，大部分執行個體都會受影響，他們的處理時間會突升，流量突降，請求數突降，是以可以通過判斷r值是否突變來判斷主機異常。
我們可以利用上文的算法來對r值的突變進行判斷，對過去一段時間的每一個時間點都做這樣的計算，我們可以得到一段曆史視窗的突升／突降執行個體比例r行程的資料點集合S{R0,R1,R2,…}。根據曆史視窗資料集，我們算出資料集的中位數M，以及MAD值，回歸出這個資料集的柯西機率分布D。
因為比例r的取值是－1～1，而柯西機率分布D的自變量x範圍是負無窮到正無窮。我們需要對原來的比率r做轉化讓他的範圍擴充到正負無窮。通過定義的映射函數求出這一時刻下該名額的柯西機率分布的CDF()，如果CDF()非常小，比如小于0.1%，主機hostA的名額metric1呈現總體下降趨勢，或者非常大比如99.8%, 主機hostA的名額metric1呈現總體上升趨勢。 但是這樣做判斷，隻是判斷出了r值的突升和突降，為了減少誤判，我們還要判斷出r值的突升和突降需要落到警戒範圍。是以需要一個必要條件：r值的絕對值至少為20％。
另外，當r值足夠高時，無論r值是否突升還是突降，都應該認為是異常，是以還需要一個充分條件：r值的絕對值大于AlarmRatio(主機上的活躍執行個體t),那麼認為是異常。根據我們自己的實際情況，AlarmRatio(t)＝0.8*Pow(0.987, t) + 0.2. 曲線如圖，當主機上的活躍執行個體比較少時，AlarmRatio值比較高，這樣為了保證判斷出異常的主機上異常的執行個體足夠多，這樣才有較高的說服力，而随着主機上活躍執行個體數變多，AlarmRatio值會相應得變小最後收斂到0.2，這樣為了不漏掉r比較少但是異常執行個體數足夠多的情況。
當r＝-1時，這台機器hostA上所有的執行個體的名額metric1都出現了下降趨勢，當r=1時，hostA上所有執行個體的名額metric1都出現了上升趨勢。除了獨占執行個體，一台主機上有數十甚至上百的執行個體，他們分屬不同的使用者，運作着不同的業務，呈現出一緻的趨勢機率很小，是以在正常的時候r值往往穩定在一個較低的範圍内，當r值很高的時候，極有可能主機問題了。
但是這樣的判斷還不夠，因為還存在這兩種情況：1. 執行個體之間公用的某個元件出現了異常。比如網絡中間件引起的異常，路由器的異常等等。也會引起r值變高；2.有的主機上因為執行個體數比較少（比如：小于3）時，單純根據比例判斷還分辨不出是否是主機的問題，因為樣本數太少，不具有說服力。針對這兩種情況，我們還用了多種方法來提高準确率，比如：
1.結合實體機的資源名額（load，iowait，dirty，writeback等）的權重和來協助判斷。2.如果存在上遊節點（比如：proxy），并且上遊節點存在異常，則優先報上遊節點的異常。因為上遊節點往往還連接配接多個下遊節點，如果是某個單獨的下遊節點出現了異常，一般上遊節點是不會出現異常的，因為上遊節點上連接配接的下遊節點很多，這一個點并不會明顯改變整體的名額趨勢變化，而某個節點的多個下遊節點都出了問題，他們的上遊節點出問題的機率更大一些。假設上遊節點完全正常，下遊節點近似互相獨立，一個節點出問題的機率為p，K各節點同時出問題的機率就是p^K,是以問題的原因很可能是機率更大的上遊節點。
Proxy異常檢測
我們的大部分執行個體在通路db前要經過proxy的轉發，proxy可以幫使用者做短連結優化，負載均衡，連接配接審計，注入檢測等。proxy是我們生産叢集非常重要的元件，一個proxy節點最多會有上千個執行個體的請求（requests of thousands of instances）經過。也就是說，如果一個proxy節點發生了故障，将會影響到上千個執行個體，這樣的故障我們需要快速準确地發現并定位出來，否則後果不敢想象。
我們一開始對proxy的qps，連接配接數等設定門檻值的方式來進行報警，但是由于不同分組的proxy業務量大小不一樣，是以我們需要對不同分組設定不同的門檻值，而且我們的業務增長迅速，proxy會經常進行擴容，這樣門檻值又要重新調整，維護起來費時費力。
我們雖然可以利用上邊所講的判斷db主機異常一樣的算法來判斷proxy異常，但是由于proxy的處理時間包含了db本地的處理時間，應用這種方式我們是無法評估出請求在單純在proxy中停留的時間。對于使用了proxy鍊路的使用者，由于在網絡中多了proxy轉發的代價，是以SQL請求的延時會稍微比不用proxy鍊路的請求要慢。是以為了不影響使用者的體驗，我們希望SQL請求在proxy節點中停留的時間越短越好。是以我們以SQL請求在proxy節點中停留和proxy與db之間的傳輸總時間prT(proxy relay time)作為衡量proxy服務品質的重要名額。如果執行個體ins1的請求在proxy節點的prT>=ProxyRelayTimeLimit，對于該請求，proxy代價時間過長。
由于有現成的生産叢集上proxy節點和db節點都安裝了tcprt核心驅動，我們打算proxy節點和db節點的tcprt資料來做類似的工作。
如圖是ins1，ins2的SQL請求在proxy節點和db節點上的鍊路活動圖。 ins1執行個體的一次請求時間rt1＝ t0+ t1 + t2 + t3 + t4 + t5 + t6, 其中t0是SQL請求從client端到proxy端傳輸的時間， t1是接收client端發的請求到向db端發送所需的時間，t2是proxy1到db1的網絡鍊路時間，t3是db1的本地處理時間，t4是db1到proxy1的網絡鍊路時間，t5是接受到db1端發的SQL應答到向client端發送的時間，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節點中停留和proxy與db之間網絡傳輸的總時間prT。
由于網絡延遲正常情況下在内部網絡中比較穩定的，如果diff1值變大了，多出的部分，往往是proxy節點貢獻的，是以我們可以大緻通過diff1估計執行個體ins1在proxy1停留的的大緻時間。對于經過proxy的每個執行個體，如果prT>=ProxyRelayTimeLimit，則認為prT過大。我們算出proxy1上的各個執行個體的prT值，得到prT值過長的執行個體數量占proxy1上活躍執行個體數的比例r。我們可以根據r的突升和範圍來判斷proxy及下遊網絡鍊路是否對使用者形成影響。 為了判斷r的突升，首先，利用上面判斷db主機異常的方法，回歸出這個資料集的柯西機率分布D。
因為比例r的取值是0～1，而柯西機率分布D的自變量x範圍是負無窮到正無窮。我們需要對原來的比率r做轉化讓他的範圍擴充到正負無窮。通過映射函數，我們求出這一時刻下該名額的柯西機率分布的CDF(x’)，由于r越小表明proxy越健康，是以隻有當r>M是才會進一步判斷proxy是否異常，如果CDF(x’)非常大比如：大于99.8%, 說明比率r突然明顯上升，需要引起注意。為了減少誤判，我們還要判斷出r值的突升和突降需要落到警戒範圍。是以需要一個必要條件：r值的絕對值至少為20％。
不過如果r本身就很大的話比如：由于proxy更新到了一個有bug的版本上，所有的執行個體從新版本上線後就一直慢，由于資料集的中位數變成了100%，上面的方法就無法判斷了。我們還要再加個異常的充分條件，那就是：如果r>MaxRatio(比如：80%),就判斷為異常。使用回歸分布的方法适合當r發生巨變時來判斷異常，主要是為了找到proxy的急性病；而後加的判斷異常的充分條件适用于當r從一開始就不正常，或者r緩慢變成不正常的情況，是為了找到proxy的慢性病。
網絡異常檢測
為了容忍交換機單點故障，每個節點（代理節點和資料庫節點）會上聯到一對TOR交換機上。TOR中的高丢包率會導緻大量TCP資料包重新傳輸，并導緻查詢延遲變高、失敗連接配接增加，進而導緻使用者資料庫性能下降。是以，在短時間内，識别網絡故障并定位異常網絡裝置，通過修複或者更換的方式去解決網絡異常是至關重要的。 通過TcpRT采集的TCP連接配接上亂序資料包，重傳資料包，RTT抖動和RST資料包的數量，可用于網絡故障排查。
如上圖所示，在分布式體系結構中，每個節點互相通信，比如，Proxy節點到資料庫節點的請求重定向。我們繪制一個二分圖來表示節點之間的關系，頂點是Proxy節點和正在通信的資料庫節點，如果兩個節點存在互相通信，那麼這兩個節點存在一條連結邊。用虛線标記的連結表示在兩個節點之間觀察到大量網絡異常事件（無序，重傳等），否則我們使用實線代替。
根據主機到TOR交換機對的連接配接資訊，通過把主機節點替換成相應的TOR交換機對，我們将上圖b轉換成上圖c。直覺上，相連虛線數越多的頂點異常可能性越高。是以，我們定義公式count^1.5/total來衡量TOR交換機對發生異常的機率，其中count表示虛線數，total表示線（虛+實）數。count^1.5/total值越大，該TOR交換機對越有可能是異常。
小結
到目前為止，TcpRT以每秒采集2千萬條原始trace資料、每天背景處理百億吞吐資料、秒級檢測異常的卓越性能在阿裡雲持續穩定運作三年。今年TcpRT的監控能力将包裝成雲産品開放給RDS客戶，給客戶提供更好的資料庫與應用診斷能力。在技術上，我們也在基于TcpRT開發更多的算法，發掘更多的異常行為。
原文釋出時間為：2018-05-21
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。