使用 ftrace 追蹤核心函式延遲

當一台 Linux 系統讓人感覺「變慢了」，但常見監控圖表看起來卻並無異常時，真正缺失的訊號往往埋藏在使用者態之下。這時，ftrace 就顯得格外有用。對於負責伺服器租用基礎設施、底層平台，或對延遲高度敏感服務的工程師而言，ftrace 能揭示核心究竟如何走過一條程式碼路徑、時間消耗在何處，以及延遲究竟來自排程、中斷、檔案操作，還是網路處理。與其根據表面症狀猜測，不如貼近底層去觀察執行流程，並對機器實際在做什麼建立一個精確的判斷。

為什麼 ftrace 對核心延遲分析如此重要

ftrace 內建於 Linux 核心追蹤體系中，專門用於透過 tracefs 直接觀察核心行為。核心文件將它描述為一個框架，而非單一追蹤器；它支援函式追蹤、函式圖追蹤、事件追蹤，以及面向延遲分析的追蹤模式。現代系統通常會在 /sys/kernel/tracing 下暴露控制檔案，而較舊的布局則可能仍透過除錯路徑提供相容支援。實際意義很直接：如果你需要檢查核心端的延遲問題，ftrace 往往已經存在於許多伺服器環境中。

它特別吸引人的一點，在於能夠聚焦於呼叫路徑，而不是停留在寬泛的平均值層面。通用監控工具可以告訴你回應時間不穩定，但 ftrace 能進一步展示：某個請求進入了一個核心路徑，呼叫了特定函式，繼續深入到更深的分支，最終返回時卻比預期更慢。對於那些間歇性出現、範圍很窄、又難以透過粗粒度效能分析定位的問題，這種可見性極具價值。

• 它可以在函式進入時追蹤核心函式，而在圖模式下還能記錄函式退出。
• 它有助於定位延遲從哪裡開始，而不只是延遲最終在哪裡被觀察到。
• 它尤其擅長除錯詭異的抖動問題，而不僅僅是明顯的吞吐崩塌。
• 它可以透過篩選目標函式來縮小範圍，從而讓追蹤結果保持可讀。

哪些伺服器場景最適合使用 ftrace

核心追蹤並不是儀表板一變紅就應該立刻啟用的工具。它最有價值的場景，是系統出現了使用者真實可感知、但對常規工具來說又相當模糊的異常。最常見的模式是：應用程式日誌顯示存在卡頓，可 CPU 使用率、記憶體壓力和儲存指標卻無法充分解釋問題。

1. 請求路徑抖動：並發上來後延遲突增，但工作行程並沒有表現出穩定的使用者態熱點。
2. I/O 卡頓：讀寫路徑偶發性停頓，足以拉高尾端延遲，而佇列視圖看起來卻並不誇張。
3. 網路處理延遲：資料封包已經到達，但在協定堆疊中的處理似乎忽快忽慢。
4. 排程異常：執行緒已經被喚醒，卻沒有在預期時間內真正執行。
5. 中斷相關干擾：系統出現成簇的時間雜訊，暗示中斷被關閉過久或處理被延後。

在這些場景中，ftrace 並不是為了取代常規可觀測性工具。它更像是在你已經框定症狀之後，進一步深入核心路徑、查明問題是如何傳遞和放大的關鍵步驟。

ftrace 在底層是如何運作的

函式追蹤器會記錄核心函式的進入，而 function_graph 追蹤器會同時記錄函式進入與返回，因此能夠估算執行時長，並繪製出類似結構化程式碼的呼叫圖。根據核心文件，這種圖模式在排查異常延遲，或理解某個函式實際走了哪條路徑時尤其有價值。這也是為什麼大多數延遲問題分析會優先選擇圖模式，而不是普通函式模式。

追蹤過程透過 tracefs 中的一組檔案進行控制。你可以切換活動追蹤器、開啟或關閉採集、選擇性篩選目標函式、觸發工作負載，然後檢視產生的輸出結果。由於這一控制介面基於檔案，因此它非常容易腳本化，也很適合集成進故障處理流程。核心文件還指出，追蹤資料會緩存在記憶體頁中，這也正是為什麼應當盡量縮小範圍並縮短採集視窗。

