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

背景

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

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

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

Agith與變更影響面

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

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

圖1 變更影響面示例

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

Agith架構

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

圖2Agith架構圖

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

應用場景

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

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

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

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

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

路線圖

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

表1 Agith開發計劃

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

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

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

圖3 運維變更行為