feat: interruptible CPU collector

[kolesnikovae]

Pyroscope CPU Profiler HTTP Handler

This package facilitates the collection of CPU profiles via HTTP without disrupting the background operation of the Pyroscope profiler. It enables you to seamlessly gather CPU profiles through HTTP while continuously sending them to Pyroscope.

The standard Go pprof HTTP endpoint /debug/pprof/profile returns an error if profiling is already started:

Could not enable CPU profiling: CPU profiling already in use

The Pyroscope CPU Profiler HTTP handler handles this gracefully by communicating with the Pyroscope profiler, which collects profiles in the background.

Usage

The package does not register the handler automatically. It is highly recommended to avoid using the standard path /debug/pprof/profile and the default mux because attempting to register the handler on the same path will cause a panic. In many cases, the net/http/pprof package is imported by dependencies, and therefore there is no reliable way to avoid the conflict.

import (
    "net/http"

    "github.com/grafana/pyroscope-go/http/pprof"
)

func main() {
	http.Handle("/debug/pprof/cpu", pprof.Profile())
}

[korniltsev]

I got

panic: http: multiple registrations for /debug/pprof/profile

goroutine 1 [running]:
net/http.(*ServeMux).Handle(0x927540, {0x6eccca, 0x14}, {0x764a00?, 0x718420})
        /home/korniltsev/.asdf/installs/golang/1.21.5/go/src/net/http/server.go:2530 +0x219

Maybe we should not register automatically the new endpoint in init function? or maybe the path should be different.

I am thinking that there may be cases when users import net/http/pprof from a transitive dependency, for example dskit. Also users may want to use grafana/http/pprof for cpu and net/http/pprof for heap.

[kolesnikovae]

panic: http: multiple registrations for /debug/pprof/profile

Yeah, this is expected, experimented with this while developing. I'm still testing/fixing it, and I will likely finish today – want to add some unit tests.

Maybe we should not register automatically the new endpoint in init function? or maybe the path should be different.

Agreed, I don't think there is a nice way to register it automatically. I'm not sure about a custom path: use of this handler together with the standard one has little to no value, IMO. Although, that would make sense if we wanted to embed our own UI

[korniltsev]

LGTM, nice job.

Took me a while to understand, but now that I understand, everything makes sense to me.

As we discussed: another approach could be forking parts of cpu profiler, linking to runtime_pprof_readProfile and we could share cpu data, for example here https://github.com/golang/go/blob/master/src/runtime/pprof/pprof.go?name=release#L851 we could write to multiple pprof builders. We can also never stop cpu profiler in theory. This way it could not interruptible but sharing.