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

這樣的自動化運維平臺基本上滿足了運維的日常操作需求，在 Kunkka 平臺中還有自動擴縮容的功能，我們針對這個功能進行延伸。

在自動擴所容的基礎上，根據(jù)時間段，流量進行動態(tài)判斷，自動決策的擴所容夠功能。

彈性計算

為什么需要彈性計算

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

在云服務商方面，我們常用阿里云、華為云跟一部分自建的私有云。DCP 混合平臺是我們微博另外一個團隊做了幾年的平臺，它能夠對接云服務，快速生成

現(xiàn)在拿到了一個非常重要的容量值及消耗比來進行容量評估，用于描述當前的容量消耗情況。

拿到這個消耗比之后是不是就可以擴容了?還是可以縮容了?此處還需要一個評估標準，是 30% 就擴?還是 50% 再擴?

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

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

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

⑤在線容量評估體系

前面進行的數(shù)據(jù)采集、計算，以及動作的串聯(lián)，都是為了完成最后一個目標，服務擴容成功。

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

部署效率：我們通過擴容演練來尋找整個擴容過程中的瓶頸，比如，我們下發(fā)是通過 DCP 對接云服務商來完成擴容的。

在真正的線上擴容過程中，DCP 有時要同時承載幾千臺節(jié)點的擴容并發(fā)。DCP 的效率是否能夠滿足?在擴容演練過程中需要確認這一點。

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

而且一般在流量增加的時候他們的擴容也是非常猛烈的，所以帶寬是否可用，也是我們在日常演練過程中非常注意的現(xiàn)象。

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

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

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

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

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

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

另外，監(jiān)控系統(tǒng)一般都會具備告警功能，有告警就會有告警問題，接下來會詳細地介紹告警問題。

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

一旦發(fā)生問題，第一個反應并不是上服務器看一下系統(tǒng)怎么了，而是翻監(jiān)控，看看哪些監(jiān)控指標發(fā)生了問題，所以監(jiān)控系統(tǒng)會越來越多地面向于問題定位這個方向。

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

作為監(jiān)控系統(tǒng)，Oops 在架構上并沒有什么出奇的地方，所有的監(jiān)控無非就是四個階段：

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

監(jiān)控數(shù)據(jù)流向特點

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

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

還有另外一個團隊開發(fā)的針對于這一部分數(shù)據(jù)的頁面展示化，還有一個系統(tǒng)叫 Hubble，針對精細數(shù)據(jù)的展現(xiàn)，實現(xiàn)個性化定制的展現(xiàn)。

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

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

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

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

接下來詳細介紹實時數(shù)據(jù)計算。

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

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

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

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

另外，關于分類計算，不同的需求推送給不同的計算節(jié)點。存儲也進行了分類，實時性要求比較強的話會直接放到內存，以最精細粒度進行存儲。

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

另外一些歷史性的數(shù)據(jù)需要出報表的，比如說要看前一周的數(shù)據(jù)，前一個月的數(shù)據(jù)，按照大數(shù)據(jù)的方式存到 OpenTSDB 當中。

存儲的數(shù)據(jù)提供一個 API，通過 API 我們進行了分類計算、分類存儲，這種分類的需求來源于用戶，需要看用戶有什么要求，要什么樣的數(shù)據(jù)。

比如，Dashboard 的展示數(shù)據(jù)會直接被放到內存里。另外，上文提到的在線擴縮容數(shù)據(jù)，會相應獲取數(shù)據(jù)給用戶，其他相關的獲取需求 API 也會進行分類獲取。

接下來我們計算過的數(shù)據(jù)還有一部分會存儲到 Redis 通過 WatchD 作為告警中心的數(shù)據(jù)，因為告警數(shù)據(jù)一般都只要求當前數(shù)據(jù)，不會有人需要查看上個月這臺機器的負載有沒有告警。

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

同時有一個相對個性化的展示叫九宮格。我們的九宮格實際上是一個結合報警功能的監(jiān)控，它是一個頁面，但具備了告警功能。

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

第三張圖是拿到這些數(shù)據(jù)之后，自動平臺顯示應該擴容了。藍色跟綠色的流量線已經(jīng)降下來了，大部分量調到

下圖是我們的九宮格，因為時效性比較強，正常來說是以產(chǎn)品為頁面，以業(yè)務線為格子，每個格子記錄的是單機的詳細信息。

如果在這一組服務器當中單機故障數(shù)超過一定的比例，這個格子會變顏色。

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

告警

告警有很多的問題，我們遇到的問題可以分為以下四個方面：

①告警數(shù)量巨大

運維人員需要關注所有部分，從系統(tǒng)到服務、接口等等，維度很多，一旦有問題，各種策略都會觸發(fā)報警，報警數(shù)量多到一定程度，基本上等于沒有報警。

②重復告警率高

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

比如，我們有一個業(yè)務線叫超粉，會有 360 臺服務器，流量高峰時 360 臺服務器會同時發(fā)送告警，這種告警的重復率很高。

③告警有效性不足

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

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

④告警模式粗放

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

針對這些問題，我們采取了以下措施：

①抖動收斂

對于這種大規(guī)模服務器的維護，抖動是非常常見的現(xiàn)象。網(wǎng)絡抖一抖，整個服務單元就會向你告警。

針對這種抖動，我們增加了一些策略，抖動的時候會前后比較，監(jiān)測重復性，看看是不是具備告警的意義，通過增加告警策略這種方式來進行收斂。

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

②告警的分類和分級

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

③同類合并

同一個原因可能會觸發(fā)一個服務池里面的所有實例都報警，比如同時無法連接數(shù)據(jù)庫，其實只需要報一次即可。

④變更忽略

我們的好多變更都是在 Kunkka 平臺上操作的，開發(fā)有時候會選中一個通知，現(xiàn)在是變更，告警請忽略。

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

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

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

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

等故障出現(xiàn)的時候，開發(fā)人員就會去翻監(jiān)控圖，去查看大概是哪些原因導致了故障。

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

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

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

新聞名稱：3000臺服務器不宕機，微博廣告系統(tǒng)全景運維大法
網(wǎng)址分享：http://www.rwnh.cn/news/97690.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、微信公眾號、外貿建站、動態(tài)網(wǎng)站、網(wǎng)站收錄、品牌網(wǎng)站建設

廣告

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