SysOM 可觀測體系建設(一):萬字長文解讀低開銷、高精度性能剖析工具livetrace

可觀測性是一種通過分析系統輸出結果并推斷和衡量系統內部狀態的能力。談及可觀測性一般包含幾大功能:監控指標、鏈路追蹤、告警日志,及 Continues Profiling 持續剖析能力。對于操作系統可觀測,監控指標可以幫助查看各個子系統(IO、網絡、內存、調度等)的運行狀態;鏈路追蹤可以查看系統從用戶態到內核態、容器到宿主機、再到網卡等整條鏈路的處理延遲;而持續剖析能力可以分析當前系統上各個任務的熱點信息,找到性能瓶頸點;日志主要是通過 dmesg 等系統日志及用戶日志分析當前系統運行出錯情況。

龍蜥社區智能運維平臺 SysOM?實現了在 CPU 和 GPU 側的可觀測體系,以幫助您對系統可觀測生態的全面認識,特別是在大模型訓練和推理過程中,內部廣泛使用的基于 AI 火焰圖的 CPU 及 GPU 性能追蹤的融合分析能力。我們將通過系列文章解讀 SysOM 可觀測體系建設,本文首先介紹 CPU 側的可觀測體系,包括 livetrace 的火焰圖功能。下一篇文章,我們將重點介紹 GPU 側的觀測體系及 AI 火焰圖功能。

?SysOM 整體架構

SysOM 的可觀測體系,包括了對 JAVA、Mysql、Nginx 等應用的 CPU 系統側的持續剖析,及對 Pytorch、VLLM 等訓練和推理框架(Python 語言)及 GPU 的持續剖析,我們分別稱之為 livetrace 和 AI 可觀測體系。上述體系都是基于 eBPF 實現的,AI 可觀測也融合了 ptrace 動態注入的方式進行 hook。

首先我們來看看 SysOM 的整體架構。它包含節點端的采集和中心端的數據處理和前端展示三部分:

  • SysOM:一站式智能運維平臺,中心端采用微服務的方式處理來自多個 region 的 Profiling 和監控數據。

  • 系統工具集,處理來自中心端的請求和數據預處理,進行診斷結果匯總和 Profiling、監控數據上傳。

  • Coolbpf:eBPF 開發框架和功能庫,提供持續剖析采樣,網絡、IO、內存、調度等監控指標等功能。

SysOM 的主要功能包括對各類應用及操作系統內核的可觀測,支持 JAVA、Python、C/C++、Go、Rust 等解釋性語言和編譯語言的持續剖析,嘗試找到應用和系統內核之間的問題關聯性,同時對訓練和推理過程也具備 GPU?Profiling 能力;還包括對 CPU 和 GPU 的監控能力;以及 CPU 和 GPU 的診斷能力。另外,針對系統宕機問題,提供了宕機分析及歷史宕機問題的自動追蹤功能。簡單來說,SysOM 是集合了診斷、監控、持續剖析的 CPU 和 GPU 的系統智能運維平臺。

(圖/SysOM 整體架構)

?SysOM 開發背景

在探討 SysOM 可觀測體系時,我們重點關注了持續性能剖析(Continuous Profiling)及其在 GPU 性能分析中的應用。這些技術在現代軟件系統中扮演著至關重要的角色,尤其是在處理大規模分布式系統和高性能計算等環境時。

使用場景

持續性能剖析(Continuous Profiling)主要用于識別和優化應用程序的性能瓶頸。通過實時收集和分析運行時數據,開發人員可以深入了解代碼執行路徑、資源使用情況以及潛在的性能問題。這種技術特別適用于以下場景:

1.?微服務架構:在復雜的微服務環境中,持續性能剖析可以幫助快速定位跨服務調用中的性能瓶頸。

2.?云原生應用:對于部署在 Kubernetes 等容器編排平臺上的應用,持續性能剖析能夠提供細粒度的性能洞察,幫助優化資源利用率。

3. 高并發系統:在處理大量并發請求的應用中,持續性能剖析有助于發現并解決線程競爭、鎖爭用等問題。

GPU 性能剖析則專注于圖形處理單元(GPU)的性能優化。隨著人工智能、機器學習和高性能計算領域的發展,GPU 已經成為許多計算密集型任務的核心組件。GPU 性能剖析可以幫助開發人員:

1. 優化深度學習模型:通過分析 GPU 在訓練和推理過程中的性能,優化模型結構和參數,提高計算效率。

2. 加速科學計算:在科學計算和工程仿真中,GPU 性能剖析有助于識別并消除計算瓶頸,提升整體計算速度。

3. 游戲和圖形渲染:在游戲開發和圖形渲染領域,GPU 性能剖析可以幫助優化渲染管線,提升幀率和視覺效果。

未來需求

