一、基礎設施研發

我們屬于新浪微博的基礎研發團隊，如圖所示，我們需要負責三層架構：運維基礎設施、服務端和客戶端業務運維。

運維基礎設施層（運維平臺底座）：內部混合云平臺、CICD系統、K8s私有云容器平臺、4層/7層負載均衡等；

• 服務端：SLA、服務拓撲、成本優化、服務日志；
• 客戶端：APP、PC、H5、小程序等的運維保障。

依據不同業務場景，我們建設了垂類監控、智能報警、鏈路追蹤，同時也基于一些經典算法，實現了智能監控告警。

在技術選型上，主要做了哪些考慮呢？

1、數據分析

可觀測本質上是以大數據為底座的，所以數據分析非常重要。所以我們引入了數據分析領域比較專精的Grafana、R語言、plotly、Shiny等，來搭建數據可視化場景和框架；

2、鏈路追蹤

存量業務很難實現標準化。在兩三年前，我們就在內部推廣了一個全鏈路監控協議，雖然不如OpenTelemetry，但基本上實現后端資源監控的目標，現在我們新的業務則逐漸以OpenTelemetry作為標準；

3、大數據引擎

三四年前還沒有可觀測性的概念，當時還叫監控平臺，當時還面臨著比較大的數據分析問題，用傳統的Hadoop框架，抽取各種數據層次，再把數據從Hive提取到MySQL，這樣一通操作，只能實現T+1的分析報表功能。

之后流行的ES方案，也有很多問題，如復雜查詢性能差、資源占用高等；Spark、Flink等流式計算，也存在上手難度大等問題。

監控應該是一個7*24小時的服務，不是離線服務，所以亟需一個非常高效的工具來解決慢速查詢的問題。

對比了業界比較常用的一些方案后，我們最終選擇了ClickHouse作為查詢引擎。

左圖是新浪微博線上的一些數據表，基本上都是百億、千億級的規模，由于ClickHouse速度快、性能好、資源占用率低的特點，一些復雜SQL都可以在極短時間內返回我們想的結果。目前為止，ClickHouse每天承載的數據量大概在3,000億條，每秒的數據量大概在500萬左右。

在一次熱點事件中，峰值達到近千萬QPS，我們僅用了30臺服務器，就承載了這么大數據量的數據分析工作。所以，不管是運維，還是傳統數據分析，ClickHouse都是一個利器。

基于這些考慮，我們把ClickHouse作為整個數據分析平臺的基礎設施。

原來的架構中，數據流是非常復雜的，導致整個數據生命周期難以維護，有了ClickHouse作為超高性能的數據底座以后，我們的數據就變得非常簡單。

上層對接各種業務層數據，這些數據通過Kafka數據總線，最終通過ETL流程寫到ClickHouse數據倉庫里，運維和數據分析師則可以直接在ClickHouse上面做查詢。而對于需要長期保留的數據，我們開發了一些工具把這些數據打撈到MySQL等持久化存儲。

二、監控產品演進

有了數據平臺后，要由上往下去建設產品層面的監控，做好產品側的“最后一公里”。

上圖是一個典型的移動端訪問的鏈路路徑，大部分場景下，大家使用的是移動互聯網產品，90%的用戶喜歡用手機進入微博，而移動網絡本身存在很多不確定性，如網絡問題、3G/4G/5G/Wifi切換的問題、IPv6的問題、DNS問題等。

比如早年接到用戶投訴，反映安卓客戶端提示APP要升級，點進去之后變成了其它APP，端上請求下載的是新浪apk，但是卻變成了別人的apk，發生了DNS劫持問題。但HTTPS全量鋪開后，這類問題基本上也不存在了。

再舉一個跟DNS相關的例子，之前接到一個用戶投訴，客戶端訪問非常慢，我們打開了他端上的日志，發現用戶本人在北京，但訪問到的服務到了廣州，就導致了客戶端訪問慢的問題。大家都知道現在大部分本地化調度，基本上都是基于DNS來做的，DNS根據你的Local DNS IP來源, 返回給你一個離你最近的一個IP。由于運營商的Local DNS大部分都不是eDNS，所以無法通過用戶真實IP判斷。后來看了用戶的APM日志和DNS，發現其可能通過某些“優化軟件”，把手機系統DNS的IP篡改了。

再如疫情期間推出了疫情地圖這樣的產品，這些頁面基本上都是一個接口去后端取數據，再交給前端JS渲染，邏輯非常簡單。有一天早上某同事發現疫情地圖白頁掛掉了，但查看后端數據一切正常。后來發現，后端返回的數據里，有一個int型的數據，不知道什么原因，成了字符串，導致端上的JS在渲染的異常。

