背景

當(dāng)前數(shù)字化轉(zhuǎn)型進(jìn)程持續(xù)加速中，在頂層設(shè)計指導(dǎo)下，結(jié)合自身發(fā)展需要，全面推廣一朵全棧云，深化云原生生態(tài)建設(shè)，推動業(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ù)價值。

成都創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都做網(wǎng)站、網(wǎng)站制作、柯坪網(wǎng)絡(luò)推廣、小程序設(shè)計、柯坪網(wǎng)絡(luò)營銷、柯坪企業(yè)策劃、柯坪品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；成都創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供柯坪建站搭建服務(wù)，24小時服務(wù)熱線：13518219792，官方網(wǎng)址：www.cdcxhl.com

云原生建設(shè)是一個綜合性的系統(tǒng)工程，涉及微服務(wù)重構(gòu)、國產(chǎn)信創(chuàng)、分布式數(shù)據(jù)庫、容器云、服務(wù)治理等多個方面，系統(tǒng)規(guī)模和復(fù)雜度以及數(shù)據(jù)量成倍提升，可能發(fā)生故障的數(shù)量和類型也同比提升，全面有效的保障服務(wù)持續(xù)穩(wěn)定運(yùn)行至關(guān)重要，云原生安全運(yùn)營是當(dāng)下面臨的重要課題。

面臨的挑戰(zhàn)

要保障服務(wù)安全運(yùn)營，首先必須要能全面理解系統(tǒng)運(yùn)行的狀態(tài)和行為，這要求實(shí)現(xiàn)從底層到上層對網(wǎng)絡(luò)、主機(jī)、容器、應(yīng)用、業(yè)務(wù)服務(wù)等進(jìn)行全?？捎^測?？捎^測性（observability）最早來源于控制理論領(lǐng)域，指的是系統(tǒng)可以由其外部輸出推斷其內(nèi)部狀態(tài)的程度。在云原生架構(gòu)中，可觀測性描述的是對系統(tǒng)中所發(fā)生情況的掌握程度。云原生系統(tǒng)規(guī)模大、系統(tǒng)復(fù)雜、動態(tài)變化，對其進(jìn)行全面、有效的理解和掌控，以及保障安全運(yùn)營方面面臨著巨大的挑戰(zhàn)：

如何理解大規(guī)模動態(tài)容器環(huán)境中應(yīng)用的實(shí)際運(yùn)行情況：云原生系統(tǒng)通過容器化技術(shù)對基礎(chǔ)設(shè)施進(jìn)行了標(biāo)準(zhǔn)化，提升了應(yīng)用部署的便利性，并支持動態(tài)擴(kuò)縮容?；A(chǔ)設(shè)施層的信息通過虛擬化封裝不再透明，微服務(wù)化架構(gòu)使應(yīng)用部署的服務(wù)數(shù)量急劇增加，容器集群根據(jù)業(yè)務(wù)運(yùn)行情況動態(tài)調(diào)度。服務(wù)間流量既有南北向，也有東西向，且以東西向?yàn)橹?。在這樣大規(guī)模動態(tài)服務(wù)實(shí)例的環(huán)境中，有效全面理解從應(yīng)用、容器、主機(jī)到網(wǎng)絡(luò)的運(yùn)行情況，是保障業(yè)務(wù)安全運(yùn)營的關(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)用路徑變長且跨越網(wǎng)絡(luò)交互，當(dāng)發(fā)生錯誤時怎樣快速定位故障點(diǎn)，及時采取流量切換、服務(wù)回退等措施，是保障服務(wù)持續(xù)運(yùn)行的關(guān)鍵；不同服務(wù)模塊在整個系統(tǒng)中承擔(dān)的功能不同，請求壓力也不同，當(dāng)系統(tǒng)出現(xiàn)性能瓶頸時，怎樣快速發(fā)現(xiàn)出現(xiàn)瓶頸的服務(wù)并進(jìn)行服務(wù)擴(kuò)容，或者及時采取熔斷限流措施，是保障服務(wù)穩(wěn)定運(yùn)行的關(guān)鍵。

