文/系統運維 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 擷取，除了功能項也可以設定運作模式等。
運作模式
| 正常模式 | trigger 模式 | filter 模式 |
| 定時觸發去 profiling，預設 5 分鐘一次 | 設定名額門檻值異常時觸發 | 限定應用或者 CPU，針對明确了異常應用或者應用綁核隻在特定 CPU 上有問題場景。 |
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 開源運維倉庫：
SysOM：
SysAK：
Coolbpf：
參考
[1]《Google-Wide Profiling: A Continuous Profiling Infrastructure for Data Centers》
[2]《Observability Engineering》
[3]
[4]