我以為一次 gRPC 呼叫就是一來一回，然後在線上數到它多送了六個沒人寫過的 frame
一個 caller、每秒 24 次：每一次呼叫，兩端都各多送 WINDOW_UPDATE、PING、PING ACK——grpc-go 的 BDP 估算器，六個控制 frame 對呼叫本身的五個。八個 caller、同樣速率：八次呼叫才一輪，socket 寫入少 6.5 倍。
閱讀文章 → 📊 對帳面板 · grpc-frames-20261005
實測筆記
CodeBull 在真實服務上跑出來的東西
對執行中的 Go 服務實際掛觀測點的紀錄。文中每一條 SQL、每一個數字都出自實測數據，並附上遠端面板可線上對帳。
我讓八個 goroutine 同時寫進 leveldb，它每一波都只寫兩次 WAL
同樣每秒 24 筆，一個寫入者換成八個。5,760 次 Put 換來 1,440 次 WAL 寫入：720 波，每一波都是第一個人自己寫、第二個人帶走另外六個。leveldb 裡一個點都不掛，形狀還在；毫秒數就不在了。
我盯著一個 singleflight 看了十分鐘，然後看到同一個逾時被一次發給了七個人
八個讀者擠在同一個 singleflight.Group 後面，254 次逾時的查詢打到了 687 個讀者，平均每次 2.705 人；成功的查詢是 2.764 人。312 次逾時的 c.err 全部指向同一個位址 0x180cff1f100。失敗率沒有變，變的是一次失敗同時打到幾個人。
它說收下了五十二萬次，實際留下十七個
呼叫端 527,268 次 Set 全部拿到 true——那個 true 的意思其實是「排進 setBuf 這個 channel 了」。而 MaxCost: 1000 也不是一千個項目：每個項目被加上簿記開銷後要 57 個單位，1000 ÷ 57 ≈ 17，而帳本上 46,944 − 46,927 正好是 17。
我拆掉自己的觀測點，那條 55 毫秒的尾巴就消失了
五個相位、350 個請求：鏈被推進的次數是 4、4、4、3、0，沒有一個相位是圖上那個 ×3。把 p95 拉到 54.578 毫秒的尾巴看起來在中介層鏈裡——直到客戶端的對照組顯示它需要有人在收堆疊：沒有任何點收堆疊時，500 個請求沒有一個超過 2.0 毫秒。
一次讀，也會敲一次 WAL
六個點沿著整條寫入路徑，流量分五個相位。請求側四個點全部 9,472，而 wal.Save 被進入 22,555 次、真正走到底 17,404 次、etcd 自己數的 fsync 只有 9,421。而最後那個只送讀取的相位裡，Save 又多了 5,151 次——正好等於客戶端送出的讀取數。
我叫了 Delete，資料庫收到的是 UPDATE
八個觀測點夾住一個正在跑的 GORM：236 輪 CRUD 展開成 1,888 次執行，八種語句每種剛好 236 次——而那八種裡面一句 DELETE 都沒有。db.Delete() 送出去的是 UPDATE … SET deleted_at。
我差點寫出一個很漂亮的錯結論
五個點看七分鐘，token 一個不剩地兜起來：648 + 13 × 216 = 3,456，加上每輪一個的 last_run 值，正好是 3,672。然後為了知道延遲裡有多少是觀測本身，我做了對照組——第一次 +28.1%，第二次 −1.2%，方向相反。
我把 PUT 的 body 砍到只剩一個欄位，資料庫收到的六句話一句沒少
在 MySQL driver 的門口掛點，兩個相位各 240 次 PUT：前四分鐘送整包巢狀 JSON，後四分鐘只送 {"quantity":N}。六句 SQL 每一句都還是 240 次——那兩張關聯表不是前端送回來的，是 Preload 讀進來的。
同一個函式上的三個點，數出兩個不同的數字
在同一個收斂點上掛計數、計時與逐字內容：計數說 1,888、計時說 1,652。差的 236 不是掉事件，是堆疊上 Execute 出現兩次的那條鏈。
即將推出
搶先預覽即將登場的 CodeBull Agent
從模糊症狀更快走到正確的觀察路徑。這段產品預告說明了未來推出的 CodeBull Agent 將如何協助你規劃可觀測性流程中的下一步。
從自然語言開始
規劃中的體驗會讓你直接用日常語言描述延遲飆高、行為不穩定或錯誤訊息過雜等問題，而不是先被工具選單綁住。
更快找到下一步
未來推出的 Agent 預計會協助你判斷接下來應該先看日誌、指標、儀表板，還是火焰圖，減少在不同面板之間盲目切換。
讓調查不中斷
正式提供後，Agent 預期會成為調查流程中的即時助手，幫助你快速縮小範圍、對照不同訊號，並決定先驗證哪個方向。
為什麼選擇 CodeBull？
動態日誌 (Dynamic Logging)
立即注入日誌語句以擷取變數值。獲取您需要的資料，而不會污染您的原始碼或弄亂 git 歷史紀錄。
即時指標 (Instant Metric)
立即將計數器和儀表附加到任何程式碼行。追蹤命中率和變數趨勢，無需定義全域變數或手動註冊指標。
歷史儀表板 (History Dashboard)
從本地插樁歷史資料一鍵產生監控儀表板並開啟可分享的報表頁面。可檢視跨點位趨勢，涵蓋最多 30 天快取資料。
火焰圖分析 (Flamegraph)
我們現在支援火焰圖分析。可直接從 VS Code 檢視堆疊樣本與熱點分布，更快找出執行路徑中的瓶頸。
Runtime 儀表板 (Runtime Dashboard)
在 VS Code 中即時監控 goroutine 數量、Heap 記憶體配置、GC 次數與處理器狀態。無需加入 pprof 端點，無需修改程式碼——連線即可觀測。
即將推出
無處不在的追蹤 (Tracing Everywhere)
動態注入追蹤。視覺化執行路徑並測量函數延遲，而無需修改任何一行代碼。
