支持百億請求的微博廣告運維技術實踐

本文由 dbaplus 社羣授權轉載。

一、運維在廣告體系中的價值

運維的工作來源已久,但直到近些年,隨着互聯網的發展,產品的維護工作越來越複雜,以及服務可用性的提升,都讓運維的工作越來越重要。我們可以回顧下運維發展至今都經歷了哪些階段。

① 人工階段

這個階段的運維主要通過人肉操作我們的服務,由於這個階段的服務大都是單實例,流量服務器都比較少,所以我們通過命令行就能夠解決絕大多數的問題。

② 工具階段

隨着互聯網影響逐漸變大,我們的流量也開始變大,我們的產品功能也開始變得豐富,曾經我們單實例的服務也開始朝着多實例、分佈式發展,爲了應對逐漸增加的服務器、服務數,我們開始使用一些如Puppet的運維工具,通過Shell、Python寫一些腳本來提升運維的工作效率,減少重複的勞動。

③ DevOps

前幾年,運維領域開始提出DevOps的理念,開始着手解決運維與開發的合作問題,開始讓運維的工作走向規範化、平臺化。讓一個產品從功能開發到測試交付、再到後期運維能夠更加的快捷、頻繁、可靠,更快的響應互聯網快速的發展和產品迭代。

④ AiOps

這兩年,人工智能和大數據的異常火熱,而運維領域的許多工作都爲AI和大數據的實施落地提供了良好的土壤。我們也希望通過Ai和大數據等技術的引入,能夠將運維的技術層次帶入一個更高的臺階。

通過以上描述,我們可以看到運維的工作在互聯網的產品技術鏈中是不可或缺的一環,那麼下面我們再來看下在微博廣告團隊,我們都是通過哪些方案舉措來服務微博廣告的產品。

對於我們微博廣告團隊來說,服務的可用性是至關重要的,也是我們的核心KPI,所以保障廣告服務的穩定性也是我們運維工作的重中之重。我們主要會通過優化系統和提升效率兩個方面來保障和提升我們服務的可用性。

具體涉及的內容包括系統性能評估、故障迅速定位、應急事件處理、請求鏈路跟蹤、代碼快速迭代、指標走勢預測等等。

▲ 圖1-1 運維在微博廣告的價值

二、複雜業務場景下的運維建設之路

1、服務治理

圖2-1是去年IG奪冠時,王思聰發了一條博文,而這條博文對微博廣告的影響就如圖2-2所示。這種突發的流量波動是微博典型的特徵之一,它不同於雙十一等活動,可以提前預估流量,做好前期準備工作。在傳統的運維場景下,也許在你也還沒準備好的情況下,流量的高峯就已經過去了。所以如果應對這樣突發的流量高峯是我們需要重點解決的問題之一。

▲ 圖2-1

▲ 圖2-2

從去年開始,我們運維團隊開始進行基於機房的服務治理工作。在以前,廣告的很多服務部署都是單點單機房、很多多機房的部署也面臨部署不均衡,流量不均勻等現象。跨機房的請求更是無形的增加了整個廣告鏈路的請求耗時。所以再出現機房級故障時,我們的服務就可能像圖2-4所示的那樣,那麼服務的高可用性也就無從談起了。

▲ 圖2-3

▲ 圖2-4

在19年的上半年,經過大半年的時間,我們完成了微博廣告基於機房級別的服務優化改造。共治理服務一百多個,所有的服務都分佈在兩個及以上的運營商和機房中,從而避免了單機房出現故障時,造成廣告服務的不可用。而我們治理過程中堅持的準備主要有以下幾點:

  • 服務多機房均衡部署
  • 分佈在不同運營商
  • 機房承載能力冗餘
  • 流量請求均勻分佈
  • 上下游同機房請求

同時,我們還會定期做流量壓測,來發現我們系統鏈路中的服務瓶頸。我們將生產環境的流量重新拷貝到生產環境中去,來增加線上流量,發現服務性能瓶頸。

圖2-5是我們對某廣告產品的整體性能壓測所展示的效果,我們可以清楚的發現圖中有兩個模塊的在流量高峯下,出現了耗時波動較大的問題。由此我們可以針對性的進行優化。

▲ 圖2-5

2、自動化運維平臺

隨着互聯網的發展,我們的廣告產品也是日新月異,迭代頻繁。我們運維團隊每天需要面對來自三百多個業務方提過來的上線需求,在三千多臺機器上進行服務的變更等操作,如何提升服務上線的效率和質量,如何讓變更變得安全可靠也是我們重要的目標之一。

▲ 圖2-6

從17年開始,我們運維團隊自研了一套自動化運維平臺Kunkka,該平臺主要基於SaltStack、Jenkins等技術,可以實現服務的快速上線、快速回滾等操作。整體架構如圖2-7所示。