隨著技術的不斷進步和應用場景的日益復雜,對性能剖析工具的需求也在不斷增加。未來的性能剖析工具需要具備更高的精度、更低的開銷和更強的可擴展性。具體來說:

1. 低開銷監控:在不影響應用性能的前提下,實現高精度的數據采集和分析。

2. 多維度分析:支持從多個角度(如 CPU、內存、I/O、網絡等)進行綜合分析,提供全面的性能視圖。

3. 集成與兼容性:與現有的 CI/CD 流水線、監控系統和日志管理工具無縫集成,形成統一的可觀測性解決方案。

eBPF 技術

為了滿足上述需求,擴展伯克利包過濾器(Extended Berkeley Packet Filter, eBPF)技術應運而生。eBPF 是一種高效的內核技術,能夠在不修改內核源碼的情況下,動態插入和執行沙箱化的程序。這使得 eBPF 成為實現低開銷、高精度性能剖析的理想選擇。

eBPF 的主要優勢包括:

1. 低開銷:eBPF 程序在內核中運行,減少了用戶空間和內核空間之間的上下文切換,顯著降低了性能開銷。

2. 靈活性:eBPF 支持多種類型的事件跟蹤,包括系統調用、網絡包、文件操作等,為多維度性能分析提供了強大的支持。

3. 安全性:eBPF 程序在嚴格的沙箱環境中執行,確保了系統的安全性和穩定性。

4. 實時性:eBPF 能夠實時收集和分析數據,為實時性能監控和故障排查提供了有力支持。

綜上所述,基于 eBPF 在持續性能剖析和 GPU 性能剖析中具有廣泛的應用前景,有望成為未來可觀測性體系中的關鍵技術之一。

?Coolbpf 功能庫簡介

SysOM 底層數據采集使用 Coolbpf 提供的能力。Coolbpf 建立在 CO-RE(一次編譯到處運行)的基礎之上,不僅保持了資源占用低和高可移植性的特點,還整合了 BCC 的動態編譯特性,使其非常適合在生產環境中批量部署開發的應用。Coolbpf 開辟了一條新路徑,采用了遠程編譯的理念,將用戶的 BPF 程序上傳到遠程服務器進行編譯,并返回編譯后的 .o 或 .so 文件。這允許用戶使用高級編程語言如 Python、Rust、Go 或 C 加載這些文件,進而在不同內核版本中安全運行。用戶只需集中精力于功能開發,無須擔心底層庫(例如 LLVM、Python 等)的安裝和環境配置,為 BPF 社區提供了一種新的探索和實踐方式。此外,Coolbpf 還支持在 3.10 版本的內核上,通過內核模塊的方式執行 BPF 程序,實現了在較高版本的內核上開發的應用程序能夠無須修改直接在舊版本內核上運行的能力。

由于 eBPF 技術的普及和廣泛應用于實際生產中,編譯環境的搭建已經相當成熟,并且由于 3.10 等低內核版本已逐漸遷移到 4.19 甚至 5.10 版本,Coolbpf 的遠程編譯和低版本驅動特性將進一步弱化。未來 Coolbpf 將更聚焦于具體功能的提供,比如用戶態 probe 功能、軟件網絡功能、profiling 等功能,通過 lib 庫等形式服務于上層的特定應用,讓開發者不再糾結于系統底層細粒度的指標采集,而更專注于自己業務的應用開發,直接調用 Coolbpf 的庫函數就能滿足業務需求。

Coolbpf 的功能架構如圖所示,主要分為三個層次。

(圖/Coolbpf 功能架構)

1. 接口層:提供給用戶的接口,目前主要有 4 類接口,分別是:

①功能配置:配置和管理不同BPF功能或任務。可以通過用戶接口或配置文件進行配置。

②資源配置:獲取系統或應用程序的監控數據,這通常由BPF探針執行,并用于收集特定的性能指標或事件。

③事件監聽:處理和轉發采集到的事件到指定的處理模塊。

④指標采集:協調和管理采集到的數據,確保它們按照計劃進行分析和處理。

2. 核心組件:由三個核心模塊組成,高級網絡功能、零侵入式性能分析以及其他內核子系統。高級網絡功能模塊涵蓋了鏈路追蹤、網絡性能指標監測以及網絡異常檢測等關鍵特性。無侵入式性能分析是 Coolbpf 的亮點之一,它基于 eBPF 技術,提供了強大的性能分析工具,并且已經實現了對 Java、Lua/LuaJIT、Python、C/C++、Rust、Go 等多種編程語言的支持。此外,其他內核子系統模塊則包括了對 I/O、調度和內存等關鍵性能指標的監控。。

3. 基礎組件:它提供了 Coolbpf 運行所需的底層支持,主要有:

①eBPF 加載庫:加載和管理 eBPF 程序。

②編譯組件:提供了編譯環境。

③多語言支持:支持多種語言來擴展 Coolbpf 功能。

