《直擊傳統(tǒng)運(yùn)維痛點(diǎn),京東金融智能運(yùn)維初探!》要點(diǎn):
本文介紹了直擊傳統(tǒng)運(yùn)維痛點(diǎn),京東金融智能運(yùn)維初探!,希望對(duì)您有用。如果有疑問,可以聯(lián)系我們。
隨著互聯(lián)網(wǎng)+時(shí)代的到來,京東金融業(yè)務(wù)規(guī)模不斷擴(kuò)大,業(yè)務(wù)場(chǎng)景也不斷創(chuàng)新.但是,業(yè)務(wù)變化之快超乎想象,相應(yīng)的 SOA 及微服務(wù)架構(gòu)日趨深入,服務(wù)數(shù)量不斷膨脹,線上環(huán)境日益復(fù)雜,服務(wù)依賴關(guān)系每天都在變化.
面對(duì)上述難題,本文將從智能容量評(píng)估與智能告警切入,為大家分享京東金融的運(yùn)維實(shí)踐.
應(yīng)用的容量評(píng)估是一個(gè)老大難問題,目前也沒有一種簡(jiǎn)單而有效的方式,主要是通過壓測(cè)手段直接得到應(yīng)用單機(jī)最高 QPS 的相關(guān)數(shù)據(jù).
為了測(cè)試數(shù)據(jù)的相對(duì)真實(shí)性,在容量評(píng)估的線下壓測(cè)中一般通過 tcpcopy 等工具,將線上的流量直接復(fù)制到測(cè)試服務(wù)器,在測(cè)試服務(wù)器出現(xiàn)瓶頸時(shí)得到應(yīng)用最高的 QPS,再通過線上線下的換算系數(shù)推算出線上的應(yīng)用能承載的容量.
注:本圖片轉(zhuǎn)自tcpcopy官網(wǎng)
通過線下壓測(cè)的方式進(jìn)行容量評(píng)估的優(yōu)點(diǎn)是壓測(cè)過程對(duì)線上的環(huán)境幾乎沒有影響,但是過程比較繁瑣,耗時(shí)也較長(zhǎng).所以以短平快為主要特色的互聯(lián)網(wǎng)公司更鐘愛通過線上的壓測(cè)來進(jìn)行容量評(píng)估.
一般來說,不管是通過集中的負(fù)載設(shè)備(如 F5、Radware 等)或是四七層的軟負(fù)載(LVS、Nginx、HAProxy 等)亦或是開源的服務(wù)框架(如 Spring Cloud、DUBBO 等)都支持加權(quán)輪詢算法(Weighted Round Robin).簡(jiǎn)單的說就是在負(fù)載輪詢的時(shí)候,不同的服務(wù)器可以指定不同的權(quán)重.
線上壓測(cè)的原理就是逐漸加大某一臺(tái)服務(wù)器的權(quán)重,使這臺(tái)服務(wù)器的流量遠(yuǎn)大于其他服務(wù)器,直至該服務(wù)器出現(xiàn)性能瓶頸.這個(gè)瓶頸可能是 CPU、LOAD、內(nèi)存、帶寬等物理瓶頸,也可能是 RT、失敗率、QPS 波動(dòng)等軟瓶頸.
當(dāng)單機(jī)性能出現(xiàn)性能瓶頸時(shí),工程師記下此時(shí)的應(yīng)用 QPS 就是單機(jī)容量,然后根據(jù)集群服務(wù)器數(shù)量很容易得到集群的容量.
如下 Nginx 的配置,使得服務(wù)器 192.168.0.2 的流量是其他服務(wù)器的 5 倍,假設(shè)此時(shí)服務(wù)器 192.168.0.2 出現(xiàn)瓶頸,QPS 為 1000,那么集群容量為 3000.(假設(shè)負(fù)載沒有瓶頸)
http {
upstream cluster {
server 192.168.0.2 weight= 5;
server 192.168.0.3 weight= 1;
server 192.168.0.4 weight= 1;
}
}
不管是線上還是線下的壓測(cè),反映的都是壓測(cè)時(shí)的應(yīng)用容量.在互聯(lián)網(wǎng)快速發(fā)展的今天,程序版本迭代的速度驚人,針對(duì)每次版本的迭代、環(huán)境的變化都進(jìn)行一次線上的壓測(cè)是不現(xiàn)實(shí)的,也是不具備可操作性的.
那么換一種思路去思考,我們通過壓測(cè)去評(píng)估應(yīng)用的容量其實(shí)是因?yàn)槲覀儫o法知道具體的一個(gè)方法的耗時(shí)到底在哪里?也就是說被壓測(cè)的對(duì)象對(duì)我們是一個(gè)黑盒子,如果我們想辦法打開了這個(gè)黑盒子,理論上我們就有辦法計(jì)算應(yīng)用的容量,而且可以做到實(shí)時(shí)的應(yīng)用容量評(píng)估.
因此,迫切需要尋求另外一種解決問題的思路:QPS 的瓶頸到底是什么?如果弄清楚了這個(gè)問題,應(yīng)用的 QPS 就可以通過計(jì)算得到.
再結(jié)合下圖的耗時(shí)明細(xì)和應(yīng)用所處的運(yùn)行環(huán)境,我們就可以找到具體的瓶頸點(diǎn).
舉一個(gè)簡(jiǎn)單的例子:
如果一個(gè)方法在一定采樣時(shí)間內(nèi),平均 QPS 為 200,平均耗時(shí)為 100ms,耗時(shí)明細(xì)分析發(fā)現(xiàn)平均訪問數(shù)據(jù)庫 6 次,每次耗時(shí) 10ms,也就是數(shù)據(jù)庫總耗時(shí) 60ms,其他均為業(yè)務(wù)邏輯耗時(shí) 40ms.如何確定應(yīng)用的容量呢?
假如數(shù)據(jù)庫連接池的最大連接數(shù)為 30,執(zhí)行此方法的線程池最大為 50(簡(jiǎn)單起見暫時(shí)不考慮線程的切換成本),那么理論上數(shù)據(jù)庫的單機(jī)最高 QPS 為 30*1000/60=500.
同理業(yè)務(wù)邏輯的單機(jī)最高 QPS 為 50*1000/40=1250,顯然這個(gè)方法的瓶頸點(diǎn)在數(shù)據(jù)庫上,也就是這個(gè)方法的單機(jī)最高 QPS 為 500.
然后,針對(duì)這個(gè)方法進(jìn)行優(yōu)化,數(shù)據(jù)庫每次訪問的耗時(shí)降到了 5ms,平均訪問次數(shù)變成了 4 次,也就是數(shù)據(jù)庫總耗時(shí)為 20ms,業(yè)務(wù)邏輯耗時(shí)依然是 40ms,此時(shí)數(shù)據(jù)庫的單機(jī)最高 QPS 為 30*1000/20=1500.顯然此時(shí)的瓶頸點(diǎn)在業(yè)務(wù)邏輯上,也就是這個(gè)方法的單機(jī)最高 QPS 為 1250.
上例為一個(gè)方法的單機(jī)最高 QPS 推斷,結(jié)合其他方法做同理分析,依據(jù)計(jì)算出這個(gè)方法在整個(gè)應(yīng)用中對(duì)資源的占用比例就可以推算出整個(gè)應(yīng)用的單機(jī)最高 QPS.
進(jìn)一步分析,業(yè)務(wù)邏輯耗時(shí)也就是總耗時(shí)去除了 IO 的耗時(shí)(如 RPC 遠(yuǎn)程調(diào)用、訪問數(shù)據(jù)庫、讀寫磁盤耗時(shí)等等),業(yè)務(wù)邏輯耗時(shí)主要分為兩大部分:
通過對(duì)業(yè)務(wù)邏輯耗時(shí)的分類得知,真正消耗 CPU 資源的是線程運(yùn)行耗時(shí),那么問題就變成了我們?cè)趺茨玫竭\(yùn)行時(shí)間與等待時(shí)間的耗時(shí)比例了.
CPU 使用率(進(jìn)程、線程)可以通過 proc 虛擬文件系統(tǒng)得到,此處不是本文重點(diǎn),不展開討論.不同環(huán)境還可以通過不同的特性快速得到這些數(shù)據(jù).以 Java 應(yīng)用為例,我們可以從 JMX 中拿到線程執(zhí)行的統(tǒng)計(jì)情況,大致推算出上述的比例,如下圖所示:
繼續(xù)分析上面的例子,假設(shè)我們通過分析線程的運(yùn)行情況得知,運(yùn)行時(shí)間與等待時(shí)間為 1:1,此時(shí)進(jìn)程 CPU 的使用率為 20%,那么 CPU 指標(biāo)能支撐的單機(jī)最高 QPS 為 200 * 100% / 20% = 1000,也就是這個(gè)方法的單機(jī)最高 QPS 為 1000.同理可以推斷網(wǎng)絡(luò)帶寬等物理資源的瓶頸點(diǎn).
一般來說,業(yè)務(wù)邏輯耗時(shí)中,對(duì)于計(jì)算密集型的應(yīng)用,CPU 計(jì)算耗時(shí)的比例比較大,而 IO 密集型的應(yīng)用反之.
通過以上的數(shù)據(jù),我們就可以實(shí)時(shí)評(píng)估系統(tǒng)的容量,如下圖:
根源告警分析是基于網(wǎng)絡(luò)拓?fù)?結(jié)合調(diào)用鏈,通過時(shí)間相關(guān)性、權(quán)重、機(jī)器學(xué)習(xí)等算法,將告警進(jìn)行分類篩選,快速找到告警根源的一種方式.它能從大量的告警中找到問題的根源,因此大大縮短了故障排查及恢復(fù)時(shí)間.
告警處理步驟
舉例來說:
假設(shè)多個(gè)系統(tǒng)通過 RPC 進(jìn)行服務(wù)調(diào)用,調(diào)用關(guān)系如下:D 系統(tǒng)->C 系統(tǒng)-> B 系統(tǒng)-> A 系統(tǒng).
當(dāng) A 系統(tǒng)查詢數(shù)據(jù)庫出現(xiàn)查詢超時(shí)后,告警會(huì)層層往前推進(jìn),導(dǎo)致 B、C、D 系統(tǒng)均有 N 個(gè)超時(shí)告警產(chǎn)生.此時(shí),ROOT 分析可以將告警進(jìn)行收斂,直接分析出根源告警為 A 系統(tǒng)訪問數(shù)據(jù)庫異常,導(dǎo)致 A、B、C、D 多個(gè)系統(tǒng)異常.
這樣,就避免了處理人員和每個(gè)系統(tǒng)開發(fā)人員溝通,輔助處理人員快速定位問題根源、提高了平均解決時(shí)間(MTTR).如下圖所示:
根源告警調(diào)用鏈關(guān)系
根源告警明細(xì)表?
根源告警分析主要分為強(qiáng)關(guān)聯(lián)分析與機(jī)器學(xué)習(xí)兩類.
強(qiáng)關(guān)聯(lián)指的是已知確定的關(guān)聯(lián)關(guān)系.如:
若在同一個(gè)時(shí)間窗內(nèi),有多個(gè)強(qiáng)關(guān)聯(lián)的設(shè)備或應(yīng)用服務(wù)器同時(shí)告警,則大概率認(rèn)為告警之間存在關(guān)聯(lián)關(guān)系.
在權(quán)重算法中,有一個(gè)重要的規(guī)則,鏈路上存在連續(xù)的告警可能存在關(guān)聯(lián),越靠后的應(yīng)用越可能是根源.現(xiàn)在我們根據(jù)例子,分別計(jì)算各類根源告警.
繼續(xù)使用上面的例子,D 應(yīng)用->C 應(yīng)用->B 應(yīng)用->A 應(yīng)用->數(shù)據(jù)庫異常的情況.
根據(jù)權(quán)重計(jì)算規(guī)則,數(shù)據(jù)庫告警為 90,GC 告警 10,也就是說數(shù)據(jù)庫異常告警權(quán)重最高.這時(shí)由于數(shù)據(jù)庫根源告警和調(diào)用鏈根源告警一致,會(huì)將兩種類型的告警合并.最后得出結(jié)論:數(shù)據(jù)庫異常導(dǎo)致 A、B、C、D 系統(tǒng)告警.
強(qiáng)關(guān)聯(lián)數(shù)據(jù)分析是對(duì)已知告警的關(guān)聯(lián)關(guān)系,直接進(jìn)行根源告警分析.但是有些時(shí)候,關(guān)聯(lián)關(guān)系是未知的.這時(shí)就需要通過機(jī)器學(xué)習(xí)算法,找到告警之間的隱含聯(lián)系,再進(jìn)行根源告警預(yù)測(cè).
目前,主要進(jìn)行了兩類機(jī)器學(xué)習(xí)實(shí)踐.
1、關(guān)聯(lián)規(guī)則算法
關(guān)聯(lián)規(guī)則算法主要進(jìn)行了 Apriori 算法和 FPGrowth 兩類算法的實(shí)踐.這兩類功能相似,都可以發(fā)現(xiàn)頻繁項(xiàng)集.經(jīng)過實(shí)測(cè),FPGrowth 比 Apriori 更高效一些.
我們按一定的時(shí)間間隔劃分時(shí)間窗,計(jì)算每個(gè)時(shí)間窗內(nèi),各種告警一起出現(xiàn)的頻率,找出各類告警之間的關(guān)聯(lián).最終可按分析出的關(guān)聯(lián)關(guān)系,生成根源告警.
關(guān)聯(lián)規(guī)則算法的優(yōu)點(diǎn)在于理解和實(shí)現(xiàn)起來比較簡(jiǎn)單.缺點(diǎn)是效率比較低,靈活度也不夠高.
2、神經(jīng)網(wǎng)絡(luò)算法
循環(huán)神經(jīng)網(wǎng)絡(luò)(簡(jiǎn)稱 RNN)是一個(gè)和時(shí)間序列有關(guān)系的神經(jīng)網(wǎng)絡(luò),對(duì)單張圖片而言,像素信息是靜止的,而對(duì)于一段話而言,里面的詞的組成是有先后的,而且通常情況下,后續(xù)的詞和前面的詞有順序關(guān)聯(lián).
這時(shí)候,卷積神經(jīng)網(wǎng)絡(luò)通常很難處理這種時(shí)序關(guān)聯(lián)信息,而 RNN 卻能有效地進(jìn)行處理.
隨著時(shí)間間隔的增大,RNN 對(duì)于后面時(shí)間的節(jié)點(diǎn)相比前面時(shí)間節(jié)點(diǎn)的感知力將下降.解決這個(gè)問題需要用到 LongShort Term 網(wǎng)絡(luò)(簡(jiǎn)稱 LSTM),它通過刻意的設(shè)計(jì)來避免長(zhǎng)期依賴問題.LSTM 在實(shí)踐中默認(rèn)可以記住長(zhǎng)期的信息,而不需要付出很大代價(jià).
對(duì)于某類故障引起的大量告警之間,存在著時(shí)間相關(guān)性.將歷史派生告警作為輸入,將根源告警類型作為輸出.通過 LSTM 提取派生告警特征,建立告警相關(guān)性分析模型.這樣就可以實(shí)時(shí)將符合特征的派生告警,劃分到同一類根源告警中,幫助用戶快速定位問題.
需要說明的是金融本身的業(yè)務(wù)特點(diǎn)決定了對(duì)第三方存在依賴性,因此告警本身的隨機(jī)性較大,客觀上導(dǎo)致學(xué)習(xí)樣本的質(zhì)量不高,需要長(zhǎng)期的積累和修正才能達(dá)到比較好的效果,因此對(duì)于根源告警,如果有條件取到強(qiáng)關(guān)聯(lián)關(guān)系,建議使用強(qiáng)關(guān)聯(lián)分析,能達(dá)到事半功倍的效果.
智能運(yùn)維是目前運(yùn)維領(lǐng)域被炒得最火的詞匯之一,但是個(gè)人認(rèn)為沒有一個(gè)智能運(yùn)維的產(chǎn)品是放之四海而皆準(zhǔn),智能運(yùn)維需要在真實(shí)的環(huán)境中不斷的磨合,才能達(dá)到我們預(yù)期的效果.
隨著人工智能在運(yùn)維領(lǐng)域的不斷嘗試與探索,未來在運(yùn)維領(lǐng)域中的異常檢測(cè)與智能報(bào)警及自動(dòng)化容量規(guī)劃與分配必將得到快速的發(fā)展,從而成為運(yùn)維的核心競(jìng)爭(zhēng)力.
原文來自:51CTO技術(shù)棧
作者:沈建林,京東金融集團(tuán)資深架構(gòu)師,曾在多家知名第三方支付公司任職系統(tǒng)架構(gòu)師,致力于基礎(chǔ)中間件與支付核心平臺(tái)的研發(fā),主導(dǎo)過 RPC 服務(wù)框架、數(shù)據(jù)庫分庫分表、統(tǒng)一日志平臺(tái),分布式服務(wù)跟蹤、流程編排等一系列中間件的設(shè)計(jì)與研發(fā),參與過多家支付公司支付核心系統(tǒng)的建設(shè).現(xiàn)任京東金融集團(tuán)資深架構(gòu)師,負(fù)責(zé)基礎(chǔ)開發(fā)部基礎(chǔ)中間件的設(shè)計(jì)和研發(fā)工作.擅長(zhǎng)基礎(chǔ)中間件設(shè)計(jì)與開發(fā),關(guān)注大型分布式系統(tǒng)、JVM 原理及調(diào)優(yōu)、服務(wù)治理與監(jiān)控等領(lǐng)域.
轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址:
http://www.fzlkiss.com/jiaocheng/2383.html