云原生應(yīng)用可觀測架構(gòu)設(shè)計（方案詳解與實踐分享）

來源：市場資訊

（來源：twt企業(yè)IT社區(qū)）

導(dǎo)讀

云原生可觀測性已從單純的IT運(yùn)維工具，發(fā)展為數(shù)字化轉(zhuǎn)型的核心技術(shù)。本文系統(tǒng)性地介紹汽車制造業(yè)云原生應(yīng)用可觀測性架構(gòu)的設(shè)計理念、關(guān)鍵技術(shù)選型，并分享了幾個具體場景下的實踐經(jīng)驗，具有實踐價值和指導(dǎo)意義，對其他行業(yè)也很有參考性。

作者：楊承龍

某機(jī)械制造企業(yè)云平臺架構(gòu)師

一、引言

信息與通信、云計算、大數(shù)據(jù)、人工智能等數(shù)字化技術(shù)的進(jìn)步，推動了企業(yè)數(shù)字化轉(zhuǎn)型和汽車“新四化”的發(fā)展，傳統(tǒng)汽車制造企業(yè)正面臨前所未有的IT架構(gòu)變革。現(xiàn)代汽車制造已不再是單純的機(jī)械裝配過程，而是融合了物聯(lián)網(wǎng)、AI、大數(shù)據(jù)和云計算的復(fù)雜數(shù)字化生態(tài)系統(tǒng)。

在傳統(tǒng)汽車制造環(huán)境中，監(jiān)控主要關(guān)注PLC、機(jī)器人等工業(yè)設(shè)備的運(yùn)行狀態(tài)，數(shù)據(jù)采集頻率以秒級甚至分鐘級為主。而云原生架構(gòu)下的汽車制造平臺，需要處理從供應(yīng)鏈管理、生產(chǎn)排程到質(zhì)量控制的各類微服務(wù)，這些服務(wù)通常以容器化方式部署，具有動態(tài)調(diào)度、彈性伸縮等特性，傳統(tǒng)的監(jiān)控手段已無法滿足需求。

汽車制造企業(yè)面臨著特殊的可觀測性（Observability）挑戰(zhàn)：

1.混合架構(gòu)復(fù)雜性：既有傳統(tǒng)OT系統(tǒng)，又有新建云原生平臺

2.數(shù)據(jù)多樣性：時序數(shù)據(jù)、日志數(shù)據(jù)、追蹤數(shù)據(jù)等多源異構(gòu)

3.實時要求：核心生產(chǎn)系統(tǒng)需要毫秒級響應(yīng)和故障檢測

4.合規(guī)壓力：汽車行業(yè)嚴(yán)格的質(zhì)量追溯和合規(guī)要求

本文將系統(tǒng)性地探討汽車制造業(yè)云原生應(yīng)用可觀測性架構(gòu)的設(shè)計理念、關(guān)鍵技術(shù)選型和實踐經(jīng)驗，幫助IT同行構(gòu)建適應(yīng)汽車行業(yè)特點的現(xiàn)代化可觀測體系。

二、云原生可觀測性架構(gòu)設(shè)計原則

2.1 全棧覆蓋：分層觀測模型

針對汽車制造的多層IT架構(gòu)，一般采用“四層觀測模型”進(jìn)行全棧可觀測性，以云原生應(yīng)用為中心，自上而下追蹤用戶體驗層、業(yè)務(wù)流程層、應(yīng)用服務(wù)層的各種監(jiān)控對象性能指標(biāo)數(shù)據(jù)，最終以應(yīng)用為單位展示應(yīng)用自身的健康程度。

用戶體驗層：MES操作界面響應(yīng)、AGV調(diào)度效率等

業(yè)務(wù)流程層：訂單處理、生產(chǎn)排程等業(yè)務(wù)流

應(yīng)用服務(wù)層：微服務(wù)、服務(wù)網(wǎng)格等

基礎(chǔ)設(shè)施層：物理服務(wù)器、虛擬機(jī)、容器平臺、網(wǎng)絡(luò)等

圖1 分層觀測模型示例

2.2 多維關(guān)聯(lián)：業(yè)務(wù)指標(biāo)與技術(shù)指標(biāo)的融合

