一、摘要

應用上云、云原生化是企業全面數字化轉型的必要技術基礎，G行2020年啟動全棧云平臺建設，采用云原生集群架構為應用架構服務化改造提供平臺支撐，也同步建設了云化系統的全棧可觀測性能力：

• 在技術可控性方面：通過全棧調用鏈追蹤能力，構建性能基線圖譜，破解異構環境兼容性驗證難題；基于零侵擾采集技術，規避傳統插樁方案的安全合規風險，構建覆蓋信創技術棧的統一監控范式。
• 在業務穩定性方面：建立業務指標-技術指標-資源指標三級關聯機制，助力實現分鐘級故障發現、定位與恢復；通過分布式推理服務鏈路追蹤、剖析等能力，保障應用系統穩定運維。

二、背景與挑戰

2020年以來，《金融行業信息化發展規劃（2022-2025）》、《關于銀行業保險業數字化轉型的指導意見》等文件明確要求金融機構“實現關鍵核心技術自主可控”，2027年成為金融信創全面落地的硬性時間節點。

銀行應用系統同步替換底層數據庫、中間件、操作系統、服務器等全棧組件，對技術驗證與業務連續性保障帶來的壓力巨大，在可觀測性建設上主要面臨如下挑戰：

1.在容量預估和故障排查方面

調用鏈追蹤落地難：傳統調用鏈追蹤的實現方式可能面臨安全合規及穩定性訴求矛盾。APM或日志類方案需要對應用代碼改造，落地困難且有合規隱患；NPM類方案需要對云內流量全量引流，開銷巨大且數據質量差。

系統容量評估困難：需要高性能、零侵擾的性能評測手段，便于開發迭代過程中隨時可以在不同硬件、操作系統、中間件、數據庫環境下完成性能測試，為上線后的容量評估提供充足的參考數據。

生產環境性能剖析難：線上性能問題往往難以在測試環境復現，而生產環境中往往由于性能剖析工具缺乏、工具執行權限審批困難、應用進程需要重啟、應用代碼需要修改而無法獲取關鍵現場數據。

2.在應用性能和業務性能指標方面

性能指標覆蓋不全：僅從管理上要求開發項目組和技術產品供應商提供標準化的性能指標數據有很大的挑戰，若能從技術上提供零侵擾的全棧黃金性能指標，將極大的降低管理難度。

APM調用鏈采集性能損耗：基于插碼的APM調用鏈采集能力對應用的性能和穩定性影響不可控，通常不敢在生產環境開啟，即使啟用也通常會設置較低的采樣率。

業務指標和技術指標難關聯：傳統BPM的引流手段在云環境下落地困難，導致業務指標僅能在云入口處采集，難以和云內應用組件及基礎設施服務的技術指標關聯。

指標、追蹤、日志數據孤島：不同采集工具的數據顆粒度不一致、數據標簽不統一，關聯分析低效。

3.在云基礎設施可觀測方面

基礎服務相關故障定界困難：L4、L7云網關的轉發鏈路無法追蹤，分布式數據庫在代理節點、計算節點、數據節點上的調用鏈路無法追蹤，涉及到基礎服務的性能問題難以定界。

微服務訪問排障低效：多副本微服務相互的調用鏈比較復雜，對于概率性發生的性能問題，傳統的抓包、找日志的方式極端低效，可能長達數周仍無進展。

跨區域、專線帶寬用量難優化：云主機、容器Pod的IP動態性高，跨區域/跨可用區/專線流量使用傳統方式采集分析難以和云資源、容器服務關聯，帶寬利用效率很難分析。

三、G行全棧可觀測平臺建設

面對可觀測性建設各方面的挑戰，G行選擇采用基于零侵擾解決方案建設全棧可觀測平臺，能夠零侵擾采集業務語義、系統調用、網絡轉發、文件讀寫調用鏈，并通過收集和關聯服務自身的日志鏈路數據實現調用鏈的全覆蓋。與傳統技術方案相比，G行建設方案優勢如下：

圖片

G行全棧觀測平臺的能力主要包括“業務全景拓撲、全棧調用鏈追蹤、持續性能剖析、跨可用區、Agent資源管理”等五方面，平臺架構如下圖所示：

圖1 G行全棧可觀測性平臺

如上圖所示，G行全棧觀測平臺各方面功能介紹如下：

1.全景業務拓撲

全景覆蓋：覆蓋容器、云主機、物理機。

零侵擾業務語義采集：零侵擾解析Payload中的業務語義。

