中文字幕日韩精品一区二区免费_精品一区二区三区国产精品无卡在_国精品无码专区一区二区三区_国产αv三级中文在线

3000臺(tái)服務(wù)器不宕機(jī),微博廣告系統(tǒng)全景運(yùn)維大法

2021-01-27    分類: 網(wǎng)站建設(shè)

微博現(xiàn)在日活達(dá)到了 2 億,微博廣告是微博最重要且穩(wěn)定的收入來(lái)源,沒(méi)有之一,所以微博廣告系統(tǒng)的穩(wěn)定性是我們廣告運(yùn)維所有工作中的重中之重。

這樣的自動(dòng)化運(yùn)維平臺(tái)基本上滿足了運(yùn)維的日常操作需求,在 Kunkka 平臺(tái)中還有自動(dòng)擴(kuò)縮容的功能,我們針對(duì)這個(gè)功能進(jìn)行延伸。

在自動(dòng)擴(kuò)所容的基礎(chǔ)上,根據(jù)時(shí)間段,流量進(jìn)行動(dòng)態(tài)判斷,自動(dòng)決策的擴(kuò)所容夠功能。

彈性計(jì)算

為什么需要彈性計(jì)算

首先簡(jiǎn)單介紹一下彈性計(jì)算的架構(gòu),彈性計(jì)算依托于 Kunkka 自動(dòng)化運(yùn)維平臺(tái),以及 Oops 監(jiān)控平臺(tái),在業(yè)務(wù)壓測(cè)的情況下獲取業(yè)務(wù)指標(biāo)監(jiān)控,將數(shù)據(jù)送到容量決策系統(tǒng),做出是否擴(kuò)縮容的決定。

在云服務(wù)商方面,我們常用阿里云、華為云跟一部分自建的私有云。DCP 混合平臺(tái)是我們微博另外一個(gè)團(tuán)隊(duì)做了幾年的平臺(tái),它能夠?qū)釉品?wù),快速生成

現(xiàn)在拿到了一個(gè)非常重要的容量值及消耗比來(lái)進(jìn)行容量評(píng)估,用于描述當(dāng)前的容量消耗情況。

拿到這個(gè)消耗比之后是不是就可以擴(kuò)容了?還是可以縮容了?此處還需要一個(gè)評(píng)估標(biāo)準(zhǔn),是 30% 就擴(kuò)?還是 50% 再擴(kuò)?

我們基于歷史數(shù)據(jù)給予分析,制定了三條水位線,包括安全線、警戒線和致命線,拿當(dāng)前消耗值與水位線進(jìn)行對(duì)比,在不同階段采取不同的措施。

比如,現(xiàn)在的消耗度遠(yuǎn)遠(yuǎn)低于安全線,說(shuō)明現(xiàn)在服務(wù)器部署有冗余,我們可以進(jìn)行逐步的縮容。

如果說(shuō)現(xiàn)在已經(jīng)高于致命線,則需要擴(kuò)容,讓這個(gè)值更加接近安全線,保證系統(tǒng)的穩(wěn)定性。

⑤在線容量評(píng)估體系

前面進(jìn)行的數(shù)據(jù)采集、計(jì)算,以及動(dòng)作的串聯(lián),都是為了完成最后一個(gè)目標(biāo),服務(wù)擴(kuò)容成功。

真正的服務(wù)器擴(kuò)容到線上之后,怎么樣才能保證服務(wù)是健康可用的呢?我們還有另外一套輔助系統(tǒng)叫擴(kuò)容演練。在實(shí)時(shí)演練過(guò)程中,要注意以下幾點(diǎn):

部署效率:我們通過(guò)擴(kuò)容演練來(lái)尋找整個(gè)擴(kuò)容過(guò)程中的瓶頸,比如,我們下發(fā)是通過(guò) DCP 對(duì)接云服務(wù)商來(lái)完成擴(kuò)容的。

在真正的線上擴(kuò)容過(guò)程中,DCP 有時(shí)要同時(shí)承載幾千臺(tái)節(jié)點(diǎn)的擴(kuò)容并發(fā)。DCP 的效率是否能夠滿足?在擴(kuò)容演練過(guò)程中需要確認(rèn)這一點(diǎn)。