上述種種問題都表明，如果想做好用戶產品體驗的話，首先要保證的其實就是產品距離用戶的最后一公里，也就是產品側APM監控。

有了產品側的APM監控后，就能夠很明確知道服務在用戶層面到底是怎樣的體驗：訪問CDN的質量怎么樣？CDN作為IT成本較高的服務，不同廠商的質量到底怎么樣？錢是不是花得值？

我們現在都是用混合CDN，有了APM數據后，就可以判斷各家廠商的覆蓋程度有沒有達到承諾，這是產品保障非常重要的指標。

除了基線層面的數據，還有Trace監控產品，如果有用戶投訴，我們則能夠復現其訪問路徑，檢查網絡和訪問質量，以此解決問題。

那么有了APM是不是就夠了呢？答案是否定的，當用戶問題發生并進入公司內部服務后，接下來要做的就要搞清楚為什么訪問慢？慢在哪里？是DB慢，還是前端慢？

所以有了產品側監控后，緊接著就是做后端全鏈路監控。

上圖是內部產品的調用拓撲圖，本身已經非常復雜。前面提到我們內部使用的是自定義協議來做打點的拓撲架構繪制，雖然并沒有用到OpenTelemetry，但它所串聯的ID和APM其實都是一一對應的，本質上和OpenTelemetry沒有太大的區別。

有了上面這些點線關系后，我們也能知道它在后端進入內部服務后，具體是怎樣的訪問路徑，可以很清楚看見某個服務從不同機房到后端，以及不用接口、不同pod IP到對端的服務可用性。同時，我們定義了很多SLI，如平均響應時間、P90、P95、P99響應時間、錯誤率等，結合ClickHouse的函數，可以實現快速的統計需求，最后形成了內部服務的metric和trace可觀測。

我們現在也在積極擁抱OpenTelemetry，上右圖是一個使用Jaeger展示存在ClickHouse里的一個調用瀑布圖。

三、AIOps應用

前面提到，有了端上、鏈路等日志后，數據量會非常龐大，遠不是人肉去配置報警規則就能搞定的。

所有的可觀測指標，不可能讓工程師盯著大屏發現異常，最終一定都要落地到監控報警，以下是傳統監控面臨的一些困境：

• 業務多樣性：同一場景不同業務，差異巨大，導致添加報警繁瑣無比；

比如同一個DB，有兩個業務或接口，背后的SQL、業務邏輯都是不一樣的，這一塊的報警就要引入算法去做。

• 周期差異性：不同時間范圍，波動巨大，導致無法固定閾值“一刀切”；

新浪的業務是偏媒體類的，早上9點、晚上23點會存在訪問高峰，中間時間段的流量則不是很規律，對于這種場景，也需要算法去實現。

• 數據多維度：維度眾多，出現問題不知道是什么導致的，導致報警只能是“吹哨”。

傳統的報警，只會告訴你出了什么事，運維人員需要登錄機器，一頓shell操作排查原因，我們則希望是收到報警后，能及時告訴我們是什么原因，具體是哪個組件出了問題等。

基于以上思考，我們做了無閾值的異常檢測。

如上右圖，是同一MySQL的兩個不同業務，我們看到基準值相差非常大，一個1ms，一個5ms，靠人工加報警閾值，已然不現實。

因此，我們的監控系統在不同的業務調用鏈上，有各自不同的閾值，報警系統會根據各自的模型判斷報警。

當觸發報警條件時，能不能告訴用戶一些信息，以此提升信息的有效荷載呢？

舉個例子，上圖是一個web服務5xx的報警，傳統運維可能會配置500、502、504多個報警，無疑會增加工作量。現在我們支持配置一個5xx的報警，讓報警告訴你現在是誰占得多？哪個運營商的用戶受影響最大？具體是哪個接口？有了這些信息，就可以幫助運維減少大量的排查工作。

目前報警特征這部分的功能，我們用了較經典的算法——關聯規則算法，該算法不是簡單每個維度group by，一份日志會有個幾十上百個字段，特征組合是Cn1的復雜度，它能夠有效減少計算的時間復雜度。

在AIOps應用上，我們還做了多級服務日志關聯，定位問題產品位置。如圖是端上發生的一次鏈路，我們展示了它在后端整個調用鏈路，在這個過程中，它對哪些資源依賴、對各個鏈路上是否有問題，我們都可以很直觀看到。

以上就是我們在算法層面的一些應用。

四、數據科學應用

