建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
微博現(xiàn)在日活達(dá)到了 2 億，微博廣告是微博最重要且穩(wěn)定的收入來(lái)源，沒(méi)有之一，所以微博廣告系統(tǒng)的穩(wěn)定性是我們廣告運(yùn)維所有工作中的重中之重。
讓客戶(hù)滿(mǎn)意是我們工作的目標(biāo)，不斷超越客戶(hù)的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛(ài)。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶(hù)，將通過(guò)不懈努力成為客戶(hù)在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：空間域名、虛擬主機(jī)、營(yíng)銷(xiāo)軟件、網(wǎng)站建設(shè)、友好網(wǎng)站維護(hù)、網(wǎng)站推廣。
[[279814]]
圖片來(lái)自 Pexels
微博廣告的運(yùn)維主要負(fù)責(zé)資產(chǎn)管理、服務(wù)穩(wěn)定性維護(hù)、故障應(yīng)急處理以及成本控制等多個(gè)責(zé)任。
微博廣告運(yùn)維發(fā)展經(jīng)歷了如下階段：從早期小規(guī)模的手工運(yùn)維到工具化運(yùn)維，隨著服務(wù)器數(shù)量的發(fā)展，業(yè)務(wù)模型日漸發(fā)展，開(kāi)發(fā)、運(yùn)營(yíng)、QA 都參與到產(chǎn)品的生命周期中，我們現(xiàn)在也進(jìn)入了自動(dòng)化運(yùn)維的階段，在新的虛擬化技術(shù)、算法技術(shù)的驅(qū)動(dòng)下，我們也在朝著 AIOps 的方向努力。
在整個(gè)運(yùn)維過(guò)程中，我們遇到了很多痛點(diǎn)，幸福的人生都是一樣的，不幸的人生各有各的不幸，各家的運(yùn)維都各有各的痛點(diǎn)。
我們的服務(wù)器在 3000 臺(tái)以上，業(yè)務(wù)線(xiàn)及輔助資源各種各樣，產(chǎn)品迭代非?？欤乙蕾?lài)關(guān)系復(fù)雜，流量變更，切換損失不可接受。
在這種情況下，我們面臨資產(chǎn)管理困難、環(huán)境不統(tǒng)一、上線(xiàn)難度大、運(yùn)維成本高的問(wèn)題。
基于這些問(wèn)題，微博廣告運(yùn)維工作主要集中在以下四個(gè)方面：
- 運(yùn)維自動(dòng)化
- 彈性計(jì)算
- 智能監(jiān)控
- 服務(wù)治理
運(yùn)維自動(dòng)化
一個(gè)健全的自動(dòng)化運(yùn)維平臺(tái)必須要具備如下幾個(gè)功能：
- 基礎(chǔ)監(jiān)控
- 資源管理
- 事件集中分析
- 配置管理
- 批量運(yùn)維工具
- 持續(xù)集成和發(fā)布
基于這些功能和需求，我們廣告運(yùn)維自主研發(fā)了 Kunkka 平臺(tái)(微博廣告運(yùn)維自主研發(fā)的自動(dòng)化運(yùn)維平臺(tái))、資產(chǎn)管理、自動(dòng)化上線(xiàn)等運(yùn)維平臺(tái)。
資產(chǎn)管理是基于公司 CMDB(公司級(jí)別的資產(chǎn)管理系統(tǒng))獲取到主機(jī)云服務(wù)器，針對(duì)微博廣告對(duì)資源的管理需求自建定制化的資產(chǎn)管理平臺(tái)。
配置中心包括服務(wù)注冊(cè)、服務(wù)配置等功能;自動(dòng)化上線(xiàn)涵蓋了開(kāi)發(fā)在上線(xiàn)過(guò)程中所需要的節(jié)點(diǎn)和流程。
自主終端是行業(yè)變化的功能實(shí)現(xiàn)，大家可以通過(guò)頁(yè)面完成文件或命令下發(fā)、日志審計(jì)等各種工作。
Kunkka 基于主機(jī)和容器，通過(guò) Salt 作為傳輸層進(jìn)行命令下發(fā)，組件層包含開(kāi)源軟件，操作層將命令頁(yè)面化，通過(guò)頁(yè)面進(jìn)行日常工作和管理。
這樣的自動(dòng)化運(yùn)維平臺(tái)基本上滿(mǎn)足了運(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ì)算
首先，在產(chǎn)品方面，我們的產(chǎn)品線(xiàn)很多，依賴(lài)關(guān)系比較復(fù)雜。
微博廣告相當(dāng)于一個(gè)橋梁，左邊連接的是廣告主，右邊連接的是客戶(hù)，需要將廣告主的廣告計(jì)劃轉(zhuǎn)化為用戶(hù)的需求，讓用戶(hù)看到自己想要看的廣告。
為了滿(mǎn)足兩邊不同的需求，產(chǎn)品的變更和發(fā)布非常重要且頻繁。
其次，在運(yùn)營(yíng)方面，很多有推廣需求計(jì)劃的大型活動(dòng)都有臨時(shí)擴(kuò)容需要，比如 618 跟雙十一，對(duì)于我們而言這兩個(gè)活動(dòng)帶來(lái)了很大的沖擊。
在 618 和雙十一大促之前，為了加大自己的影響力，各個(gè)廣告主會(huì)增加廣告計(jì)劃，微博廣告這邊再針對(duì)廣告主的行為加大我們的曝光量，實(shí)現(xiàn)廣告主廣告計(jì)劃的轉(zhuǎn)化。
在 618 和雙十一大促之前，為了加大自己的影響力，各個(gè)廣告主會(huì)增加廣告計(jì)劃，微博廣告這邊再針對(duì)廣告主的行為加大我們的曝光量，實(shí)現(xiàn)廣告主廣告計(jì)劃的轉(zhuǎn)化。
傳統(tǒng)的業(yè)務(wù)運(yùn)維
按照傳統(tǒng)運(yùn)維模式，擴(kuò)容計(jì)劃從立項(xiàng)到服務(wù)器上線(xiàn)，會(huì)經(jīng)過(guò)諸多的流程跟漫長(zhǎng)的等待。
從結(jié)果上來(lái)看，服務(wù)器擴(kuò)容了，而且對(duì)傳統(tǒng)項(xiàng)目而言，整體流程都是可控的，這是它的優(yōu)點(diǎn)。
它的缺點(diǎn)不言而喻，有以下幾點(diǎn)：
首先，它時(shí)效性太差，如果按照新浪服務(wù)器的采購(gòu)周期，從審計(jì)到上線(xiàn)需要兩個(gè)月的流程。兩個(gè)月后服務(wù)器上線(xiàn)，恐怕剛結(jié)婚的明星都已經(jīng)離婚了，突發(fā)事件流量都已經(jīng)過(guò)去了。
另外，它無(wú)法準(zhǔn)確預(yù)估容量，在傳統(tǒng)的業(yè)務(wù)運(yùn)維模式下，范冰冰分手、雙宋離婚帶來(lái)的流量是無(wú)法實(shí)現(xiàn)的，我們無(wú)法評(píng)估擴(kuò)容量。
除此之外，傳統(tǒng)模式下資源利用率比較低，服務(wù)器很難在業(yè)務(wù)間共享。
在這些問(wèn)題共同作用下催生了動(dòng)態(tài)擴(kuò)縮容體系。
彈性計(jì)算：實(shí)時(shí)動(dòng)態(tài)擴(kuò)縮容
動(dòng)態(tài)擴(kuò)縮容不是一個(gè)工具，是一整套體系。它基于云服務(wù)，包含了在線(xiàn)壓力檢測(cè)和消耗度評(píng)測(cè)的功能，最終實(shí)現(xiàn)分級(jí)治理。
①?gòu)椥杂?jì)算架構(gòu)
首先簡(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ù)，快速生成云主機(jī)快速擴(kuò)容。
今天的重點(diǎn)跟業(yè)務(wù)方有著最直接的關(guān)系：業(yè)務(wù)上要不要擴(kuò)容?什么時(shí)候擴(kuò)容?擴(kuò)多少?我們要解決這樣的問(wèn)題。
②決策系統(tǒng)
在上文的架構(gòu)中，我們提到了容量決策系統(tǒng)，容量決策系統(tǒng)實(shí)際上指的是計(jì)算系統(tǒng)，會(huì)對(duì)我們獲取到的業(yè)務(wù)指標(biāo)進(jìn)行計(jì)算、評(píng)估。
比如系統(tǒng)的基礎(chǔ)信息、一些業(yè)務(wù)上日志來(lái)源的信息等，得到當(dāng)前業(yè)務(wù)的容量，通過(guò)對(duì)歷史數(shù)據(jù)進(jìn)行同比、環(huán)比的分析，得到流量趨勢(shì)，了解接下來(lái)流量會(huì)變成什么樣子，這兩組數(shù)據(jù)計(jì)算結(jié)果會(huì)給出擴(kuò)縮容的建議。
同時(shí)，他們會(huì)計(jì)算這些數(shù)據(jù)并予以呈現(xiàn)，提供一個(gè)輔助的 API 接口，給上下游部門(mén)做擴(kuò)縮容數(shù)據(jù)。
③容量評(píng)估方法
這個(gè)業(yè)務(wù)的當(dāng)前容量是什么樣的?是不是健康的?這個(gè)指標(biāo)靠什么來(lái)評(píng)估?
由于業(yè)務(wù)系統(tǒng)、業(yè)務(wù)形態(tài)、架構(gòu)的不同，選取一個(gè)實(shí)時(shí)且通用的指標(biāo)是非常具有挑戰(zhàn)性的，我們也嘗試了很久，引入了 AVG-hits 的概念。
對(duì)于處在不同時(shí)間內(nèi)的請(qǐng)求數(shù)進(jìn)行加權(quán)、求和來(lái)擬合實(shí)際的單機(jī)消耗量，這個(gè)代表的是在不同的區(qū)間的耗時(shí)數(shù)，我們給它一個(gè)系數(shù)，大于 5 毫秒小于 10 毫秒，根據(jù)自己的業(yè)務(wù)給予耗時(shí)分區(qū)，這樣就能計(jì)算出來(lái)。
事實(shí)證明，與之前傳統(tǒng)的單一 QPS 負(fù)載對(duì)比起來(lái)，綜合的數(shù)據(jù)對(duì)業(yè)務(wù)的評(píng)估比這種單一指標(biāo)是更加準(zhǔn)確的。
在獲得這個(gè)數(shù)據(jù)之后是不是就能夠描述當(dāng)前的系統(tǒng)容量呢?
回答是肯定不能，AVG-hits 這個(gè)概念第一次接觸，確實(shí)是有點(diǎn)生澀，舉個(gè)簡(jiǎn)單的例子來(lái)幫助理解，比如說(shuō)某個(gè)業(yè)務(wù)消耗指標(biāo)衡量非常簡(jiǎn)單，需要通過(guò)內(nèi)存判斷消耗情況。
如果監(jiān)控指標(biāo)提示內(nèi)存消耗到 80G，那能不能用 80G 來(lái)描述當(dāng)前系統(tǒng)的消耗情況?
這樣問(wèn)就比較容易理解，回答肯定是不能的，因?yàn)椴恢婪?wù)器最大的內(nèi)存是多少，如果最大是 96G，那么 80G 已經(jīng)超過(guò) 80% 了，接近危險(xiǎn)值，如果最大內(nèi)存是 256G 則消耗不到 30%，是非常安全的值。
道理是一樣的，僅拿到當(dāng)前消耗值是不能對(duì)業(yè)務(wù)當(dāng)前狀態(tài)進(jìn)行描述的，還需要另一個(gè)評(píng)估標(biāo)準(zhǔn)。
這個(gè)業(yè)務(wù)當(dāng)前能承載的最大容量是多少?如果是看內(nèi)存就簡(jiǎn)單了，可這是一個(gè)綜合評(píng)估標(biāo)準(zhǔn)，要怎么拿到它呢?
作為一個(gè)有經(jīng)驗(yàn)的運(yùn)維，我覺(jué)得根據(jù)服務(wù)器當(dāng)前硬件的表現(xiàn)，猜測(cè)最大容量不是困難的事情，但現(xiàn)在都 2019 年了，靠猜是不行的，我們通過(guò)壓測(cè)獲取最大容量值。
在實(shí)際環(huán)境中減少服務(wù)器數(shù)量，減少到不能再少，記錄當(dāng)前的容量值，作為最大容量，用壓測(cè)開(kāi)始之前的實(shí)際消耗值除以壓測(cè)獲取的最大容量，得到整個(gè)系統(tǒng)的消耗比。這個(gè)消耗比就認(rèn)為是當(dāng)前這個(gè)系統(tǒng)消耗的畫(huà)像。
壓測(cè)壓到什么情況下達(dá)到最大容量不能再壓呢?是要壓到服務(wù)器宕機(jī)?
我們接入了另外一個(gè)概念叫消耗比，在耗時(shí)最大區(qū)間的 Ahits(請(qǐng)求數(shù)量)數(shù)(PPT 上顯示：慢速比=100.0*當(dāng)前容量(Ahits)/最大容量(max_Ahts))與總的請(qǐng)求數(shù)之比超過(guò)一定的比例，則是影響用戶(hù)的體現(xiàn)。
這個(gè)壓力達(dá)到最大值就不能再壓了，就會(huì)記錄當(dāng)時(shí)的 Ahit 數(shù)，作為這個(gè)接口最大容量。
④分級(jí)治理：水位線(xiàn)
現(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ù)給予分析，制定了三條水位線(xiàn)，包括安全線(xiàn)、警戒線(xiàn)和致命線(xiàn)，拿當(dāng)前消耗值與水位線(xiàn)進(jìn)行對(duì)比，在不同階段采取不同的措施。
比如，現(xiàn)在的消耗度遠(yuǎn)遠(yuǎn)低于安全線(xiàn)，說(shuō)明現(xiàn)在服務(wù)器部署有冗余，我們可以進(jìn)行逐步的縮容。
如果說(shuō)現(xiàn)在已經(jīng)高于致命線(xiàn)，則需要擴(kuò)容，讓這個(gè)值更加接近安全線(xiàn)，保證系統(tǒng)的穩(wěn)定性。
⑤在線(xiàn)容量評(píng)估體系
現(xiàn)在自動(dòng)擴(kuò)縮容的三個(gè)要素，當(dāng)前消耗、水位線(xiàn)、容量決策系統(tǒng)都已經(jīng)具備了，我們?nèi)绾伟堰@三個(gè)點(diǎn)聯(lián)動(dòng)起來(lái)?如何讓它串在一起完成擴(kuò)容動(dòng)作?這些環(huán)節(jié)都包含在在線(xiàn)容量評(píng)估體系內(nèi)，這個(gè)體系可以實(shí)現(xiàn)壓測(cè)的過(guò)程。
我們剛才說(shuō)了壓測(cè)不是通過(guò)流量拷貝進(jìn)行模擬測(cè)試的，我們是針對(duì)目標(biāo)服務(wù)，就用線(xiàn)上的流量，記錄當(dāng)前(Ahits)數(shù)，開(kāi)始減少服務(wù)器的數(shù)量，一直到慢速比達(dá)到臨界值的時(shí)候，記錄 Ahits 數(shù)作為本服務(wù)單元最大的消耗。
得到消耗值后和水位線(xiàn)進(jìn)行對(duì)比，調(diào)用決策系統(tǒng)做出是否擴(kuò)縮容的決定，接下來(lái)再對(duì)接云服務(wù)商，就完成了擴(kuò)容的動(dòng)作。
⑥實(shí)時(shí)演練體系
前面進(jìn)行的數(shù)據(jù)采集、計(jì)算，以及動(dòng)作的串聯(lián)，都是為了完成最后一個(gè)目標(biāo)，服務(wù)擴(kuò)容成功。
真正的服務(wù)器擴(kuò)容到線(xiàn)上之后，怎么樣才能保證服務(wù)是健康可用的呢?我們還有另外一套輔助系統(tǒng)叫擴(kuò)容演練。在實(shí)時(shí)演練過(guò)程中，要注意以下幾點(diǎn)：
部署效率：我們通過(guò)擴(kuò)容演練來(lái)尋找整個(gè)擴(kuò)容過(guò)程中的瓶頸，比如，我們下發(fā)是通過(guò) DCP 對(duì)接云服務(wù)商來(lái)完成擴(kuò)容的。
在真正的線(xiàn)上擴(kuò)容過(guò)程中，DCP 有時(shí)要同時(shí)承載幾千臺(tái)節(jié)點(diǎn)的擴(kuò)容并發(fā)。DCP 的效率是否能夠滿(mǎn)足?在擴(kuò)容演練過(guò)程中需要確認(rèn)這一點(diǎn)。
帶寬限制：微博和云服務(wù)商之間確實(shí)是拉了專(zhuān)線(xiàn)，但是微博和云服務(wù)商不只是微博廣告的一個(gè)業(yè)務(wù)，還有很多其他大戶(hù)。
而且一般在流量增加的時(shí)候他們的擴(kuò)容也是非常猛烈的，所以帶寬是否可用，也是我們?cè)谌粘Ｑ菥氝^(guò)程中非常注意的現(xiàn)象。
依賴(lài)服務(wù)：這方面有很多案例，在這里簡(jiǎn)單分享一下，2015 年春節(jié)，自動(dòng)擴(kuò)縮容的流程才剛剛開(kāi)始，春節(jié)當(dāng)天晚上我們擴(kuò)容完幾千個(gè)節(jié)點(diǎn)后，忽然發(fā)現(xiàn)負(fù)載均衡加不上去。
之前做過(guò)演練，但不會(huì)拿幾千臺(tái)云服務(wù)器進(jìn)行擴(kuò)容，可能幾十臺(tái)確保功能可用就可以了，到時(shí)候要讓負(fù)載均衡的同事通過(guò)配置文件增加下 Memeber 就可以。
如果上千臺(tái)的服務(wù)器沒(méi)有辦法增加到負(fù)載均衡設(shè)備，那個(gè)時(shí)候大家手忙腳亂，最后通過(guò)手動(dòng)的方式擴(kuò)容節(jié)點(diǎn)。
大家知道春晚的流量高峰很短，但那天確實(shí)給了我們當(dāng)頭一棒。接下來(lái)我們?cè)跀U(kuò)容演練過(guò)程中，不僅會(huì)對(duì)負(fù)載均衡進(jìn)行確認(rèn)，還會(huì)對(duì)我們依賴(lài)的服務(wù)進(jìn)行確認(rèn)。
比如每次發(fā)生熱點(diǎn)事件時(shí)，大家會(huì)說(shuō)微博又崩了，評(píng)論又崩了，熱搜出不來(lái)了。
其實(shí)應(yīng)對(duì)峰值流量是件很頭大的事情，我把事情解決了，兄弟部門(mén)沒(méi)有解決，兄弟部門(mén)解決了，姐妹部門(mén)又出現(xiàn)了問(wèn)題。
安全限制：618 大促時(shí)，京東的同學(xué)分享了在擴(kuò)容的時(shí)候新增的服務(wù)器 IP 與 VIP 發(fā)生了沖突，而微博主要的體現(xiàn)就是數(shù)據(jù)庫(kù)會(huì)對(duì)很多業(yè)務(wù)的請(qǐng)求設(shè)置白名單，可是云服務(wù)器擴(kuò)容之后 IP 是隨機(jī)的。
另外，新浪對(duì)于通行證有很多 IP 限制，所以我們通過(guò)擴(kuò)容演練體系不斷發(fā)現(xiàn)各個(gè)環(huán)節(jié)中的問(wèn)題，加以解決，保證在擴(kuò)容動(dòng)作進(jìn)行時(shí)能夠順利地完成，保證擴(kuò)容出來(lái)的云主機(jī)真正安全上線(xiàn)服務(wù)。
有了這個(gè)系統(tǒng)的加持，截止到現(xiàn)在自動(dòng)擴(kuò)容服務(wù)都處于比較穩(wěn)定的狀態(tài)。
智能監(jiān)控
在上文提到的自動(dòng)擴(kuò)縮容體系當(dāng)中，提到一個(gè)叫 Oops 的系統(tǒng)，這是微博廣告運(yùn)維人員建立的智能監(jiān)控系統(tǒng)，接下來(lái)給大家簡(jiǎn)單介紹一下。
監(jiān)控面臨的挑戰(zhàn)
說(shuō)到監(jiān)控，不得不說(shuō)監(jiān)控遇到的很多問(wèn)題。市面上有很多開(kāi)源的監(jiān)控軟件，比如說(shuō)常見(jiàn)的 Zabbix，在監(jiān)控?cái)?shù)據(jù)量少的情況下，不管是基礎(chǔ)監(jiān)控還是業(yè)務(wù)監(jiān)控，這些開(kāi)源軟件都是可以直接滿(mǎn)足需求的。
但是隨著監(jiān)控指標(biāo)的增多，加上我們的指標(biāo)是實(shí)時(shí)性變化的，數(shù)據(jù)要求又比較高，這些原生軟件不再滿(mǎn)足我們需求了。
另外，微博廣告的業(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)控的日志收集方法是不能滿(mǎn)足需求的，這也是我們面臨的挑戰(zhàn)。
另外，監(jiān)控系統(tǒng)一般都會(huì)具備告警功能，有告警就會(huì)有告警問(wèn)題，接下來(lái)會(huì)詳細(xì)地介紹告警問(wèn)題。
還面臨定位方面的挑戰(zhàn)，在監(jiān)控越來(lái)越完善的基礎(chǔ)上，很多開(kāi)發(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è)階段：
- 從客戶(hù)端進(jìn)行數(shù)據(jù)采集
- 數(shù)據(jù)的清洗和計(jì)算
- 數(shù)據(jù)存儲(chǔ)
- 數(shù)據(jù)展示
監(jiān)控?cái)?shù)據(jù)流向特點(diǎn)
所有的監(jiān)控系統(tǒng)都逃不開(kāi)這四個(gè)階段，只是根據(jù)業(yè)務(wù)的不同進(jìn)行了定制化的工作。
針對(duì)廣告業(yè)務(wù)的監(jiān)控流向，我們把數(shù)據(jù)分成兩類(lèi)，有一部分精密數(shù)據(jù)的計(jì)算，我們采取的是離線(xiàn)分析的方式，通過(guò)采集軟件將所有的日志采集到 Kafka，通過(guò)計(jì)算的工具進(jìn)行拆洗、計(jì)算，計(jì)算之后落存儲(chǔ)。
還有另外一個(gè)團(tuán)隊(duì)開(kāi)發(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ā)生了變化，我們并不采集全量日志，而是在客戶(hù)端做了預(yù)處理，進(jìn)行分類(lèi)計(jì)算。
比如說(shuō)監(jiān)控?cái)?shù)據(jù)，就按監(jiān)控?cái)?shù)據(jù)的方法計(jì)算;告警數(shù)據(jù)，就按告警數(shù)據(jù)的計(jì)算。而且按照用戶(hù)讀取的需求進(jìn)行分類(lèi)存儲(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)行分類(lèi)聚合，最終向后推送的數(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)于分類(lèi)計(jì)算，不同的需求推送給不同的計(jì)算節(jié)點(diǎn)。存儲(chǔ)也進(jìn)行了分類(lèi)，實(shí)時(shí)性要求比較強(qiáng)的話(huà)會(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)行了分類(lèi)計(jì)算、分類(lèi)存儲(chǔ)，這種分類(lèi)的需求來(lái)源于用戶(hù)，需要看用戶(hù)有什么要求，要什么樣的數(shù)據(jù)。
比如，Dashboard 的展示數(shù)據(jù)會(huì)直接被放到內(nèi)存里。另外，上文提到的在線(xiàn)擴(kuò)縮容數(shù)據(jù)，會(huì)相應(yīng)獲取數(shù)據(jù)給用戶(hù)，其他相關(guān)的獲取需求 API 也會(huì)進(jìn)行分類(lèi)獲取。
接下來(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)色跟綠色的流量線(xiàn)已經(jīng)降下來(lái)了，大部分量調(diào)到云服務(wù)器上。
下圖是我們的九宮格，因?yàn)闀r(shí)效性比較強(qiáng)，正常來(lái)說(shuō)是以產(chǎn)品為頁(yè)面，以業(yè)務(wù)線(xiàn)為格子，每個(gè)格子記錄的是單機(jī)的詳細(xì)信息。
如果在這一組服務(wù)器當(dāng)中單機(jī)故障數(shù)超過(guò)一定的比例，這個(gè)格子會(huì)變顏色。
所以在正常的運(yùn)維工位上都會(huì)有這樣的大屏幕，運(yùn)維可以一目了然發(fā)現(xiàn)自己所有負(fù)責(zé)的業(yè)務(wù)線(xiàn)情況，而不是讓一臺(tái)臺(tái)機(jī)器在這里展現(xiàn)，這樣就沒(méi)有辦法看到業(yè)務(wù)線(xiàn)情況了。九宮格可以讓運(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í)行，一直到告警條件不被滿(mǎn)足，如果服務(wù)一直不恢復(fù)，就會(huì)重復(fù)報(bào)下去，另外，同一個(gè)故障也可能引發(fā)不同層次的告警。
比如，我們有一個(gè)業(yè)務(wù)線(xiàn)叫超粉，會(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)警，但這類(lèi)報(bào)警要么不再重現(xiàn)，要么可以自愈。
比如一個(gè)硬盤(pán)在接近 80% 的時(shí)候開(kāi)始告警了，你讓它告嗎?好像得告，但似乎不告也可以。
④告警模式粗放
無(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è)情況。
②告警的分類(lèi)和分級(jí)
詳細(xì)定義告警級(jí)別，發(fā)送優(yōu)先級(jí)、升級(jí)策略等，可有效減少粗放模式下告警接收量。比如，一些低優(yōu)先等級(jí)的告警會(huì)讓它告，處理的級(jí)別會(huì)低一點(diǎn)。
③同類(lèi)合并
同一個(gè)原因可能會(huì)觸發(fā)一個(gè)服務(wù)池里面的所有實(shí)例都報(bào)警，比如同時(shí)無(wú)法連接數(shù)據(jù)庫(kù)，其實(shí)只需要報(bào)一次即可。
④變更忽略
我們的好多變更都是在 Kunkka 平臺(tái)上操作的，開(kā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í)候，開(kāi)發(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)的前后哪些業(yè)務(wù)也出現(xiàn)了流量變化，方便對(duì)故障原因進(jìn)行分析和定位。
服務(wù)治理
還有一項(xiàng)非常重要的工作——服務(wù)治理，這里只進(jìn)行簡(jiǎn)單的介紹。
為什么需要服務(wù)治理
微博廣告現(xiàn)階段所出現(xiàn)的問(wèn)題主要有：架構(gòu)越來(lái)越復(fù)雜，上文提到微博廣告的服務(wù)器已經(jīng)達(dá)到 3000 臺(tái)。
所以在這種服務(wù)器數(shù)量情況下，架構(gòu)會(huì)越來(lái)越復(fù)雜，穩(wěn)定性要求也變得非常高;開(kāi)發(fā)的多語(yǔ)言環(huán)境對(duì)上線(xiàn)發(fā)布也造成了挑戰(zhàn);資源使用是否合理，對(duì)運(yùn)維來(lái)說(shuō)也是一個(gè)挑戰(zhàn)。
低成本和高可用的平衡
針對(duì)這些問(wèn)題，我們進(jìn)行了低成本和高可用的平衡，爭(zhēng)取用最小的服務(wù)器達(dá)到最穩(wěn)定的架構(gòu)。
在保證服務(wù)穩(wěn)定的情況下，將流量進(jìn)行均分，分到最小服務(wù)單元三機(jī)房部署為基本規(guī)則，保障在一個(gè)機(jī)房掛掉的情況下，另外 2/3 的服務(wù)器能承載全部的流量。
關(guān)于上下游之間調(diào)用的平衡，盡量減少跨運(yùn)營(yíng)商的調(diào)用，微博廣告每一毫秒的消耗都會(huì)影響到收入。
我們的請(qǐng)求時(shí)間是 1 毫秒、1 毫秒地優(yōu)化下來(lái)的，這些損耗產(chǎn)生在網(wǎng)絡(luò)和服務(wù)器上，很難通過(guò)人力彌補(bǔ)，因此在這方面我們也非常謹(jǐn)慎。
另外，小功能會(huì)抽象出功能的共同點(diǎn)，將這些功能服務(wù)化，服務(wù)則按單元化部署。
服務(wù)發(fā)現(xiàn)及負(fù)載均衡
在服務(wù)治理過(guò)程中，我們會(huì)根據(jù)服務(wù)的引入服務(wù)自動(dòng)發(fā)現(xiàn)，盡量減少服務(wù)變更環(huán)節(jié)的人工干預(yù)，提高安全性和實(shí)時(shí)性，自建負(fù)載均衡會(huì)有標(biāo)準(zhǔn)的數(shù)據(jù)輸入和數(shù)據(jù)發(fā)布的過(guò)程，可以大大提升后期的可擴(kuò)展性和可用性。
服務(wù)治理成績(jī)
經(jīng)過(guò)近半年的服務(wù)治理，我們達(dá)到了這樣的成績(jī)：
- 架構(gòu)更加強(qiáng)健，容災(zāi)能力提高
- 系統(tǒng)、數(shù)據(jù)、配置標(biāo)準(zhǔn)化
- 服務(wù)器的合理使用，成本控制
其中，我覺(jué)得最重要的是系統(tǒng)、數(shù)據(jù)、配置標(biāo)準(zhǔn)化的過(guò)程。
今天好多分享的嘉賓也提到了 AIOps，這些上層的建設(shè)都是依賴(lài)于整個(gè)業(yè)務(wù)標(biāo)準(zhǔn)化的過(guò)程。
中國(guó)有句古話(huà)，工欲善其事，必先利其器，我們所有的標(biāo)準(zhǔn)化過(guò)程就是為下一步人工智能打下堅(jiān)實(shí)的基礎(chǔ)，希望我們的工作能夠以技術(shù)保證微博系統(tǒng)穩(wěn)定，助力微博廣告的收入。
[[279819]]
孫燕，微博廣告基礎(chǔ)運(yùn)維負(fù)責(zé)人，2009 年入職新浪，任職 10 年間參與博客、圖片、視頻、微博平臺(tái)監(jiān)控、微博廣告多個(gè)產(chǎn)品運(yùn)維，致力于運(yùn)維自動(dòng)化、產(chǎn)品架構(gòu)優(yōu)化、服務(wù)治理、智能監(jiān)控及以監(jiān)控為依托的服務(wù)容災(zāi)建設(shè)。
網(wǎng)頁(yè)題目：3000臺(tái)服務(wù)器不宕機(jī)，微博廣告系統(tǒng)全景運(yùn)維大法
分享URL：http://www.fisionsoft.com.cn/article/cdopicc.html
