Vercel Tracing 正式開放，新專案從此預設收集並照常計費

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Vercel 在 2026 年 11 月 6 日把 Tracing 從測試推到正式開放，所有方案都能用。公告裡最顯眼的是新的 Traces 搜尋頁，但真正會改變團隊日常的是另一件事：符合條件的新 Next.js 專案，第一次成功建置之後，Vercel 會自動掛上一條「所有環境、100% 請求」的取樣規則，並照一般追蹤用量計費。測試期間的設計剛好相反，官方當時的說法是「不加規則就什麼都不收，你只為自己選擇追蹤的流量付費」；正式版把這個預設值翻了過來，觀測從主動開啟的功能，變成新專案內建的成本項。

這翻轉決定了兩種讀者要問的問題。剛開新專案的團隊該問的是「我要收多少、健康檢查要不要排除、每個月大概幾個 span 單位」；既有專案行為不變，不會被自動開啟，想用就自己加規則。以下對照正式開放公告與官方設定文件，把資格條件、計價單位、取樣規則順序與查不到資料的原因整理成可以直接動手的內容。

先把時間軸定位：2026 年 8 月 21 日的 always-on tracing 讓追蹤進入測試，靠取樣規則控制收集；9 月 29 日加入命令列搜尋；11 月 6 日正式開放。三年前要重現問題才能除錯，現在是平台先收好證據，問題發生後回頭查。

Pin

測試到正式版，變的是入口與保留天數

測試期間要從日誌頁（Logs）逐筆請求打開追蹤，正式版新增 Traces 頁，可以就單一專案或整個團隊搜尋所有追蹤與 span。列表有兩種視角：Spans 列出個別步驟，適合找特定的對外呼叫；Traces 一列代表一整筆請求，適合先縮小哪批請求有問題。搜尋用 KQL（Kibana Query Language），條件以欄位開頭，像 trace.id、http.route 或 span.name 都能當欄位；span.name:db* AND span.duration > 500 就是找名稱以 db 開頭、期間超過 500 毫秒的步驟。要注意 Traces 列表的條件比對的是整條追蹤的根步驟，問題在更深層的子步驟時要切到 Spans 視角，同一句查詢在兩個列表的涵蓋範圍不同。

span 是這套功能的計量基礎：一筆請求走過的每個步驟各是一個 span，帶著名稱、起訖時間與期間。以文件給的例子，一筆請求是「抵達 CDN、中介層執行、函式處理、資料庫查詢、回傳結果」的序列，每一步各成一個 span。Vercel 自動收集的是基礎設施（路由、中介層、快取、函式生命週期）與對外的 HTTP 呼叫；資料庫查詢或框架內部的細節，要有 OpenTelemetry 設定才會出現。所以時間軸上只看到一條外部請求，不代表那個服務只做了一件事，看得到的是目前有被記錄的範圍。

讀時間軸時還要注意步驟的重疊。兩個對外呼叫若同時進行，把各自的期間直接相加，會超過使用者實際等待的時間。追蹤適合回答「時間花在哪一段」，回答不了「答案對不對」；生成式應用的回應品質與執行時間是兩件事，要分開評。

打開單筆追蹤後有三種看法，用途不同：Timeline 把所有 span 放在同一條水平時間軸上，適合看哪些步驟重疊、等待集中在哪；Tree 用縮排階層呈現誰呼叫誰，適合追某個 route handler 發出一串下游呼叫的結構；Waterfall 把階層與期間條放在時間軸上，結構與時間一起讀。列表頁另有 Live 模式，即時串流新收進來的追蹤，適合盯著剛上線的變更；它顯示的仍是進入收集範圍的紀錄，不能讓沒被取樣的請求事後現身。

保留天數也延長了。測試期間追蹤跟著執行日誌的保留期走，Hobby 一小時、Pro 一天、Enterprise 三天；正式版改成 Hobby 三天、Pro 十四天、Enterprise 十四天。定價則沿用測試期間的費率，沒有因為轉正調整。

哪些專案會被自動開啟，哪些不會