④BTF hub:BTF 集中庫,用于管理和查找內核數據結構定義,確保 eBPF 字節碼與內核數據結構的一致性。

Coolbpf 正如其名,非常”酷“地提升了 eBPF 的開發效率,同時保證工具的跨平臺兼容性。其主要應用場景為系統故障診斷、網絡優化、系統安全和性能監控。 未來,Coolbpf 還將探索新技術和新特性,例如提升字節碼翻譯效率和內核運行時安全等,進一步豐富應用場景。

?livetrace 架構簡介

livetrace 是 SysOM 里面進行持續剖析的主要模塊,其在節點端的架構如圖所示,它采用異步機制構建了一套高度模塊化的插件管理框架。

該框架能夠以插件化的方式管理和處理多種類型的數據,用戶可以自由開關對應的插件以及對對應的插件進行參數配置,管理的插件具體包括:

  • 基礎監控數據:提供系統運行狀態的基本指標。

  • 基礎心跳和元數據信息:確保系統的實時健康狀況及關鍵配置信息的持續傳輸。

  • 性能分析(Profiling)數據:涵蓋基于不同技術棧的性能分析結果,例如:

    • Perf Profiling:利用 Linux Perf 工具進行低層次的性能分析。

    • eBPF Profiling:通過擴展的 Berkeley Packet Filter (eBPF) 技術實現高效的內核級數據采集。

    • 多語言 Profiling:支持 Java 和 Python 等多種編程語言的性能分析。

    • Java 專用堆/鎖 Profiling:針對 Java 應用程序特有的內存和鎖競爭情況進行深入剖析。

    • 符合 OpenTelemetry (OTEL) 標準的 Profiling 數據:遵循 OTEL 規范,確保數據格式的一致性和互操作性。

    • GPU 監控數據:對圖形處理單元 (GPU) 的性能進行觀測與分析。

此外,LiveTrace 針對 RunD(安全容器運行時)環境進行了專門優化,旨在最小化其在資源受限場景下的占用,從而提升整體效率和穩定性。

在數據輸出方面,LiveTrace 支持以下幾種標準協議和格式:

  • OpenTelemetry Exporter:兼容 OTEL 生態系統中的各種后端服務。

  • 阿里云 SLS (Simple Log Service):這是一項專為阿里巴巴云平臺設計的日志存儲與分析服務,旨在為用戶提供高效、可靠且可擴展的日志管理解決方案。通過SLS,用戶能夠在云端環境中輕松實現日志數據的采集、存儲、檢索及實時分析,從而顯著提升運維效率和故障排查能力。

  • 阿里云 OSS (Object Storage Service):作為一款高度可擴展且具備企業級安全特性的對象存儲服務,OSS 為用戶提供了海量、安全、低成本的數據存儲方案。它支持多種數據訪問方式,并具備強大的數據處理能力,適用于各類應用場景,如靜態網站托管、多媒體文件存儲、大數據分析等。借助OSS,企業能夠輕松應對日益增長的數據存儲需求,同時確保數據的高可用性和持久性。

綜上所述,LiveTrace 通過靈活的插件架構、高效的資源管理和廣泛的數據輸出選項,為不同部署場景提供了強大的監控與分析能力。

?全棧 profiling 功能

棧回溯能力

棧回溯是性能分析(profiling)中的關鍵能力。Livetrace 通過支持以下幾種場景,顯著提升了這一能力:

1. 無幀指針(Frame Pointer,FP)的應用程序:為了優化性能,許多應用程序選擇不保留幀指針。這導致傳統的基于幀指針的回溯方法無法使用。因此,我們必須采用更為復雜的基于 DWARF 的棧回溯技術來獲取調用棧信息。

2. 解釋型語言的棧回溯:Java、Python 等解釋型或高級編程語言具有獨特的棧幀結構。因此,關鍵在于準確識別當前運行的程序,并解析相應的棧幀信息。

Coolbpf Profiler 利用 eBPF 的編程靈活性,支持有幀指針和無幀指針的應用程序以及解釋性語言(如 Java 和 Python)的棧回溯功能。

棧分析能力

Livetrace 通過對性能分析數據的存儲和處理流程進行優化,增強了性能分析的水平擴展能力和集中展示能力。此外,通過自主研發的 SQL 引擎,實現了數據加工、轉換和融合展示的功能。目前實現的功能包括:

1. 熱點分析

熱點分析主要應用于單實例的熱點可視化,旨在為用戶提供對其進程內關鍵性能瓶頸的全面概覽。該功能通過先進的可視化技術,以直觀且詳盡的方式呈現了進程中資源消耗較高的部分,從而幫助用戶精準識別并優化高負載區域。此方法不僅提升了系統性能監控的透明度,還顯著增強了對復雜應用環境中資源使用情況的理解與管理能力。

2.調用圖譜