帶寬限制:微博和云服務(wù)商之間確實(shí)是拉了專線,但是微博和云服務(wù)商不只是微博廣告的一個(gè)業(yè)務(wù),還有很多其他大戶。

而且一般在流量增加的時(shí)候他們的擴(kuò)容也是非常猛烈的,所以帶寬是否可用,也是我們?cè)谌粘Q菥氝^(guò)程中非常注意的現(xiàn)象。

依賴服務(wù):這方面有很多案例,在這里簡(jiǎn)單分享一下,2015 年春節(jié),自動(dòng)擴(kuò)縮容的流程才剛剛開始,春節(jié)當(dāng)天晚上我們擴(kuò)容完幾千個(gè)節(jié)點(diǎn)后,忽然發(fā)現(xiàn)負(fù)載均衡加不上去。

說(shuō)到監(jiān)控,不得不說(shuō)監(jiān)控遇到的很多問(wèn)題。市面上有很多開源的監(jiān)控軟件,比如說(shuō)常見(jiàn)的 Zabbix,在監(jiān)控?cái)?shù)據(jù)量少的情況下,不管是基礎(chǔ)監(jiān)控還是業(yè)務(wù)監(jiān)控,這些開源軟件都是可以直接滿足需求的。

但是隨著監(jiān)控指標(biāo)的增多,加上我們的指標(biāo)是實(shí)時(shí)性變化的,數(shù)據(jù)要求又比較高,這些原生軟件不再滿足我們需求了。

另外,微博廣告的業(yè)務(wù)數(shù)據(jù)有特殊性,一般運(yùn)維關(guān)注的數(shù)據(jù)是系統(tǒng)的性能,系統(tǒng)的性能數(shù)據(jù)有時(shí)候來(lái)源于業(yè)務(wù)日志。

但是微博廣告的業(yè)務(wù)日志是收入,很多業(yè)務(wù)日志是一條都不能丟的,比如說(shuō)結(jié)算的曝光。

每一條曝光對(duì)于廣告來(lái)說(shuō),都是真金白銀,對(duì)精準(zhǔn)性要求比較高,單獨(dú)通過(guò)性能監(jiān)控的日志收集方法是不能滿足需求的,這也是我們面臨的挑戰(zhàn)。

另外,監(jiān)控系統(tǒng)一般都會(huì)具備告警功能,有告警就會(huì)有告警問(wèn)題,接下來(lái)會(huì)詳細(xì)地介紹告警問(wèn)題。

還面臨定位方面的挑戰(zhàn),在監(jiān)控越來(lái)越完善的基礎(chǔ)上,很多開發(fā)的操作情況發(fā)生了變化。

一旦發(fā)生問(wèn)題,第一個(gè)反應(yīng)并不是上服務(wù)器看一下系統(tǒng)怎么了,而是翻監(jiān)控,看看哪些監(jiān)控指標(biāo)發(fā)生了問(wèn)題,所以監(jiān)控系統(tǒng)會(huì)越來(lái)越多地面向于問(wèn)題定位這個(gè)方向。

Oops 整體架構(gòu)面臨的挑戰(zhàn)

作為監(jiān)控系統(tǒng),Oops 在架構(gòu)上并沒(méi)有什么出奇的地方,所有的監(jiān)控?zé)o非就是四個(gè)階段:

  • 從客戶端進(jìn)行數(shù)據(jù)采集
  • 數(shù)據(jù)的清洗和計(jì)算
  • 數(shù)據(jù)存儲(chǔ)
  • 數(shù)據(jù)展示

監(jiān)控?cái)?shù)據(jù)流向特點(diǎn)

所有的監(jiān)控系統(tǒng)都逃不開這四個(gè)階段,只是根據(jù)業(yè)務(wù)的不同進(jìn)行了定制化的工作。

針對(duì)廣告業(yè)務(wù)的監(jiān)控流向,我們把數(shù)據(jù)分成兩類,有一部分精密數(shù)據(jù)的計(jì)算,我們采取的是離線分析的方式,通過(guò)采集軟件將所有的日志采集到 Kafka,通過(guò)計(jì)算的工具進(jìn)行拆洗、計(jì)算,計(jì)算之后落存儲(chǔ)。

