在這篇文章中，我們將介紹 below：一個用于現(xiàn)代 Linux 系統(tǒng)的 Apache 2.0 許可的資源監(jiān)視器。below 可以讓你重放以前記錄的數(shù)據(jù)。

背景

內(nèi)核的主要職責(zé)之一是調(diào)度對資源的訪問。有時這可能意味著分配物理內(nèi)存，使多個進程可以共享同一主機。其他時候，它可能意味著確保 CPU 時間的公平分配。在這些場景里，內(nèi)核提供了機制，而將策略留給了“別人”。

近來，這個“別人”通常是 systemd 或 dockerd 這樣的運行時。運行時接受來自調(diào)度器或最終用戶的輸入（類似于運行什么和如何運行）并在內(nèi)核上轉(zhuǎn)動正確的旋鈕和拉動正確的杠桿，從而使工作負(fù)載能夠好好工作。

在一個完美的世界里，故事就到此結(jié)束了。然而，現(xiàn)實情況是，資源管理是一個復(fù)雜的、相當(dāng)不透明的技術(shù)混合體，在幾十年里計算技術(shù)不斷發(fā)展。盡管其中一些技術(shù)有各種缺陷和死角，但最終的結(jié)果是，容器運作得比較好。

雖然用戶通常不需要關(guān)心這些細(xì)節(jié)，但對于基礎(chǔ)設(shè)施運營商來說，對他們的技術(shù)架構(gòu)擁有可見性是至關(guān)重要的。可見性和可調(diào)試性對于檢測和調(diào)查錯誤的配置、問題和系統(tǒng)性故障至關(guān)重要。

讓事情變得更加復(fù)雜的是，資源中斷往往難以重現(xiàn)。經(jīng)常需要花費數(shù)周時間等待一個問題重新出現(xiàn)，以便調(diào)查其根本原因。規(guī)模的擴大進一步加劇了這個問題：我們不能在每臺主機上運行一個自定義腳本，希望在錯誤再次發(fā)生時記錄下關(guān)鍵狀態(tài)的片段。因此，需要更復(fù)雜的工具。這就出現(xiàn)了 below。

動機

歷史上，F(xiàn)acebook 一直是 atop［1］ 的忠實用戶。atop 是一個用于 Linux 的性能監(jiān)視器，能夠報告所有進程的活動以及各種系統(tǒng)級活動。與 htop 等工具相比，atop 最引人注目的功能之一是能夠作為一個守護程序記錄歷史數(shù)據(jù)。

這聽起來是一個簡單的功能，但在實踐中，這使得調(diào)試無數(shù)的生產(chǎn)問題成為可能。有了足夠長的數(shù)據(jù)保留，就有可能在時間上回溯，查看在問題或故障發(fā)生之前、期間和之后的主機狀態(tài)。

不幸的是，隨著時間的推移，人們發(fā)現(xiàn)atop 有某些不足之處。首先，控制組［2］cgroup 已經(jīng)成為控制和監(jiān)視 Linux 機器上資源的實際方式。atop 仍然缺乏對這一基本構(gòu)建模塊的支持。

第二，atop 用自定義的 delta 壓縮方法在磁盤上存儲數(shù)據(jù)。這在正常情況下運行良好，但在沉重的資源壓力下，主機很可能會丟失數(shù)據(jù)點。由于使用了 delta 壓縮，在數(shù)據(jù)最重要的時間段內(nèi)，數(shù)據(jù)可能會大面積丟失。

第三，用戶體驗有一個陡峭的學(xué)習(xí)曲線。我們經(jīng)常聽到 atop 的資深用戶說，他們喜歡密集的布局和眾多的鍵盤綁定。然而，這也是一把雙刃劍。當(dāng)一個剛進入這個領(lǐng)域的人想要調(diào)試一個生產(chǎn)問題時，他們現(xiàn)在要同時解決兩個問題：手頭的問題和如何使用 atop。

below 是由 Facebook 的資源控制團隊為其設(shè)計和開發(fā)的，并得到了 atop 生產(chǎn)環(huán)境用戶的支持。顧名思義，資源控制團隊負(fù)責(zé)的是規(guī)模化的資源管理。該團隊由內(nèi)核開發(fā)人員、容器運行時開發(fā)人員和硬件人員組成。認(rèn)識到下一代系統(tǒng)監(jiān)控器的機會，我們在設(shè)計 below 時考慮到以下幾點：