函數調用圖譜以樹狀結構清晰地展示了函數間的調用關系。每個節點框代表一個函數,其中“自”表示該函數自身的執行熱度,“調”表示被該函數調用的所有子函數的總執行熱度,“總”則是兩者之和。邊表示調用關系,邊上標注的百分比數字表示被調用函數“總”熱度在當前節點“總”熱度中的占比。通過加粗和標紅連線來突出顯示圖譜中最熱點的調用路徑,并通過放大節點框和字體來標識最熱點的函數。該圖譜支持鼠標拖動和縮放功能,用戶可以根據需要調整視圖。相比于傳統的火焰圖形式,函數調用圖譜能夠更直觀地揭示函數熱點及其調用關系,從而便于性能分析和優化。

3.熱點對比

熱點對比功能在分析正常環境與異常環境方面具有顯著的價值,能夠從海量數據中精準識別細微的熱點差異,從而有效定位問題的根本原因。這一技術手段通過高級算法和數據分析模型,實現了對復雜系統狀態的深度洞察,為故障診斷和性能優化提供了強有力的支持。通過對不同環境下的數據進行精細化比對,該功能可以揭示潛在的問題模式,進而輔助決策者制定更加科學合理的解決方案。

livetrace 在持續性能分析中的應用

持續性能分析在多個關鍵領域得到了廣泛應用,尤其在性能瓶頸分析和應用上線評估中發揮了重要作用。這些應用不僅提升了系統的穩定性和效率,還為開發團隊提供了寶貴的反饋信息,從而促進了軟件質量的持續改進。

1. 性能瓶頸分析

性能瓶頸是指系統運行過程中出現的限制因素,它會顯著降低整個系統的處理能力或響應速度。通過持續性能分析,可以有效地識別出這些瓶頸所在,進而采取針對性措施進行優化。例如,在一個分布式計算環境中,如果某個節點成為了數據傳輸的瓶頸,則可以通過增加該節點的資源配置或者調整網絡拓撲結構來緩解問題;對于數據庫查詢而言,使用性能監控工具能夠幫助發現執行效率低下的 SQL 語句,并據此對索引策略或查詢邏輯進行優化。此外,持續性地收集與分析性能指標還有助于預防未來可能出現的新瓶頸,確保系統始終處于最佳工作狀態。

2. 應用上線評估

當一個新的應用程序準備部署到生產環境時,對其進行徹底而全面的測試是非常必要的。這不僅包括功能驗證,也涵蓋了性能方面的考量。在此階段實施持續性能分析可以幫助團隊了解新版本相對于舊版本在資源消耗、響應時間等方面的差異,及時發現潛在的風險點。比如,通過模擬真實用戶訪問場景的壓力測試,可以評估新功能上線后對服務器負載的影響程度;利用 A/B 測試方法比較不同配置下的用戶體驗效果,選擇最優方案發布。同時,基于歷史數據建立基線模型,實時監測上線后的實際表現是否符合預期目標,一旦發現問題能夠迅速定位原因并作出響應。

總之,無論是為了消除現有系統的性能障礙還是保證即將發布的軟件產品達到預期的質量標準,持續性能分析都是不可或缺的重要手段之一。它貫穿于軟件開發生命周期的各個階段,為企業構建高效可靠的信息技術基礎設施提供了強有力的支持。

3. 持續性能分析的進一步應用

除了在性能瓶頸分析和應用上線評估中的重要作用外,持續性能分析還在其他多個方面發揮著關鍵作用。例如,在系統容量規劃中,通過長期收集和分析性能數據,可以更準確地預測未來資源需求,從而避免過度配置或資源不足的問題。這不僅有助于優化成本,還能確保系統的可擴展性和彈性。

1)系統容量規劃

在進行系統容量規劃時,持續性能分析提供了重要的數據支持。通過對歷史性能數據的深入分析,可以識別出資源使用模式和趨勢,進而預測未來的負載情況。例如,通過分析過去一年中特定時間段(如節假日或促銷活動期間)的性能指標,可以更好地預估這些高峰期的資源需求,并提前進行相應的資源配置。此外,還可以利用機器學習算法對性能數據進行建模,以提高預測的準確性。這種基于數據驅動的方法能夠幫助企業更加科學地進行資源規劃,減少不必要的浪費。

2)故障診斷與根因分析

持續性能分析也是故障診斷和根因分析的重要工具。當系統出現異常時,通過實時監控和歷史數據對比,可以快速定位問題所在。例如,如果某個服務的響應時間突然增加,可以通過性能監控工具查看相關指標的變化,結合日志信息和其他上下文數據,確定是由于網絡延遲、硬件故障還是代碼缺陷引起的。此外,通過構建性能基線模型,可以自動檢測偏離正常范圍的異常行為,并觸發警報機制,以便及時采取措施。

3)服務質量保障