預設追蹤的資格條件比「新專案」三個字窄得多，官方文件列出四個條件要全部成立：專案在 2026 年 11 月 5 日或之後建立、部署在 Vercel 上以 Next.js 16.5 以上建置、部署包含至少一個 Node.js 函式、專案未曾關閉追蹤。用 vercel deploy –prebuilt 事先建好再上傳的部署不算，純靜態輸出與只有 Edge runtime 的應用也不算。換句話說，既有專案升級框架不會自動被開啟，這套預設只影響門檻日之後建立的新專案。

符合資格的專案在首次成功建置後，Vercel 會做兩件事：加上那條 100% 取樣規則（可以像其他規則一樣修改或刪除），以及在每次建置時注入 @vercel/otel，讓追蹤包含 Next.js 框架步驟。注入不會改變專案的 package.json 或鎖定檔，span 以專案名稱當服務名稱，想換名字可以設 OTEL_SERVICE_NAME 環境變數。但有三種情況 Vercel 會略過注入：專案自己有 instrumentation.ts、已使用 @opentelemetry/api 1.10 以上（直接或透過其他套件）、或在 Next.js 設定裡開了 instrumentationInject。這時基礎設施步驟照樣收集，框架內部的步驟要自己設定才會有。

順帶畫清一條界線：這裡講的追蹤收的是真實流量，與 Session Tracing 不同。Session Tracing 用 Vercel 工具列只錄你自己瀏覽器的工作階段，適合互動式地點查某個操作流程；正式版追蹤收的是所有使用者的正式與預覽流量。兩者是互補關係，不是新舊版。

span 單位怎麼算，帳單怎麼估

計價單位是 span unit，計算取樣後實際被索引的步驟。一個不超過 2 KiB（2048 bytes）的步驟算一個單位，更大的按每 2 KiB 進位：3 KiB 算兩個單位、5 KiB 算三個。費率依方案：Hobby 每月包含一百萬個單位，Pro 每一百萬單位 0.50 美元，Enterprise 從同樣的每百萬 0.50 美元起。官方文件明說預設追蹤照一般追蹤用量計費，那條 100% 規則收到的每個索引步驟都用至少一個單位。

官方給的換算例子可以直接套：如果每筆請求產生 20 個索引步驟，收集 100,000 筆請求至少用掉兩百萬個單位，在 Pro 費率下大約一美元。這個數字只能當量級參考：步驟一多或內容變大，單位數就往上跳，兩百萬單位對 Pro 是一美元，對還在免費額度內的 Hobby 卻已經是兩個月的量。反過來看，新專案預設全收，實際流量高時用量會跟著線性成長，值得在第一次看帳單前先把取樣比例調低，或把不需要的路徑排除。

Hobby 的額度用完後果要特別注意：該團隊所有專案的追蹤會一起暫停，而且新的用量期間開始後不會自己恢復，需要有權限更新團隊每個專案的人到設定頁按 Resume Tracing。想立刻恢復就得升級到 Pro。同樣一百萬單位，安靜的 side project 與有真實流量的新專案是完全不同的消耗速度。

Pin

取樣規則的順序，比百分比更容易出錯

每個專案最多十條取樣規則，Vercel 套用第一條符合請求的規則，新規則一律加到列表最底下，而且目前不能直接調整順序。0% 規則的運作方式值得單獨理解：它一樣會「符合」請求，只是符合之後什麼都不收，所以它既能用來排除路徑，也會把請求從後面更寬的規則手上搶走。想排除 /health 這類健康檢查路徑，0% 規則必須排在較寬的規則前面，否則請求先被上面的規則攔走，下面的排除永遠不會生效。官方給的做法是把順序一次改對：先刪掉較寬的規則，加上該路徑的 0% 規則，再把寬規則加回來，然後一次儲存。

命令列與儀表板的能力也不對稱。vercel traces config 可以管理規則，但只接受 1% 到 100% 的比例，0% 的排除規則只能從儀表板加。規則本身有三個欄位：環境（全部、正式或預覽）、比例、以及可選的路徑前綴。要完全關閉追蹤，就是把規則全部刪掉再儲存，收費隨即停止；若是預設追蹤的專案，下一個部署起 Vercel 也不再注入 @vercel/otel，而且不會自己重新開啟。