作為被監(jiān)控觀測的對象，云、容器以及云原生應(yīng)用不應(yīng)該被孤立看待，需要各類型層面的監(jiān)控數(shù)據(jù)有效整體聯(lián)動。特有的業(yè)務(wù)指標(biāo)需要與技術(shù)指標(biāo)深度關(guān)聯(lián)融合，利于指標(biāo)聯(lián)動，故障快速定位：

業(yè)務(wù)視角：關(guān)注生產(chǎn)節(jié)拍、設(shè)備綜合效率（ OEE ）、一次合格率等KPI

技術(shù)視角：追蹤服務(wù)延遲、錯誤率、資源利用率等指標(biāo)

例1- 業(yè)務(wù)指標(biāo)聯(lián)動：將生產(chǎn)節(jié)拍指標(biāo)直接作為HPA伸縮依據(jù)，實現(xiàn)IT資源與生產(chǎn)需求的動態(tài)匹配。

例2- 信號關(guān)聯(lián)定位：通過使用相同的元數(shù)據(jù)結(jié)構(gòu)和標(biāo)簽關(guān)聯(lián)數(shù)據(jù)，確保數(shù)據(jù)一致性。連續(xù)收集所有可觀測性信號，標(biāo)記時間戳，通過請求 ID 關(guān)聯(lián)日志和跟蹤數(shù)據(jù)，便于快速定位日志。

2.3 實時優(yōu)先：平衡成本與時效性的設(shè)計

企業(yè)內(nèi)部有各種類型的數(shù)據(jù)，全量高頻采集成本和存儲成本巨大，根據(jù)場景不同，數(shù)據(jù)采集設(shè)計原則如下：

關(guān)鍵路徑：毫秒級采集（如焊裝機(jī)器人電流波形，實時性要求極高）

重要業(yè)務(wù)：秒級聚合（如車身流轉(zhuǎn)計數(shù)、檢測臺質(zhì)量數(shù)據(jù)數(shù)據(jù)）

輔助系統(tǒng)：分鐘級采樣（如辦公系統(tǒng)健康檢查）

三、可觀測性技術(shù)架構(gòu)設(shè)計

可觀測性是確保系統(tǒng)穩(wěn)定性和高效運(yùn)行的關(guān)鍵組成部分。涉及微服務(wù)的鏈路跟蹤、日志采集、狀態(tài)采集、資源監(jiān)控、性能監(jiān)控等多個方面。將Metrics、Logging、Tracing三類關(guān)鍵數(shù)據(jù)密切關(guān)聯(lián)，實時監(jiān)控和分析系統(tǒng)運(yùn)行狀態(tài)，全面呈現(xiàn)端到端的系統(tǒng)運(yùn)行全貌，確保系統(tǒng)穩(wěn)定性、性能和安全性。

圖2 可觀測三大核心支柱

指標(biāo)Metrics： 連續(xù)時間下的系統(tǒng)的值，常規(guī)的包含計數(shù)、計量兩種類型

鏈路Tracing： 業(yè)務(wù)運(yùn)行各個模塊的調(diào)用關(guān)系，監(jiān)控數(shù)據(jù)的可靠鏈接紐帶

日志Logging： 系統(tǒng)或應(yīng)用輸出的時間相關(guān)的記錄，方便定位應(yīng)用系統(tǒng)錯誤

3.1 指標(biāo)（Metrics）架構(gòu)設(shè)計

指標(biāo)是衡量系統(tǒng)性能和資源使用情況的關(guān)鍵量化數(shù)據(jù)。常見的指標(biāo)包括CPU使用率、內(nèi)存占用、網(wǎng)絡(luò)流量、請求響應(yīng)時間、吞吐量等。在云原生架構(gòu)中，由于系統(tǒng)的動態(tài)性和分布式特性，實時監(jiān)測這些指標(biāo)對于掌握系統(tǒng)的運(yùn)行狀態(tài)至關(guān)重要。傳統(tǒng)數(shù)據(jù)采集主要基于agent方式、snmp協(xié)議、日志分析等方式，存在侵入性、不靈活、兼容性差、數(shù)據(jù)采集不全面等問題，相比于傳統(tǒng)監(jiān)測數(shù)據(jù)采集與分析技術(shù)，基于eBPF技術(shù)的可觀測系統(tǒng)在數(shù)據(jù)采集方面有著顯著的優(yōu)勢，下面主要介紹基于eBPF技術(shù)的可觀測實踐探索。