持續性能分析對于保障服務質量同樣至關重要。特別是在高可用性要求嚴格的場景下,如金融交易系統或在線服務平臺,任何性能下降都可能導致嚴重的業務影響。通過實時監控關鍵性能指標(如響應時間、吞吐量、錯誤率等),可以確保系統始終處于最佳狀態。一旦發現潛在的服務降級風險,可以立即啟動應急預案,進行故障切換或負載均衡調整,以最小化對用戶的影響。

4)自動化運維

隨著 DevOps 文化的普及,自動化運維成為越來越多企業的選擇。持續性能分析為自動化運維提供了堅實的數據基礎。通過集成性能監控工具與 CI/CD 流水線,可以在每次部署后自動進行性能測試,確保新版本的穩定性和高效性。同時,結合自愈系統,可以根據性能數據自動調整資源配置、重啟服務或執行其他恢復操作,從而實現真正的無人值守運維。

總之,持續性能分析不僅是提升系統穩定性和效率的關鍵手段,還在系統容量規劃、故障診斷、服務質量保障以及自動化運維等多個方面發揮著重要作用。它為企業構建高效可靠的信息技術基礎設施提供了強有力的支持,推動了軟件質量的持續改進。通過全面而深入的性能分析,企業能夠更好地應對復雜多變的業務環境,確保業務連續性和競爭力。

?應用可觀測

在系統運維領域,問題的第一視角都是在應用,分析路徑也是自頂層應用向下到 OS、硬件及基礎設施層面。在 OS 運維中,SysOM 目前具備 IO、內存、網絡、調度等領域問題的深度剖析與監控能力,力求能緊扣用戶痛點,做到結論與客戶問題能關聯,但仍然存在如下問題:

  • 數據監控只限:系統資源(內存、調度、IO、網絡),缺乏對應用的觀測能力,解決的是什么時間有什么問題;無法解決問題在哪里,根因是什么。

  • 不具備問題第一視角,無法建立應用異常與 OS 異常指標或事件的關聯性,OS 側的診斷分析可能關聯不到客戶問題;一般的,經過上下游多個團隊來回 debug 才找到應用與 OS 的關系點。

我們也分析了 nginx-agent、openresty xray 等開源產品,這些開源產品雖然做到了應用指標監控,但無法做到內核側的對應分析。

為了解決這一痛點,我們通過深入應用側的問題觀測,把應用的異常和 OS 的行為對應起來,給客戶一個明確的根因分析:如網絡抖動,Nginx 性能抖動問題場景中、將應用指標或異常事件與 OS 異常指標或事件關聯分析,以應用問題的第一視角,解決“問題在哪里,根因是什么”。

SysOM 應用觀測功能主要解決應用出現的異常問題后,如何一步一步對應用、中間件、內核、硬件驅動、前后端虛擬化、底層基礎設施的問題進行定界和定位。Agent 側主要進行指標和日志的采集和初步分析,Server 主要是對采集到的數據進行關聯分析,給出進一步的修復建議。

功能詳細設計

1. 網絡拓撲觀測功能設計

上圖為應用拓撲總體架構,總體上分為指標采集和指標聚合&上傳兩大板塊,具體介紹如下:

指標采集

  • 網絡鏈接,這部分主要獲取應用的鏈接信息用于繪制拓撲,包括:源地址和目的地址。

  • 網絡 RT,這部分主要獲取應用處理請求的響應時延指標,應用拓撲前端會根據時延信息來標記出現明顯阻塞的應用。

  • 進程信息,獲取進程的信息,包括:進程 pid、進程名、進程的容器 ID、進程的 pod ID 等關鍵信息,應用拓撲會根據進程信息來進行頁面的跳轉。

  • 網絡流量,獲取應用的流量,包括 ingress 和 egress 流量信息。

指標聚合&上傳

  • 拓撲節點表:將采集上來的信息以應用為基本單位進行聚合,生成節點表。

  • 拓撲邊表:將采集上來的網絡鏈接指標進行處理,聚合成應用之間的連接關系。

全局網絡拓撲,可以可視化展示集群內業務 Pod 之間的交互關系。如果發生異常的 Pod,會以紅色標記出來。當將鼠標懸停在 Pod 節點上時,可以查看該 Pod 的名稱、最大網絡延遲、相關的 URL 請求和網絡流量等詳細信息。

2. Nginx 觀測功能設計

上圖為 Nginx 應用觀測總體架構,總體上分為 Agent 指標采集、應用抖動診斷、異常檢測、監控大盤三大板塊,具體介紹如下

Agent 指標采集

  • Nginx 請求采集,主要從 nginx access log 進行指標提取。另外一個是 nginx error log,包含一些鏈接錯誤的信息。采集的指標有:http 狀態碼,請求 RT、upstream RT 等。

  • Nginx 系統指標:從unity獲取的系統指標,包括 CPU、內存、網絡、調度等信息。

  • Nginx 系統增強指標:需要使用 eBPF 采集的系統增強指標,如網絡隊列飽和度、丟包信息等。