如何保證觀測能力的實(shí)時性：云原生應(yīng)用的動態(tài)性要求可觀測性平臺必須具備實(shí)時性或近實(shí)時性。如果應(yīng)用的升級或擴(kuò)容在分鐘級完成，那么監(jiān)測系統(tǒng)就必須提供秒級的反饋能力。云原生系統(tǒng)產(chǎn)生的指標(biāo)、追蹤、日志等數(shù)據(jù)往往是海量的，因此對可觀測性平臺實(shí)時處理海量數(shù)據(jù)的能力提出了極高要求。

如何實(shí)現(xiàn)多個運(yùn)維平臺的有機(jī)整合：云原生生態(tài)涉及多個支撐系統(tǒng)，各系統(tǒng)的有機(jī)協(xié)調(diào)運(yùn)行才能共同構(gòu)成云原生運(yùn)行平臺，但現(xiàn)實(shí)是各個運(yùn)維工具平臺由不同時期、不同產(chǎn)品、不同廠商建設(shè)，怎樣將這些運(yùn)維工具平臺的數(shù)據(jù)進(jìn)行有效的治理，實(shí)現(xiàn)數(shù)據(jù)關(guān)聯(lián)整合，充分發(fā)揮數(shù)據(jù)的價值，實(shí)現(xiàn)運(yùn)維的全景運(yùn)行、有機(jī)協(xié)調(diào)，是對運(yùn)維數(shù)據(jù)治理能力的巨大挑戰(zhàn)。

針對上述云原生架構(gòu)帶來的新問題與挑戰(zhàn)，我們將嘗試設(shè)計一套整體的云原生可觀測性平臺來解決上述擔(dān)憂。

可觀測平臺設(shè)計

可觀測性平臺方案設(shè)計由可觀測運(yùn)維對象、可觀測數(shù)據(jù)、數(shù)據(jù)關(guān)聯(lián)性、可觀測方案實(shí)現(xiàn)四部分組成，涵蓋識別運(yùn)維對象、可觀測數(shù)據(jù)標(biāo)準(zhǔn)、不同數(shù)據(jù)關(guān)聯(lián)實(shí)現(xiàn)，組成整體的可觀測性方案，最后實(shí)現(xiàn)價值輸出，具體如下：

可觀測對象

云原生系統(tǒng)可觀測體系需要涵蓋從網(wǎng)絡(luò)、主機(jī)、容器、應(yīng)用、業(yè)務(wù)服務(wù)等所有云原生系統(tǒng)的組成部分，根據(jù)監(jiān)控對象在系統(tǒng)中所處的位置，將可觀測體系劃分為四個層次，如圖1所示，涵蓋從系統(tǒng)基礎(chǔ)設(shè)施、容器、應(yīng)用到業(yè)務(wù)的全范圍，分別為：

圖1 云原生運(yùn)維棧示意圖

基礎(chǔ)設(shè)施層：也即IaaS層，該層涉及的監(jiān)控對象為系統(tǒng)底層資源，如網(wǎng)絡(luò)、存儲設(shè)備、裸金屬等。這些設(shè)備與組件的可靠性，直接影響到上層應(yīng)用服務(wù)的穩(wěn)定性。該層關(guān)聯(lián)的可觀測性數(shù)據(jù)包含指標(biāo)（網(wǎng)絡(luò)流量、網(wǎng)絡(luò)連接數(shù)、主機(jī)性能）、日志（交換機(jī)日志、操作系統(tǒng)日志）、事件（系統(tǒng)平臺事件、故障、宕機(jī)）等。

容器層：也即，PaaS層，該層涉及的監(jiān)控對象涵蓋了容器內(nèi)的系統(tǒng)資源，如：Kubernetes服務(wù)運(yùn)行情況、集群節(jié)點(diǎn)、CPU、內(nèi)存、存儲等，是針對容器云平臺進(jìn)行的監(jiān)控，這些資源的使用情況決定了應(yīng)用服務(wù)的性能和容量。該層關(guān)聯(lián)的可觀測性數(shù)據(jù)包含指標(biāo)（節(jié)點(diǎn)或容器的CPU使用率、內(nèi)存使用率、存儲使用率等）、日志（Kubernetes各個組件日志）、事件（Kubernetes Event）等。

