系統運維 SysOM profiling 在雲上環境的應用觀測實踐

背景

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

實現方案

所謂的"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等，以此希望發現一些應用等鎖耗時造成的收發包延遲等問題。

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

硬中斷和軟中斷收包，
用戶態應用進程系統調用取包，也做了相關的profiling觀測：

如何持續的profiling

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

使用說明

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

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

如果是想獲取 profiling 的一些結論性信息可以通過診斷模式，對應路徑在：診斷中心->調度診斷中心->應用 profile 分析。

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

以上展示的是 oncpu 的面板信息，profiling 的其他功能的面板信息持續適配中。

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

運行模式

常規模式	trigger模式	filter模式
定時觸發去profiling，默認5分鐘一次	設定指標閾值異常時觸發	限定應用或者cpu，針對明確了異常應用或者應用綁核只在特定cpu上有問題場景