3.1.1 基于eBPF構(gòu)建云原生數(shù)據(jù)采集

隨著云原生應(yīng)用復(fù)雜度增加，eBPF技術(shù)因其獨(dú)特性能有效應(yīng)對傳統(tǒng)可觀測挑戰(zhàn)。

基于eBPF云原生可觀測性技術(shù)架構(gòu)

eBPF是一種數(shù)據(jù)包過濾技術(shù)，從BPF(Berkeley Packet Filter) 技術(shù)擴(kuò)展而來，它起源于 Linux 內(nèi)核，可以在操作系統(tǒng)內(nèi)核中運(yùn)行沙盒程序。eBPF被用于安全有效地擴(kuò)展內(nèi)核的功能，而無需更改內(nèi)核源代碼或加載內(nèi)核模塊。

基于eBPF在操作系統(tǒng)內(nèi)核特性優(yōu)勢，與OpenTelemetry結(jié)合實現(xiàn)云原生觀測數(shù)據(jù)收集處理的架構(gòu)，極大增強(qiáng)云原生環(huán)境可觀測性能力。基于eBPF的可觀測性架構(gòu)如下圖：

圖3 eBPF可觀測技術(shù)架構(gòu)

數(shù)據(jù)接收階段：eBPF技術(shù)在用戶空間和內(nèi)核空間之間架起了“橋梁”，通過將eBPF程序加載到trace points、內(nèi)核、及用戶空間應(yīng)用，經(jīng)用戶態(tài)eBPF程序預(yù)處理后，由 OpenTelemetry規(guī)范的Receiver 接收；

數(shù)據(jù)處理階段：依據(jù)規(guī)范進(jìn)行協(xié)議解析、指標(biāo)處理和Kubernetes元信息填充。

數(shù)據(jù)導(dǎo)出階段：通過Exporter將數(shù)據(jù)輸出到可觀測平臺。

該架構(gòu)具有采集全面、完全無侵入，對應(yīng)用系統(tǒng)來說完全無感知、資源消耗小、靈活可伸縮和適應(yīng)容器動態(tài)變化等優(yōu)勢。

3.1.2 指標(biāo)可視化

利用Grafana創(chuàng)建各種直觀、簡潔的儀表盤，將Prometheus采集到的指標(biāo)數(shù)據(jù)以直觀的圖表形式展示出來。例如，在動態(tài)網(wǎng)絡(luò)性能監(jiān)控中，eBPF 程序獲取進(jìn)程與地址關(guān)系、流量統(tǒng)計等數(shù)據(jù)，構(gòu)造動態(tài)拓?fù)鋱D；在HTTP黃金指標(biāo)監(jiān)控中，解析網(wǎng)絡(luò)報文獲取關(guān)鍵指標(biāo)并關(guān)聯(lián)服務(wù)標(biāo)識；在性能剖析中，基于On-CPU事件繪制火焰圖，分析CPU使用率高的問題。

通過設(shè)置不同的儀表盤面板和告警規(guī)則，能夠?qū)崟r監(jiān)控系統(tǒng)的性能指標(biāo)，并在指標(biāo)超出正常范圍時及時發(fā)出告警。

圖4 火焰圖輔助性能分析

3.2 日志（Logging）架構(gòu)設(shè)計

日志是記錄系統(tǒng)運(yùn)行過程中各類事件的重要載體。在云原生環(huán)境下，大量的微服務(wù)、容器以及分布式組件會產(chǎn)生海量的日志數(shù)據(jù)。這些日志包含了豐富的信息，如請求的處理過程、錯誤信息、系統(tǒng)狀態(tài)變化等。通過對日志的收集、存儲和分析，能夠還原系統(tǒng)的運(yùn)行軌跡，發(fā)現(xiàn)潛在的問題。

3.2.1 日志統(tǒng)一收集

采用邊緣日志預(yù)處理+中心持久化存儲的模式，通過日志標(biāo)簽實現(xiàn)多維度關(guān)聯(lián)，統(tǒng)一的日志管理解決方案可保留事件上下文和相關(guān)性，自動執(zhí)行相關(guān)性和分析等任務(wù)，便于訪問和分析，使團(tuán)隊能夠騰出時間執(zhí)行故障排除和根因分析等任務(wù)，支持探索性分析、數(shù)據(jù)洞察力的安全協(xié)作，以及運(yùn)營和應(yīng)用程序的主動優(yōu)化。