應(yīng)用層：該層涉及的監(jiān)控對象和應(yīng)用服務(wù)緊密相關(guān)，如：服務(wù)可用性、JVM、中間件等，這些監(jiān)控對象的健康度與負(fù)載情況決定了應(yīng)用之上運(yùn)行的業(yè)務(wù)的可用性與性能。該層關(guān)聯(lián)的可觀測性數(shù)據(jù)包含指標(biāo)（服務(wù)存活性、JVM內(nèi)存使用率、JVM GC停頓時長、數(shù)據(jù)庫連接、緩存連接、消息隊(duì)列消息堆積數(shù)等）、鏈路（應(yīng)用服務(wù)間調(diào)用、應(yīng)用調(diào)用中間件形成的分布式鏈路）、日志（運(yùn)行日志、錯誤日志）等。

業(yè)務(wù)層：該層涉及的監(jiān)控對象主要涉及業(yè)務(wù)運(yùn)行信息，如：交易量、交易金額、服務(wù)請求量、請求延遲、變化比率、錯誤率等，這些監(jiān)控指標(biāo)直接反應(yīng)業(yè)務(wù)的運(yùn)行狀態(tài)，體現(xiàn)著用戶體驗(yàn)與企業(yè)發(fā)展情況。該層關(guān)聯(lián)的可觀測性數(shù)據(jù)包含指標(biāo)（訪問統(tǒng)計、請求數(shù)、錯誤數(shù)、延時等）、日志（訪問日志、錯誤日志）。

可觀測數(shù)據(jù)

可觀測性體系的構(gòu)建是通過對系統(tǒng)運(yùn)行狀態(tài)數(shù)據(jù)的收集、分析來判斷系統(tǒng)的運(yùn)行狀態(tài)并實(shí)現(xiàn)快速排障。因此，首先要定義可觀測性數(shù)據(jù)，當(dāng)前業(yè)界主流標(biāo)準(zhǔn)將可觀測性數(shù)據(jù)分為三個類別：

圖2 Metrics, tracing, logging及關(guān)聯(lián)關(guān)系

指標(biāo)（metrics）：指標(biāo)數(shù)據(jù)通常為一段時間內(nèi)可度量的數(shù)據(jù)，也被稱為時序數(shù)據(jù)，用于觀測系統(tǒng)的狀態(tài)與趨勢，常用于畫曲線圖。支持以下四種數(shù)據(jù)：

類型	說明	示例
Counter	單調(diào)遞增的計數(shù)器	http請求總數(shù)、QPS、TPS等
Gauge	支持加和減的計數(shù)器	CPU使用率、內(nèi)存使用值、負(fù)載等
Histogram	直方圖	對觀察值（如請求持續(xù)時間或響應(yīng)大小）進(jìn)行采樣，并統(tǒng)計樣本分布，服務(wù)端可用于計算分位數(shù)（P95、P99）、Apdex指數(shù)，如果需要聚合或者觀測值的范圍和分布，可以選擇直方圖。
Summary	分位數(shù)	百分位（客戶端直接計算），如果需要精確的分位數(shù)，選擇Summary。

指標(biāo)數(shù)據(jù)類型

指標(biāo)效果展示

鏈路（tracing）：分布式追蹤是一種理解分布式系統(tǒng)執(zhí)行過程中參與的上下游及影響，支持跟蹤應(yīng)用請求從前端到后端服務(wù)以及數(shù)據(jù)庫等中間件的流轉(zhuǎn)過程，支持對高延時與高錯誤率的請求進(jìn)行故障排查。同時從鏈路數(shù)據(jù)中，可以提取出業(yè)務(wù)的RED（速率、錯誤、持續(xù)時間），豐富指標(biāo)監(jiān)控。

