針對 openEuler 運維變更過程觀測困難的問題，華為 2012服務實驗室 OSMind 團隊開發(fā)了基于 eBPF 的變更觀測工具—— Agith。Agith 可以識別與變更相關的行為，并將變更過程表示為一種拓撲結構——變更影響面。通過變更影響面可以完成變更告警、審計、根因定位、依賴分析等功能。

背景

云計算成為信息時代的算力底座，服務千家萬戶。作為重要的基礎實施，穩(wěn)定壓倒一切。但同時云計算也在追求擴大規(guī)模以及適配上層業(yè)務。因此帶來頻繁的變更難免會引發(fā)故障。

變更任務大致可以分為兩類。第一類白屏變更是通過運維工具執(zhí)行操作，適用于版本變更、資源擴縮容、災備倒換等流程固定的任務。但是靈活性差，只能執(zhí)行標準流程。另一類黑屏變更需要運維人員登錄系統(tǒng)，通過執(zhí)行命令來完成變更過程。黑屏變更簡單靈活，適合中小型企業(yè)的 IT 運維與復雜的運維任務，例如根因分析或故障修復。黑屏變更是變更不確定性的主要來源，也更容易引發(fā)故障，需要加強可觀測性。

目前對于變更過程的主要觀測方法是記錄變更過程中運維人員輸入的所有命令。在變更結束后，通過審計監(jiān)察發(fā)現(xiàn)潛在的風險。這種方式需要大量的專家經(jīng)驗。因為命令日志很難表示變更過程。例如2022-09-12 0000.0 張三 obs_cmd.sh 1818 華東 10.164.179.21，包含時間、人員、主機IP，主機集群（華東）和最重要的命令（obs_cmd.sh 1818）。但是如果沒有專家經(jīng)驗，這條命令是無法解讀的。

Agith與變更影響面

Agith 是 Agent Smith 的縮寫。這是致敬《黑客帝國》的 Smith 探員。雖然 Smith 探員是電影中的反派角色，但從運維工程師的視角來看，探員是 Matrix 系統(tǒng)中最優(yōu)秀的運維工程師。Matrix 系統(tǒng)每時每刻有數(shù)十億的流量接入，但是探員卻可以感知輕微的變更異常，并通過最近的節(jié)點登入以處理故障（Kill Neo）。這種觀測能力正是 Agith 的設計目標。系統(tǒng)每時每刻都在處理大量的請求，包括正常的上層服務與變更任務。Agith 需要從中區(qū)分出變更任務，將變更的行為記錄下來，整理為變更影響面拓撲圖。

Agith 是一款面向變更過程的觀測工具。相比只記錄命令名，Agith 更關注命令的行為。這種區(qū)別體現(xiàn)在最終輸出上。傳統(tǒng)方法輸出的是運維人員的所有輸入，組織為日志數(shù)據(jù)。而 Agith 的輸出的是變更影響面，如下圖所示：

圖1 變更影響面示例

橙色節(jié)點表示進程，紫色節(jié)點表示文件，藍色節(jié)點表示一個遠程節(jié)點。每種類型節(jié)點的都有對應的屬性信息展示在右側列表中。例如進程節(jié)點屬性信息有進程工作路徑、執(zhí)行命令名、PID 等。文件節(jié)點有 inode、文件路徑。遠程節(jié)點有 IP-Port 地址，交互信息等。節(jié)點之間的邊存儲了系統(tǒng)調用類型，例如進程節(jié)點與文件節(jié)點可調用類型有 read、write、unlink（刪除）。 圖1的變更中，運維人員登錄主機后執(zhí)行了一條命令 obs_cmd.sh 1818，隨即退出。這個操作反應在圖中是進程節(jié)點P1（bash）創(chuàng)建了進程節(jié)點P2（obs_cmd.sh 1818）。進程節(jié)點 P2 在執(zhí)行中又創(chuàng)建了一個 python 腳本（進程節(jié)點P3）與一個 shell 腳本（進程進程 P4）。進程節(jié)點 P3 創(chuàng)建了一個文件節(jié)點 F1。而進程節(jié)點 P4 修改了文件 F1，并且通過 curl 命令（進程節(jié)點 P5）訪問了一個遠程節(jié)點 N1 的 1818 端口。點擊藍色節(jié)點可以看到這次訪問的 URL 鏈接。 相比命令日志，Agith 更關注命令的行為。這種方法將無限的命令映射到有限的行為上，方便運維人員理解。只要有這張變更影響面拓撲圖，任何一個運維人員都可以理解此次變更的操作，不需要復雜的專家經(jīng)驗。

