系統運維 SysOM profiling 在雲上環境的應用觀測實踐 | 龍蜥技術

文/系統運維 SIG

01 背景

雲上環境，ECS 使用者一般都會佈置一些常規監控觀察系統指標或者業務指標，雖然透過這些指標能監控到系統或者應用的異常，但卻不能完全瞭解系統/應用正在做什麼導致的指標異常。常見的如：看到系統 CPU 偶爾飆高卻不知道是哪個應用引起、抓包發現報文已經到達了本機卻不知道應用為何遲遲不收包等等，束手無策之餘只能認為“系統有問題” ，而在排查系統問題之後發現往往是應用對系統資源在做一些野蠻消耗，這些應用有些是業務自身，有些則悄悄躲在 "ps -ef" 的千百個任務中，很難發現。於是我們想透過 profiling 的方式去觀測系統/應用的執行行為，幫助使用者解決難題。

02 實現方案

所謂的"profiling"可以認為是以一種動態的方式去觀測程式的執行邏輯。這個程式可以大到一個作業系統，甚至是一個基礎設施，有興趣的同學可以看下文[1]，也可以小到一個 pod，甚至一個簡單的應用程式。如果在這種方式上再增加一個時間維度，持續性的以“profiling”的方式去做觀測，對上面說的常見系統資源偶現指標異常等問題就可以做一個很好的追蹤，不需要苦苦守著問題出現。

那麼如何去做 profiling 呢？

不同的程式語言有不同的 profiling 工具，像 Go 的 pprof、Java 的 jstack 等，這裡我們希望觀測應用但又想拋開語言的差異化，於是我們藉助 eBPF 來實現程式棧資訊的獲取，這裡的棧資訊包括一個應用在使用者態執行和核心態的執行的全部資訊。藉助 eBPF 的好處在於我們可以做到 profiling 過程的可控 ：頻率快慢、執行時安全、系統資源佔用小等。

如下圖所示，透過 eBPF 加 PMU(Performance Monitoring Unit)事件我們就可以定期獲取應用的執行棧資訊，同時利用 bpf map 對每個應用的棧資訊做統計。藉助我們前期 開源的 Coolbpf(eBPF 開發編譯框架，具備 CORE、高低版本適配能力)，我們對不同的核心版本做了相關適配，具體可執行版本見下文。

profiling 應用的那些行為邏輯

一個程式的執行時最簡單的可以概括為執行和不執行兩種狀態 ，即 on cpu 和 off cpu。on cpu 我們希望看到程式佔用 CPU 時的執行邏輯，哪個任務甚至任務的哪一段程式碼在 CPU 上消耗資源，而 off cpu 我們希望看到應用是否是自願放棄的 CPU，出於何種原因不佔用 CPU，如等鎖、等 IO 等，以此希望發現一些應用等損耗時造成的收發包延遲等問題。

針對網路抖動的常見問題我們在收包的兩個階段：

1. 硬中斷和軟中斷收包。

2.使用者態應用程式系統呼叫取包，也做了相關的 profiling 觀測：

如何持續地profiling

整體我們採用 c/s 的架構方式，日常問題定位中我們只需要部署 agent 去負責 profiling，在 server 端去檢視資料。同時將 profiling 資料做切片處理，定時從 map 中拿資料並清空 map 上一週期的取樣資料，這樣的話確保我們在做資料回放的時候看到的是對應時間段的 profiling 結果 。考慮使用者對雲上環境資料安全的要求，我們也可以藉助 SLS 通道完成資料上傳。

03 使用說明

在 SysOM 上可以有兩種使用方式。

如果想持續性的觀測系統那麼可以監控模式下 profiling 功能，對應路徑在：監控中心->機器 ip->General dashboard->sysom-profiling。

如果是想獲取 profiling 的一些結論性資訊可以透過診斷模式，對應路徑在：診斷中心->排程診斷中心->應用 profile 分析。

當前會統計 top 10 應用 CPU 佔用百分比，同時會將熱點棧資訊展示出，熱點棧在應用自身所有棧資訊的百分比也會做一個統計，最後會對熱點棧做個分析，明確熱點棧是在應用自身還是在 OS。

以上展示的是 oncpu 的皮膚資訊，profiling 的其他功能的皮膚資訊持續適配中。

具體 profiling 功能可以執行 sysAK 統一監控目錄下的 raptor 獲取，除了功能項也可以設定執行模式等。

執行模式

profilng 功能支援的核心版本

CentOS 7.6 及以上，alinux2/3、anolis，同時也支援了倚天 Arm 架構。

04 相關案例

1.某使用者 CPU 指標偶有飆高，而相同業務的其他機器並無異常，懷疑 ECS 資源有問題

ecs 監控如下：

由於是間歇性抖動，常規手段較難抓到現場，對系統持續 profiling 一天後發現抖動時刻對應系統上 nginx 應用佔用的 CPU 最多，並且 nginx 主要在做收發包處理，使用者最佳化業務流量請求分佈後該問題得到解決。

2.某使用者系統業務壓力沒有增加的情況下 sys 指標莫名升高

使用者監控如下：

對系統做 profiling 觀測後發現有個 cachestat 指令碼開啟了 ftrace 功能，該指令碼是之前同學定位問題部署後沒有及時停止，停掉指令碼後系統恢復正常。由於 ftrace 不是透過 sysfs 目錄開啟，檢視 sysfs 的 ftrace 其實並無改動。

3.某使用者機器 CPU 指標異常，ssh 無法登陸，整機夯住

使用者監控圖如下：

ssh 無法登陸、CPU 指標異常、記憶體有壓力，根據“經驗”一般懷疑係統在做記憶體回收，但是通常情況下無法拿到第一現場佐證，沒有說服力。透過 profiling，部署一天，我們抓到了第一現場，13:57 分 CPU 佔用異常高，大陽線拔地而起，再看系統行為就是核心佔著 CPU 在做記憶體回收，隨後建議使用者最佳化應用的記憶體使用。該問題可以算是雲上環境的“經典問題”。

4.某使用者機器 ping 報文偶現秒級時延抖動

ping 主機偶現秒級的時延抖動，同時伴隨個別 CPU sys 偶現佔用達到 100%。

由於是個別 CPU 的短暫抖動，因此我們對某一 CPU 上的執行情況做 profiling。我們看到網路抖動時間點，runc 在讀 /proc/cpuinfo 資訊，“smp_call_function_single”核間call 存在熱點，跟我們看到的 sys 偶爾高現象也能吻合。

最終容器同學透過對 cpuinfo 資訊快取備份以減少對 /proc/cpuinfo 的訪問，緩解系統壓力，當然高版本核心對 /proc/cpuinfo 的訪問也做了部分最佳化，相關 patch 見[4]。

05 總結

SysOM 致力打造一個集主機管理、配置部署、監控報警、異常診斷、安全審計等一些列功能的自動化運維平臺。以上是對 SysOM profiling 功能的相關介紹，由於篇幅有限只介紹了部分案例，相關功能模組已完成功能驗證，正在開源中，敬請期待。

更多的運維技術，可關注我們的 gitee 開源運維倉庫，連結可移步龍蜥公眾號（OpenAnolis龍蜥）2023年2月1日相同推送檢視。

參考

[1]《Google-Wide Profiling: A Continuous Profiling Infrastructure for Data Centers》

[2]《Observability Engineering》

[3]

[4]

—— 完 ——