Trace路徑感知與性能分析

Trace效果展示

日志（logging）：日志數(shù)據(jù)是離散事件的記錄，反應(yīng)系統(tǒng)運(yùn)行過程中產(chǎn)生的信息，可以詳細(xì)解釋系統(tǒng)的運(yùn)行狀態(tài)。大多數(shù)開發(fā)語言、應(yīng)用程序框架或庫都支持日志。日志可以分為不同的類別，例如系統(tǒng)日志、應(yīng)用日志、安全日志、基礎(chǔ)設(shè)施日志。日志中存儲的信息是無格式的文本，需要制定對應(yīng)的字段規(guī)范以便于后續(xù)分析，例如日志包含服務(wù)名稱、traceid，并附加采集的容器信息。

日志展示

數(shù)據(jù)關(guān)聯(lián)性

可觀測對象雖然劃分為四層，但在實(shí)際使用時，通常需要結(jié)合多層數(shù)據(jù)和多個運(yùn)維工具平臺中的數(shù)據(jù)一起來分析問題，這就需要觀測數(shù)據(jù)存在一定關(guān)聯(lián)性。如下圖所示：

數(shù)據(jù)關(guān)聯(lián)性

從數(shù)據(jù)特性上可以區(qū)分為：

同一運(yùn)維對象關(guān)聯(lián)

同一運(yùn)維對象應(yīng)該具有確定且唯一的標(biāo)識，在不同數(shù)據(jù)中（指標(biāo)、鏈路、日志）應(yīng)該使用統(tǒng)一的標(biāo)識標(biāo)準(zhǔn)，用戶可以使用同一套標(biāo)識分別查詢到不同數(shù)據(jù)，以方便關(guān)聯(lián)分析。例如根據(jù)Prometheus告警中帶的標(biāo)簽和時間戳，可以在日志中定位到對應(yīng)服務(wù)在特定時刻的行為，在鏈路中也可以定位到對應(yīng)服務(wù)特定時刻的執(zhí)行鏈路。

相同運(yùn)維對象和對應(yīng)的指標(biāo)和日志數(shù)據(jù)

不同運(yùn)維對象關(guān)聯(lián)

不同運(yùn)維對象間的關(guān)聯(lián)關(guān)系比較多樣化，需要具體問題具體分析。在傳統(tǒng)的環(huán)境中，我們通常基于IP進(jìn)行不同主機(jī)、網(wǎng)絡(luò)節(jié)點(diǎn)進(jìn)行標(biāo)識和關(guān)聯(lián)，而在容器云環(huán)境中，通?；跇?biāo)簽標(biāo)識不同運(yùn)維對象和資源，不同資源類型不同，但應(yīng)該具有相同的標(biāo)簽，這樣才能實(shí)現(xiàn)組合。例如Kubernetes中Deployment與Service中的定義必須匹配對應(yīng)的Labels才能實(shí)現(xiàn)匹配和對應(yīng)功能。

不同運(yùn)維對象基于標(biāo)簽識別關(guān)聯(lián)

鏈路ID關(guān)聯(lián)

在分布式環(huán)境中，應(yīng)用服務(wù)被拆分為不同的服務(wù)模塊，一個服務(wù)請求會跨越多個不同的運(yùn)維對象，運(yùn)維對象也服務(wù)于多個不同請求，這種分布式并發(fā)性使得如何區(qū)分不同請求成為一個難題，這個問題與TCP服務(wù)于多個請求的問題類似，HTTP1.1沒有請求標(biāo)識，無法多路復(fù)用，HTT2中加入了流標(biāo)識才可以，類似的，不同應(yīng)用間服務(wù)請求加入唯一的標(biāo)識ID即可區(qū)分彼此?；阪溌稩D的鏈路跟蹤可以將一次分布式請求還原成調(diào)用鏈路，對一次分布式請求的調(diào)用情況集中展示，比如各個服務(wù)節(jié)點(diǎn)上的耗時、請求具體到達(dá)哪臺機(jī)器上、每個服務(wù)節(jié)點(diǎn)的請求狀態(tài)等等，實(shí)現(xiàn)調(diào)用拓?fù)淇梢暬⑸舷掠我蕾嚪治?、故障快速定位等?/p>

