淺談云原生可觀測(cè)性
背景
當(dāng)前數(shù)字化轉(zhuǎn)型進(jìn)程持續(xù)加速中,在頂層設(shè)計(jì)指導(dǎo)下,結(jié)合自身發(fā)展需要,全面推廣一朵全棧云,深化云原生生態(tài)建設(shè),推動(dòng)業(yè)務(wù)應(yīng)用大量采用微服務(wù)、容器等云原生技術(shù),基于DevOps模式進(jìn)行研發(fā),將傳統(tǒng)的單體服務(wù)拆分成粒度更細(xì)的微服務(wù)模塊,使系統(tǒng)可以更好地適配容器化部署,更好地進(jìn)行敏捷的業(yè)務(wù)迭代研發(fā),快速輸出系統(tǒng)業(yè)務(wù)價(jià)值。
云原生建設(shè)是一個(gè)綜合性的系統(tǒng)工程,涉及微服務(wù)重構(gòu)、國(guó)產(chǎn)信創(chuàng)、分布式數(shù)據(jù)庫(kù)、容器云、服務(wù)治理等多個(gè)方面,系統(tǒng)規(guī)模和復(fù)雜度以及數(shù)據(jù)量成倍提升,可能發(fā)生故障的數(shù)量和類型也同比提升,全面有效的保障服務(wù)持續(xù)穩(wěn)定運(yùn)行至關(guān)重要,云原生安全運(yùn)營(yíng)是當(dāng)下面臨的重要課題。
面臨的挑戰(zhàn)
要保障服務(wù)安全運(yùn)營(yíng),首先必須要能全面理解系統(tǒng)運(yùn)行的狀態(tài)和行為,這要求實(shí)現(xiàn)從底層到上層對(duì)網(wǎng)絡(luò)、主機(jī)、容器、應(yīng)用、業(yè)務(wù)服務(wù)等進(jìn)行全??捎^測(cè)??捎^測(cè)性(observability)最早來(lái)源于控制理論領(lǐng)域,指的是系統(tǒng)可以由其外部輸出推斷其內(nèi)部狀態(tài)的程度。在云原生架構(gòu)中,可觀測(cè)性描述的是對(duì)系統(tǒng)中所發(fā)生情況的掌握程度。云原生系統(tǒng)規(guī)模大、系統(tǒng)復(fù)雜、動(dòng)態(tài)變化,對(duì)其進(jìn)行全面、有效的理解和掌控,以及保障安全運(yùn)營(yíng)方面面臨著巨大的挑戰(zhàn):
如何理解大規(guī)模動(dòng)態(tài)容器環(huán)境中應(yīng)用的實(shí)際運(yùn)行情況:云原生系統(tǒng)通過(guò)容器化技術(shù)對(duì)基礎(chǔ)設(shè)施進(jìn)行了標(biāo)準(zhǔn)化,提升了應(yīng)用部署的便利性,并支持動(dòng)態(tài)擴(kuò)縮容。基礎(chǔ)設(shè)施層的信息通過(guò)虛擬化封裝不再透明,微服務(wù)化架構(gòu)使應(yīng)用部署的服務(wù)數(shù)量急劇增加,容器集群根據(jù)業(yè)務(wù)運(yùn)行情況動(dòng)態(tài)調(diào)度。服務(wù)間流量既有南北向,也有東西向,且以東西向?yàn)橹?。在這樣大規(guī)模動(dòng)態(tài)服務(wù)實(shí)例的環(huán)境中,有效全面理解從應(yīng)用、容器、主機(jī)到網(wǎng)絡(luò)的運(yùn)行情況,是保障業(yè)務(wù)安全運(yùn)營(yíng)的關(guān)鍵。
如何在復(fù)雜的服務(wù)調(diào)用間快速定位故障:單體服務(wù)拆分成微服務(wù)后,模塊間的交互由進(jìn)程內(nèi)的方法函數(shù)調(diào)用轉(zhuǎn)變?yōu)檫M(jìn)程間的服務(wù)調(diào)用,導(dǎo)致服務(wù)的調(diào)用路徑變長(zhǎng)且跨越網(wǎng)絡(luò)交互,當(dāng)發(fā)生錯(cuò)誤時(shí)怎樣快速定位故障點(diǎn),及時(shí)采取流量切換、服務(wù)回退等措施,是保障服務(wù)持續(xù)運(yùn)行的關(guān)鍵;不同服務(wù)模塊在整個(gè)系統(tǒng)中承擔(dān)的功能不同,請(qǐng)求壓力也不同,當(dāng)系統(tǒng)出現(xiàn)性能瓶頸時(shí),怎樣快速發(fā)現(xiàn)出現(xiàn)瓶頸的服務(wù)并進(jìn)行服務(wù)擴(kuò)容,或者及時(shí)采取熔斷限流措施,是保障服務(wù)穩(wěn)定運(yùn)行的關(guān)鍵。
如何保證觀測(cè)能力的實(shí)時(shí)性:云原生應(yīng)用的動(dòng)態(tài)性要求可觀測(cè)性平臺(tái)必須具備實(shí)時(shí)性或近實(shí)時(shí)性。如果應(yīng)用的升級(jí)或擴(kuò)容在分鐘級(jí)完成,那么監(jiān)測(cè)系統(tǒng)就必須提供秒級(jí)的反饋能力。云原生系統(tǒng)產(chǎn)生的指標(biāo)、追蹤、日志等數(shù)據(jù)往往是海量的,因此對(duì)可觀測(cè)性平臺(tái)實(shí)時(shí)處理海量數(shù)據(jù)的能力提出了極高要求。
如何實(shí)現(xiàn)多個(gè)運(yùn)維平臺(tái)的有機(jī)整合:云原生生態(tài)涉及多個(gè)支撐系統(tǒng),各系統(tǒng)的有機(jī)協(xié)調(diào)運(yùn)行才能共同構(gòu)成云原生運(yùn)行平臺(tái),但現(xiàn)實(shí)是各個(gè)運(yùn)維工具平臺(tái)由不同時(shí)期、不同產(chǎn)品、不同廠商建設(shè),怎樣將這些運(yùn)維工具平臺(tái)的數(shù)據(jù)進(jìn)行有效的治理,實(shí)現(xiàn)數(shù)據(jù)關(guān)聯(lián)整合,充分發(fā)揮數(shù)據(jù)的價(jià)值,實(shí)現(xiàn)運(yùn)維的全景運(yùn)行、有機(jī)協(xié)調(diào),是對(duì)運(yùn)維數(shù)據(jù)治理能力的巨大挑戰(zhàn)。
針對(duì)上述云原生架構(gòu)帶來(lái)的新問(wèn)題與挑戰(zhàn),我們將嘗試設(shè)計(jì)一套整體的云原生可觀測(cè)性平臺(tái)來(lái)解決上述擔(dān)憂。
可觀測(cè)平臺(tái)設(shè)計(jì)
可觀測(cè)性平臺(tái)方案設(shè)計(jì)由可觀測(cè)運(yùn)維對(duì)象、可觀測(cè)數(shù)據(jù)、數(shù)據(jù)關(guān)聯(lián)性、可觀測(cè)方案實(shí)現(xiàn)四部分組成,涵蓋識(shí)別運(yùn)維對(duì)象、可觀測(cè)數(shù)據(jù)標(biāo)準(zhǔn)、不同數(shù)據(jù)關(guān)聯(lián)實(shí)現(xiàn),組成整體的可觀測(cè)性方案,最后實(shí)現(xiàn)價(jià)值輸出,具體如下:
可觀測(cè)對(duì)象
云原生系統(tǒng)可觀測(cè)體系需要涵蓋從網(wǎng)絡(luò)、主機(jī)、容器、應(yīng)用、業(yè)務(wù)服務(wù)等所有云原生系統(tǒng)的組成部分,根據(jù)監(jiān)控對(duì)象在系統(tǒng)中所處的位置,將可觀測(cè)體系劃分為四個(gè)層次,如圖1所示,涵蓋從系統(tǒng)基礎(chǔ)設(shè)施、容器、應(yīng)用到業(yè)務(wù)的全范圍,分別為:
圖1 云原生運(yùn)維棧示意圖
基礎(chǔ)設(shè)施層:也即IaaS層,該層涉及的監(jiān)控對(duì)象為系統(tǒng)底層資源,如網(wǎng)絡(luò)、存儲(chǔ)設(shè)備、裸金屬等。這些設(shè)備與組件的可靠性,直接影響到上層應(yīng)用服務(wù)的穩(wěn)定性。該層關(guān)聯(lián)的可觀測(cè)性數(shù)據(jù)包含指標(biāo)(網(wǎng)絡(luò)流量、網(wǎng)絡(luò)連接數(shù)、主機(jī)性能)、日志(交換機(jī)日志、操作系統(tǒng)日志)、事件(系統(tǒng)平臺(tái)事件、故障、宕機(jī))等。
容器層:也即,PaaS層,該層涉及的監(jiān)控對(duì)象涵蓋了容器內(nèi)的系統(tǒng)資源,如:Kubernetes服務(wù)運(yùn)行情況、集群節(jié)點(diǎn)、CPU、內(nèi)存、存儲(chǔ)等,是針對(duì)容器云平臺(tái)進(jìn)行的監(jiān)控,這些資源的使用情況決定了應(yīng)用服務(wù)的性能和容量。該層關(guān)聯(lián)的可觀測(cè)性數(shù)據(jù)包含指標(biāo)(節(jié)點(diǎn)或容器的CPU使用率、內(nèi)存使用率、存儲(chǔ)使用率等)、日志(Kubernetes各個(gè)組件日志)、事件(Kubernetes Event)等。
應(yīng)用層:該層涉及的監(jiān)控對(duì)象和應(yīng)用服務(wù)緊密相關(guān),如:服務(wù)可用性、JVM、中間件等,這些監(jiān)控對(duì)象的健康度與負(fù)載情況決定了應(yīng)用之上運(yùn)行的業(yè)務(wù)的可用性與性能。該層關(guān)聯(lián)的可觀測(cè)性數(shù)據(jù)包含指標(biāo)(服務(wù)存活性、JVM內(nèi)存使用率、JVM GC停頓時(shí)長(zhǎng)、數(shù)據(jù)庫(kù)連接、緩存連接、消息隊(duì)列消息堆積數(shù)等)、鏈路(應(yīng)用服務(wù)間調(diào)用、應(yīng)用調(diào)用中間件形成的分布式鏈路)、日志(運(yùn)行日志、錯(cuò)誤日志)等。
業(yè)務(wù)層:該層涉及的監(jiān)控對(duì)象主要涉及業(yè)務(wù)運(yùn)行信息,如:交易量、交易金額、服務(wù)請(qǐng)求量、請(qǐng)求延遲、變化比率、錯(cuò)誤率等,這些監(jiān)控指標(biāo)直接反應(yīng)業(yè)務(wù)的運(yùn)行狀態(tài),體現(xiàn)著用戶體驗(yàn)與企業(yè)發(fā)展情況。該層關(guān)聯(lián)的可觀測(cè)性數(shù)據(jù)包含指標(biāo)(訪問(wèn)統(tǒng)計(jì)、請(qǐng)求數(shù)、錯(cuò)誤數(shù)、延時(shí)等)、日志(訪問(wèn)日志、錯(cuò)誤日志)。
可觀測(cè)數(shù)據(jù)
可觀測(cè)性體系的構(gòu)建是通過(guò)對(duì)系統(tǒng)運(yùn)行狀態(tài)數(shù)據(jù)的收集、分析來(lái)判斷系統(tǒng)的運(yùn)行狀態(tài)并實(shí)現(xiàn)快速排障。因此,首先要定義可觀測(cè)性數(shù)據(jù),當(dāng)前業(yè)界主流標(biāo)準(zhǔn)將可觀測(cè)性數(shù)據(jù)分為三個(gè)類別:
圖2 Metrics, tracing, logging及關(guān)聯(lián)關(guān)系
指標(biāo)(metrics):指標(biāo)數(shù)據(jù)通常為一段時(shí)間內(nèi)可度量的數(shù)據(jù),也被稱為時(shí)序數(shù)據(jù),用于觀測(cè)系統(tǒng)的狀態(tài)與趨勢(shì),常用于畫(huà)曲線圖。支持以下四種數(shù)據(jù):
類型 | 說(shuō)明 | 示例 |
Counter | 單調(diào)遞增的計(jì)數(shù)器 | http請(qǐng)求總數(shù)、QPS、TPS等 |
Gauge | 支持加和減的計(jì)數(shù)器 | CPU使用率、內(nèi)存使用值、負(fù)載等 |
Histogram | 直方圖 | 對(duì)觀察值(如請(qǐng)求持續(xù)時(shí)間或響應(yīng)大?。┻M(jìn)行采樣,并統(tǒng)計(jì)樣本分布,服務(wù)端可用于計(jì)算分位數(shù)(P95、P99)、Apdex指數(shù),如果需要聚合或者觀測(cè)值的范圍和分布,可以選擇直方圖。 |
Summary | 分位數(shù) | 百分位(客戶端直接計(jì)算),如果需要精確的分位數(shù),選擇Summary。 |
指標(biāo)數(shù)據(jù)類型
指標(biāo)效果展示
鏈路(tracing):分布式追蹤是一種理解分布式系統(tǒng)執(zhí)行過(guò)程中參與的上下游及影響,支持跟蹤應(yīng)用請(qǐng)求從前端到后端服務(wù)以及數(shù)據(jù)庫(kù)等中間件的流轉(zhuǎn)過(guò)程,支持對(duì)高延時(shí)與高錯(cuò)誤率的請(qǐng)求進(jìn)行故障排查。同時(shí)從鏈路數(shù)據(jù)中,可以提取出業(yè)務(wù)的RED(速率、錯(cuò)誤、持續(xù)時(shí)間),豐富指標(biāo)監(jiān)控。
Trace路徑感知與性能分析
Trace效果展示
日志(logging):日志數(shù)據(jù)是離散事件的記錄,反應(yīng)系統(tǒng)運(yùn)行過(guò)程中產(chǎn)生的信息,可以詳細(xì)解釋系統(tǒng)的運(yùn)行狀態(tài)。大多數(shù)開(kāi)發(fā)語(yǔ)言、應(yīng)用程序框架或庫(kù)都支持日志。日志可以分為不同的類別,例如系統(tǒng)日志、應(yīng)用日志、安全日志、基礎(chǔ)設(shè)施日志。日志中存儲(chǔ)的信息是無(wú)格式的文本,需要制定對(duì)應(yīng)的字段規(guī)范以便于后續(xù)分析,例如日志包含服務(wù)名稱、traceid,并附加采集的容器信息。
日志展示
數(shù)據(jù)關(guān)聯(lián)性
可觀測(cè)對(duì)象雖然劃分為四層,但在實(shí)際使用時(shí),通常需要結(jié)合多層數(shù)據(jù)和多個(gè)運(yùn)維工具平臺(tái)中的數(shù)據(jù)一起來(lái)分析問(wèn)題,這就需要觀測(cè)數(shù)據(jù)存在一定關(guān)聯(lián)性。如下圖所示:
數(shù)據(jù)關(guān)聯(lián)性
從數(shù)據(jù)特性上可以區(qū)分為:
同一運(yùn)維對(duì)象關(guān)聯(lián)
同一運(yùn)維對(duì)象應(yīng)該具有確定且唯一的標(biāo)識(shí),在不同數(shù)據(jù)中(指標(biāo)、鏈路、日志)應(yīng)該使用統(tǒng)一的標(biāo)識(shí)標(biāo)準(zhǔn),用戶可以使用同一套標(biāo)識(shí)分別查詢到不同數(shù)據(jù),以方便關(guān)聯(lián)分析。例如根據(jù)Prometheus告警中帶的標(biāo)簽和時(shí)間戳,可以在日志中定位到對(duì)應(yīng)服務(wù)在特定時(shí)刻的行為,在鏈路中也可以定位到對(duì)應(yīng)服務(wù)特定時(shí)刻的執(zhí)行鏈路。
相同運(yùn)維對(duì)象和對(duì)應(yīng)的指標(biāo)和日志數(shù)據(jù)
不同運(yùn)維對(duì)象關(guān)聯(lián)
不同運(yùn)維對(duì)象間的關(guān)聯(lián)關(guān)系比較多樣化,需要具體問(wèn)題具體分析。在傳統(tǒng)的環(huán)境中,我們通?;贗P進(jìn)行不同主機(jī)、網(wǎng)絡(luò)節(jié)點(diǎn)進(jìn)行標(biāo)識(shí)和關(guān)聯(lián),而在容器云環(huán)境中,通常基于標(biāo)簽標(biāo)識(shí)不同運(yùn)維對(duì)象和資源,不同資源類型不同,但應(yīng)該具有相同的標(biāo)簽,這樣才能實(shí)現(xiàn)組合。例如Kubernetes中Deployment與Service中的定義必須匹配對(duì)應(yīng)的Labels才能實(shí)現(xiàn)匹配和對(duì)應(yīng)功能。
不同運(yùn)維對(duì)象基于標(biāo)簽識(shí)別關(guān)聯(lián)
鏈路ID關(guān)聯(lián)
在分布式環(huán)境中,應(yīng)用服務(wù)被拆分為不同的服務(wù)模塊,一個(gè)服務(wù)請(qǐng)求會(huì)跨越多個(gè)不同的運(yùn)維對(duì)象,運(yùn)維對(duì)象也服務(wù)于多個(gè)不同請(qǐng)求,這種分布式并發(fā)性使得如何區(qū)分不同請(qǐng)求成為一個(gè)難題,這個(gè)問(wèn)題與TCP服務(wù)于多個(gè)請(qǐng)求的問(wèn)題類似,HTTP1.1沒(méi)有請(qǐng)求標(biāo)識(shí),無(wú)法多路復(fù)用,HTT2中加入了流標(biāo)識(shí)才可以,類似的,不同應(yīng)用間服務(wù)請(qǐng)求加入唯一的標(biāo)識(shí)ID即可區(qū)分彼此。基于鏈路ID的鏈路跟蹤可以將一次分布式請(qǐng)求還原成調(diào)用鏈路,對(duì)一次分布式請(qǐng)求的調(diào)用情況集中展示,比如各個(gè)服務(wù)節(jié)點(diǎn)上的耗時(shí)、請(qǐng)求具體到達(dá)哪臺(tái)機(jī)器上、每個(gè)服務(wù)節(jié)點(diǎn)的請(qǐng)求狀態(tài)等等,實(shí)現(xiàn)調(diào)用拓?fù)淇梢暬?、上下游依賴分析、故障快速定位等?/p>
基于traceid關(guān)聯(lián)多個(gè)運(yùn)維對(duì)象的日志和鏈路
利用上述運(yùn)維對(duì)象和數(shù)據(jù)的關(guān)聯(lián)性,并結(jié)合梳理的全棧運(yùn)行環(huán)境(圖1),包括基礎(chǔ)設(shè)施、容器云平臺(tái)、應(yīng)用和業(yè)務(wù)信息,構(gòu)建整體的全景可觀測(cè)性拓?fù)鋱D,針對(duì)不同組件、不同層面的運(yùn)維對(duì)象分別展示不同觀測(cè)數(shù)據(jù),并與CMDB信息聯(lián)動(dòng),實(shí)現(xiàn)直觀的拓?fù)湫畔⒄故尽?/p>
全棧監(jiān)測(cè)拓?fù)涫疽鈭D
可觀測(cè)實(shí)現(xiàn)
可觀測(cè)性體系的實(shí)現(xiàn)分為三大流程:可觀測(cè)性數(shù)據(jù)采集、可觀測(cè)性數(shù)據(jù)分析、可觀測(cè)性數(shù)據(jù)價(jià)值輸出,覆蓋可觀測(cè)性數(shù)據(jù)的產(chǎn)生、采集、處理分析、存儲(chǔ)、應(yīng)用的全流程。
可觀測(cè)性數(shù)據(jù)采集
數(shù)據(jù)采集
該流程主要完成可觀測(cè)性數(shù)據(jù)的規(guī)范化定義與采集,包括指標(biāo)、鏈路、日志三類數(shù)據(jù)。怎樣保證采集數(shù)據(jù)的完整性以及對(duì)應(yīng)用的無(wú)侵入性,是方案需要考慮的關(guān)鍵。指標(biāo)數(shù)據(jù)為時(shí)序數(shù)據(jù),數(shù)據(jù)結(jié)構(gòu)相對(duì)固定,在設(shè)計(jì)時(shí)需限制表示業(yè)務(wù)信息的標(biāo)簽數(shù)量與取值范圍,避免數(shù)據(jù)量過(guò)大,對(duì)指標(biāo)服務(wù)端的性能造成影響。針對(duì)Kubernetes平臺(tái)、業(yè)務(wù)應(yīng)用、中間件等,采用服務(wù)端拉取的模式進(jìn)行采集,在相應(yīng)的服務(wù)器上部署獨(dú)立的指標(biāo)采集組件,這些組件負(fù)責(zé)收集指標(biāo)數(shù)據(jù)并通過(guò)HTTP協(xié)議對(duì)外提供指標(biāo)查詢接口,由指標(biāo)服務(wù)端(如Prometheus)定時(shí)調(diào)用。針對(duì)業(yè)務(wù)應(yīng)用,使用Java Agent技術(shù)在JVM應(yīng)用啟動(dòng)時(shí)進(jìn)行JVM字節(jié)碼的增強(qiáng),在不改變業(yè)務(wù)代碼的前提下進(jìn)行JVM性能指標(biāo)與業(yè)務(wù)指標(biāo)的生成,實(shí)現(xiàn)監(jiān)控邏輯與業(yè)務(wù)邏輯解耦,保證開(kāi)發(fā)流程的擴(kuò)展性。以上采集過(guò)程均能做到對(duì)應(yīng)用無(wú)侵入。
為了保證鏈路數(shù)據(jù)結(jié)構(gòu)相對(duì)固定的同時(shí)提高數(shù)據(jù)擴(kuò)展性,鏈路數(shù)據(jù)結(jié)構(gòu)采用半結(jié)構(gòu)化的JSON格式。對(duì)于鏈路數(shù)據(jù),在開(kāi)發(fā)框架中引入鏈路埋點(diǎn)庫(kù)。該庫(kù)對(duì)于服務(wù)間調(diào)用、服務(wù)調(diào)用主流中間件(如數(shù)據(jù)庫(kù)、緩存、消息隊(duì)列等)等關(guān)鍵程序執(zhí)行位置自動(dòng)埋點(diǎn),提供了通用鏈路采集埋點(diǎn)邏輯,引入該開(kāi)發(fā)庫(kù)就能自動(dòng)完成相應(yīng)位置的鏈路采集。同時(shí)提供了手動(dòng)埋點(diǎn)能力,供開(kāi)發(fā)團(tuán)隊(duì)基于自身業(yè)務(wù)需求,自定義鏈路埋點(diǎn)代碼以采集特定場(chǎng)景下的鏈路信息。通過(guò)無(wú)侵入埋點(diǎn)解決通用鏈路采集并結(jié)合手動(dòng)埋點(diǎn)滿足個(gè)性化定制需求的方式,在較少代碼侵入的情況下,滿足應(yīng)用全面鏈路采集的需求。
考慮到日志數(shù)據(jù)后續(xù)解析、處理的統(tǒng)一標(biāo)準(zhǔn)化,業(yè)務(wù)團(tuán)隊(duì)需制訂并實(shí)施標(biāo)準(zhǔn)化的日志數(shù)據(jù)結(jié)構(gòu)規(guī)范。對(duì)于日志數(shù)據(jù),采用獨(dú)立組件上報(bào)的模式進(jìn)行采集,在相應(yīng)的服務(wù)器上部署獨(dú)立的日志采集組件(如Filebeat、Flunetbit),負(fù)責(zé)完成本地日志數(shù)據(jù)的讀取、上報(bào)日志服務(wù)端(如ElasticSearch、Loki、ClickHouse)。日志采集組件使用通用的采集配置模板,以便運(yùn)維人員快速修改進(jìn)行本地日志采集,提升日志接入監(jiān)控的效率,并于開(kāi)發(fā)約定雙方日志目錄,實(shí)現(xiàn)雙方解耦。
可觀測(cè)性數(shù)據(jù)分析
指標(biāo)分析處理
指標(biāo)采集端(如Prometheus、Grafana Agent)將從指標(biāo)采集組件中采集到的指標(biāo),首先根據(jù)不同指標(biāo)的特征在內(nèi)存中進(jìn)行聚類,對(duì)于內(nèi)存中存儲(chǔ)時(shí)長(zhǎng)超過(guò)兩個(gè)小時(shí)的指標(biāo)數(shù)據(jù),進(jìn)行壓縮并存儲(chǔ)在磁盤中,以實(shí)現(xiàn)長(zhǎng)久存儲(chǔ)指標(biāo)數(shù)據(jù)的目的(使用Thanos)。采用定時(shí)觸發(fā)器的方法(Prometheus record rule),定期從時(shí)序數(shù)據(jù)庫(kù)中讀取指標(biāo)數(shù)據(jù),對(duì)其進(jìn)行聚合分析,然后生成聚合指標(biāo),以支持高層抽象粒度分析。此外,由于指標(biāo)監(jiān)測(cè)數(shù)據(jù)隨時(shí)間價(jià)值降低,但存儲(chǔ)成本隨時(shí)間增加,將歷史數(shù)據(jù)進(jìn)行壓縮降采樣(Thanos downsampling),在保留更長(zhǎng)歷史數(shù)據(jù)的同時(shí)減少存儲(chǔ)成本,而且還可以提升查詢效率。
鏈路/日志分析處理
鏈路服務(wù)端接收到客戶端上報(bào)的鏈路數(shù)據(jù)后,首先將鏈路數(shù)據(jù)推送到消息隊(duì)列(如Kafka)中,使用消息隊(duì)列的高性能流式處理特性,為鏈路數(shù)據(jù)的后續(xù)分析、存儲(chǔ)提供性能保障。之后,一方面鏈路存儲(chǔ)應(yīng)用讀取消息隊(duì)列中的鏈路數(shù)據(jù),將其直接存儲(chǔ)在全文檢索中間件(如ElasticSearch)中,另一方面鏈路分析應(yīng)用讀取消息隊(duì)列中的鏈路數(shù)據(jù),在內(nèi)存中進(jìn)行鏈路數(shù)據(jù)的聚類分析,以構(gòu)建系統(tǒng)服務(wù)拓?fù)?,服?wù)拓?fù)湫畔到y(tǒng)中組成分布式鏈路的所有應(yīng)用、應(yīng)用間調(diào)用的計(jì)數(shù)與平均延時(shí)、應(yīng)用內(nèi)部的錯(cuò)誤分布,鏈路分析應(yīng)用將分析后的數(shù)據(jù)也存儲(chǔ)在全文檢索中間件中。使用全文檢索中間件存儲(chǔ)鏈路數(shù)據(jù)與服務(wù)拓?fù)鋽?shù)據(jù),可支持實(shí)現(xiàn)后續(xù)豐富的數(shù)據(jù)檢索場(chǎng)景。
日志服務(wù)端與鏈路服務(wù)端類似,日志服務(wù)端(如ElasticSearch、Loki)接收到日志采集組件上報(bào)的日志數(shù)據(jù)后,由日志解析組件基于預(yù)先定義的日志解析規(guī)則,對(duì)日志數(shù)據(jù)進(jìn)行格式解析與數(shù)據(jù)過(guò)濾,并將解析后的數(shù)據(jù)構(gòu)建成標(biāo)準(zhǔn)JSON數(shù)據(jù)格式,分類存儲(chǔ)在全文檢索中間件(如ElasticSearch)中。日志解析組件為集群部署,通過(guò)并行的流式處理,保證解析過(guò)程的高性能。日志解析規(guī)則支持多種日志解析格式,如JSON、Logfmt等,以及支持自定義日志解析器,讓運(yùn)維人員可以自定義日志格式,以滿足不同業(yè)務(wù)場(chǎng)景的需求。
可觀測(cè)性數(shù)據(jù)價(jià)值輸出
可觀測(cè)性價(jià)值輸出示例——指標(biāo)大盤
通過(guò)統(tǒng)一的可觀測(cè)性平臺(tái),提供一體化、可配置化、可視化的監(jiān)控、告警、排障、日志檢索等能力,實(shí)現(xiàn)可觀測(cè)體系的價(jià)值輸出,包括故障告警、監(jiān)控大屏、鏈路檢索、日志檢索等功能。故障告警,提供針對(duì)系統(tǒng)故障的自動(dòng)化實(shí)時(shí)告警功能。該功能支持用戶自定義基于指標(biāo)、日志關(guān)鍵詞的告警規(guī)則,自動(dòng)觸發(fā)告警,并通過(guò)多渠道(郵件、通信軟件)實(shí)時(shí)發(fā)送告警通知,保證運(yùn)維人員能第一時(shí)間發(fā)現(xiàn)系統(tǒng)中的異常情況。監(jiān)控大屏,提供針對(duì)系統(tǒng)當(dāng)前運(yùn)行狀態(tài)的監(jiān)控圖表展示功能。該功能支持用戶基于預(yù)設(shè)的大屏模板創(chuàng)建監(jiān)控大屏,監(jiān)控大屏實(shí)時(shí)調(diào)用指標(biāo)服務(wù)端的指標(biāo)數(shù)據(jù)查詢接口,生成監(jiān)控面板。監(jiān)控面板支持豐富的指標(biāo)展示形式,如:折線圖、柱狀圖、餅圖、度量?jī)x等,方便運(yùn)維人員在開(kāi)發(fā)、測(cè)試、生產(chǎn)階段,直觀、高效的了解系統(tǒng)當(dāng)前情況,或進(jìn)行故障分析與定位。
可觀測(cè)性價(jià)值輸出示例——排障
鏈路檢索,提供鏈路數(shù)據(jù)查詢、鏈路詳情展示、服務(wù)拓?fù)浞治龉δ堋T摴δ苤С钟脩艋阪溌稩D或者時(shí)間范圍查詢鏈路數(shù)據(jù)。在分布式鏈路詳情頁(yè)面中,可以直觀看到請(qǐng)求在系統(tǒng)內(nèi)流轉(zhuǎn)時(shí)經(jīng)過(guò)的應(yīng)用服務(wù)關(guān)鍵路徑,以及每個(gè)處理階段的具體耗時(shí)情況。開(kāi)發(fā)、運(yùn)維人員可以利用鏈路檢索功能,進(jìn)行快速的故障定位,分析各個(gè)調(diào)用環(huán)節(jié)的性能與可用性,或者統(tǒng)計(jì)分析用戶行為數(shù)據(jù)日志檢索,提供日志數(shù)據(jù)查詢與分析功能。運(yùn)維人員可以借助日志檢索功能,從分布式系統(tǒng)的海量日志中,快速定位到所需日志,以進(jìn)行基于日志的故障原因排查或者業(yè)務(wù)數(shù)據(jù)統(tǒng)計(jì)。
通過(guò)可觀測(cè)性體系設(shè)計(jì),對(duì)復(fù)雜的云原生系統(tǒng)不同層次的監(jiān)控對(duì)象,執(zhí)行可觀測(cè)性數(shù)據(jù)采集、分析、價(jià)值輸出流程,實(shí)現(xiàn)云原生系統(tǒng)的全范圍監(jiān)控,支持快速洞察系統(tǒng)當(dāng)前運(yùn)行狀況;針對(duì)系統(tǒng)故障進(jìn)行實(shí)時(shí)告警,通過(guò)多維監(jiān)控工具輔助快速的故障定位與解決,保障系統(tǒng)可用性;該體系提供的監(jiān)控能力,同樣可以應(yīng)用在系統(tǒng)開(kāi)發(fā)與測(cè)試階段,用于快速排查開(kāi)發(fā)問(wèn)題,輔助進(jìn)行應(yīng)用性能觀測(cè),提升業(yè)務(wù)交付的效率與質(zhì)量。
未來(lái)展望
可觀測(cè)性平臺(tái)
在平臺(tái)建設(shè)過(guò)程中,我們發(fā)現(xiàn)關(guān)于云原生系統(tǒng)的可觀測(cè)性體系,仍然有可以持續(xù)深耕的領(lǐng)域:
持續(xù)剖析(Continues Profilling),是一種深入分析程序復(fù)雜性和性能的動(dòng)態(tài)方法,例如CPU利用率或函數(shù)調(diào)用的頻率和持續(xù)時(shí)間。通過(guò)持續(xù)剖析可以準(zhǔn)確定位應(yīng)用程序的哪些部分在哪個(gè)時(shí)刻消耗的資源最多,這為優(yōu)化核心程序執(zhí)行性能提供了一個(gè)可靠的方案。
OpenTelemetry (OTEL)標(biāo)準(zhǔn),由OpenCensus和OpenTracing項(xiàng)目合并形成的CNCF項(xiàng)目,是一個(gè)供儀表化、生成、收集和導(dǎo)出遙測(cè)數(shù)據(jù)(跟蹤、指標(biāo)和日志)使用的供應(yīng)商中立的開(kāi)源可觀測(cè)性框架。提供了一組標(biāo)準(zhǔn)規(guī)范和工具集,規(guī)范可觀測(cè)性數(shù)據(jù)的數(shù)據(jù)模型、數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)治理和數(shù)據(jù)導(dǎo)出。目前各個(gè)主流開(kāi)源項(xiàng)目(包括Kubernetes、Spring Cloud)都已經(jīng)開(kāi)始支持或切換到OTEL,是CNCF未來(lái)主推方案,值得關(guān)注。
eBPF(Extended Berkeley Packet Filter),是一種數(shù)據(jù)包過(guò)濾技術(shù),從BPF(Berkeley Packet Filter)技術(shù)擴(kuò)展而來(lái)。自Linux 4.14內(nèi)核以來(lái),Linux社區(qū)為eBPF加入多個(gè)新特性和優(yōu)化改進(jìn),提升了eBPF在跟蹤分析、可觀測(cè)性、安全和網(wǎng)絡(luò)加速等場(chǎng)景的應(yīng)用能力。eBPF在內(nèi)核中實(shí)施觀測(cè)和跟蹤,可以實(shí)現(xiàn)無(wú)侵入性的持續(xù)剖析,并基于各種可能的來(lái)源生成可見(jiàn)性事件,擴(kuò)展了可以實(shí)現(xiàn)的可見(jiàn)性深度。
擴(kuò)展到系統(tǒng)層面的全棧全鏈路觀測(cè)能力——采集
擴(kuò)展到系統(tǒng)層面的全棧全鏈路觀測(cè)能力——透視
未來(lái),基于eBPF在操作系統(tǒng)內(nèi)核態(tài)實(shí)施可觀測(cè)性,與用戶態(tài)OpenTelemetry結(jié)合建立云原生觀測(cè)數(shù)據(jù)收集處理的標(biāo)準(zhǔn)范式,并引入持續(xù)剖析,不斷擴(kuò)展可觀測(cè)性深度和廣度,將成為增強(qiáng)云原生環(huán)境可觀測(cè)性未來(lái)發(fā)展的趨勢(shì)。
總結(jié)
云原生架構(gòu)在提升企業(yè)系統(tǒng)交付效率的同時(shí),也使得系統(tǒng)的復(fù)雜性成倍提升,因此如何使系統(tǒng)具有可觀測(cè)性,系統(tǒng)內(nèi)部狀態(tài)易于洞察變得尤其重要,系統(tǒng)可觀測(cè)性平臺(tái)正是云原生趨勢(shì)下的必然產(chǎn)物。本文闡述了云原生系統(tǒng)可觀測(cè)性平臺(tái)的從數(shù)據(jù)采集、分析、存儲(chǔ)、價(jià)值輸出的關(guān)鍵技術(shù)方案與數(shù)據(jù)間的關(guān)聯(lián)關(guān)系,以及如何利用可觀測(cè)性平臺(tái)高效進(jìn)行故障定位與解決,降低故障定位與解決的運(yùn)維成本,在最大程度上保障云原生系統(tǒng)的高性能與高可用性。同時(shí),隨著操作系統(tǒng)eBPF、Opentelementry、人工智能機(jī)器學(xué)習(xí)等技術(shù)的不斷發(fā)展,可觀測(cè)性技術(shù)一定會(huì)在信創(chuàng)和云原生場(chǎng)景中發(fā)揮更大作用,推動(dòng)下一代監(jiān)控技術(shù)的發(fā)展。
- 上一篇
萬(wàn)字詳解滴滴彈性云混部的落地歷程
由于未來(lái)自建IDC公共集群的容量有限,并且公有云需要額外購(gòu)買資源,存在成本增加,所以總體來(lái)說(shuō)驅(qū)逐目的優(yōu)先級(jí)是:混部集群>自建IDC公共集群>公有云,如果不是全局性問(wèn)題,還是盡快在混部集群內(nèi)部進(jìn)行驅(qū)逐。
- 下一篇
從最終用戶視角看待數(shù)字化轉(zhuǎn)型中的挑戰(zhàn)和機(jī)遇
Reliance Industries的Divyang提供了至關(guān)重要的最終用戶視角,他表示,企業(yè)面臨著通過(guò)降低運(yùn)營(yíng)成本和提高競(jìng)爭(zhēng)力來(lái)提高盈利能力的壓力。
相關(guān)資訊
- 人工智能技術(shù)如何保護(hù)自然?
- 物聯(lián)網(wǎng)采用熱潮——您需要知道的
- 區(qū)塊鏈,正找回自我
- 無(wú)線技術(shù)是未來(lái)智能建筑的關(guān)鍵
- 大數(shù)據(jù)有哪些發(fā)展趨勢(shì)以及在不同
- 淺談:云原生可觀測(cè)性的未來(lái)
- 2023年金融服務(wù)行業(yè)的數(shù)字化轉(zhuǎn)型
- 大數(shù)據(jù)和人工智能:當(dāng)兩大力量相遇
- 單對(duì)以太網(wǎng)技術(shù)的六大優(yōu)勢(shì)
- 物聯(lián)網(wǎng)連接數(shù)將在四年內(nèi)增長(zhǎng)400%