開始追蹤前如何準備環境

在真正採集資料之前，先確認追蹤能力可用，並確認系統使用的是正確檔案系統路徑。目前核心文件將 /sys/kernel/tracing 指定為標準 tracefs 位置，而舊版相容路徑則可能仍暴露在除錯目錄下。如果 tracefs 尚未掛載，也可以手動掛載。這一點很重要，因為許多舊教學仍預設只使用傳統路徑。

• 使用具備足夠權限的 shell。
• 檢查 tracefs 是否存在並已掛載。
• 查看 available_tracers，確認圖追蹤支援是否可用。
• 規劃一個盡可能短的問題重現視窗。
• 決定是否需要函式篩選，或者按 PID 篩選。

在接近生產的機器上，謹慎往往比炫技更重要。長時間追蹤所有內容，反而可能扭曲你真正想測量的時序。一次短小、定向的採集，通常比一份巨大卻難以推理的追蹤結果更有資訊量。

追蹤核心函式延遲的實用流程

最乾淨的方法，是把追蹤當作一次受控實驗。先清空環境，定義範圍，重現一次問題，立刻停止，然後帶著一個明確的問題去閱讀追蹤結果。

1. 重設狀態：清除舊的追蹤輸出，並確保追蹤處於關閉狀態。
2. 選擇圖模式：將 function_graph 寫入 current_tracer。
3. 限制目標範圍：使用 set_ftrace_filter，只包含相關函式或路徑。
4. 按行程進一步縮小：如果問題與某個特定負載有關，可使用 PID 篩選。
5. 開啟追蹤：只有在準備好觸發問題時才打開採集。
6. 重現一次問題：使用最短的工作負載觸發該異常。
7. 停止追蹤：立刻關閉採集，並讀取 trace 檔案。

這種流程與官方追蹤模型高度契合。核心透過專用檔案分別提供活動追蹤器、函式篩選器、追蹤緩衝區和追蹤開關。文件明確指出，篩選檔案中列出的函式會限制圖追蹤器所跟隨的範圍，並包含這些函式所呼叫的下層函式，這正是圖模式在真實除錯中仍然可控、可讀的關鍵原因。

一個很「極客」但也非常有用的習慣，是在採集之前先建立假設。比如：「我懷疑延遲發生在喚醒之後但執行緒尚未真正執行的階段」，或者「我懷疑時間消耗在檔案路徑內部」。帶著這種框架去採集，你就不是在機械地記錄一張呼叫圖，而是在驗證一個解釋。

如何讀 trace，而不是被 trace 誤導

原始輸出一開始可能會顯得頗為嚇人，因為它同時反映了巢狀層次、時間資訊和執行上下文。關鍵並不是盯著整份輸出發呆，而是從那些明顯緩慢的返回區塊開始，再逐步向外看。在圖模式中，一個父函式耗時很長，並不總意味著父函式本身很慢。時間有可能消耗在其子函式中，也可能來自排程中斷，或者來自呼叫框架保持開啟時發生的等待。

• 優先尋找那些位於你懷疑路徑上的異常長返回。
• 比較同一父節點下的兄弟呼叫，看分支在哪裡開始出現差異。
• 觀察延遲是否總是重複出現在同一函式中，還是在不同層之間遷移。
• 如果啟用了更多上下文資訊，可結合喚醒、中斷或儲存事件一起判斷。

核心文件還描述了若干面向延遲分析的追蹤器與格式選項，可向追蹤結果中加入更多上下文字段，幫助理解排程和中斷狀態。當普通函式追蹤過於嘈雜時，適度引入基於事件的上下文，往往能解釋某個長時間區間為何出現，而無需追蹤系統中的每一個函式。

函式追蹤器與函式圖追蹤器的差異

兩者都很有用，但回答的問題並不相同。基礎函式追蹤器更適合確認某條路徑是否被進入，而圖追蹤器更適合回答「這條路徑停留了多久，以及巢狀呼叫是如何展開的」。官方文件指出，圖追蹤會記錄進入和退出，目的是測量執行時間並產生可靠的呼叫圖。在延遲分析中，這通常正是最有價值的能力。