自動化業務語義標注：通過業務語義標注技術，自動標注云資源、容器服務、CMDB等語義標簽，從而自動生成全景拓撲。

2.全棧鏈路追蹤

圖2 全棧調用鏈追蹤能力

上圖展示了全棧觀測平臺的調用鏈追蹤頁面，其核心的功能特點包括：

零侵擾調用鏈追蹤：基于零侵擾采集能力，無需改變任何代碼、無需重編譯任何代碼、無需重啟任何進程，實現了分布式調用鏈的零侵擾追蹤，避免了APM、日志方案中的侵入性問題。

應用、系統、網絡全棧鏈路：自動關聯每一筆交易在應用進程、系統調用、網絡傳輸中的Span。

關聯瓶頸文件讀寫操作：自動關聯瓶頸文件讀寫操作，快速定界Nginx靜態資源讀取、數據庫索引文件及數據文件讀寫相關的業務性能抖動。

深入關聯網絡性能數據：自動關聯每個調用前的DNS解析、TLS握手、TCP握手性能，快速分析網絡建連時延、系統協議棧響應時延、網包重傳、協議棧零窗等行為對應用調用性能的影響。

深入關聯進程內的瓶頸函數：自動關聯系統Span與應用進程的On-CPU、Off-CPU、Mem-Alloc、Mem-Inuse等函數粒度性能剖析數據。

多種展示形式：提供開發人員習慣的火焰圖、瀑布列表展示形式，同時也提供網絡、系統團隊習慣的拓撲圖展示形式。

3.持續性能剖析

圖3 持續剖析頁面

上圖展示了全棧觀測平臺的持續剖析頁面，其核心的功能特點包括：

零侵擾、熱加載：基于零侵擾剖析技術，無需改變任何代碼、無需重編譯任何代碼、無需重啟任何進程，可隨時對生產環境中的性能問題進行剖析。

全棧函數：支持展示業務函數、庫/框架函數、語言運行時函數、Linux共享庫函數、Linux內核函數、NVIDIA CUDA函數的資源消耗。

低資源開銷：以On-CPU為例，整機開啟僅需消耗1%計算資源，讓性能剖析數據能夠被持續采集，從而不用擔心遺漏難以復現的線上問題的現場數據。

多語言支持：支持JVM虛擬機語言，Python等解釋型語言，Golang、C/C++、Rust等編譯型語言。

4.多可用區部署架構

G行雙棧云部署在多個區域和可用區，銀行系統由于其高可用要求運行在多個可用區上。為了呈現應用系統業務的全景拓撲，要求可觀測性平臺能夠呈現多個可用區的觀測數據。

圖4 多可用區部署架構

在上圖中，每個可用區內的采集Agent僅會將觀測數據發送到本可用區的數據節點集群中，消除了數據的跨可用區傳輸，從而避免了跨可用區的專線帶寬開銷。另一方面，所有可用區的數據節點構成了一個松耦合的集群，全景拓撲、調用鏈追蹤的查詢請求會同時發送到所有可用區，每個可用區將本地的聚合計算結果回傳，從而有效降低了查詢期的跨可用區帶寬消耗。

5.Agent的資源限制、自監控和熔斷能力

下圖中展示了全棧觀測平臺中Agent自身豐富的資源限制、自監控和熔斷能力，這些能力保障了Agent的高效運轉，以及在發生最惡劣情況下Agent能夠進入熔斷狀態以避免影響業務運行。

圖5 全棧觀測平臺Agent的資源限制、自監控和熔斷能力

四、總結和未來展望

隨著銀行數字化轉型進入新的階段，全棧觀測性在提升系統穩定性、保障業務連續性方面將發揮更加重要的作用。全棧可觀測性不僅為傳統系統引入了高效的監控手段，而且成功解決了多團隊協作中的數據孤島問題，提升了故障定位、性能優化與資源管理的工作效率。

展望未來，隨著大模型智能體技術的發展，全棧可觀測性平臺的應用場景將進一步擴展，大模型的智能分析能力將徹底打破傳統運維中因知識和精力瓶頸帶來的限制，并在性能調優、容量預估和智能化故障檢測方面提供更高效的支持，以及更加精細化和實時的風險防控。

馮帆

十余年云計算相關工作經驗，目前負責云平臺運營及云資源管理工作，致力于成為超能陸戰隊里大白一樣溫暖且靠譜的人。

高瑄

主要負責云資源運營和云觀測應用管理，處在新人經驗積累學習期。道阻且長，行則將至。

王述敏

從事數據庫運維工作，希望能持續為大家分享精彩好文。