數據科學應用是我們近兩年重點發力的方向，這塊更偏向于運維垂直領域下的數據分析，和我們傳統業務的數據分析不大一樣。

近兩年，大家都在講降本增效，在整個運維體系中，也避免不了降本增效的需求。

在增效方面，我們的運維生命周期，以及運維生命周期中的故障排查、處理流程，也完全用數據走成了閉環。

在降本方面，我們進行了K8s資源智能分配。

如圖是K8s資源分配的模板，K8s組員分配是按照request和limit來預分配的，但因為實際使用是動態、不確定的，這就可能會造成資源浪費，如果用HPA覆蓋的話，又存在滯后性，業務會抖動一下，才能把資源拉高。那么這個問題怎么解決呢？

我們用一些簡單的數據分析，就把問題解決了。如上圖所示是財經類的業務，周六日不開盤，量非常少，工作日9-11點、14-16點開盤，黃色曲線是K8s request給某個項目兩周時間全部CPU，綠色是實際CPU的使用情況，可以看到有明顯的大周期和小周期，如果把黃線拉得過高，大部分業務空閑的時候，資源就會白白浪費。

目前，我們是貼著實際使用量去分配資源的，首先通過長期實際使用的數據進行觀測，再根據實際使用的CPU情況，判斷出下一時刻資源的預期，把下一時刻的資源改成預期數值，最終實現降本的目標。

接下來分享我們在數據可視化方面的一些案例。

大家在做數據分析的時候，往往會使用一些平均值、P99、中位數等，但有時候這類數據會造成極大的信息偏差，如上右圖，散點形狀一直在變化，均值、方差基本上在小數點后3位才有差異。

這提醒我們，在做數據可觀測、數據分析的時候，提取的指標本身可能沒有意義，無法反饋處問題的真實情況。

那么我們是如何利用數據可視化解決實際問題的呢？

前面提到的降本增效，除了要減少資源的不合理分配，還有一個目標就是要通過數據分析，找到不合理的服務器利用率。

上右圖是內部針對服務器的利用率做的散點圖分析，由圖可見，有的業務利用率都集中在上部，這種一般是離線計算業務，CPU越高越好；有的業務CPU分布呈現棗核型，分布比較平均，一般常見于在線業務，因為要保障響應時間，所以不能把CPU堆的特別高，有的又全是很低，這種就不太合理。

有時候運維總說服務器不夠用，通過實際的利用率分析觀察，發現服務器不夠用只是個假象。就如K8s問題，預期和實際使用的GAP其實是非常大的，把GAP消除掉之后，就發現有大把的資源閑置。

在提高服務器利用率上，我們往前延伸了一步，把散點圖增加了時間序列，變成了時間序列熱力圖。

如圖是某個業務線某天所有服務器CPU使用率的熱力圖，右上角X軸是CPU利用率，越靠右越高，Y軸是對應的服務器數量。

上右圖服務器利用率一部分較高、一部分較低，但是這個圖它只能體現出一天的情況，為增加時間維度，我們把這個圖做成了下面的時間序列熱力圖，X軸又變成了日期，顏色的深淺來代表多少服務器的多少，然后 Y軸變成了CPU利用率。

明顯看到，隨著時間的變化，集中在上半部的顏色越來越深，說明這個部門CPU的利用率高的機器是越來越多的，這樣的話，就避免了我們只用某一時刻的數據來簡單描述數據，讓數據變得更加客觀真實。

這個案例屬于宏觀層面的分析，業界有做eBPF分析的，比如IO的latency分布，也會使用這種時間序列熱力圖進行展示。

如上圖所示，我們在數據分析上，也對CDN服務做了多維度的數據展示。圖中是一個多家CDN性能的綜合對比，展示了五個維度的動態數據，其中包括日期數據，顏色代表廠家，圓圈大小代表體量，X軸和Y軸分別代表了CDN的響應時間和下載時間。

通過這個圖，我們可以非常直觀判斷廠商產品質量，實現多維度的數據可觀測。

除此之外，我們還做了能夠給運維直接賦能數據能力的工具——交互式BI分析工具。

數據分析的最后一公里，是讓需要用的人，以一個很低的成本用起來，如我們內部的APM日志回撈的工具，CDN的同事就會經常用來分析問題。作為基礎服務，需要快速排查用戶的投訴問題，比如用戶反饋視頻的首幀慢了、圖片加載異常了，使用這些工具，就能夠快速的看到到底是DNS的原因，還是TCP建聯的問題，還是后端服務的確是慢了。