易用性：below 必須既能為新用戶提供直觀的體驗，又能為日常用戶提供強大的功能。*有意義的統(tǒng)計數(shù)據(jù)：below 顯示準(zhǔn)確和有用的統(tǒng)計數(shù)據(jù)。即便可以，但我們盡量避免收集和傾倒統(tǒng)計數(shù)字。

靈活性：當(dāng)默認(rèn)設(shè)置不合適時，我們允許用戶自定義他們的體驗。例如包括可配置的鍵綁定、可配置的默認(rèn)視圖，以及腳本界面（默認(rèn)為終端用戶接口）。

安裝

安裝該軟件包：

# dnf install -y below

打開記錄守護進程：

# systemctl enable --now below

快速介紹

below 最常用的模式是重放模式。顧名思義，重放模式是重放以前記錄的數(shù)據(jù)。假設(shè)你已經(jīng)啟動了記錄守護程序，那么通過運行以下程序啟動一個會話：

$ below replay --time “5 minutes ago”

然后你會看到控制組視圖：

如果你不知道該怎么操作，或者忘記了一個鍵位，按 ？ 可以進入幫助菜單。

屏幕的最上方是狀態(tài)欄。狀態(tài)欄顯示關(guān)于當(dāng)前樣本的信息。你可以通過按 t 和 T 分別向前和向后移動樣本。中間的部分是系統(tǒng)概覽。系統(tǒng)概覽包含了關(guān)于整個系統(tǒng)的統(tǒng)計數(shù)據(jù)，一般來說，這些數(shù)據(jù)總是很有用的。第三部分也是最下面的部分是多用途視圖。上面的圖片顯示了控制組視圖。此外，還有進程和系統(tǒng)視圖，分別通過按 p 和s 來訪問。

按 ↑ 和 ↓ 來移動列表選擇。按回車鍵來折疊和展開控制組。假設(shè)你發(fā)現(xiàn)了一個感興趣的控制組，你想看看它里面有哪些進程在運行。要放大進程視圖，選擇控制組并按 z：

再按 z 返回到控制組視圖。這個視圖有時會有點長。如果你對你要找的東西有一個模糊的概念，你可以通過按 / 并輸入一個過濾器來過濾控制組名稱。

在這一點上，你可能已經(jīng)注意到了一個我們還沒有探索過的標(biāo)簽系統(tǒng)。要在標(biāo)簽中向前和向后循環(huán)，可以分別按 Tab 和 Shift + Tab。我們把這個問題留給讀者去做練習(xí)。

其他功能

在底層，below 有一個強大的設(shè)計和架構(gòu)。Facebook 正在不斷升級到更新的內(nèi)核，所以我們從不假設(shè)數(shù)據(jù)源是可用的。這種默契的假設(shè)使得內(nèi)核和 below版本之間能夠完全向前和向后兼容。此外，每個數(shù)據(jù)點都用 zstd 壓縮并完整地存儲。這解決了我們看到的 atop 在大規(guī)模時的 delta 壓縮問題。根據(jù)我們的測試，我們的每個樣本壓縮可以達(dá)到平均 5 倍的壓縮率。

below 也使用 ［eBPF］［8］ 來收集關(guān)于短暫進程（生存時間短于數(shù)據(jù)收集間隔的進程）的信息。相比之下，atop 使用 BSD 進程核算來實現(xiàn)這一功能，這是一個已知緩慢且容易發(fā)生優(yōu)先級轉(zhuǎn)換的內(nèi)核接口。

對于用戶來說，below 還支持實時模式和一個轉(zhuǎn)儲接口。實時模式將記錄守護程序和 TUI 會話合并到一個進程中。這對于瀏覽系統(tǒng)狀態(tài)是很方便的，不需要為數(shù)據(jù)存儲投入長期運行的守護程序或磁盤空間。轉(zhuǎn)儲接口是一個可編寫腳本的接口，用于所有的 below 數(shù)據(jù)存儲。轉(zhuǎn)儲既強大又靈活，詳細(xì)的數(shù)據(jù)以 CSV、JSON 和人類可讀格式提供。

總結(jié)

below 是一個 Apache 2.0 許可的開源項目，我們（below 的開發(fā)者）認(rèn)為它比資源監(jiān)控領(lǐng)域的現(xiàn)有工具具有引人注目的優(yōu)勢。我們已經(jīng)花了大量的精力來準(zhǔn)備 below，以提供開源使用，所以我們希望讀者和社區(qū)有機會嘗試 below，并報告錯誤和功能要求。

編輯：jq