一、基礎(chǔ)設(shè)施研發(fā)

我們屬于新浪微博的基礎(chǔ)研發(fā)團隊，如圖所示，我們需要負責三層架構(gòu)：運維基礎(chǔ)設(shè)施、服務(wù)端和客戶端業(yè)務(wù)運維。

運維基礎(chǔ)設(shè)施層（運維平臺底座）：內(nèi)部混合云平臺、CICD系統(tǒng)、K8s私有云容器平臺、4層/7層負載均衡等；

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

依據(jù)不同業(yè)務(wù)場景，我們建設(shè)了垂類監(jiān)控、智能報警、鏈路追蹤，同時也基于一些經(jīng)典算法，實現(xiàn)了智能監(jiān)控告警。

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

1、數(shù)據(jù)分析

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

2、鏈路追蹤

存量業(yè)務(wù)很難實現(xiàn)標準化。在兩三年前，我們就在內(nèi)部推廣了一個全鏈路監(jiān)控協(xié)議，雖然不如OpenTelemetry，但基本上實現(xiàn)后端資源監(jiān)控的目標，現(xiàn)在我們新的業(yè)務(wù)則逐漸以O(shè)penTelemetry作為標準；

3、大數(shù)據(jù)引擎

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

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

監(jiān)控應(yīng)該是一個7*24小時的服務(wù)，不是離線服務(wù)，所以亟需一個非常高效的工具來解決慢速查詢的問題。

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

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

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

基于這些考慮，我們把ClickHouse作為整個數(shù)據(jù)分析平臺的基礎(chǔ)設(shè)施。

原來的架構(gòu)中，數(shù)據(jù)流是非常復(fù)雜的，導(dǎo)致整個數(shù)據(jù)生命周期難以維護，有了ClickHouse作為超高性能的數(shù)據(jù)底座以后，我們的數(shù)據(jù)就變得非常簡單。

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

二、監(jiān)控產(chǎn)品演進

有了數(shù)據(jù)平臺后，要由上往下去建設(shè)產(chǎn)品層面的監(jiān)控，做好產(chǎn)品側(cè)的“最后一公里”。

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

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

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

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

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

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

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

除了基線層面的數(shù)據(jù)，還有Trace監(jiān)控產(chǎn)品，如果有用戶投訴，我們則能夠復(fù)現(xiàn)其訪問路徑，檢查網(wǎng)絡(luò)和訪問質(zhì)量，以此解決問題。

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

所以有了產(chǎn)品側(cè)監(jiān)控后，緊接著就是做后端全鏈路監(jiān)控。

上圖是內(nèi)部產(chǎn)品的調(diào)用拓撲圖，本身已經(jīng)非常復(fù)雜。前面提到我們內(nèi)部使用的是自定義協(xié)議來做打點的拓撲架構(gòu)繪制，雖然并沒有用到OpenTelemetry，但它所串聯(lián)的ID和APM其實都是一一對應(yīng)的，本質(zhì)上和OpenTelemetry沒有太大的區(qū)別。

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

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

三、AIOps應(yīng)用

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

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

• 業(yè)務(wù)多樣性：同一場景不同業(yè)務(wù)，差異巨大，導(dǎo)致添加報警繁瑣無比；

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

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

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

• 數(shù)據(jù)多維度：維度眾多，出現(xiàn)問題不知道是什么導(dǎo)致的，導(dǎo)致報警只能是“吹哨”。

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

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

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

因此，我們的監(jiān)控系統(tǒng)在不同的業(yè)務(wù)調(diào)用鏈上，有各自不同的閾值，報警系統(tǒng)會根據(jù)各自的模型判斷報警。

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

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

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

在AIOps應(yīng)用上，我們還做了多級服務(wù)日志關(guān)聯(lián)，定位問題產(chǎn)品位置。如圖是端上發(fā)生的一次鏈路，我們展示了它在后端整個調(diào)用鏈路，在這個過程中，它對哪些資源依賴、對各個鏈路上是否有問題，我們都可以很直觀看到。

以上就是我們在算法層面的一些應(yīng)用。

四、數(shù)據(jù)科學(xué)應(yīng)用

數(shù)據(jù)科學(xué)應(yīng)用是我們近兩年重點發(fā)力的方向，這塊更偏向于運維垂直領(lǐng)域下的數(shù)據(jù)分析，和我們傳統(tǒng)業(yè)務(wù)的數(shù)據(jù)分析不大一樣。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通過這個圖，我們可以非常直觀判斷廠商產(chǎn)品質(zhì)量，實現(xiàn)多維度的數(shù)據(jù)可觀測。

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

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

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

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

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

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

五、未來展望

1、數(shù)倉的可拓展

近幾年OLAP領(lǐng)域發(fā)展火爆，國產(chǎn)產(chǎn)品也非常優(yōu)秀，比如databend這種定位于存算分離架構(gòu)的數(shù)據(jù)倉庫。

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

2、數(shù)據(jù)分析的未來

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

如圖是直接從Nginx7層服務(wù)里導(dǎo)出來的一些日志，直接給到ChatGPT后，發(fā)現(xiàn)它可以直接做好初步的數(shù)據(jù)分析結(jié)論，判斷異常、響應(yīng)時間分布等情況，結(jié)果讓我們感到興奮，AI的思考能力實在強大。

3、全路徑可觀測

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

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

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

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

做數(shù)據(jù)可觀測，本質(zhì)上是通過各種手段降低數(shù)據(jù)衡量的難度、數(shù)據(jù)使用的復(fù)雜度，讓數(shù)據(jù)成為武器，讓開發(fā)提效，讓運維“安穩(wěn)長滿優(yōu)”。

Q&A

Q1：底層用ClickHouse作為OLAP的數(shù)據(jù)庫，如何支撐實時的并發(fā)查詢呢？

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

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

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

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

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

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

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

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

講師介紹

高鵬，新浪部門主管。在高可用架構(gòu)設(shè)計、業(yè)務(wù)邏輯設(shè)計和優(yōu)化方面，有較為豐富的經(jīng)驗。目前負責新浪智能數(shù)據(jù)分析平臺建設(shè)，致力于運維大數(shù)據(jù)價值挖掘，提升運維服務(wù)質(zhì)量和產(chǎn)品用戶體驗度。ClickHouse中國社區(qū)發(fā)起人之一，國內(nèi)最早大規(guī)模使用ClickHouse的用戶之一，對ClickHouse的架構(gòu)、使用、優(yōu)化，有較好的理解和實踐經(jīng)驗。