針對(duì) openEuler 運(yùn)維變更過程觀測困難的問題，華為 2012服務(wù)實(shí)驗(yàn)室 OSMind 團(tuán)隊(duì)開發(fā)了基于 eBPF 的變更觀測工具—— Agith。Agith 可以識(shí)別與變更相關(guān)的行為，并將變更過程表示為一種拓?fù)浣Y(jié)構(gòu)——變更影響面。通過變更影響面可以完成變更告警、審計(jì)、根因定位、依賴分析等功能。

背景

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

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

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

Agith與變更影響面

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

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

圖1 變更影響面示例

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

Agith架構(gòu)

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

圖2Agith架構(gòu)圖

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

應(yīng)用場景

Agith功能是觀測變更過程，最終得到的變更影響面可以應(yīng)用在風(fēng)險(xiǎn)告警、根因定位、變更審計(jì)、依賴分析等。

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

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

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

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

路線圖

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

表1 Agith開發(fā)計(jì)劃

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

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

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

圖3 運(yùn)維變更行為