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

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

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

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

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

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

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

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

2、鏈路追蹤

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、AIOps應(yīng)用

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

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

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

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

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

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

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

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

基于以上思考，我們做了無(wú)閾值的異常檢測(cè)。

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

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

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

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

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

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

以上就是我們?cè)谒惴▽用娴囊恍?yīng)用。

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

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

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

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

在降本方面，我們進(jìn)行了K8s資源智能分配。

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

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

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

接下來(lái)分享我們?cè)跀?shù)據(jù)可視化方面的一些案例。

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

這提醒我們，在做數(shù)據(jù)可觀測(cè)、數(shù)據(jù)分析的時(shí)候，提取的指標(biāo)本身可能沒(méi)有意義，無(wú)法反饋處問(wèn)題的真實(shí)情況。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

前面提到使用勾選工具，解決寫(xiě)SQL難的問(wèn)題，那么能否通過(guò)自然語(yǔ)言描述的形式，讓ChatGPT生成我們想要的SQL呢？

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

五、未來(lái)展望

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

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

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

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

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

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

3、全路徑可觀測(cè)

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

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

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

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

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

Q&A

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

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

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

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

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

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

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

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

所以目前來(lái)看，對(duì)性能的影響是微乎其微的。

講師介紹

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