還有另外一個(gè)團(tuán)隊(duì)開發(fā)的針對(duì)于這一部分?jǐn)?shù)據(jù)的頁(yè)面展示化,還有一個(gè)系統(tǒng)叫 Hubble,針對(duì)精細(xì)數(shù)據(jù)的展現(xiàn),實(shí)現(xiàn)個(gè)性化定制的展現(xiàn)。

另外一部分是運(yùn)維比較關(guān)心的數(shù)據(jù),今天來(lái)了多少流量?流量有多少是正常的?有多少是異常的?平均耗時(shí)是多少?針對(duì)這一部分,我們采取了實(shí)時(shí)數(shù)據(jù)計(jì)算的方法。

在數(shù)據(jù)采集階段發(fā)生了變化,我們并不采集全量日志,而是在客戶端做了預(yù)處理,進(jìn)行分類計(jì)算。

比如說(shuō)監(jiān)控?cái)?shù)據(jù),就按監(jiān)控?cái)?shù)據(jù)的方法計(jì)算;告警數(shù)據(jù),就按告警數(shù)據(jù)的計(jì)算。而且按照用戶讀取的需求進(jìn)行分類存儲(chǔ),保證了高并發(fā)數(shù)據(jù)的實(shí)時(shí)性。

海量指標(biāo)監(jiān)控系統(tǒng)流程

接下來(lái)詳細(xì)介紹實(shí)時(shí)數(shù)據(jù)計(jì)算。

首先從數(shù)據(jù)采集上講,上文提到我們不采取全量的采集方式,而是通過(guò) Agent 對(duì)數(shù)據(jù)進(jìn)行處理。

在數(shù)據(jù)采集階段,在數(shù)據(jù)產(chǎn)生的服務(wù)器上,針對(duì)不同的需求按不同的時(shí)間進(jìn)行分類聚合,最終向后推送的數(shù)據(jù)是 key-value、計(jì)算方法這種模式,推送給 Proxy。

Proxy 拿到已經(jīng)被打包的數(shù)據(jù)進(jìn)行拆包,然后送給不同的計(jì)算結(jié)點(diǎn),再按照 Key 進(jìn)行計(jì)算,打時(shí)間戳。

這個(gè)數(shù)據(jù)并不精準(zhǔn),但我們可以接受部分損失,只需要保證數(shù)據(jù)的趨勢(shì)是正確的。

另外,關(guān)于分類計(jì)算,不同的需求推送給不同的計(jì)算節(jié)點(diǎn)。存儲(chǔ)也進(jìn)行了分類,實(shí)時(shí)性要求比較強(qiáng)的話會(huì)直接放到內(nèi)存,以最精細(xì)粒度進(jìn)行存儲(chǔ)。

前三個(gè)小時(shí)的數(shù)據(jù)是按秒存的,按天計(jì)算的數(shù)據(jù)是按 10 秒、30 秒存的,一些單機(jī)數(shù)據(jù)是按分鐘存的。

另外一些歷史性的數(shù)據(jù)需要出報(bào)表的,比如說(shuō)要看前一周的數(shù)據(jù),前一個(gè)月的數(shù)據(jù),按照大數(shù)據(jù)的方式存到 OpenTSDB 當(dāng)中。

存儲(chǔ)的數(shù)據(jù)提供一個(gè) API,通過(guò) API 我們進(jìn)行了分類計(jì)算、分類存儲(chǔ),這種分類的需求來(lái)源于用戶,需要看用戶有什么要求,要什么樣的數(shù)據(jù)。

比如,Dashboard 的展示數(shù)據(jù)會(huì)直接被放到內(nèi)存里。另外,上文提到的在線擴(kuò)縮容數(shù)據(jù),會(huì)相應(yīng)獲取數(shù)據(jù)給用戶,其他相關(guān)的獲取需求 API 也會(huì)進(jìn)行分類獲取。

接下來(lái)我們計(jì)算過(guò)的數(shù)據(jù)還有一部分會(huì)存儲(chǔ)到 Redis 通過(guò) WatchD 作為告警中心的數(shù)據(jù),因?yàn)楦婢瘮?shù)據(jù)一般都只要求當(dāng)前數(shù)據(jù),不會(huì)有人需要查看上個(gè)月這臺(tái)機(jī)器的負(fù)載有沒(méi)有告警。