▲ 圖2-7 Kunkka整體架構圖

開發同學在提交代碼到Gitlab後,自動觸發Jenkins的編譯操作,並將編譯後的包上傳至Nexus中,這時開發同學只需要選擇他們想要部署的目標主機就可以了。

同時,爲了應對平常突發的流量高峯和節假日的流量高峯,我們還對接了公司的DCP平臺,可以在我們的Kunkka平臺上自動生成Docker鏡像文件,並上傳公司的鏡像倉庫中,這樣就可以在快速的將服務部署到雲主機上,實現服務動態擴縮容。

整個服務部署過程中,我們還加入了多級審覈機制,保障服務上線的安全性。具體流程如圖2-8所示。

▲ 圖2-8 Kunkka上線流程圖

3、有效的報警

在服務上線後,我們要做的一個很重要的工作就是給我們的服務添加監控報警機制,否則我們就像瞎子一樣,對我們系統服務運行情況一無所知。

關於報警系統業界優秀的報警系統有很多,使用的方案也基本大同小異。我們目前主要用的是開源的Prometheus報警系統,這裏就不詳細介紹了。

這裏主要想說下我們在做報警的一些想法。比如我們經常遇到的一個問題就是報警郵件狂轟濫炸,每天能收到成百上千的報警郵件,這樣很容易讓系統中一些重要的報警信息石沉大海。對此,我們主要以下三個方面來考慮:

  • 質疑需求的合理性
  • 報警聚合
  • 追蹤溯源

首先,在業務方提出報警需求的時候,我們就需要學會質疑他們的需求,因爲並不是每個需求都是合理的,其實很多開發他們並不懂報警,也不知道如果去監控自己的服務。這時候就是發揮我們運維人員的價值了。我們可以在充分了解服務架構屬性的前提下提出我們的意見,和開發人員共同確定每個服務需要報警的關鍵指標。

其次,我們可以對報警做預聚合。現在我們的服務大都都是多機部署的,一個服務有可能部署到成百上千臺機器上。有時候因爲人爲失誤或者上線策略等原因,可能導致該服務集體下線,這時就會有成百上千來自不同主機的相同報警信息發送過來。

對於這種場景,我們可以通過報警聚合的方式,將一段時間內相同的報警合併成一條信息,放在一封郵件裏面發送給開發人員,從而避免郵件轟炸的情況發生。關於報警聚合,像Prometheus這樣的報警系統自身已經支持,所以也不會有太多的開發量。

最後,再高層次,我們就可以通過一些策略、算法去關聯我們的報警。很多時候,一條服務鏈路上的某個環節出現問題可能導致整條鏈路上的多個服務都觸發了報警,這個時候,我們就可以通過服務與服務之間的相關性,上下游關係,通過一些依賴、算法等措施去屏蔽關聯的報警點,只對問題的根因進行報警,從而減少報警觸發的數量。

圖2-9是我們運維團隊17年優化報警期間,報警數量的走勢。

▲ 圖2-9 有效的報警

4、全鏈路Trace系統

除了添加報警以外,在服務上線後,我們還會經常需要跟蹤我們整個服務鏈路處理請求的性能指標需求。這時就需要有一套全鏈路的Trace系統來方便我們實時監控我們系統鏈路,及時排查問題,定位問題。

在全鏈路Trace系統中,最重要的就是Traceid,它需要貫穿整個鏈路,我們再通過Traceid來關聯所有的日誌,從而跟蹤一條請求在整個系統鏈路上的指標行爲。圖2-10是我們約定的用於全鏈路Trace的日誌格式信息。

▲ 圖2-10 日誌格式與解析

有了日誌後,我們就可以基於這些日誌進行分析關聯,就像上面說的,Traceid是我們整個系統的核心,我們通過Traceid來關聯所有的日誌。如圖2-11所示,所有的日誌會寫入Kafka中,並通過Flink進行實時的日誌解析處理,寫入ClickHouse中。有了這些關鍵指標數據後,我們就可以在此基礎上去做我們想做的事,比如形成服務拓撲進行請求跟蹤、日誌的檢索以及指標的統計分析等。

▲ 圖2-11 數據收集與處理

在所有的數據收集解析完成後,業務方就可以根據一些維度,比如UID,來跟蹤用戶的在整個廣告系統中請求處理情況,如圖2-12所示。隨後再將查詢的數據以Traceid維度進行關聯展示給用戶。

▲ 圖2-12 業務查詢

三、海量指標監控平臺Oops實踐

最後我們看下我們如何應對微博廣告海量指標數據下多維的監控需求。前文也說了,監控報警就像我們的眼睛,能夠讓我們實時的看到我們系統內部的運行情況,因此,每一個服務都應該有一些關鍵指標通過我們的監控報警系統展示出來,實時反饋系統的健康狀態。

