四月中旬的一個周二早晨，我打開Rembrandt的定時任務(wù)摘要時，屏幕一片紅色。前一天剛給四個關(guān)鍵任務(wù)套上Sentry.withMonitor，就為了拿到清晰的SLO指標(biāo)，結(jié)果等來的是41次sync-formidable超時、9次check-replies失敗，外加一個API 5xx告警。我坐下了。

Niran，那個周末去道場、工作日穿深色連帽衫的二十歲實(shí)習(xí)生，已經(jīng)坐在那兒了。他瞟了眼我的屏幕，又看了眼Supabase Studio，眼睛沒抬就說："昨天的線索進(jìn)數(shù)據(jù)庫了。"確實(shí)都在。contacts表有插入記錄，lead-pipeline跑完了，Slack通知也發(fā)了。任務(wù)執(zhí)行成功了，但Sentry說的完全相反——儀器在撒謊，而我得先搞懂儀器，才能碰代碼。

Sentry.withMonitor(slug, fn, config)的設(shè)計看起來無懈可擊：啟動時發(fā)in_progress，執(zhí)行fn，結(jié)束時發(fā)ok或error。只要進(jìn)程活得夠久，讓兩個check-in都發(fā)出去，監(jiān)控就能反映現(xiàn)實(shí)。陷阱藏在你的函數(shù)運(yùn)行環(huán)境里。

Vercel上每個路由都是lambda。runtime一旦判定HTTP響應(yīng)已發(fā)送，就會凍結(jié)worker。但Sentry的傳輸層天生異步：事件先存進(jìn)內(nèi)存buffer，后臺worker再推送到ingest端。如果lambda沒給后臺worker留窗口，buffer就跟著lambda一起銷毀。in_progress發(fā)出去了，ok卻永遠(yuǎn)沒發(fā)出去。Sentry看到一個啟動后沒回應(yīng)的任務(wù)，等到maxRuntime就報timeout。

這是最陰險的bug類型：代碼正常運(yùn)行，可觀測性卻反向撒謊制造假警報。你會先浪費(fèi)一整天排查"問題"，最后才承認(rèn)"問題"出在可觀測性本身。

修復(fù)只要五行。在finally里包一層await Sentry.flush(2000)，強(qiáng)制在lambda交還控制權(quán)前清空buffer。兩秒超時是保險——萬一Sentry網(wǎng)絡(luò)抽風(fēng)，不至于拖垮Vercel的maxDuration。

我封裝了一個withCronMonitor工具函數(shù)，把flush邏輯藏進(jìn)去。從此監(jiān)控終于說真話了：任務(wù)成功就是綠，失敗才是真紅。那個周二下午三點(diǎn)，我刪掉了之前寫的三個臨時補(bǔ)丁，把這段代碼推進(jìn)了main分支。