持續剖析（continuous profiling）

傳統剖析是你按需做一次的事：你懷疑有問題，掛上剖析器，收集一份剖析，看一看，停止。但你最想搞懂的那個慢請求，往往發生在上週二凌晨三點、一個你無法重現的負載下。持續剖析用「一直」剖析來回答這個困境——在正式環境裡、在每一台機器上，維持一個低負擔、常開的取樣剖析持續運行，於是每當你需要問「那起事件期間 CPU 把時間花在哪裡？」時，資料早已存在。

具體來說，持續剖析倚賴取樣式剖析器（而非插樁），因為取樣的負擔很小且大致固定，這正是讓「常開」負擔得起的原因。每台主機上的一個代理程式週期性地（譬如每秒數十次）擷取整台機器上運行中執行緒的呼叫堆疊——常用 PMU 或計時器，並越來越常用 eBPF 來便宜地、一次橫跨所有行程地做這件事。這些樣本被持續送往一個中央儲存，在那裡可以彙總，並渲染成依服務、主機、版本或時間窗切分的火焰圖。結果是你能捲回任何一個過去的分鐘，看每顆 CPU 當時在做什麼，還能比對兩個時間窗（差分火焰圖），確切看出某次部署後什麼變貴了。on-CPU 視角顯示計算花在哪裡；一個搭配的 off-CPU 視角（由阻塞時間樣本建成）顯示執行緒在哪裡等待。

它之所以重要，是因為它把剖析從一個被動、先重現再說的活動，轉成一份隨時可用的紀錄，這正是把可觀測性套用在效能上的精髓：答案在你知道問題之前就被捕捉了。它也揭露機隊規模的浪費——一個函式在數千台機器上各燒掉 3% 的 CPU，是一筆任何單次剖析都不會凸顯的龐大帳單。誠實的提醒：它仍然是「取樣」，所以給的是統計比例、不是精確的每呼叫計時，而且可能漏掉非常罕見或非常短的事件；為整個機隊儲存持續剖析本身就是儲存與頻寬上的實質成本；而那個低負擔是「低」、不是零——剖析這個動作本身會稍微擾動系統，這正是下一個詞要正面面對的觀測者效應。