日志類型

應(yīng)用日志：記錄應(yīng)用程序的運(yùn)行情況，例如錯誤信息、用戶操作、請求參數(shù)等。

系統(tǒng)日志：記錄操作系統(tǒng)級別的事件，例如 CPU 負(fù)載、磁盤 I/O、進(jìn)程狀態(tài)等。

安全日志：記錄訪問控制、身份驗證、異常請求等信息，確保系統(tǒng)安全性。

集中式日志管理

使用 ELK（Elasticsearch + Logstash + Kibana）、Graylog、Splunk進(jìn)行日志存儲、索引和可視化分析

圖5 ELK 架構(gòu)

ELK工作原理：常用 Logstash、 Fluentd、Filebeat等日志代理工具，實現(xiàn)多源日志的采集，數(shù)據(jù)源采集數(shù)據(jù)，并對數(shù)據(jù)進(jìn)行過濾，格式化處理，然后交由Elasticsearch存儲，kibana對日志進(jìn)行可視化處理，查詢數(shù)據(jù)生成圖表。

3.2.2 日志智能解析與存儲

日志可分為應(yīng)用程序日志、安全日志、系統(tǒng)日志、審核日志和基礎(chǔ)架構(gòu)日志等不同類別。其記錄的信息為自由格式文本，解析難度較大，但在故障分析中具有重要價值。通過解析、分段和分析日志文件獲取信息，還可將日志數(shù)據(jù)轉(zhuǎn)換為其他可觀測性信號。根據(jù)數(shù)據(jù)獲取顆粒度，日志可設(shè)置“錯誤”“警告”“信息”“調(diào)試”等不同級別。

實時解析：使用Grok模式提取設(shè)備報警代碼

智能路由：關(guān)鍵日志實時告警，普通日志批量分析

長期歸檔：滿足IATF 16949 、TISAX的質(zhì)量記錄要求，要求保留10年以上

在進(jìn)行存儲設(shè)計時，采用多層存儲架構(gòu)，熱數(shù)據(jù)使用內(nèi)存時序數(shù)據(jù)庫，溫數(shù)據(jù)使用壓縮時序存儲，冷數(shù)據(jù)轉(zhuǎn)儲到對象存儲。設(shè)置合理的日志保留策略，避免存儲成本過高，可采用S3對象存儲和分布式文件存儲歸檔舊日志。

3.2.3 日志可視化分析

基于日志的追蹤將Trace、Span等信息輸出到應(yīng)用日志中，從日志中反推調(diào)用鏈拓?fù)潢P(guān)系，具有低侵入性和低性能影響的優(yōu)點，但依賴日志歸集，精準(zhǔn)度有限。基于服務(wù)的追蹤通過注入追蹤探針獲取服務(wù)調(diào)用信息并發(fā)送給鏈路追蹤系統(tǒng)，資源消耗大、侵入性強(qiáng)，但精確性和穩(wěn)定性較高，被 Zipkin、SkyWalking等廣泛采用。

在Kibana中，通過創(chuàng)建各種查詢和可視化報表，對存儲在Elasticsearch中的日志數(shù)據(jù)進(jìn)行深入分析。例如，使用Kibana的Discover功能，可以自由搜索和過濾日志數(shù)據(jù)，查看特定時間段內(nèi)的日志記錄；通過創(chuàng)建Timeline可視化報表，可以直觀地了解系統(tǒng)在一段時間內(nèi)的事件發(fā)生順序和頻率。

當(dāng)應(yīng)用程序出現(xiàn)異常時，通過查看相關(guān)的日志記錄，詳細(xì)了解異常發(fā)生的時間、相關(guān)的上下文信息，為快速定位問題提供有力支持。

圖6 日志查詢

3.3 鏈路追蹤（Tracing）實踐

鏈路追蹤是可觀測性的重要組成部分，用于記錄請求在整個應(yīng)用程序中的傳播路徑。在云原生應(yīng)用中，一個請求往往會經(jīng)過多個微服務(wù)的處理，涉及多個容器和網(wǎng)絡(luò)節(jié)點。分布式追蹤能夠?qū)⑦@些分散的處理過程串聯(lián)起來，形成完整的調(diào)用鏈。通過分析調(diào)用鏈，我們可以清晰地看到請求在各個環(huán)節(jié)的耗時情況，可以快速定位問題并進(jìn)行優(yōu)化。