應用抖動診斷

  • 抖動診斷,目前主要覆蓋用戶態收包慢、內核隊列慢、關中斷和軟中斷調度延遲和 fpga 抖動檢測。

  • 丟包診斷,診斷應用丟包的詳情以及根因分析。

異常事件:異常事件大盤主要進行抖動、499/504 的根因分析。

監控大盤:根據黃金四指標(錯誤、飽和度、延遲、流量),將監控大盤分為 4 個子盤:告警分布、Nginx 資源利用率、Nginx 延遲和 Nginx 吞吐。

監控大盤包含 mysql 異常事件分布、應用指標、系統指標三個部分。

用戶進入大盤,首先可以看到 Nginx?異常事件分布一欄是否存在相關計數,如有計數,點擊對應柱狀圖區域跳轉到異常事件大盤,查看異常事件的詳情。在異常事件大盤中,存在對此次異常事件的簡要原因分析,更詳細的進一步根因,支持點擊“進一步診斷”,跳轉到進一步的根因分析診斷界面,如當原因為網絡抖動導致,則跳轉到應用診斷界面做進一步診斷。

沒有異常告警的情況下,可在大盤上查看 Nginx 的應用指標詳情,其中包含 Nginx 應用側所實現的請求數、http 狀態碼分布、響應時延、workers 數量、活躍的連接數等指標。這些指標都是 Nginx 用戶非常熟悉而且容易理解的指標,通過這些指標,用戶可以剖析 Nginx 應用的具體行為。

最后是系統指標,系統指標是從內核層面觀測到的和 Nginx 應用有關的指標,包括:Nginx 進程 CPU 利用率、Nginx 進程內核利用率以及 Nginx 進程網絡流量。

異常事件大盤展示應用異常事件,以表格形式呈現,重點突出異常事件描述,描述事件的初步分析原因,并支持通過點擊“應用抖動診斷”對初步原因進行更深入的分析。

3. Nginx 診斷功能設計

診斷功能預計包含三大部分:

1. tcpping 探測診斷:主要覆蓋了通用類型網絡故障,包括:調度抖動導致的網絡抖動、內核隊列慢、軟中斷延遲、關中斷、FPGA 故障等;

2. HTTP 業務報文診斷:主要覆蓋了和應用相關的抖動,比如用戶收包慢;

3. Nginx LUA 應用分析:主要結合具體應用進行分析,包括 LUA 熱點分析、LUA 占用內存分析。

當發現網絡抖動時,可以點應用抖動診斷。

同時,網頁會自動跳轉到下面頁面,也自動輸入了相應的診斷參數,點擊開始診斷。

點擊開始診斷后,會新增一條診斷記錄,當診斷結束時,可以點擊查看診斷結果。

下圖是診斷的輸出結果,可以看到已經抓到了進程關閉了中斷,導致網絡抖動。

對于應用的可觀測,除了通過 SysOM 中心端的網絡拓撲進行監控和分析,使用 SysOM 的 livetrace 功能,可以將用戶態的棧、內核態的棧都呈現在一張火焰圖或者調用圖譜里,這樣就方便的看到每一個應用在用戶態是如何調用下來的,在內核態是如何處理的,對于那些應用訪問延時高一類問題,非常能直觀的看到在哪里慢了,比如是否做了阻塞的 IO 操作。

?總結和展望

SysOM 可觀測體系通過其強大的持續性能剖析和 GPU 性能分析功能,為現代軟件系統提供了全面的性能優化工具。該平臺基于 eBPF 技術,結合 Coolbpf 增強型開發框架,實現了低開銷、高精度的數據采集和分析。LiveTrace 客戶端架構采用異步機制和模塊化插件管理,支持多種數據類型,并針對 RunD 環境進行了優化,確保在資源受限場景下的高效運行。全棧 Profiling 功能包括無幀指針和解釋型語言的棧回溯、熱點分析、調用圖譜和熱點對比,幫助用戶深入理解性能瓶頸并進行精準優化。

LiveTrace 的技術優勢:

  • 低開銷監控:基于 eBPF 技術,LiveTrace 能夠在不顯著影響系統性能的情況下進行高精度的數據采集。

  • 全面的數據支持:支持基礎監控、心跳信息、性能分析等多種數據類型,確保數據的多樣性和完整性。

  • 靈活的輸出協議:支持 OpenTelemetry、阿里云 SLS 和 OSS 等多種數據輸出協議,提高了數據的互操作性和一致性。

  • 模塊化設計:采用模塊化插件管理框架,便于擴展和維護,能夠快速適應不同的應用場景和需求。