如圖3-1所示,做一個監控平臺很容易,我們將指標、日誌等數據進行ETL清洗後寫入一個時序數據庫中,再通過可視化工具展示出來,對於有問題的指標通過郵件或者微信的方式報警出來。但是在這個過程中,隨着我們數據量的增長、我們指標的增長以及查詢複雜度的增加,我們可能會遇到監控指標延遲、數據偏差以及系統不穩定等問題。

▲ 圖3-1 監控平臺的挑戰

因此,在設計我們的監控系統時,就不能僅僅基於實現考慮,還需要考慮它的穩定性、實施性、準確性,同時還應儘量把系統做的簡單易用。

▲ 圖3-2 監控平臺的目標

而我們目前的監控平臺Oops,也是基於上述原則,經歷了多年的迭代和考驗。圖3-3是我們Oops監控平臺當前的整體架構。

▲ 圖3-3 Oops監控平臺架構

① 數據採集

整個平臺分爲四個層次,首先是我們的數據採集。我們當前主要通過Filebeat這樣一款優秀的開源採集客戶端來採集我們的日誌。對我們使用而言,Filebeat足夠的高效、輕量,使用起來也很靈活易用。

▲ 圖3-4 Filebeat架構圖

② 指標清洗

數據採集到Kafka後,我們再根據具體的業務需求將指標提取出來。如圖3-5所示,當前我們主要通過Flink來解析日誌,並寫入ClickHouse中。

同時,針對一些業務需求,我們需要將一些指標維度做關聯處理,這裏主要通過HBase實現指標的關聯,比如,有曝光和互動兩個日記,我們將曝光日誌中的mark_id字段作爲rowkey寫入HBase中,並儲存一個小時,當在時間窗口內互動日誌匹配到相同的mark_id時,就將曝光日誌的內容從HBase中取出,並與互動日誌組合成一條新的日誌,寫入到一個新的Kafka Topic中。

此外,我們還將Kafka中數據消費寫入ElasticSearch和HDFS中,用於日誌檢索和離線計算。

▲ 圖3-5 指標清洗

③ 指標儲存

當前,我們通過ClickHouse來儲存查詢我們的監控指標。最初也是選擇了流行的時序數據庫Graphite。但是在長期的使用中,我們發現在複雜的多維分析上,Graphite並沒有很好的體驗。在去年,我們將我們的監控指標引擎替換成了現在的ClickHouse,ClickHouse是一款優秀的開源OLAP引擎,它在多維分析等功能上相比傳統的時序數據庫具有很大的優勢。

同時,我們基於ClickHouse強大的函數功能和物化視圖表引擎構建了一個實時的指標倉庫。如圖3-6所示,我們會將清洗後的指標寫入到一張原始表中,比如這裏的ods_A,我們再根據具體的監控需求在ods_A表上進行維度的聚合。再比如,我們將請求維度按秒聚合成agg_A_1s,或者按照psid維度按分鐘聚合成agg_A_1m_psid,又或者我們按照用戶id維度來統計每個用戶的訪問次數。

由此我們可以實現不同時間維度和不同業務維度的組合分析查詢,同時提升了查詢響應速度,以及數據的重複利用率。而原始表的存在也讓我們可以根據不同的需求定製不同的複雜的聚合表數據。

▲ 圖3-6 實時指標倉庫

④ 指標可視化

最後,我們通過Grafana實現我們的指標可視化,Grafana應該是當前全球最受歡迎的監控可視化開源軟件,它支持很多的數據源,而ClickHouse也是其中之一,我們只需要寫一條SQL就可以按照我們的想法在Grafana上以圖表的形式呈現出來。如圖3-7呈現的監控圖就是圖3-8這樣一條簡單的SQL實現的。

▲ 圖3-7 折線圖監控指標

▲ 圖3-8 折線圖監控指標SQL語句

對於表格的指標監控展示,也很簡單,也是一條SQL就能完成的,如圖3-9所示。

▲ 圖3-9 表格監控指標

當前我們的實時指標倉庫存儲120T的數據量,峯值處理QPS在125萬左右,秒級查詢、多維分析,爲微博廣告的指標監控、數據分析以及鏈路跟蹤等場景提供了底層數據支撐。

作者介紹

朱偉,微博廣告SRE團隊負責人,書籍《智能運維:從0搭建大規模分佈式AIOps系統》作者之一。目前負責微博廣告業務可用性的保障與優化、資源利用率的提升、監控報警系統的建設以及自動化體系的推進。

原文鏈接

https://mp.weixin.qq.com/s/95oLNOX8P_OjM1PD9XRszA

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章