Enable pprof¶

net/http/pprof gives you live heap, goroutine, allocation, CPU and trace profiles — the tools you reach for when a long-running service leaks memory or goroutines. transport-metrics can mount it behind the same guard as /metrics.

Why it is off by default¶

/metrics publishes counters. pprof publishes the heap — including whatever data happens to be in it — the command line the process was started with, and, for the CPU and trace profiles, a handler that holds the process for the requested duration. Those are qualitatively different exposures, so enabling them is a decision the module makes you take rather than one it takes for you. There is no configuration that turns it on without a code change.

Enable it¶

metrics.Register(mux,
    metrics.WithMiddleware(authMiddleware), // guards pprof too
    metrics.WithPprof(),
)

This mounts, under /debug/pprof/ (override with WithPprofPath, keeping the trailing slash — see below):

Every one is wrapped by the middleware you passed — pprof is never exposed unguarded.

Use it¶

Point go tool pprof straight at the live endpoint (with whatever auth your guard needs, e.g. a bearer token via -H):

# a heap profile
go tool pprof http://localhost:8080/debug/pprof/heap

# 30s of CPU
go tool pprof http://localhost:8080/debug/pprof/profile?seconds=30

# goroutine dump in the browser
go tool pprof -http=: http://localhost:8080/debug/pprof/goroutine

The pprof path must end in a slash¶

WithPprofPath is not validated, and the sub-handlers are mounted by string concatenation. WithPprofPath("/debug/pprof") silently produces /debug/pprofcmdline, /debug/pprofprofile and so on, /debug/pprof/cmdline 404s, and go tool pprof fails against the endpoint. Nothing errors or warns. See Failure modes.

Keep it off the open internet¶

Because pprof can dump memory contents and block the process (CPU/trace profiles), treat the guard as mandatory. For a local debugging aid, prefer a standalone metrics server bound to loopback so the profiles are reachable only from the host.