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