所以 Alert 節(jié)點(diǎn)計(jì)算之后的數(shù)據(jù)直接存在 Redis,Redis 把這個(gè)數(shù)據(jù)拿出來(lái)之后經(jīng)過(guò)告警中心根據(jù)告警規(guī)則進(jìn)行清洗,通過(guò)各種方式推送到需求方。

同時(shí)有一個(gè)相對(duì)個(gè)性化的展示叫九宮格。我們的九宮格實(shí)際上是一個(gè)結(jié)合報(bào)警功能的監(jiān)控,它是一個(gè)頁(yè)面,但具備了告警功能。

接下來(lái)看一下監(jiān)控圖,下面三張圖是范冰冰宣布分手拿到的流量,我們的反映是非常靈敏的,平均耗時(shí)也漲上來(lái)了。

第三張圖是拿到這些數(shù)據(jù)之后,自動(dòng)平臺(tái)顯示應(yīng)該擴(kuò)容了。藍(lán)色跟綠色的流量線已經(jīng)降下來(lái)了,大部分量調(diào)到

下圖是我們的九宮格,因?yàn)闀r(shí)效性比較強(qiáng),正常來(lái)說(shuō)是以產(chǎn)品為頁(yè)面,以業(yè)務(wù)線為格子,每個(gè)格子記錄的是單機(jī)的詳細(xì)信息。

如果在這一組服務(wù)器當(dāng)中單機(jī)故障數(shù)超過(guò)一定的比例,這個(gè)格子會(huì)變顏色。

所以在正常的運(yùn)維工位上都會(huì)有這樣的大屏幕,運(yùn)維可以一目了然發(fā)現(xiàn)自己所有負(fù)責(zé)的業(yè)務(wù)線情況,而不是讓一臺(tái)臺(tái)機(jī)器在這里展現(xiàn),這樣就沒(méi)有辦法看到業(yè)務(wù)線情況了。九宮格可以讓運(yùn)維更加直觀地看到當(dāng)前的告警情況。

告警

告警有很多的問(wèn)題,我們遇到的問(wèn)題可以分為以下四個(gè)方面:

①告警數(shù)量巨大

運(yùn)維人員需要關(guān)注所有部分,從系統(tǒng)到服務(wù)、接口等等,維度很多,一旦有問(wèn)題,各種策略都會(huì)觸發(fā)報(bào)警,報(bào)警數(shù)量多到一定程度,基本上等于沒(méi)有報(bào)警。

②重復(fù)告警率高

告警策略一般會(huì)周期性執(zhí)行,一直到告警條件不被滿足,如果服務(wù)一直不恢復(fù),就會(huì)重復(fù)報(bào)下去,另外,同一個(gè)故障也可能引發(fā)不同層次的告警。

比如,我們有一個(gè)業(yè)務(wù)線叫超粉,會(huì)有 360 臺(tái)服務(wù)器,流量高峰時(shí) 360 臺(tái)服務(wù)器會(huì)同時(shí)發(fā)送告警,這種告警的重復(fù)率很高。

③告警有效性不足

很多時(shí)候,網(wǎng)絡(luò)抖動(dòng)、擁堵、負(fù)載暫時(shí)過(guò)高或者變更等原因,會(huì)觸發(fā)報(bào)警,但這類報(bào)警要么不再重現(xiàn),要么可以自愈。

比如一個(gè)硬盤在接近 80% 的時(shí)候開始告警了,你讓它告嗎?好像得告,但似乎不告也可以。

④告警模式粗放

無(wú)論是否重要、優(yōu)先級(jí)如何,告警都通過(guò)郵件、短信、App PUSH 發(fā)送到接收人,就像暴風(fēng)一樣襲擊著接收人,接收人沒(méi)有辦法從中獲取到有效的信息,經(jīng)常會(huì)讓真正重要的告警淹沒(méi)在一大堆普通告警中。

針對(duì)這些問(wèn)題,我們采取了以下措施:

①抖動(dòng)收斂

對(duì)于這種大規(guī)模服務(wù)器的維護(hù),抖動(dòng)是非常常見(jiàn)的現(xiàn)象。網(wǎng)絡(luò)抖一抖,整個(gè)服務(wù)單元就會(huì)向你告警。

針對(duì)這種抖動(dòng),我們?cè)黾恿艘恍┎呗裕秳?dòng)的時(shí)候會(huì)前后比較,監(jiān)測(cè)重復(fù)性,看看是不是具備告警的意義,通過(guò)增加告警策略這種方式來(lái)進(jìn)行收斂。