在性能分析領域的廣闊前景:

  • 多維度綜合分析:未來,LiveTrace 將進一步拓展其分析維度,從 CPU、內存、I/O、網絡等多個角度進行綜合分析,提供更全面的性能視圖。這將幫助企業更準確地識別和解決性能瓶頸,提升系統的整體性能和穩定性。

  • 自動化與智能化:結合機器學習和人工智能技術,LiveTrace 將實現自動化的性能優化和故障預測。通過智能算法,系統能夠自動檢測異常行為并提出優化建議,減少人工干預,提高運維效率。

  • 無縫集成:LiveTrace 將繼續與現有的 CI/CD 流水線、監控系統和日志管理工具無縫集成,形成統一的可觀測性解決方案。這將簡化企業的運維流程,提升整體的 IT 基礎設施管理水平。

在 AI 領域的廣闊前景:

  • 深度學習模型優化:隨著 AI 技術的不斷發展,LiveTrace 將在深度學習模型的性能優化中發揮重要作用。通過詳細的 GPU 利用率和內核函數調用時間統計,LiveTrace 可以幫助研究人員和工程師優化模型結構和參數,提高訓練和推理的效率。

  • 邊緣計算與物聯網:LiveTrace 的技術優勢使其在邊緣計算和物聯網領域具有廣泛的應用前景。這些領域的設備通常資源受限,對性能監控和優化有更高的要求。LiveTrace 的低開銷監控和靈活的數據支持將使其成為這些領域的理想選擇。

  • AI 驅動的運維:未來的運維將越來越依賴于 AI 技術。LiveTrace 將結合 AI 技術,實現更智能的性能分析和故障診斷。通過實時監控和歷史數據分析,系統能夠自動檢測異常行為并提出優化建議,從而提升系統的穩定性和響應速度。

總之,LiveTrace 憑借其低開銷監控、全面的數據支持、靈活的輸出協議和模塊化設計等技術優勢,在性能分析和 AI 領域展現了廣闊的應用前景。未來,LiveTrace 將繼續創新和發展,為企業構建高效可靠的信息技術基礎設施提供強有力的支持,推動軟件質量的持續改進。

—— 完 ——

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/bicheng/73994.shtml
繁體地址,請注明出處:http://hk.pswp.cn/bicheng/73994.shtml
英文地址,請注明出處:http://en.pswp.cn/bicheng/73994.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

網絡安全設備配置與管理-實驗4-防火墻AAA服務配置

實驗4-p118防火墻AAA服務配置 從這個實驗開始,每一個實驗都是長篇大論😓 不過有好兄弟會替我出手 注意:1. gns3.exe必須以管理員身份打開,否則ping不通虛擬機。 win10虛擬機無法做本次實驗,必須用學校給的虛擬機。首…

路由Vue Router基本用法

