Dynamic observability for Go. Inject logs, metrics, and traces into your running application directly from VS Code.
Get StartedWrite-ups from real instrumentation runs against live Go services — every SQL statement, token, and percentile comes from measured data, with the remote dashboard linked for reconciliation.
One caller at 24 calls a second: every call, both sides add a WINDOW_UPDATE, a PING and a PING ACK — grpc-go's BDP estimator, six control frames against the call's own five. Eight callers at the same rate: one round per eight calls, and 6.5 times fewer socket writes.
Read article → 📊 Dashboard · grpc-frames-20261005Same 24 writes a second, one writer then eight. 5,760 Put calls became 1,440 WAL writes: 720 waves, and in each one the first caller wrote alone while the second carried the other six. The shape held with no probe in the store at all; the milliseconds did not.
With eight readers behind one singleflight.Group, 254 timed-out queries reached 687 readers: 2.705 per query, against 2.764 for successful ones. All 312 timeouts carried the same c.err address, 0x180cff1f100. The failure rate did not change; what changed is how many callers one failure reaches at once.
The caller's 527,268 Set calls all returned true — and that true only ever meant "it went into the setBuf channel". Nor is MaxCost: 1000 a thousand items: bookkeeping overhead makes each one cost 57 units, 1000 ÷ 57 ≈ 17, and the ledger's 46,944 − 46,927 is exactly 17.
Five phases, 350 requests: the chain advanced 4, 4, 4, 3 and 0 times per request, and no phase is the ×3 on the graph. The tail that pulled p95 to 54.578 ms looked like the middleware chain — until a client-side control showed it needs stack collection: with nothing collecting stacks, none of 500 requests went over 2.0 ms.
Six probes along the whole write path, traffic in five phases. The four request-side probes all read 9,472, while wal.Save was entered 22,555 times, ran to the end 17,404 times, and etcd counted only 9,421 fsyncs. In the last phase, which sent reads only, Save gained 5,151 more — exactly the number of reads the client sent.
Eight probes bracketing a running GORM: 236 CRUD rounds became 1,888 executions, eight statement shapes at exactly 236 each — and not one of them a DELETE. db.Delete() emits UPDATE … SET deleted_at.
Five probes over seven minutes, and every token accounted for: 648 + 13 × 216 = 3,456, plus one last_run value per round, making exactly 3,672. Then, to find how much of the latency was the observation itself, I ran a control — +28.1% the first time, −1.2% the second, in opposite directions.
Probes at the MySQL driver's door, two phases of 240 PUTs: the first four minutes send the whole nested JSON back, the last four send {"quantity":N}. Each of the six statements still runs 240 times — those association tables are not coming from the front end, they came in through Preload.
A count, a timed span and verbatim content on one convergence point: the counter says 1,888, the timer says 1,652. The 236 gap is not dropped events — it is the chain where Execute appears twice.
Move from vague symptoms to the right inspection path faster. This product preview outlines how CodeBull Agent is planned to guide the next step across your observability workflow.
The planned experience will let you describe latency spikes, unstable behavior, or noisy errors in your own words, starting from the problem instead of the tooling menu.
Instead of jumping between panels blindly, the upcoming Agent is intended to suggest whether logs, metrics, dashboards, or flamegraphs should be your next view.
Once available, the Agent is expected to act as a fast investigation copilot for narrowing the search space, comparing signals, and deciding what to verify first.
Inject log statements instantly to capture variable values. Get the data you need without polluting your source code or dirtying your git history.
Instantly attach counters and gauges to any line of code. Track hit rates and variable trends without defining globals or registering metrics manually.
Generate a monitor dashboard from local instrument history and open a shareable report page in one click. Review trends across points with up to 30 days of cached data.
We now support flamegraph analysis in VS Code. Inspect stack samples and hotspot distribution directly to find performance bottlenecks faster.
Watch goroutine count, heap allocation, GC cycles, and processor states update live in VS Code. No pprof endpoint, no code change — just connect and observe.
Inject traces on the fly. Visualize execution paths and measure function latency without modifying a single line of code.
If this project helps you, a small donation goes a long way—help fund the next feature.
