題幹與適用場景
一個 Node.js API 在流量高峰時出現 P99 延遲尖峰，但資料庫與外部服務的延遲指標沒有同步升高。請設計能區分「事件迴圈被阻塞」與「下游變慢」的診斷方案。執行環境已升級到 Node.js 26.5.0；Node.js 文件為 monitorEventLoopDelay 增加 samplePerIteration 選項，可按每次事件迴圈迭代取樣，也保留按時間間隔取樣的模式。
題目要求說明取樣語義、奈秒單位、直方圖生命週期、閒置程序行為，以及如何避免把觀測指標誤讀成使用者請求延遲。
面試官考察點
面試官關注候選人能否先定義 loop delay 測量的對象，再選取取樣模式；能否說明直方圖必須啟用、讀取並停用，統計視窗必須與請求指標對齊；能否識別取樣模式切換會改變資料分布，不能直接比較兩個視窗的 P99。
強回答還會把 loop delay 與 CPU、GC、請求佇列、下游延遲和執行個體負載關聯起來，提出低成本常態設定、故障時短視窗加密觀測，以及回滾和對照驗證。
回答前需要澄清的問題
- 目標是定位本地阻塞，還是直接解釋端到端 P99？
- 服務是常駐程序、無伺服器執行個體，還是短時 CLI？
- 診斷視窗、取樣解析度和可接受的監控成本是多少？
- Node.js 版本是否全部為 26.5.0，是否存在混合版本執行個體？
- 是否同時有 CPU、GC、請求佇列、下游延遲與事件迴圈利用率指標？
30 秒回答框架
「我先把事件迴圈延遲定義為迴圈迭代沒有及時推進的時間，不把它當成請求延遲。Node.js 的直方圖資料以奈秒回傳；常態可以用時間間隔取樣，故障視窗再評估按每次迭代取樣。兩種模式的樣本生成機制不同，不能直接比較百分位。我的方案是固定視窗啟停直方圖，記錄 P50、P99、最大值和樣本數，同時關聯 CPU、GC、下游與請求 P99；若只有 loop delay 升高，再抓取阻塞呼叫棧和同步 CPU 路徑。」
分步驟深入解答
先明確指標邊界
monitorEventLoopDelay 回傳延遲直方圖，單位是奈秒。它描述取樣點觀察到的事件迴圈推進延遲，不包含網路請求完整生命週期，也不能單獨證明某個請求被誰阻塞。若要解釋使用者 P99，必須把此指標與請求開始、佇列、業務處理和下游時間放在同一時間視窗。
選擇兩種取樣模式
預設模式按 resolution 的時間間隔觸發取樣，適合常態低成本監控。Node.js 26.5.0 新增 samplePerIteration: true 後，每次事件迴圈迭代取樣；文件同時說明該模式在程序閒置時不會強迫事件迴圈產生額外迭代，也不會讓迴圈保持存活。
按迭代取樣更適合需要觀察短暫阻塞、且執行個體有持續事件迴圈活動的診斷視窗。它會產生不同的樣本數量和分布；不能用一種模式的 P99 直接與另一種模式的 P99 做回歸結論。
管理直方圖生命週期
把直方圖視為視窗級狀態，而非全域永久累加器。開始診斷時建立並 enable()，視窗結束時讀取 percentile(99)、max、count 等值，再 disable() 並丟棄或匯出結果。所有指標名稱應帶上取樣模式、解析度、Node 版本和視窗起止時間。
import { monitorEventLoopDelay } from 'node:perf_hooks';
const histogram = monitorEventLoopDelay({
resolution: 20,
samplePerIteration: true,
});
histogram.enable();
setTimeout(() => {
const snapshot = {
p99Ns: histogram.percentile(99),
maxNs: histogram.max,
samples: histogram.count,
};
histogram.disable();
console.log(snapshot);
}, 10_000);把資料換算成可讀單位
直方圖回傳奈秒。展示為毫秒時除以 1000000，並保留原始奈秒值供精確比較。不要把最大值直接當成 SLA；單一異常樣本可能來自暫停、程序凍結或收集邊界。優先觀察固定視窗內的 P99、P999、最大值、樣本數和時間序列。
關聯阻塞根因
若 loop delay 與 CPU 同時升高，檢查同步 JSON 序列化、正規表示式回溯、壓縮、加密和大陣列遍歷；若與 GC 同時升高，查看堆積成長和配置速率；若 loop delay 高但 CPU 低，檢查同步系統呼叫、鎖等待或主機排程。若只有下游延遲和請求 P99 升高，本地迴圈指標不能取代下游追蹤。
處理混合版本與取樣成本
啟動時記錄執行時版本，並按版本拆分指標。26.5.0 之前的執行個體沒有 samplePerIteration 選項，不能靜默把它當成可用。常態監控可使用較大 resolution，故障時透過開關啟用短期按迭代取樣；持續高頻取樣會增加觀測成本，也會讓不同版本的資料難以橫向比較。
設計驗證與回滾
用受控的同步 CPU 阻塞、計時器阻塞、GC 壓力和閒置程序分別製造樣本，驗證四件事：單位換算正確、視窗啟停不洩漏、閒置時不會被人為喚醒、故障時指標能與請求 P99 對齊。若取樣成本或資料雜訊影響服務，關閉診斷開關並回到預設間隔模式；保留帶版本和模式標籤的對照資料。
高品質示範回答
「我會把 monitorEventLoopDelay 當成本地排程健康指標，而不是請求延遲本身。常態用 resolution 做低成本時間取樣；Node.js 26.5.0 的按迭代取樣只在需要捕捉短阻塞時短期開啟，並記錄模式、版本、視窗和樣本數。每個視窗建立、啟用、讀取、停用一個直方圖，奈秒統一換算成毫秒。分析時把 P99 與 CPU、GC、下游延遲和請求 P99 對齊；只有本地指標同步升高，才把重點轉向同步 CPU、系統呼叫或排程問題。兩種取樣模式的分布不能直接比較，混合版本也要分組。」
常見錯誤
- 把 loop delay 當成請求延遲 → 指標無法定位下游或佇列時間 → 明確分層並與請求追蹤對齊。
- 忘記奈秒單位 → 報表放大或縮小百萬倍 → 統一在邊界轉換並保留原始值。
- 直接比較兩種模式的 P99 → 樣本生成機制不同 → 按模式分組建立各自基線。
- 永久啟用按迭代取樣 → 監控成本和雜訊持續存在 → 常態低頻，故障短窗加密。
- 忽略閒置行為 → 誤以為執行個體一直被取樣喚醒 → 用閒置程序驗證不會強迫新迭代。
- 跨 Node 版本混算 → 舊執行個體沒有同一選項 → 啟動時打標籤並分版本聚合。
追問及應對
追問一：按迭代取樣的 P99 比預設模式高，代表效能變差嗎？
不能直接這樣推斷。兩種模式觀察點不同，樣本量和分布都會改變。先在同一負載、同一版本、同一視窗分別收集，再比較各自模式內的基線；若要評估取樣成本，還需比較 CPU、吞吐和請求 P99。
追問二：為什麼 loop delay 很高但 CPU 不高？
可能是同步系統呼叫、鎖等待、主機排程或程序暫停。應結合執行時診斷、系統指標和呼叫棧，而不是把低 CPU 直接解釋為「沒有阻塞」。
追問三：無伺服器函式適合長期啟用這個直方圖嗎？
通常不適合把跨請求的長期視窗當作主要訊號，因為執行個體生命週期短且視窗可能被截斷。可在診斷版本中按單次呼叫或短批次取樣，並將冷啟動、執行時間和下游追蹤一起記錄。
追問四：如何證明取樣沒有改變閒置執行個體的行為？
啟動一個沒有計時器和請求的程序，分別啟用兩種模式，觀察程序是否提早退出、事件迴圈迭代計數和 CPU；按迭代模式應不會為了取樣強迫額外迭代，也不會保持迴圈存活。