Slightly off-topic, but the web-based visualization tool - Chromium Catapult's Trace-viewer [0] - used to present the profiling data here is pretty nice I think.

The input JSON data format for Trace-viewer is also simple, so it's easy to to leverage it when creating a profiling tool. As a simple example I built a POSIX function call tracer for Linux - cpuusage [1] - which uses it.

[0]: https://github.com/catapult-project/catapult/blob/master/tra...

[1]: https://github.com/d99kris/cpuusage

On the same topic, I found this presentation by Brad Fitzpatrick very useful: https://www.youtube.com/watch?v=xxDZuPEgbBU

I found the original golang blog to be a fantastic resource on the topic: https://blog.golang.org/profiling-go-programs

I wonder how many sites have left the /debug/pprof endpoint enabled in production. Sounds like something pentesters should keep in mind.

http://mmcloughlin.com/posts/your-pprof-is-showing - "Golang’s net/http/pprof package is incredibly powerful: it’s trivial to debug a running production server. In the process it’s equally easy to accidentally expose your debugging information to the world. In this post we use the zmap project to show this is a real problem in the wild, and explain preventative measures you can take."

However it's not very hard to wrap pprof's HTTP handlers with your own one, so you can add a layer of protection for it.

Pretty much any brute force pentesters will check for exposed endpoints of any kind or anything open/accessible on a network and/or a particular server/desktop/system. Security software are pretty thorough nowadays.

justforfunc - www.youtube.com/watch?v=ySy3sR1LFCQ