前面提到，ClickHouse解決了從數據存儲、查詢的問題，但實際上讓數據用起來，還是有一定難度的。很多運維人員不太會寫SQL，因此我們內容做了類似數據打撈的工具，使用者可以簡單通過勾選，完成數據提取和數據聚合等查詢工作。

最近ChatGPT特別火，我們也在嘗試與其建立連接。

前面提到使用勾選工具，解決寫SQL難的問題，那么能否通過自然語言描述的形式，讓ChatGPT生成我們想要的SQL呢？

通過測試，90%的情況下，ChatGPT都能“聽懂”描述，給出正確的SQL，未來相信也能不斷幫助我們降低數據獲取的難度。

五、未來展望

1、數倉的可拓展

近幾年OLAP領域發展火爆，國產產品也非常優秀，比如databend這種定位于存算分離架構的數據倉庫。

ClickHouse雖已經一款高性能的數倉產品，但在運維層還有一定的復雜度，未來我們會引入存算分離的數據倉庫，進一步地減少在數據存儲、運維方面的壓力。

2、數據分析的未來

前面討論了很多用工具降低數據分析難度的時間，那么ChatGPT是否也能讓數據分析變得簡單？能否直接把數據給ChatGPT，讓AI直接給我們結論呢？

如圖是直接從Nginx7層服務里導出來的一些日志，直接給到ChatGPT后，發現它可以直接做好初步的數據分析結論，判斷異常、響應時間分布等情況，結果讓我們感到興奮，AI的思考能力實在強大。

3、全路徑可觀測

有了全鏈路、端上監控后，發現端上報的指標都是非常宏觀的，不能馬上定位到根本問題，這些工作非常依賴于資深SRE，通過抓包、系統工具，排查系統層、內核層的指標才能找到根因所在，整體非常耗時。

再如，客戶端、后端、DB層、TCP層等都需要更微觀的監控，線上有很多異常，可能是TCP重傳、RTT惡化導致的，這些根因數據我們在應用宏觀層面是沒辦法拿到的。

因此，我們未來要做更微觀的可觀測。目前我們做的是基于eBPF，去拿一些內核層面的微觀數據做解釋，逐步讓可觀測“深入骨髓”。

最后和大家分享業界常說的一句名言：“If You Can't Measure lt,  You Can't lmprove lt.”

做數據可觀測，本質上是通過各種手段降低數據衡量的難度、數據使用的復雜度，讓數據成為武器，讓開發提效，讓運維“安穩長滿優”。

Q&A

Q1：底層用ClickHouse作為OLAP的數據庫，如何支撐實時的并發查詢呢？

A1：OLAP產品談并發本身是個偽命題，這個場景大部分是熱數據，真正需要并發需求的，可能就是近幾分鐘的數據，這類熱數據，本身就有較高的并發性能。

其次，ClickHouse本身也會有各種各樣的機制去提升并發性能，比如物化視圖等，通過構建視圖，把原始數據做提取并物理存儲，提取后的數據再查詢，基本上也能達到千級別QPS。

Q2：AIOps的鏈路圖是通過聚合出來的嗎？通過自定義協議怎么采集這些節點？

首先，拓撲圖本身沒有太大的技術含量，主要就是依賴端上日志的記錄，包括我們看到從APP到后端，鏈路管理本質上有記錄全局ID，有了ID就能知道先后，OpenTelemetry也是一樣的邏輯，只不過OpenTelemetry增加了Span ID的概念，可以看到調用的上下游關系，本身沒有什么特殊的地方。

Q3：AIOps鏈路的采樣率是怎樣的？會不會影響性能？

端上的采樣率是嚴格控制的，比如采用率低于1%，數據量也非常大的。如果采樣率不合理，對數據的觀測肯定會有影響，所以可以通過針對VIP用戶全量采集的方式，去規避問題排查缺少數據支撐的情況。

采樣規則的開關是可以隨時去調的，比如某段時間需要增加采集量，就可以隨時把開關調大。其次在采訪的時候，錯誤日志是全量上報的，這樣也能保障數據的客觀性。后端鏈路監控也是類似的規則，業務量較小是，基本上是全量采集。

所以目前來看，對性能的影響是微乎其微的。

講師介紹

高鵬，新浪部門主管。在高可用架構設計、業務邏輯設計和優化方面，有較為豐富的經驗。目前負責新浪智能數據分析平臺建設，致力于運維大數據價值挖掘，提升運維服務質量和產品用戶體驗度。ClickHouse中國社區發起人之一，國內最早大規模使用ClickHouse的用戶之一，對ClickHouse的架構、使用、優化，有較好的理解和實踐經驗。