比如說(shuō)流量突增的時(shí)候,需要查看是不是同單元都出現(xiàn)了這個(gè)情況。

②告警的分類和分級(jí)

詳細(xì)定義告警級(jí)別,發(fā)送優(yōu)先級(jí)、升級(jí)策略等,可有效減少粗放模式下告警接收量。比如,一些低優(yōu)先等級(jí)的告警會(huì)讓它告,處理的級(jí)別會(huì)低一點(diǎn)。

③同類合并

同一個(gè)原因可能會(huì)觸發(fā)一個(gè)服務(wù)池里面的所有實(shí)例都報(bào)警,比如同時(shí)無(wú)法連接數(shù)據(jù)庫(kù),其實(shí)只需要報(bào)一次即可。

④變更忽略

我們的好多變更都是在 Kunkka 平臺(tái)上操作的,開發(fā)有時(shí)候會(huì)選中一個(gè)通知,現(xiàn)在是變更,告警請(qǐng)忽略。

以上措施能解決告警問(wèn)題中 80% 的問(wèn)題,現(xiàn)在大家都在朝著更高級(jí)的方向發(fā)展,我們也簡(jiǎn)單做了一些探索。

在原有告警數(shù)據(jù)流情況下引入了工具 SkyLine,這個(gè)工具包含了多種算法,在異常檢測(cè)環(huán)節(jié)中,能夠通過(guò)它內(nèi)置的算法將我們傳入的數(shù)據(jù)自動(dòng)去抖動(dòng),提供平滑的數(shù)據(jù),等你再拿到這個(gè)數(shù)據(jù)時(shí)就不需要再檢測(cè)是不是告警。

這個(gè)工具避免了人工操作,通過(guò) Skyline 將數(shù)據(jù)進(jìn)行平滑,提供一份準(zhǔn)確的數(shù)據(jù),我們只需要通過(guò)這份數(shù)據(jù),進(jìn)行規(guī)則判斷,決定是否需要告警就好了,減少了對(duì)數(shù)據(jù)準(zhǔn)確性判斷的復(fù)雜過(guò)程。

接著是根因分析部分,隨著監(jiān)控的覆蓋面越來(lái)越廣,監(jiān)控精確性越來(lái)越高。

等故障出現(xiàn)的時(shí)候,開發(fā)人員就會(huì)去翻監(jiān)控圖,去查看大概是哪些原因?qū)е铝斯收稀?/p>

隨著 Dashboard 越來(lái)越多,即便是經(jīng)驗(yàn)非常豐富的工作人員也很難快速地定位到原因會(huì)出現(xiàn)哪個(gè)方面、該去看哪張監(jiān)控圖。

出現(xiàn)流量突增的情況時(shí),Skyline 會(huì)通過(guò)內(nèi)部的算法 Luminosity 尋找相似的情況,查看相同的時(shí)間內(nèi)是否有其他地方出現(xiàn)流量異常,并將根源問(wèn)題展示在 TOPN 上。

這樣就能夠快速查看在故障出現(xiàn)的前后哪些

本文標(biāo)題:3000臺(tái)服務(wù)器不宕機(jī),微博廣告系統(tǒng)全景運(yùn)維大法
網(wǎng)頁(yè)網(wǎng)址:http://m.rwnh.cn/news40/97690.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站營(yíng)銷、手機(jī)網(wǎng)站建設(shè)、響應(yīng)式網(wǎng)站網(wǎng)站排名、企業(yè)網(wǎng)站制作、網(wǎng)站導(dǎo)航

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)

h5響應(yīng)式網(wǎng)站建設(shè)
辽中县| 明光市| 尼木县| 彩票| 乐都县| 新干县| 鄂托克旗| 德清县| 南平市| 伊春市| 福建省| 乌拉特前旗| 吴堡县| 尼勒克县| 华亭县| 浪卡子县| 上饶市| 甘南县| 闽清县| 徐汇区| 新昌县| 香港| 宝山区| 晋州市| 双牌县| 蓬安县| 怀仁县| 启东市| 三门县| 潮州市| 城固县| 娄底市| 胶南市| 葵青区| 阜康市| 启东市| 横山县| 华池县| 宜阳县| 广水市| 齐河县|