3.3.1 鏈路追蹤設(shè)計

一般通過開源產(chǎn)品SkyWalking、Jaeger、商業(yè)產(chǎn)品dynatrace、日志易等工具來跟蹤微服務(wù)之間的調(diào)用鏈路，通過跟蹤請求的完整路徑，快速定位性能瓶頸和故障點。

常見的分布式追蹤工具：

a. 基于 SDK 的工具，如Jaeger，可獲取豐富數(shù)據(jù)但通用性差、部署成本高；

b. 基于探針的工具，如SkyWalking Java探針，無需修改源代碼但獲取數(shù)據(jù)有限；

c. 基于代理的Sidecar，無需修改代碼但串聯(lián)跨度數(shù)據(jù)困難；

d. 基于eBPF實現(xiàn)的方式，具備低侵入性、高性能和細(xì)粒度數(shù)據(jù)收集分析能力。

鏈路監(jiān)控使用規(guī)范參考：

a.在接口服務(wù)調(diào)用中增加TRACE_ID信息

需要在接口服務(wù)調(diào)用的輸入中增加TRACE_ID字段，作為服務(wù)鏈跟蹤使角。

b.TRACEID組成說明

一個用于服務(wù)鏈監(jiān)控的TRACEID的生成，由以下信息所構(gòu)成。

概述：UUID+SPANID+SPANID+SPANID組成

說明：UUID為每一個服務(wù)調(diào)用鏈，生成一個獨(dú)立唯一的UUID值

SPANID：SPANID為01、02順序編碼，服務(wù)調(diào)用每進(jìn)一層增即增加一層SPANID

依據(jù)上述規(guī)則，生成的一個參考如下:

TRACE_ID: 550e8400-e29b-41d4-a716-446655440000.01.01.0 2

TRACE_ID設(shè)計參考

圖8 基于TRACE_ID串聯(lián)日志和鏈路

3.3.2 鏈路可視化

鏈路追蹤工具UI界面一般會提供豐富的調(diào)用鏈可視化功能，能夠以圖形化的方式展示請求在各個微服務(wù)之間的調(diào)用路徑和耗時情況，實現(xiàn)跨系統(tǒng)、跨協(xié)議的調(diào)用鏈可視化。通過分析調(diào)用鏈圖，可以快速定位性能瓶頸所在的微服務(wù)和具體的調(diào)用環(huán)節(jié)，為優(yōu)化系統(tǒng)性能提供有力依據(jù)。

圖9 鏈路數(shù)據(jù)

3.4 告警（Alert）設(shè)計

從分級分類、告警集成、處理流程三個方面淺談一下告警處理的相關(guān)實踐方法，為開發(fā)和運(yùn)維團(tuán)隊提供一套完整的告警處理思路。

3.4.1 告警分級分類

告警分級：將告警分為 warning（警告級別，起簡單通知作用）、problem（問題級別，系統(tǒng)出現(xiàn)問題需及時修正）、critical（重要級別，系統(tǒng)嚴(yán)重錯誤導(dǎo)致線上大面積不可用）三個等級，不同等級有不同解決方式和處理流程，便于區(qū)分優(yōu)先級處理問題。

故障分級：告警分級后，真正告警時，還有故障分級。不同的故障等級，會影響該故障的參與人數(shù)和處理流程，對應(yīng)告警分級也分3個等級。

事件單：相對容易處理，對應(yīng)warning級別；

問題單：事件單未處理會升級，problem級告警直接認(rèn)定為問題單，通知開發(fā)人員；

故障單：問題未處理再次升級，系統(tǒng)嚴(yán)重錯誤，影響面廣，需多人處理，對應(yīng)critical級別，故障等級可能因未及時處理而升級。

3.4.2 告警集成

通知方式：根據(jù)故障分級選擇不同通知方式。事件單通過企業(yè)溝通軟件通知，如釘釘、企業(yè)微信、welink等；問題單可能用短信或電話通知；故障單電話聯(lián)系負(fù)責(zé)人并拉群（war room）共同解決問題。若問題未及時處理，通知方式會升級。

通知內(nèi)容：告警內(nèi)容應(yīng)簡潔，包含發(fā)生時間、錯誤現(xiàn)象、錯誤詳情（問題跟進(jìn)鏈接），幫助人員快速了解故障情況并響應(yīng)。