基于traceid關(guān)聯(lián)多個運(yùn)維對象的日志和鏈路

利用上述運(yùn)維對象和數(shù)據(jù)的關(guān)聯(lián)性，并結(jié)合梳理的全棧運(yùn)行環(huán)境（圖1），包括基礎(chǔ)設(shè)施、容器云平臺、應(yīng)用和業(yè)務(wù)信息，構(gòu)建整體的全景可觀測性拓?fù)鋱D，針對不同組件、不同層面的運(yùn)維對象分別展示不同觀測數(shù)據(jù)，并與CMDB信息聯(lián)動，實(shí)現(xiàn)直觀的拓?fù)湫畔⒄故尽?/p>

全棧監(jiān)測拓?fù)涫疽鈭D

可觀測實(shí)現(xiàn)

可觀測性體系的實(shí)現(xiàn)分為三大流程：可觀測性數(shù)據(jù)采集、可觀測性數(shù)據(jù)分析、可觀測性數(shù)據(jù)價值輸出，覆蓋可觀測性數(shù)據(jù)的產(chǎn)生、采集、處理分析、存儲、應(yīng)用的全流程。

可觀測性數(shù)據(jù)采集

數(shù)據(jù)采集

該流程主要完成可觀測性數(shù)據(jù)的規(guī)范化定義與采集，包括指標(biāo)、鏈路、日志三類數(shù)據(jù)。怎樣保證采集數(shù)據(jù)的完整性以及對應(yīng)用的無侵入性，是方案需要考慮的關(guān)鍵。指標(biāo)數(shù)據(jù)為時序數(shù)據(jù)，數(shù)據(jù)結(jié)構(gòu)相對固定，在設(shè)計時需限制表示業(yè)務(wù)信息的標(biāo)簽數(shù)量與取值范圍，避免數(shù)據(jù)量過大，對指標(biāo)服務(wù)端的性能造成影響。針對Kubernetes平臺、業(yè)務(wù)應(yīng)用、中間件等，采用服務(wù)端拉取的模式進(jìn)行采集，在相應(yīng)的服務(wù)器上部署獨(dú)立的指標(biāo)采集組件，這些組件負(fù)責(zé)收集指標(biāo)數(shù)據(jù)并通過HTTP協(xié)議對外提供指標(biāo)查詢接口，由指標(biāo)服務(wù)端（如Prometheus）定時調(diào)用。針對業(yè)務(wù)應(yīng)用，使用Java Agent技術(shù)在JVM應(yīng)用啟動時進(jìn)行JVM字節(jié)碼的增強(qiáng)，在不改變業(yè)務(wù)代碼的前提下進(jìn)行JVM性能指標(biāo)與業(yè)務(wù)指標(biāo)的生成，實(shí)現(xiàn)監(jiān)控邏輯與業(yè)務(wù)邏輯解耦，保證開發(fā)流程的擴(kuò)展性。以上采集過程均能做到對應(yīng)用無侵入。