路由的作用是根據URL來匹配對應的組件,并且無刷新切換模板的內容。vue.js中,可使用Vue Router來管理路由,讓構建單頁應用更加簡單。 一、效果 二、實現 1.項目中安裝Vue Router插件 pnpm install vue-routerlastest 2.main.js import { …

24. 狀態模式

原文地址: 狀態模式 更多內容請關注:智想天開 1. 狀態模式簡介 狀態模式(State Pattern)是一種行為型設計模式,它允許一個對象在其內部狀態改變時改變其行為,使得該對象看起來似乎修改了其類。狀態模式通過將狀態的行…

【Qt】Qt + Modbus 服務端學習筆記

《Qt Modbus 服務端學習筆記》 1.因為項目的需要,要寫一個modbus通信,csdn上感覺有些回答,代碼是人工智能生成的,有些細節不對。我這個經過實測,是可以直接用的。 首先要包含Qt 的相關模塊 Qt Modbus 模塊主要包含以…

CherryStudio + 火山引擎DeepSeek R1 告別服務器繁忙

CherryStudio 火山引擎DeepSeek R1 告別服務器繁忙 一、下載CherryStudio并安裝 CherryStudio是功能強大的多模型桌面客戶端,支持Windows、macOS和Linux系統。集成了多種主流的大語言模型(如OpenAI、DeepSeek、Gemini等)以及本地模型運行功…

醫院人事科室病區管理系統基于Spring Boot-SSM

目錄 摘要 一、研究背景與意義 二、國內外研究現狀 三. 系統目標 四、研究目的與內容 五、研究方法與技術路線 5.1 系統技術架構 六. 系統功能 6.1 人事管理 6.2 科室病區管理 6.3 科研管理 七. 系統安全性 八. 系統運行與維護 摘要 隨著醫療行業的快速發展和醫院…

Unity TextMeshPro中顯示建筑特殊符號

示例:顯示效果如圖 實現步驟 1、下載 SJQY 字體庫 2、導入字體:將 SJQY 字體文件(如 .ttf 或 .otf 文件)導入到 Unity 項目的 Assets 文件夾中。 3、創建 TMP 字體資產 方法一 方法二 選擇剛導入的字體文件,在…

工具層handle_excel

該工具類利用openpyxl的load_workbook加載Excel,通過iter_rows按行迭代數據,將表頭和用例數據用zipdict組合成字典,通過list.append將字典(單條測試用例)追加到列表中,從而封裝Excel數據解析工具。 模塊/類方法/屬性使用場景描述o…

九、JavaScript作用域、預解析

一、JavaScript作用域 1.JavaScript作用域 ①代碼名字(變量)在某個范圍內起作用和效果 目的是為了提高程序的可靠性更重要的是減少命名沖突 ②js的作用域(es6)之前:全局作用域 局部作用域 ③全局作用域:整…

Rust語言學習

Rust語言學習 通用編程概念所有權所有權引用和借用slice struct(結構體)定義并實例化一個結構體使用結構體方法語法 枚舉 enums定義枚舉match控制流運算符if let 簡單控制流 使用包、Crate和模塊管理不斷增長的項目(模塊系統)包和crate定義模塊來控制作用…

Windows Docker 報錯: has no HTTPS proxy,換源

pull python 3.7報錯: 嘗試拉取Docker 測試庫hello world也失敗 嘗試使用臨時鏡像源,可以成功拉取: sudo docker pull docker.m.daocloud.io/hello-world說明確實是網絡問題,需要配置鏡像源,為了方便,在d…

Git遠程拉取和推送配置

Git進行遠程代碼拉取和推送時候提示配置user.name 和 user.email 背景:換新電腦后使用Git進行代碼拉取和推送過程中,提示“Make sure you configure your “user.name” and “user.email” in git.”。這個配置針對git的正常使用僅需要配置一次&#xf…

詳解string類+迭代器

迭代器 概念:在 C 中,迭代器是訪問容器(如數組、列表、向量、字符串等)元素的一種方式。迭代器提供了一種統一的接口,使得你可以使用相同的代碼來遍歷不同類型的容器。迭代器本質上是一個指針或者指針的封裝&#xff0…

小紅書不綁定手機號會顯示ip嗎

小紅書作為一個生活方式分享平臺,擁有龐大的用戶群體。在小紅書上,用戶可以分享自己的生活點滴、購物心得、美食體驗等,與其他用戶進行互動交流。最近,不少用戶對于小紅書是否會在不綁定手機號的情況下顯示IP屬地產生了疑問&#…

Web-Machine-N7靶機實戰攻略

1.安裝并開啟靶機 下載VirtualBox:https://www.virtualbox.org 導入虛擬機 設置為橋接模式 2.獲取靶機IP Kali設為橋接模式 3.訪問靶機 4.獲取敏感目錄文件和端口 gobuster dir -u http://172.16.2.68 -w /usr/share/wordlists/dirbuster/directory-list-2.3-me…

wsl配置指南

wsl配置步驟 1.安裝2.列出當前的發行版3.導出要遷移的發行版,并指定導出的路徑及文件名4.注銷掉已經導出的發行版5.重新導入到新的路徑,可以指定新的名稱6.修改默認用戶7.更換source8.配置gpu環境 1.安裝 在microsoft store中搜索ubuntu,選擇…

Linux|fork命令及其使用的寫時拷貝技術

fork復制進程 fork通過以下步驟來復制進程: 分配新的進程控制塊:內核為新進程分配一個新的進程控制塊(PCB),用于存儲進程的相關信息,如進程 ID、狀態、寄存器值、內存指針等。復制進程地址空間&#xff1…

Android Compose 框架基礎按鈕模塊深度剖析(四)

Android Compose 框架基礎按鈕模塊深度剖析 一、引言 在現代 Android 應用開發中,Android Compose 框架以其聲明式編程范式和簡潔高效的開發體驗,逐漸成為開發者構建用戶界面的首選。而注解在 Android Compose 框架中扮演著至關重要的角色,…

HarmonyOS開發,A持有B,B引用A的場景會不會導致內存泄漏,看這里!

問題 :A持有B,B引用A的場景會不會導致內存泄漏? 答案 :方舟虛擬機的內存管理和GC采用的是根可達算法,根可達算法可以解決循環引用問題,不會導致A引用B,B引用A的內存泄漏。 根可達算法原理 根可達算法以一系列被稱為 “根對象”(如棧中的局部變量、靜態變量等)作為起…

【數據庫備份】docker中數據庫備份腳本——MySql備份腳本

docker中數據庫備份腳本——MySql備份腳本 #!/bin/bash# MySQL數據庫信息 DB_USER"root" DB_PASSWORD"你的密碼"# 備份保存主目錄 BACKUP_ROOT"/data/data_backup/mysql"# 最多保留的備份日期文件夾數 MAX_DATE_FOLDERS15# 數組包含要備份的數據…