3.4.3 處置流程

非重要級別告警處置：確認(rèn)告警原因，當(dāng)天給出解決辦法并跟進(jìn)改進(jìn)，記錄問題原因、恢復(fù)方法和后續(xù)改進(jìn)措施。

重要級別告警處置：相關(guān)人員聚集處理，明確事故負(fù)責(zé)人（把握故障進(jìn)度、協(xié)調(diào)資源、匯總復(fù)盤）和問題處理團(tuán)隊（負(fù)責(zé)問題處理）的職責(zé)。處理步驟包括聚集參與者、緊急恢復(fù)并保留現(xiàn)場、發(fā)現(xiàn)原因、確認(rèn)并實施解決方案、事故復(fù)盤，復(fù)盤形成的故障單需包含發(fā)生時間、發(fā)現(xiàn)時間、結(jié)束時間、處理流程、故障原因、影響范圍、后續(xù)改進(jìn)措施等內(nèi)容。

圖10 故障處置流程

四、實踐經(jīng)驗

實踐中僅圍繞指標(biāo)、日志、追蹤并不能保證理想結(jié)果，一般還需與拓?fù)洹⑿袨椤⑹录⒃獢?shù)據(jù)等信息實現(xiàn)全面可觀測性，以下介紹幾個常見的可觀測性實踐。

圖11 多維度數(shù)據(jù)關(guān)聯(lián)

實踐一：監(jiān)控真實用戶體驗

真實用戶監(jiān)控（Real User Monitoring，RUM）是指用戶在頁面上訪問，訪問時會產(chǎn)生各類性能數(shù)據(jù)，在用戶訪問停止的時候，將這些性能數(shù)據(jù)傳輸?shù)椒?wù)端，進(jìn)行數(shù)據(jù)整理分析的過程，注重監(jiān)控。

圖12 監(jiān)控真實用戶分析

場景示例：

1.頁面報錯，后臺日志沒有端倪。RUM可以發(fā)現(xiàn)并分析報錯的JavaScript代碼。

2.頁面緩慢，后臺日志顯示API不慢。RUM的瀑布圖可以宏觀分析，消除盲點。

解決思路：

1.數(shù)據(jù)捕獲與處理

采用JS 埋點的方式，采集用戶訪問過程的性能指標(biāo)，獲取瀏覽器端的真實用戶行為與體驗數(shù)據(jù)。包括頁面加載、點擊、彈窗、JS報錯、ajax等用戶全軌跡跟蹤，通過大數(shù)據(jù)分析，生成與業(yè)務(wù)結(jié)果相關(guān)聯(lián)的指標(biāo)。指標(biāo)通常包括用戶旅程各個階段的跟蹤時間、UI中用戶交互區(qū)域的熱力圖、跳出率、加載時間等。

2.埋點流程設(shè)計

一般選用Puppeteer、Selenium無界面 Chrome工具，通過提供的API可以控制Node端的Chrome工具進(jìn)行指定的操作，幫助實現(xiàn)模擬登錄、模擬上傳等用戶操作。

圖13 模擬登錄流程

3.可視化展示

儀表板處理處理平臺生成的匯總數(shù)據(jù)和指標(biāo)。這有助于開發(fā)人員專注于應(yīng)用程序中發(fā)生的集體問題，而不是有關(guān)用戶如何與應(yīng)用程序交互的個別數(shù)據(jù)點，同時應(yīng)用于故障定位、安全分析、終端分析、感知分析、異常分析等場景。

當(dāng)檢測頁面需要登錄時，分析出頁面屬于哪個devops 實例，然后通過Puppeteer跳轉(zhuǎn)到對應(yīng)的登錄頁面，然后輸入用戶名、密碼、驗證碼，待登錄完成后跳轉(zhuǎn)至正確的頁面，再進(jìn)行頁面性能檢測。如果登錄后還在登錄頁，表示登錄失敗，則獲取錯誤提示并拋出。

圖14 用

戶軌跡分析

實踐二：端到端全鏈路全量追蹤

在微服務(wù)架構(gòu)中，分布式追蹤對故障定位和性能提升至關(guān)重要，鏈路采樣導(dǎo)致缺少數(shù)據(jù)，越是偶發(fā)難分析的問題越是大概率缺數(shù)據(jù)，全量追蹤可以保證所有鏈路都被完整追蹤，不用靠猜。