為了保證鏈路數(shù)據(jù)結(jié)構(gòu)相對固定的同時提高數(shù)據(jù)擴(kuò)展性，鏈路數(shù)據(jù)結(jié)構(gòu)采用半結(jié)構(gòu)化的JSON格式。對于鏈路數(shù)據(jù)，在開發(fā)框架中引入鏈路埋點(diǎn)庫。該庫對于服務(wù)間調(diào)用、服務(wù)調(diào)用主流中間件（如數(shù)據(jù)庫、緩存、消息隊(duì)列等）等關(guān)鍵程序執(zhí)行位置自動埋點(diǎn)，提供了通用鏈路采集埋點(diǎn)邏輯，引入該開發(fā)庫就能自動完成相應(yīng)位置的鏈路采集。同時提供了手動埋點(diǎn)能力，供開發(fā)團(tuán)隊(duì)基于自身業(yè)務(wù)需求，自定義鏈路埋點(diǎn)代碼以采集特定場景下的鏈路信息。通過無侵入埋點(diǎn)解決通用鏈路采集并結(jié)合手動埋點(diǎn)滿足個性化定制需求的方式，在較少代碼侵入的情況下，滿足應(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ī)范。對于日志數(shù)據(jù)，采用獨(dú)立組件上報的模式進(jìn)行采集，在相應(yīng)的服務(wù)器上部署獨(dú)立的日志采集組件（如Filebeat、Flunetbit），負(fù)責(zé)完成本地日志數(shù)據(jù)的讀取、上報日志服務(wù)端（如ElasticSearch、Loki、ClickHouse）。日志采集組件使用通用的采集配置模板，以便運(yùn)維人員快速修改進(jìn)行本地日志采集，提升日志接入監(jiān)控的效率，并于開發(fā)約定雙方日志目錄，實(shí)現(xiàn)雙方解耦。

可觀測性數(shù)據(jù)分析

指標(biāo)分析處理

指標(biāo)采集端（如Prometheus、Grafana Agent）將從指標(biāo)采集組件中采集到的指標(biāo)，首先根據(jù)不同指標(biāo)的特征在內(nèi)存中進(jìn)行聚類，對于內(nèi)存中存儲時長超過兩個小時的指標(biāo)數(shù)據(jù)，進(jìn)行壓縮并存儲在磁盤中，以實(shí)現(xiàn)長久存儲指標(biāo)數(shù)據(jù)的目的（使用Thanos）。采用定時觸發(fā)器的方法（Prometheus record rule），定期從時序數(shù)據(jù)庫中讀取指標(biāo)數(shù)據(jù)，對其進(jìn)行聚合分析，然后生成聚合指標(biāo)，以支持高層抽象粒度分析。此外，由于指標(biāo)監(jiān)測數(shù)據(jù)隨時間價值降低，但存儲成本隨時間增加，將歷史數(shù)據(jù)進(jìn)行壓縮降采樣（Thanos downsampling），在保留更長歷史數(shù)據(jù)的同時減少存儲成本，而且還可以提升查詢效率。

鏈路/日志分析處理

鏈路服務(wù)端接收到客戶端上報的鏈路數(shù)據(jù)后，首先將鏈路數(shù)據(jù)推送到消息隊(duì)列（如Kafka）中，使用消息隊(duì)列的高性能流式處理特性，為鏈路數(shù)據(jù)的后續(xù)分析、存儲提供性能保障。之后，一方面鏈路存儲應(yīng)用讀取消息隊(duì)列中的鏈路數(shù)據(jù)，將其直接存儲在全文檢索中間件（如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)用的計數(shù)與平均延時、應(yīng)用內(nèi)部的錯誤分布，鏈路分析應(yīng)用將分析后的數(shù)據(jù)也存儲在全文檢索中間件中。使用全文檢索中間件存儲鏈路數(shù)據(jù)與服務(wù)拓?fù)鋽?shù)據(jù)，可支持實(shí)現(xiàn)后續(xù)豐富的數(shù)據(jù)檢索場景。

日志服務(wù)端與鏈路服務(wù)端類似，日志服務(wù)端（如ElasticSearch、Loki）接收到日志采集組件上報的日志數(shù)據(jù)后，由日志解析組件基于預(yù)先定義的日志解析規(guī)則，對日志數(shù)據(jù)進(jìn)行格式解析與數(shù)據(jù)過濾，并將解析后的數(shù)據(jù)構(gòu)建成標(biāo)準(zhǔn)JSON數(shù)據(jù)格式，分類存儲在全文檢索中間件（如ElasticSearch）中。日志解析組件為集群部署，通過并行的流式處理，保證解析過程的高性能。日志解析規(guī)則支持多種日志解析格式，如JSON、Logfmt等，以及支持自定義日志解析器，讓運(yùn)維人員可以自定義日志格式，以滿足不同業(yè)務(wù)場景的需求。

