本文根據(jù)孫燕老師在《2019DAMS中國數(shù)據(jù)智能管理峰會》現(xiàn)場演講內(nèi)容整理而成。
講師介紹
孫燕，微博廣告基礎(chǔ)運維負責人，2009年入職新浪，任職10年間參與博客、圖片、視頻、微博平臺監(jiān)控、微博廣告多個產(chǎn)品運維，致力于運維自動化、產(chǎn)品架構(gòu)優(yōu)化、服務(wù)治理、智能監(jiān)控及以監(jiān)控為依托的服務(wù)容災建設(shè)。
在上文提到的自動擴縮容體系當中，提到一個叫Oops的系統(tǒng)，這是微博廣告運維人員建立的智能監(jiān)控系統(tǒng)。接下來給大家簡單介紹一下。
1、監(jiān)控面臨的挑戰(zhàn)
說到監(jiān)控，不得不說監(jiān)控遇到的很多問題。
市面上有很多開源的監(jiān)控軟件，比如說常見的Zabbix，在監(jiān)控數(shù)據(jù)量少的情況下，不管是基礎(chǔ)監(jiān)控還是業(yè)務(wù)監(jiān)控，這些開源軟件都是可以直接滿足需求的。
但是隨著監(jiān)控指標的增多，加上我們的指標是實時性變化的，數(shù)據(jù)要求又比較高，這些原生軟件不再滿足我們需求了。另外，微博廣告的業(yè)務(wù)數(shù)據(jù)有特殊性，一般運維關(guān)注的數(shù)據(jù)是系統(tǒng)的性能，系統(tǒng)的性能數(shù)據(jù)有時候來源于業(yè)務(wù)日志。
但是微博廣告的業(yè)務(wù)日志是收入，很多業(yè)務(wù)日志是一條都不能丟的，比如說結(jié)算的曝光每一條曝光對于廣告來說，都是真金白銀，對精準性要求比較高，單獨通過性能監(jiān)控的日志收集方法是不能滿足需求的，這也是我們面臨的挑戰(zhàn)。
另外，監(jiān)控系統(tǒng)一般都會具備告警功能，有告警就會有告警問題，接下來會詳細地介紹告警問題。還面臨問題定位方面的挑戰(zhàn)，在監(jiān)控越來越完善的基礎(chǔ)上，很多開發(fā)的操作情況發(fā)生了變化，一旦發(fā)生問題，第一個反應(yīng)并不是上服務(wù)器看一下系統(tǒng)怎么了，而是翻監(jiān)控，看看哪些監(jiān)控指標發(fā)生了問題，所以監(jiān)控系統(tǒng)會越來越多地面向于問題定位這個方向。
2、Oops整體架構(gòu)面臨的挑戰(zhàn)
作為監(jiān)控系統(tǒng)，Oops在架構(gòu)上并沒有什么出奇的地方，所有的監(jiān)控無非就是四個階段：從客戶端進行數(shù)據(jù)采集、數(shù)據(jù)的清洗和計算、數(shù)據(jù)存儲、數(shù)據(jù)展示。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
3、監(jiān)控數(shù)據(jù)流向特點
所有的監(jiān)控系統(tǒng)都逃不開這四個階段，只是根據(jù)業(yè)務(wù)的不同進行了定制化的工作。針對廣告業(yè)務(wù)的監(jiān)控流向，我們把數(shù)據(jù)分成兩類，有一部分精密數(shù)據(jù)的計算，我們采取的是離線分析的方式，通過采集軟件將所有的日志采集到Kafka，通過計算的工具進行拆洗、計算，計算之后落存儲，還有另外一個團隊開發(fā)的針對于這一部分數(shù)據(jù)的頁面展示化，還有一個系統(tǒng)叫hubble，針對精細數(shù)據(jù)的展現(xiàn)，實現(xiàn)個性化定制的展現(xiàn)。
另外一部分是運維比較關(guān)心的數(shù)據(jù)，今天來了多少流量？流量有多少是正常的？有多少是異常的？平均耗時是多少？針對這一部分，我們采取了實時數(shù)據(jù)計算的方法。
在數(shù)據(jù)采集階段發(fā)生了變化，我們并不采集全量日志，而是在客戶端做了預處理，進行分類計算。比如說監(jiān)控數(shù)據(jù)，就按監(jiān)控數(shù)據(jù)的方法計算；告警數(shù)據(jù)，就按告警數(shù)據(jù)的計算。而且按照用戶讀取的需求進行分類存儲，保證了高并發(fā)數(shù)據(jù)的實時性。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
4、海量指標監(jiān)控系統(tǒng)流程
接下來詳細介紹實時數(shù)據(jù)計算。首先從數(shù)據(jù)采集上講，上文提到我們不采取全量的采集方式，而是通過Agent對數(shù)據(jù)進行處理，在數(shù)據(jù)采集階段，在數(shù)據(jù)產(chǎn)生的服務(wù)器上，針對不同的需求按不同的時間進行分類聚合，最終向后推送的數(shù)據(jù)是key-value、計算方法這種模式，推送給proxy。proxy拿到已經(jīng)被打包的數(shù)據(jù)進行拆包，然后送給不同的計算結(jié)點，再按照key進行計算，打時間戳。
這個數(shù)據(jù)并不精準，但我們可以接受部分損失，只需要保證數(shù)據(jù)的趨勢是正確的。另外，關(guān)于分類計算，不同的需求推送給不同的計算節(jié)點。存儲也進行了分類，實時性要求比較強的話會直接放到內(nèi)存，以最精細粒度進行存儲。前三個小時的數(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ù)會直接被放到內(nèi)存里。另外，上文提到的在線擴縮容數(shù)據(jù)，會相應(yīng)獲取數(shù)據(jù)給用戶，其他相關(guān)的獲取需求API也會進行分類獲取。
接下來我們計算過的數(shù)據(jù)還有一部分會存儲到Redis通過WatchD作為告警中心的數(shù)據(jù)，因為告警數(shù)據(jù)一般都只要求當前數(shù)據(jù)，不會有人需要查看上個月這臺機器的負載有沒有告警。
所以Alert節(jié)點計算之后的數(shù)據(jù)直接存在Redis，Redis把這個數(shù)據(jù)拿出來之后經(jīng)過告警中心根據(jù)告警規(guī)則進行清洗，通過各種方式推送到需求方。同時有一個相對個性化的展示叫九宮格。我們的九宮格實際上是一個結(jié)合報警功能的監(jiān)控，它是一個頁面，但具備了告警功能。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
接下來看一下監(jiān)控圖，下面三張圖是范冰冰宣布分手拿到的流量，我們的反映是非常靈敏的，平均耗時也漲上來了。
第三張圖是拿到這些數(shù)據(jù)之后，自動平臺顯示應(yīng)該擴容了。藍色跟綠色的流量線已經(jīng)降下來了，大部分量調(diào)到云服務(wù)器上。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
下圖是我們的九宮格，因為時效性比較強，正常來說是以產(chǎn)品為頁面，以業(yè)務(wù)線為格子，每個格子記錄的是單機的詳細信息。如果在這一組服務(wù)器當中單機故障數(shù)超過一定的比例，這個格子會變顏色。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
所以在正常的運維工位上都會有這樣的大屏幕，運維可以一目了然發(fā)現(xiàn)自己所有負責的業(yè)務(wù)線情況，而不是讓一臺臺機器在這里展現(xiàn)，這樣就沒有辦法看到業(yè)務(wù)線情況了。九宮格可以讓運維更加直觀地看到當前的告警情況。
5、告警
告警有很多的問題，我們遇到的問題可以分為以下四個方面：
1）告警數(shù)量巨大
運維人員需要關(guān)注所有部分，從系統(tǒng)到服務(wù)、接口等等，維度很多，一旦有問題，各種策略都會觸發(fā)報警，報警數(shù)量多到一定程度，基本上等于沒有報警。
2）重復告警率高
告警策略一般會周期性執(zhí)行，一直到告警條件不被滿足，如果服務(wù)一直不恢復，就會重復報下去，另外，同一個故障也可能引發(fā)不同層次的告警。
比如，我們有一個業(yè)務(wù)線叫超粉，會有360臺服務(wù)器，流量高峰時360臺服務(wù)器會同時發(fā)送告警，這種告警的重復率很高。
3）告警有效性不足
很多時候，網(wǎng)絡(luò)抖動、擁堵、負載暫時過高或者變更等原因，會觸發(fā)報警，但這類報警要么不再重現(xiàn)，要么可以自愈。
比如一個硬盤在接近80%的時候開始告警了，你讓它告嗎？好像得告，但似乎不告也可以。
4）告警模式粗放
無論是否重要、優(yōu)先級如何，告警都通過郵件、短信、AppPUSH發(fā)送到接收人，就像暴風一樣襲擊著接收人，接收人沒有辦法從中獲取到有效的信息，經(jīng)常會讓真正重要的告警淹沒在一大堆普通告警中。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
針對這些問題，我們采取了以下措施：
1）抖動收斂
對于這種大規(guī)模服務(wù)器的維護，抖動是非常常見的現(xiàn)象。網(wǎng)絡(luò)抖一抖，整個服務(wù)單元就會向你告警。
針對這種抖動，我們增加了一些策略，抖動的時候會前后比較，監(jiān)測重復性，看看是不是具備告警的意義，通過增加告警策略這種方式來進行收斂。比如說流量突增的時候，需要查看是不是同單元都出現(xiàn)了這個情況。
2）告警的分類和分級
詳細定義告警級別，發(fā)送優(yōu)先級、升級策略等，可有效減少粗放模式下告警接收量。比如，一些低優(yōu)先等級的告警會讓它告，處理的級別會低一點。
3）同類合并
同一個原因可能會觸發(fā)一個服務(wù)池里面的所有實例都報警，比如同時無法連接數(shù)據(jù)庫，其實只需要報一次即可。
4）變更忽略
我們的好多變更都是在Kunkka平臺上操作的，開發(fā)有時候會選中一個通知，現(xiàn)在是變更，告警請忽略。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
以上措施能解決告警問題中80%的問題，現(xiàn)在大家都在朝著更高級的方向發(fā)展，我們也簡單做了一些探索。在原有告警數(shù)據(jù)流情況下引入了工具SkyLine，這個工具包含了多種算法，在異常檢測環(huán)節(jié)中，能夠通過它內(nèi)置的算法將我們傳入的數(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)控圖，去查看大概是哪些原因?qū)е铝斯收稀ｋS著Dashboard越來越多，即便是經(jīng)驗非常豐富的工作人員也很難快速地定位到原因會出現(xiàn)哪個方面、該去去看哪張個監(jiān)控圖。
出現(xiàn)流量突增的情況時，Skyline會通過內(nèi)部的算法Luminosity尋找相似的情況，查看相同的時間內(nèi)是否有其他地方出現(xiàn)流量異常，并將根源問題展示在TOPN上，這樣就能夠快速查看在故障出現(xiàn)的前后哪些業(yè)務(wù)也出現(xiàn)了流量變化，方便對故障原因進行分析和定位。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
還有一項非常重要的工作——服務(wù)治理，這里只進行簡單的介紹。
1、為什么需要服務(wù)治理
微博廣告現(xiàn)階段所出現(xiàn)的問題主要有：架構(gòu)越來越復雜，上文提到微博廣告的服務(wù)器已經(jīng)達到3000臺，所以在這種服務(wù)器數(shù)量情況下，架構(gòu)會越來越復雜，穩(wěn)定性要求也變得非常高；開發(fā)的多語言環(huán)境對上線發(fā)布也造成了挑戰(zhàn)；資源使用是否合理性，對運維來說也是一個挑戰(zhàn)。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
2、低成本和高可用的平衡
針對這些問題，我們進行了低成本和高可用的平衡，爭取用最小的服務(wù)器達到最穩(wěn)定的架構(gòu)。在保證服務(wù)穩(wěn)定的情況下，將流量進行均分，分到最小服務(wù)單元三機房部署為基本規(guī)則，保障在一個機房掛掉的情況下，另外2/3的服務(wù)器能承載全部的流量。
關(guān)于上下游之間調(diào)用的平衡，盡量減少跨運營商的調(diào)用，微博廣告每一毫秒的消耗都會影響到收入。我們的請求時間是1毫秒、1毫秒地優(yōu)化下來的，這些損耗產(chǎn)生在網(wǎng)絡(luò)和服務(wù)器上，很難通過人力彌補，因此在這方面我們也非常謹慎。
另外，小功能會抽象出功能的共同點，將這些功能服務(wù)化，服務(wù)則按單元化部署。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
3、服務(wù)發(fā)現(xiàn)及負載均衡
在服務(wù)治理過程中，我們會根據(jù)服務(wù)的引入服務(wù)自動發(fā)現(xiàn)，盡量減少服務(wù)變更環(huán)節(jié)的人工干預，提高安全性和實時性，自建負載均衡會有標準的數(shù)據(jù)輸入和數(shù)據(jù)發(fā)布的過程，可以大大提升后期的可擴展性和可用性。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
4、服務(wù)治理成績
經(jīng)過近半年的服務(wù)治理，我們達到了這樣的成績：
架構(gòu)更加強健，容災能力提高；
系統(tǒng)、數(shù)據(jù)、配置標準化；
服務(wù)器的合理使用，成本控制。
圖片來源于：《2019DAMS中國數(shù)據(jù)智能管理峰會》PPT
其中，我覺得最重要的是系統(tǒng)、數(shù)據(jù)、配置標準化的過程。
今天好多分享的嘉賓也提到了AIops，這些上層的建設(shè)都是依賴于整個業(yè)務(wù)標準化的過程，中國有句古話，工欲善其事，必先利其器，我們所有的標準化過程就是為下一步人工智能打下堅實的基礎(chǔ)，希望我們的工作能夠以技術(shù)保證微博系統(tǒng)穩(wěn)定，助力微博廣告的收入。
我們立即與您溝通
營銷產(chǎn)品
旗下平臺
聯(lián)系我們
關(guān)注天擎天拓