場景示例：定位發(fā)現(xiàn)服務(wù)響應(yīng)時間長的資源

解決思路：分析問題一鉆到底，從應(yīng)用拓?fù)涞秸{(diào)用鏈，實現(xiàn)鏈路的錯、慢下鉆分析

1.查看資源詳情中該資源的接口性能，將問題范圍縮小到具體接口：查看從上游客戶端訪問某接口的響應(yīng)時間，發(fā)現(xiàn)響應(yīng)時間較長，超過2 秒，可以說明問題并不在應(yīng)用層接口邏輯本身，而是可能發(fā)生在客戶端側(cè)的網(wǎng)絡(luò)層面，我們可以繼續(xù)往下排查。

圖15 鏈路全量追蹤分析

2.查看指標(biāo)，定位問題域：查看服務(wù)請求、錯誤與異常、服務(wù)延遲、網(wǎng)絡(luò)通信等各類指標(biāo)，梳理各指標(biāo)的關(guān)聯(lián)，確定問題域（應(yīng)用問題還是網(wǎng)絡(luò)問題）。

圖16

根據(jù)指標(biāo)分析縮小問題域

3.查看日志/事件，確定根因：在容器服務(wù)的日志中心和事件中心查看對應(yīng)資源和問題域的日志/事件，定位根因，排除故障。

實踐三：利用人工智能檢測分析

場景示例：過多的人工分析問題，效率低，經(jīng)常熬夜處理問題。

解決思路：接入人工智能大模型或者選用帶有AIOps的商業(yè)監(jiān)控產(chǎn)品，利用大模型對對各類日志、指標(biāo)、數(shù)據(jù)進(jìn)行聚合關(guān)聯(lián)分析，學(xué)習(xí)并實時自動適應(yīng)變化，筆者則是構(gòu)建AI自訓(xùn)練平臺，建立T+1訓(xùn)練機(jī)制，持續(xù)優(yōu)化訓(xùn)練數(shù)據(jù)集，以自動發(fā)現(xiàn)問題，同時根因分析準(zhǔn)確率達(dá)到90%。

圖17 根因分析技術(shù)架構(gòu)-決策樹引入AI

圖18 根因分析初判

實踐四：部分場景故障自愈

典型場景包括：故障磁盤自動拉出集群；故障機(jī)器自動隔離；發(fā)現(xiàn)某類型日志自動重啟應(yīng)用等。

解決思路：規(guī)則明確、執(zhí)行流程固定、影響面可控的情況，將“監(jiān)”、“管”、“控”工具能力融合，告警信息結(jié)合AI判定算法，接入AIOPS助手觸發(fā)自動化作業(yè)能力，實現(xiàn)故障自愈流程，有效縮短故障處理、恢復(fù)時間。

圖19 故障自愈

五、總結(jié)

云原生可觀測性已從單純的IT運(yùn)維工具，發(fā)展為汽車制造業(yè)數(shù)字化轉(zhuǎn)型的核心使能技術(shù)。通過構(gòu)建覆蓋“云邊端”的統(tǒng)一觀測體系，實現(xiàn)業(yè)務(wù)與技術(shù)指標(biāo)的深度關(guān)聯(lián)，汽車企業(yè)可以在保障合規(guī)前提下降低運(yùn)營成本，最終達(dá)成“質(zhì)量可追溯、效率可量化、決策數(shù)據(jù)化”的智能制造目標(biāo)。

未來，隨著5G、AI、數(shù)字孿生等技術(shù)的發(fā)展，汽車制造可觀測性將向更智能、更自動化的方向演進(jìn)。我們建議企業(yè)從現(xiàn)在開始打好數(shù)據(jù)基礎(chǔ)，培養(yǎng)復(fù)合型人才，逐步構(gòu)建適應(yīng)“軟件定義制造”時代的新型可觀測體系。

最后，汽車行業(yè)的特殊性決定了沒有放之四海而皆準(zhǔn)的解決方案，希望本文的經(jīng)驗?zāi)軌驇椭鶬T同行構(gòu)建并優(yōu)化云原生應(yīng)用可觀測性能力，企業(yè)仍需結(jié)合各自實際情況，打造最適合自己的云原生可觀測性平臺。