Agith架構

Agith 在設計中采用數(shù)據(jù)流與控制流分離的策略。eBPF 模塊、Consumer、Repository 和 Monitor 可以組成數(shù)據(jù)篩選-采集-整理-輸出的數(shù)據(jù)流（圖 2 中實線）?？刂屏鳎▓D 2 中虛線）則以 Controller 模塊為核心，其他模塊受 Controller 模塊的統(tǒng)一管理。啟動時 Controller 模塊檢測環(huán)境，分析配置文件，檢查啟動參數(shù)。然后依次啟動部署各個模塊。當程序結束時管理各個模塊完成清理任務后依次退出。

圖2Agith架構圖

# eBPF 模塊eBPF 模塊包含 eBPF Probes、Traces、Targets 三個部分。這個模塊承擔數(shù)據(jù)的篩選工作。篩選方法是一種基于動態(tài)目標的變更監(jiān)控技術。該技術首先建立了兩類 map。第一類是 Target map。Target map 保存了監(jiān)控目標的標識符。例如進程的 pid、文件的 inode、網(wǎng)絡的 IP。第二類是Trace map。Trace map 用于存儲探針獲取的數(shù)據(jù)。 eBPF Probe 是針對特定的系統(tǒng)調用編寫的探針程序。這些程序被觸發(fā)時，首先根據(jù) Target map 判斷系統(tǒng)調用是否與監(jiān)控目標相關。如果不相關直接返回。如果相關會收集數(shù)據(jù)寫入Trace map。同時 eBPF Probe 會修改 Target map。例如在創(chuàng)建進程的 clone 系統(tǒng)調用處掛載探針程序。當任何程序執(zhí)行 clone 系統(tǒng)調用，探針會被觸發(fā)。探針程序檢測進程 pid 是否在 Target map 中。如果不存在就返回繼續(xù)執(zhí)行 clone。如果存在，會將返回值即子程序的 pid 寫入 Trace map，然后將子程序的 pid添加到 Target map 中。這樣子程序也被納入監(jiān)控范圍內了。# Consumer 模塊Consumer 模塊承擔采集工作，即讀取并緩存 Trace map 的數(shù)據(jù)。這個過程涉及讀寫速率控制，數(shù)據(jù)異常處理，數(shù)據(jù)融合等。 Consumer 讀取的數(shù)據(jù)類似 strace 得到系統(tǒng)調用記錄。這些數(shù)據(jù)采用“主謂賓”的結構體存儲。例如pid:411962, syscall:read, ret: 18, time:974333207983984, ready:1, obj:{fd:3, i_ino:2505217}是一條監(jiān)控 read 系統(tǒng)調用得到的記錄?！爸髡Z”是 pid:411962，表示一個進程號為 411962 的進程?！爸^語”是 syscall:read，表示讀取操作?！百e語”是 obj:{fd:3, i_ino:2505217}表示是一個文件，文件句柄號是 3，inode 編碼是 2505217。除此之外還有這次系統(tǒng)調用的時間和返回值。這條記錄的含義是進程 411962 讀取了文件 2505217。這條信息非常簡陋。進程執(zhí)行的程序名是什么？讀取的文件名是什么？這些信息包含在之前的記錄中。例如進程名包含在在 exec 系統(tǒng)調用中，文件名包含在 openat 系統(tǒng)調用中。# Repository & MonitorRepository 承擔整理與輸出工作。它存儲 Consumer 讀取的記錄，將信息填充到變更影響面圖中。例如打開一個新文件，會創(chuàng)建一個文件節(jié)點，并在進程與文件之間連接一條邊。除此之外 Repository 負責向 Monitor 模塊傳遞信息。 Monitor 模塊負責告警。如果在采集數(shù)據(jù)的過程中發(fā)現(xiàn)高危操作，例如刪除重要的配置文件， Monitor 模塊會發(fā)送告警。Monitor 的數(shù)據(jù)來源于 Repository。因為只有 Repository 存儲的圖中才能掌握完整的上下文信息。僅僅依靠 Consumer 的記錄不足以判定是否是高危操作。