可觀測性數(shù)據(jù)價值輸出

可觀測性價值輸出示例——指標(biāo)大盤

通過統(tǒng)一的可觀測性平臺，提供一體化、可配置化、可視化的監(jiān)控、告警、排障、日志檢索等能力，實(shí)現(xiàn)可觀測體系的價值輸出，包括故障告警、監(jiān)控大屏、鏈路檢索、日志檢索等功能。故障告警，提供針對系統(tǒng)故障的自動化實(shí)時告警功能。該功能支持用戶自定義基于指標(biāo)、日志關(guān)鍵詞的告警規(guī)則，自動觸發(fā)告警，并通過多渠道（郵件、通信軟件）實(shí)時發(fā)送告警通知，保證運(yùn)維人員能第一時間發(fā)現(xiàn)系統(tǒng)中的異常情況。監(jiān)控大屏，提供針對系統(tǒng)當(dāng)前運(yùn)行狀態(tài)的監(jiān)控圖表展示功能。該功能支持用戶基于預(yù)設(shè)的大屏模板創(chuàng)建監(jiān)控大屏，監(jiān)控大屏實(shí)時調(diào)用指標(biāo)服務(wù)端的指標(biāo)數(shù)據(jù)查詢接口，生成監(jiān)控面板。監(jiān)控面板支持豐富的指標(biāo)展示形式，如：折線圖、柱狀圖、餅圖、度量儀等，方便運(yùn)維人員在開發(fā)、測試、生產(chǎn)階段，直觀、高效的了解系統(tǒng)當(dāng)前情況，或進(jìn)行故障分析與定位。

可觀測性價值輸出示例——排障

鏈路檢索，提供鏈路數(shù)據(jù)查詢、鏈路詳情展示、服務(wù)拓?fù)浞治龉δ?。該功能支持用戶基于鏈路ID或者時間范圍查詢鏈路數(shù)據(jù)。在分布式鏈路詳情頁面中，可以直觀看到請求在系統(tǒng)內(nèi)流轉(zhuǎn)時經(jīng)過的應(yīng)用服務(wù)關(guān)鍵路徑，以及每個處理階段的具體耗時情況。開發(fā)、運(yùn)維人員可以利用鏈路檢索功能，進(jìn)行快速的故障定位，分析各個調(diào)用環(huán)節(jié)的性能與可用性，或者統(tǒng)計分析用戶行為數(shù)據(jù)日志檢索，提供日志數(shù)據(jù)查詢與分析功能。運(yùn)維人員可以借助日志檢索功能，從分布式系統(tǒng)的海量日志中，快速定位到所需日志，以進(jìn)行基于日志的故障原因排查或者業(yè)務(wù)數(shù)據(jù)統(tǒng)計。

通過可觀測性體系設(shè)計，對復(fù)雜的云原生系統(tǒng)不同層次的監(jiān)控對象，執(zhí)行可觀測性數(shù)據(jù)采集、分析、價值輸出流程，實(shí)現(xiàn)云原生系統(tǒng)的全范圍監(jiān)控，支持快速洞察系統(tǒng)當(dāng)前運(yùn)行狀況；針對系統(tǒng)故障進(jìn)行實(shí)時告警，通過多維監(jiān)控工具輔助快速的故障定位與解決，保障系統(tǒng)可用性；該體系提供的監(jiān)控能力，同樣可以應(yīng)用在系統(tǒng)開發(fā)與測試階段，用于快速排查開發(fā)問題，輔助進(jìn)行應(yīng)用性能觀測，提升業(yè)務(wù)交付的效率與質(zhì)量。

未來展望

可觀測性平臺

在平臺建設(shè)過程中，我們發(fā)現(xiàn)關(guān)于云原生系統(tǒng)的可觀測性體系，仍然有可以持續(xù)深耕的領(lǐng)域：