Pin

取樣的判定單位是整條追蹤，不是個別步驟。抽中的請求保留全部步驟，沒抽中的一個都不留，所以不會出現半條追蹤。還有一個容易誤讀的對照：規則清空時，追蹤什麼都不收，但 Trace Drains（把追蹤轉送到外部觀測服務的功能）在沒有規則時卻是全部轉送。兩個空列表的意義相反，搬遷或清理設定時不能套同一套直覺。

儀表板與命令列共用同一句查詢

正式版把儀表板與 CLI 的搜尋語法統一：在 Traces 頁調好的 KQL 查詢，原封不動丟給 vercel traces search –query 就會得到同一批結果。搜尋範圍預設是整個團隊，加 –project 可以限定單一專案；命令列搜尋預設最多回傳最近一小時的 100 個 span、新的在前，可以用 –since 與 –until 收窄時間，也能按環境、服務、span 名稱、狀態或識別碼過濾。查到請求識別碼後用 vercel traces inspect 看單筆追蹤的完整時間軸。命令列搜尋在 9 月 29 日就上線了，當時官方公告的措辭直接寫「你與你的 coding agents 現在可以從終端機搜尋專案的 span」，也就是說，把查詢交給命令列裡的 AI 代理一起除錯，是 Vercel 明說的設計對象，正式版只是把這條路與儀表板對齊。

這裡的界線值得畫清楚：平台提供的是入口與同一份執行證據，讓人與代理討論時可以直接指到某筆請求、某個步驟、某段時間，把「網站最近很慢」這類模糊描述換成可以指認的證據。但官方沒有承諾代理會自動找出或修好效能問題，查詢結果指向哪段程式、要不要改，判斷仍在人這端。把它當 AI 功能來看會失焦：這次交付的是一份可以交接的除錯證據層，人和代理都指向同一份。

Vercel 近期對代理生態的佈局可以對照著看：AI Gateway 的虛擬模型把模型選擇搬進平台設定層，Daemons 的服務綁定與存活檢查補上背景工作，市集淘汰長效金鑰的時程把代理的驗證推向短效身分，加上這次追蹤入口，平台正在把代理工作需要的觀測與治理基礎一件件接上。

查不到資料時，先分三種原因

看到時間軸上少了某段，別急著下結論，先分辨三種可能。可能它從未被收集：資料庫或框架內部沒有 OpenTelemetry 設定就不會有步驟，Edge runtime 函式裡的自訂 span 無論怎麼收集都不會出現在追蹤中。也可能它是被取樣丟掉：沒抽中的請求整條不存在，事後也補不回來。還有可能它超過了大小限制：每筆追蹤的壓縮資料上限 10 MB，單一 span 壓縮後超過 1 MB 時，Vercel 會視需要從最大的屬性開始截短，被截的屬性各加一個 truncated 布林標記，截完仍超過就整個丟棄。

另外有個整合上的坑：Sentry SDK v8 以上預設自己建立 OpenTelemetry，會與 Vercel 的設定衝突、破壞追蹤的傳遞。兩者並用時要照 Sentry 的自訂設定文件調整，不然追蹤可能默默地送不到下游。

新專案先看那條 100% 規則，Hobby 團隊記得額度共用

新專案的負責人可以先到 Settings → Tracing 看那條 100% 規則：流量低的專案留著無妨，有健康檢查路徑就把 0% 排除的順序排對，預期流量高的先用官方例子（每請求步驟數乘以請求量）估一下單位量再決定比例。既有專案什麼都不會自動變，想用就加一條規則。Hobby 團隊要記得額度是全團隊共用，用盡時所有專案一起停。

還不確定的部分：Enterprise 起價之上的實際議價未揭露；AI 代理實際用這套入口能做到什麼程度，官方只給了入口沒給成效數字。定價、保留天數與預設資格都屬於會調整的內容，行動前以官方文件現況為準，建議兩週內回查一次，特別是 2026 年 11 月 5 日這個門檻會隨時間讓「新專案」的覆蓋範圍越來越大。