應用場景

Agith功能是觀測變更過程，最終得到的變更影響面可以應用在風險告警、根因定位、變更審計、依賴分析等。

風險告警可以直接使用 Agith。首先在配置文件中聲明含有風險的行為，例如修改某個文件，訪問某項服務，刪除進程等等。Agith 在整理過程中發(fā)現(xiàn)這類數(shù)據(jù)，會向配置文件中的郵箱發(fā)送告警信息。例如美聯(lián)航故障事件中刪除文件的行為，Agith 可以發(fā)現(xiàn)這種異常操作。目前郵件告警功能在開發(fā)中，敬請期待。

根因定位是變更影響面最重要的用途。相比命令日志，變更影響面數(shù)據(jù)含有更細粒度的行為數(shù)據(jù)，可以更容易地發(fā)現(xiàn)與故障相關的命令行為。

變更審計可以在變更后檢查是否有超出預期的行為。對于重要的變更操作，可以在灰度環(huán)境中先執(zhí)行一遍，獲取變更影響面。然后在目標環(huán)境中執(zhí)行，得到另一份變更影響面。將兩份數(shù)據(jù)比較，可以發(fā)現(xiàn)在變更操作中有沒有錯誤操作。

依賴分析是獲取一個服務在運行時依賴的各種本地資源與周邊服務。這個功能雖然與變更無關。但是只要在終端中啟動這個服務，Agith 就可以獲取該服務的所有行為，從而得到所依賴的各種資源，例如動態(tài)依賴庫，配置文件等。

路線圖

當前 Agith 的功能只能覆蓋進程、文件、網(wǎng)絡的一部分行為。但是黑屏變更過程中命令行為遠遠超過這部分。

表1 Agith開發(fā)計劃

表1是未來 Agith 計劃覆蓋的變更行為。變更行為的整理是一個復雜的過程。我們一開始采用的方案是自底向上。無論什么樣的上層服務，從OS的視角來看無非5類行為：進程，內存，文件，網(wǎng)絡，外設。只要對這5類行為監(jiān)控，就可以覆蓋所有的命令行為。但是實踐并非如此。

首先過度抽象將失去數(shù)據(jù)的價值。例如執(zhí)行 mysql、docker、kubernetes 的命令，都是向已有的服務進程發(fā)送命令，可以統(tǒng)一為進程交互行為。但是如果只有交互的進程名，根本不能從中判定風險。其次過度抽象意味著所有的底層行為都是需要記錄的，會產(chǎn)生巨大的數(shù)據(jù)冗余。例如一次進程啟動，會頻繁申請內存，記錄這些數(shù)據(jù)沒有意義。

由此我們認識到觀測這張網(wǎng)既不能太粗，也不能太細，應當結合運維需求靈活調整。所以我們采用了一種自頂向下的方法。首先收集 239萬條變更命令，逐條去分析變更命令，得出這條命令所產(chǎn)生的數(shù)據(jù)。然后根據(jù)數(shù)據(jù)的相似性合并。例如文件都會有文件名，容器類操作有容器 id 或者鏡像 id。合并過程中會舍棄兩者差別的數(shù)據(jù)項。如果這個數(shù)據(jù)項對于運維價值不大，就是可以舍棄的。如果這個數(shù)據(jù)對運維很重要，說明這個合并是錯誤的。在整理的過程中有太多收益與成本的博弈，相信未來還會不斷演進。我們最終梳理出需要監(jiān)控的行為如下圖。

圖3 運維變更行為