• 持續(xù)剖析（Continues Profilling），是一種深入分析程序復(fù)雜性和性能的動態(tài)方法，例如CPU利用率或函數(shù)調(diào)用的頻率和持續(xù)時間。通過持續(xù)剖析可以準(zhǔn)確定位應(yīng)用程序的哪些部分在哪個時刻消耗的資源最多，這為優(yōu)化核心程序執(zhí)行性能提供了一個可靠的方案。
• OpenTelemetry (OTEL)標(biāo)準(zhǔn)，由OpenCensus和OpenTracing項(xiàng)目合并形成的CNCF項(xiàng)目，是一個供儀表化、生成、收集和導(dǎo)出遙測數(shù)據(jù)（跟蹤、指標(biāo)和日志）使用的供應(yīng)商中立的開源可觀測性框架。提供了一組標(biāo)準(zhǔn)規(guī)范和工具集，規(guī)范可觀測性數(shù)據(jù)的數(shù)據(jù)模型、數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)治理和數(shù)據(jù)導(dǎo)出。目前各個主流開源項(xiàng)目（包括Kubernetes、Spring Cloud）都已經(jīng)開始支持或切換到OTEL，是CNCF未來主推方案，值得關(guān)注。
• eBPF (Extended Berkeley Packet Filter)，是一種數(shù)據(jù)包過濾技術(shù)，從BPF(Berkeley Packet Filter)技術(shù)擴(kuò)展而來。自Linux 4.14內(nèi)核以來，Linux社區(qū)為eBPF加入多個新特性和優(yōu)化改進(jìn)，提升了eBPF在跟蹤分析、可觀測性、安全和網(wǎng)絡(luò)加速等場景的應(yīng)用能力。eBPF在內(nèi)核中實(shí)施觀測和跟蹤，可以實(shí)現(xiàn)無侵入性的持續(xù)剖析，并基于各種可能的來源生成可見性事件，擴(kuò)展了可以實(shí)現(xiàn)的可見性深度。

擴(kuò)展到系統(tǒng)層面的全棧全鏈路觀測能力——采集

擴(kuò)展到系統(tǒng)層面的全棧全鏈路觀測能力——透視

未來，基于eBPF在操作系統(tǒng)內(nèi)核態(tài)實(shí)施可觀測性，與用戶態(tài)OpenTelemetry結(jié)合建立云原生觀測數(shù)據(jù)收集處理的標(biāo)準(zhǔn)范式，并引入持續(xù)剖析，不斷擴(kuò)展可觀測性深度和廣度，將成為增強(qiáng)云原生環(huán)境可觀測性未來發(fā)展的趨勢。

總結(jié)

云原生架構(gòu)在提升企業(yè)系統(tǒng)交付效率的同時，也使得系統(tǒng)的復(fù)雜性成倍提升，因此如何使系統(tǒng)具有可觀測性，系統(tǒng)內(nèi)部狀態(tài)易于洞察變得尤其重要，系統(tǒng)可觀測性平臺正是云原生趨勢下的必然產(chǎn)物。本文闡述了云原生系統(tǒng)可觀測性平臺的從數(shù)據(jù)采集、分析、存儲、價值輸出的關(guān)鍵技術(shù)方案與數(shù)據(jù)間的關(guān)聯(lián)關(guān)系，以及如何利用可觀測性平臺高效進(jìn)行故障定位與解決，降低故障定位與解決的運(yùn)維成本，在最大程度上保障云原生系統(tǒng)的高性能與高可用性。同時，隨著操作系統(tǒng)eBPF、Opentelementry、人工智能機(jī)器學(xué)習(xí)等技術(shù)的不斷發(fā)展，可觀測性技術(shù)一定會在信創(chuàng)和云原生場景中發(fā)揮更大作用，推動下一代監(jiān)控技術(shù)的發(fā)展。

新聞名稱：淺談創(chuàng)新互聯(lián)可觀測性
轉(zhuǎn)載注明：http://uogjgqi.cn/article/dpgooip.html