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

來源：市場資訊

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

導(dǎo)讀

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

作者：楊承龍

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

一、引言

信息與通信、云計(jì)算、大數(shù)據(jù)、人工智能等數(shù)字化技術(shù)的進(jìn)步，推動(dòng)了企業(yè)數(shù)字化轉(zhuǎn)型和汽車“新四化”的發(fā)展，傳統(tǒng)汽車制造企業(yè)正面臨前所未有的IT架構(gòu)變革。現(xiàn)代汽車制造已不再是單純的機(jī)械裝配過程，而是融合了物聯(lián)網(wǎng)、AI、大數(shù)據(jù)和云計(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ù)采集頻率以秒級(jí)甚至分鐘級(jí)為主。而云原生架構(gòu)下的汽車制造平臺(tái)，需要處理從供應(yīng)鏈管理、生產(chǎn)排程到質(zhì)量控制的各類微服務(wù)，這些服務(wù)通常以容器化方式部署，具有動(dòng)態(tài)調(diào)度、彈性伸縮等特性，傳統(tǒng)的監(jiān)控手段已無法滿足需求。

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

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

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

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

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

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

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

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

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

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

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

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

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

圖1 分層觀測模型示例

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2 可觀測三大核心支柱

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

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

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

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

指標(biāo)是衡量系統(tǒng)性能和資源使用情況的關(guān)鍵量化數(shù)據(jù)。常見的指標(biāo)包括CPU使用率、內(nèi)存占用、網(wǎng)絡(luò)流量、請求響應(yīng)時(shí)間、吞吐量等。在云原生架構(gòu)中，由于系統(tǒng)的動(dòng)態(tài)性和分布式特性，實(shí)時(shí)監(jiān)測這些指標(biāo)對(duì)于掌握系統(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ù)的可觀測實(shí)踐探索。

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

隨著云原生應(yīng)用復(fù)雜度增加，eBPF技術(shù)因其獨(dú)特性能有效應(yīng)對(duì)傳統(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被用于安全有效地?cái)U(kuò)展內(nèi)核的功能，而無需更改內(nèi)核源代碼或加載內(nèi)核模塊。

基于eBPF在操作系統(tǒng)內(nèi)核特性優(yōu)勢，與OpenTelemetry結(jié)合實(shí)現(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ù)輸出到可觀測平臺(tái)。

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

3.1.2 指標(biāo)可視化

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

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

圖4 火焰圖輔助性能分析

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

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

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

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

日志類型

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

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

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

集中式日志管理

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

圖5 ELK 架構(gòu)

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

3.2.2 日志智能解析與存儲(chǔ)

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

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

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

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

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

3.2.3 日志可視化分析

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

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

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

圖6 日志查詢

3.3 鏈路追蹤（Tracing）實(shí)踐

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

3.3.1 鏈路追蹤設(shè)計(jì)

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

常見的分布式追蹤工具：

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

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

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

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

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

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

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

b.TRACEID組成說明

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

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

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

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

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

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

TRACE_ID設(shè)計(jì)參考

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

3.3.2 鏈路可視化

鏈路追蹤工具UI界面一般會(huì)提供豐富的調(diào)用鏈可視化功能，能夠以圖形化的方式展示請求在各個(gè)微服務(wù)之間的調(diào)用路徑和耗時(shí)情況，實(shí)現(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è)計(jì)

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

3.4.1 告警分級(jí)分類

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

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

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

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

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

3.4.2 告警集成

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

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

3.4.3 處置流程

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

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

圖10 故障處置流程

四、實(shí)踐經(jīng)驗(yàn)

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

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

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

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

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

場景示例：

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

2.頁面緩慢，后臺(tái)日志顯示API不慢。RUM的瀑布圖可以宏觀分析，消除盲點(diǎn)。

解決思路：

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

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

2.埋點(diǎn)流程設(shè)計(jì)

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

圖13 模擬登錄流程

3.可視化展示

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

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

圖14 用

戶軌跡分析

實(shí)踐二：端到端全鏈路全量追蹤

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

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

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

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

圖15 鏈路全量追蹤分析

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

圖16

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

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

實(shí)踐三：利用人工智能檢測分析

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

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

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

圖18 根因分析初判

實(shí)踐四：部分場景故障自愈

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

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

圖19 故障自愈

五、總結(jié)

云原生可觀測性已從單純的IT運(yùn)維工具，發(fā)展為汽車制造業(yè)數(shù)字化轉(zhuǎn)型的核心使能技術(shù)。通過構(gòu)建覆蓋“云邊端”的統(tǒng)一觀測體系，實(shí)現(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ā)展，汽車制造可觀測性將向更智能、更自動(dòng)化的方向演進(jìn)。我們建議企業(yè)從現(xiàn)在開始打好數(shù)據(jù)基礎(chǔ)，培養(yǎng)復(fù)合型人才，逐步構(gòu)建適應(yīng)“軟件定義制造”時(shí)代的新型可觀測體系。

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