云原生應用可觀測架構設計（方案詳解與實踐分享）

來源：市場資訊

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

導讀

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

作者：楊承龍

某機械制造企業(yè)云平臺架構師

一、引言

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

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

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

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

2.數據多樣性：時序數據、日志數據、追蹤數據等多源異構

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

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

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

二、云原生可觀測性架構設計原則

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

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

用戶體驗層：MES操作界面響應、AGV調度效率等

業(yè)務流程層：訂單處理、生產排程等業(yè)務流

應用服務層：微服務、服務網格等

基礎設施層：物理服務器、虛擬機、容器平臺、網絡等

圖1 分層觀測模型示例

2.2 多維關聯：業(yè)務指標與技術指標的融合

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

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

技術視角：追蹤服務延遲、錯誤率、資源利用率等指標

例1- 業(yè)務指標聯動：將生產節(jié)拍指標直接作為HPA伸縮依據，實現IT資源與生產需求的動態(tài)匹配。

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

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

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

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

重要業(yè)務：秒級聚合（如車身流轉計數、檢測臺質量數據數據）

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

三、可觀測性技術架構設計

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

圖2 可觀測三大核心支柱

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

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

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

3.1 指標（Metrics）架構設計

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

3.1.1 基于eBPF構建云原生數據采集

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

基于eBPF云原生可觀測性技術架構

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

基于eBPF在操作系統(tǒng)內核特性優(yōu)勢，與OpenTelemetry結合實現云原生觀測數據收集處理的架構，極大增強云原生環(huán)境可觀測性能力?；趀BPF的可觀測性架構如下圖：

圖3 eBPF可觀測技術架構

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

數據處理階段：依據規(guī)范進行協議解析、指標處理和Kubernetes元信息填充。

數據導出階段：通過Exporter將數據輸出到可觀測平臺。

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

3.1.2 指標可視化

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

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

圖4 火焰圖輔助性能分析

3.2 日志（Logging）架構設計

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

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

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

日志類型

應用日志：記錄應用程序的運行情況，例如錯誤信息、用戶操作、請求參數等。

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

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

集中式日志管理

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

圖5 ELK 架構

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

3.2.2 日志智能解析與存儲

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

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

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

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

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

3.2.3 日志可視化分析

基于日志的追蹤將Trace、Span等信息輸出到應用日志中，從日志中反推調用鏈拓撲關系，具有低侵入性和低性能影響的優(yōu)點，但依賴日志歸集，精準度有限?；诜盏淖粉櫷ㄟ^注入追蹤探針獲取服務調用信息并發(fā)送給鏈路追蹤系統(tǒng)，資源消耗大、侵入性強，但精確性和穩(wěn)定性較高，被 Zipkin、SkyWalking等廣泛采用。

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

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

圖6 日志查詢

3.3 鏈路追蹤（Tracing）實踐

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

3.3.1 鏈路追蹤設計

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

常見的分布式追蹤工具：

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

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

c. 基于代理的Sidecar，無需修改代碼但串聯跨度數據困難；

d. 基于eBPF實現的方式，具備低侵入性、高性能和細粒度數據收集分析能力。

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

a.在接口服務調用中增加TRACE_ID信息

需要在接口服務調用的輸入中增加TRACE_ID字段，作為服務鏈跟蹤使角。

b.TRACEID組成說明

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

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

說明：UUID為每一個服務調用鏈，生成一個獨立唯一的UUID值

SPANID：SPANID為01、02順序編碼，服務調用每進一層增即增加一層SPANID

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

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

TRACE_ID設計參考

圖8 基于TRACE_ID串聯日志和鏈路

3.3.2 鏈路可視化

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

圖9 鏈路數據

3.4 告警（Alert）設計

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

3.4.1 告警分級分類

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

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

事件單：相對容易處理，對應warning級別；

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

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

3.4.2 告警集成

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

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

3.4.3 處置流程

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

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

圖10 故障處置流程

四、實踐經驗

實踐中僅圍繞指標、日志、追蹤并不能保證理想結果，一般還需與拓撲、行為、事件、元數據等信息實現全面可觀測性，以下介紹幾個常見的可觀測性實踐。

圖11 多維度數據關聯

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

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

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

場景示例：

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

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

解決思路：

1.數據捕獲與處理

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

2.埋點流程設計

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

圖13 模擬登錄流程

3.可視化展示

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

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

圖14 用

戶軌跡分析

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

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

場景示例：定位發(fā)現服務響應時間長的資源

解決思路：分析問題一鉆到底，從應用拓撲到調用鏈，實現鏈路的錯、慢下鉆分析

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

圖15 鏈路全量追蹤分析

2.查看指標，定位問題域：查看服務請求、錯誤與異常、服務延遲、網絡通信等各類指標，梳理各指標的關聯，確定問題域（應用問題還是網絡問題）。

圖16

根據指標分析縮小問題域

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

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

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

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

圖17 根因分析技術架構-決策樹引入AI

圖18 根因分析初判

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

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

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

圖19 故障自愈

五、總結

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

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

最后，汽車行業(yè)的特殊性決定了沒有放之四海而皆準的解決方案，希望本文的經驗能夠幫助IT同行構建并優(yōu)化云原生應用可觀測性能力，企業(yè)仍需結合各自實際情況，打造最適合自己的云原生可觀測性平臺。