• 使用函式模式，當你的首要目標是發現呼叫路徑。
• 使用圖模式，當你的目標是分析執行時長和結構。
• 使用事件上下文，當僅憑時間資訊不足以解釋停頓原因。

真實除錯中的常見分析模式

在分析儲存相關延遲時，一個實用模式是圍繞檔案層或區塊層路徑設定篩選，然後觀察呼叫圖在哪個分支開始「張開」。如果某個分支反覆拉長，而其他分支返回很快，那麼你就找到了值得進一步深挖的候選層。類似的方法同樣適用於網路問題：從接收或傳送處理附近開始，觀察時間究竟是在協定堆疊處理、佇列移動，還是在線程喚醒行為中被拉長。

對於偏排程類的問題，僅靠圖輸出往往還不夠。這時，延遲類追蹤器或排程相關事件會更有價值。核心追蹤文件包含專門面向喚醒和中斷分析的延遲模式，它們可以幫助你判斷：某個任務究竟是已經準備好卻沒能及時執行，還是時序被中斷狀態擾亂了。

追蹤伺服器時最常見的錯誤

大多數糟糕的追蹤結果，失敗原因更多在人，而不在技術本身。要麼範圍太寬，要麼實驗時間太長，要麼閱讀者把表象誤認為根因。好的追蹤一定是有選擇性的。

1. 追蹤整個核心：這會帶來大量雜訊，並增加額外開銷。
2. 採集時間過長：巨大的緩衝區只會讓解釋更困難，而不是更簡單。
3. 篩選了錯誤符號：命名、內聯最佳化或核心差異，都可能讓你以為會出現的路徑消失。
4. 忽略上下文：一個耗時長的函式，可能只是反映其下層發生了等待，而非自身計算過慢。
5. 缺乏重現紀律：如果每次實驗工作負載都不同，那麼比較就失去了意義。

文件中還有一個細微但重要的提醒：追蹤功能與具體檔案在不同核心能力和設定下可能有所差異。因此，如果某篇教學與你的系統不完全一致，不要強行照搬命令，而應先檢查自己機器上的 tracefs 樹實際暴露了哪些介面。

ftrace 在其他核心可觀測性工具中的位置

當你需要以較低門檻獲得結構化的核心路徑可見性時，ftrace 的優勢非常明顯。採樣型工具更擅長發現熱點，可程式化追蹤框架則更適合需要自訂探針或長期執行觀測邏輯的場景。但當問題是「當前到底是哪條核心路徑慢了，以及它為什麼會這樣」時，ftrace 依然是最鋒利的工具之一，因為它能直達控制流程本身。

對於伺服器租用與伺服器託管維運來說，這種差異尤其重要。基礎設施工 程師並不總需要在每一台節點上部署一整套永久性的追蹤平台。他們真正需要的，是在故障發生時，能夠快速從症狀走到核心路徑、保留推理嚴謹性，並且在高壓環境下依然容易理解的工具。

低風險追蹤的最佳實務

• 優先使用狹窄的函式篩選，而不是全域採集。
• 只追蹤到足以重現一次問題為止。
• 立即保存追蹤結果，並記錄觸發該問題的工作負載。
• 將追蹤發現與排程、I/O 和網路側的其他觀測結合起來分析。
• 每當假設變化時，重新做一次實驗，而不是永遠反覆解讀同一份巨大追蹤。

把 ftrace 當作手術刀的工程師，通常會比把它當作大網亂撒的人得到更好的結果。精確，既能讓系統保持可讀，也能讓你自己的推理保持誠實。

結論

當伺服器行為明顯異常，但宏觀指標卻模糊不清時，ftrace 提供了一種直接檢查核心函式延遲的方法。透過謹慎使用 tracefs、優先選擇 function_graph 進行時長分析，並將採集範圍限制在可疑路徑上，你就能夠從「猜測」走向「證據」。對於負責伺服器租用效能、嘈雜多租戶環境，或延遲敏感運算節點的團隊來說，這種追蹤方式的價值，不在於收集更多資料，而在於在恰當時機收集到正確的核心故事。這也正是為什麼 ftrace 依然是嚴肅 Linux 除錯中如此實用的工具。