隨著智慧運(yùn)維平臺(tái)的不斷落地,我們基于平臺(tái)能力,落地了很多場(chǎng)景,監(jiān)控、告警、運(yùn)維操作等等,但我們的監(jiān)控場(chǎng)景與運(yùn)維操作場(chǎng)景依然還是分段式的,平臺(tái)監(jiān)測(cè)到故障告警,依舊需要運(yùn)維人員根據(jù)告警內(nèi)容去判斷執(zhí)行相對(duì)應(yīng)的運(yùn)維操作。
如何將監(jiān)控、告警能力與運(yùn)維操作能力結(jié)合,使之成為一套完整的自動(dòng)化流程?這就是本篇我們分享的主題——基于智慧運(yùn)維平臺(tái)故障自愈場(chǎng)景的小“探索”。
基于智慧運(yùn)維平臺(tái)監(jiān)控weblogicserverFullGC情況,模擬觸發(fā)FullGC告警,再基于平臺(tái)ATM模塊編排自愈運(yùn)維操作,在告警產(chǎn)生后自動(dòng)觸發(fā)故障自愈操作,完成自愈操作。
監(jiān)控自愈流程如下:
基于AMP監(jiān)控采集FullGC信息,同時(shí)針對(duì)監(jiān)控項(xiàng)配置告警觸發(fā)器
基于ATM配置自愈操作,完成故障時(shí)刻信息搜集、server重啟
綁定告警與自愈操作,使告警產(chǎn)生后自動(dòng)觸發(fā)完成自愈動(dòng)作
模擬FullGC場(chǎng)景,觸發(fā)故障自愈流程
同時(shí)針對(duì)JVM堆old區(qū)使用率配置了告警觸發(fā)器(PS:GC監(jiān)控場(chǎng)景有很多,如:FullGC次數(shù)、持久代使用率、O區(qū)使用率等等,本次僅以O(shè)區(qū)使用率作為驗(yàn)證場(chǎng)景)。
操作內(nèi)容也很簡(jiǎn)單,搜集了故障時(shí)刻server的堆棧信息treaddump、heapdump(PS:由于是測(cè)試,未做過(guò)多的信息搜集),之后便進(jìn)行了服務(wù)重啟動(dòng)作,腳本配置了采用local模式執(zhí)行。
可在監(jiān)控模板告觸發(fā)器配置時(shí),“故障自愈”頁(yè)面配置操作綁定
或者在配置管理的“告警自愈配置”模塊新增自愈配置,綁定監(jiān)控模板和觸發(fā)場(chǎng)景。兩個(gè)頁(yè)面配置類似,見(jiàn)下圖,在故障自愈方案選擇田間之前在ATM配置好多自愈操作:
配置完成后,如下圖,則新增了一條故障自愈策略,“啟用狀態(tài)”開(kāi)啟,“自動(dòng)執(zhí)行”狀態(tài)開(kāi)啟。其中自動(dòng)執(zhí)行狀態(tài)若是未開(kāi)啟,則告警產(chǎn)生后需要手動(dòng)觸發(fā)自動(dòng)動(dòng)作,可以根據(jù)具體需要設(shè)定。
至此,一個(gè)簡(jiǎn)單的故障自愈場(chǎng)景算是配置完成了。
在模擬FullGC場(chǎng)景之前,我們先來(lái)觀察一下正常情況下,weblogicserver的GC情況,如下圖,JVMold區(qū)使用率較低,穩(wěn)定在12.4%左右,F(xiàn)GC次數(shù)也僅有3次。
當(dāng)模擬觸發(fā)了FullGC場(chǎng)景后,weblogicserver進(jìn)程的FULLGC頻繁執(zhí)行,old區(qū)使用率也接近100%。
觀察平臺(tái),告警如期觸發(fā):
自愈動(dòng)作在告警觸發(fā)后同樣觸發(fā),如下圖,自愈觸發(fā)記錄
通過(guò)平臺(tái)GC信息采集看,JVM堆Old區(qū)使用率在觸發(fā)FULLGC前后的變化趨勢(shì)圖,從10%->100%->10%,恢復(fù)到正常水平。
Weblogicserver在模擬FullGC并自愈前后GC次數(shù)的變化趨勢(shì)圖如下圖所示,F(xiàn)ullGC次數(shù)迅速增加,觸發(fā)自愈動(dòng)作重啟實(shí)例后,F(xiàn)ULLGC再次恢復(fù)實(shí)例啟動(dòng)狀態(tài)。
自愈后告警狀態(tài)自動(dòng)變更為“已恢復(fù)”,至此,自愈流程驗(yàn)證完成。
以上便是通過(guò)智慧運(yùn)維平臺(tái)AMP監(jiān)控場(chǎng)景、ATM運(yùn)維操作場(chǎng)景結(jié)合,以完成從監(jiān)控,到告警產(chǎn)生,再到故障自愈的一次“探索”。過(guò)程略簡(jiǎn)陋了些,在實(shí)際運(yùn)維中,自愈場(chǎng)景需要考慮的點(diǎn)有很多,如自動(dòng)or手動(dòng)觸發(fā)自愈,自愈搜集哪些信息,如何確保自愈動(dòng)作100%完成,風(fēng)險(xiǎn)等等,都是需要我們根據(jù)不同的故障場(chǎng)景,去探究分析一套安全有效的解決方案。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://m.hztianpu.com/yun/129945.html
摘要:作者介紹王藝,百度云智能運(yùn)維架構(gòu)研發(fā)負(fù)責(zé)人。年轉(zhuǎn)向運(yùn)維方向,作為智能運(yùn)維架構(gòu)方向的技術(shù)負(fù)責(zé)人,致力于為百度智能運(yùn)維平臺(tái)和產(chǎn)品提供高性能高可用可擴(kuò)展的系統(tǒng)架構(gòu)和基礎(chǔ)設(shè)施。持續(xù)的數(shù)據(jù)建設(shè),是智能運(yùn)維建設(shè)的關(guān)鍵。 作者介紹王藝,百度云智能運(yùn)維架構(gòu)研發(fā)負(fù)責(zé)人。2010年加入百度,先后負(fù)責(zé)百度鏈接庫(kù)、百度志愿計(jì)算、百度統(tǒng)一資源管理的研發(fā),經(jīng)歷過(guò)千億級(jí)網(wǎng)頁(yè)鏈接的洗禮,也調(diào)度過(guò)數(shù)十萬(wàn)量級(jí)的服務(wù)器,熱衷于直...
摘要:只有當(dāng)超時(shí)故障扇區(qū)等明確故障項(xiàng)出現(xiàn)后,兩者關(guān)聯(lián)才確診硬盤(pán)故障,否則只是隔離觀察,不報(bào)修。如果存在進(jìn)程住時(shí)間超過(guò)分鐘,我們認(rèn)為這個(gè)硬盤(pán)故障的影響面已擴(kuò)大到了整機(jī),需要進(jìn)行重啟消除影響。 隨著阿里大數(shù)據(jù)產(chǎn)品業(yè)務(wù)的增長(zhǎng),服務(wù)器數(shù)量不斷增多,IT運(yùn)維壓力也成比例增大。各種軟、硬件故障而造成的業(yè)務(wù)中斷,成為穩(wěn)定性影響的重要因素之一。本文詳細(xì)解讀阿里如何實(shí)現(xiàn)硬件故障預(yù)測(cè)、服務(wù)器自動(dòng)下線、服務(wù)自愈以...
摘要:智能化數(shù)據(jù)中心發(fā)展的三部曲在中國(guó)電信北京研究院副總工程師楊明川看來(lái),智能化的數(shù)據(jù)中心的發(fā)展可以被歸納為三個(gè)階段。而在最終階段,則是希望能夠?qū)崿F(xiàn)完全自動(dòng)化的數(shù)據(jù)中心。對(duì)此,中國(guó)電信正在積極思考在未來(lái)智能化的數(shù)據(jù)中心里可以做一些什么樣的探索。這其中,智能化的數(shù)據(jù)中心包含兩方面含義,一方面是數(shù)據(jù)中心如何基于海量數(shù)據(jù),利用人工智能的技術(shù),進(jìn)一步去優(yōu)化數(shù)據(jù)中心的運(yùn)營(yíng);另個(gè)方面是數(shù)據(jù)中心會(huì)越來(lái)越多地去承...
摘要:最新發(fā)布的全球半年度行業(yè)云跟蹤報(bào)告也顯示,年全球四大行業(yè)金融制造醫(yī)療和公共部門(mén)的行業(yè)云支出總額將高達(dá)億美元。這樣一來(lái),華為的金融網(wǎng)絡(luò)能夠獲得市場(chǎng)的青睞也就順理成章了。金融業(yè)數(shù)字化轉(zhuǎn)型的加速,使得金融云越來(lái)越成為行業(yè)標(biāo)配;但金融云的普及,又讓傳統(tǒng)網(wǎng)絡(luò)技術(shù)架構(gòu)受到了前所未有的沖擊。這樣看來(lái),邏輯就簡(jiǎn)單了:金融業(yè)必須先推動(dòng)傳統(tǒng)網(wǎng)絡(luò)技術(shù)架構(gòu)的升級(jí),促進(jìn)金融云的普及應(yīng)用,才能進(jìn)一步實(shí)現(xiàn)自身的數(shù)字化轉(zhuǎn)型...
前言 以Docker為代表的容器技術(shù)縮短了企業(yè)應(yīng)用從開(kāi)發(fā)、構(gòu)建到發(fā)布、運(yùn)行的整個(gè)生命周期。Gartner推測(cè)到2022年將會(huì)有75%的全球化企業(yè)將在生產(chǎn)中使用容器化的應(yīng)用(當(dāng)前約為30%)。由于Docker往往難以獨(dú)立支撐起大規(guī)模容器化部署,因此誕生了Kubernetes等容器編排工具,解決了大規(guī)模容器的組織和管理難題。 但事實(shí)上,Kubernetes的使用體系還是非常復(fù)雜的,對(duì)于企業(yè)的開(kāi)...
閱讀 1461·2023-01-11 13:20
閱讀 1815·2023-01-11 13:20
閱讀 1267·2023-01-11 13:20
閱讀 2008·2023-01-11 13:20
閱讀 4227·2023-01-11 13:20
閱讀 2887·2023-01-11 13:20
閱讀 1489·2023-01-11 13:20
閱讀 3814·2023-01-11 13:20