Who is your target audience for this? You seem to know how to do it (socat + go tool pprof), which suggests you want end users to do this or something?
On Fri, Jul 29, 2016 at 3:43 PM, nathan.leclaire via golang-nuts < golang-nuts@googlegroups.com> wrote: > Hi all, > > I am interested in doing performance profiling on the Docker daemon using > the existing pprof tools and/or code inside of the internal packages of > commands, and I was hoping to get some guidance on the challenges I've > encountered attempting this. > > The Docker daemon (a Go program) exposes the pprof endpoints at > /debug/pprof. However, by default the Docker daemon only listens on a > Unix domain socket to expose its HTTP API, and exposing it over a > non-encrypted TCP port is generally inadvisable due to privilege escalation > concerns. > > The current most common method for accessing this pprof information seems > to be to use socat to temporarily forward requests from the socket to a > locally listening TCP port, and use go tool pprof to collect profile > information and analyze it. This works OK for local development, but I > have a few questions about how we might be able to expand support for > collecting these pprof dumps and analyzing them more easily: > > 1. Would a proposal be considered to add support for collecting this > information directly through go tool pprof , e.g. go tool pprof > unix:///var/run/docker.sock, or is it not an area of interest for the Go > tools? Some possible dilemmas include the unix:// protocol convention, > which seems to be fairly Docker-unique to me and a little odd to conflate > (transport layer vs. protocol) with http://. I've looked extensively at > the code and it doesn't seem to cover this today. > 2. Is it possible to install and use go tool pprof in a minimal manner, > i.e. without the rest of the Golang toolchain? If so, how? > 3. How inadvisable would it be to use the internal code for generating > *Profile > and symbolizing the profiles in a 3rd party program? Obviously due to the > internal it's not meant to be exported but it would be very nice to be > able to directly embed this type of code in a library-like fashion to be > able to quickly generate dumps from running daemons that could later be > loaded with rich semantic information into go tool pprof on another > computer (without also needing the source binary). Naturally it's > *possible* to just cp and vendor the code from the stdlib and work around > this restriction, but is it advisable? > 4. Any other ideas for getting a easily importable stand-alone *.pb.gz > pprof output from inside of an exiting Go program (separate from the one > that is being profiled)? I had an idea to make a minimal Go program (or > embed in an existing one) which might be quite good at this, but getting > richly annotated information (including symbols, etc.) via HTTP alone > without any of the surrounding internal code to process it has proven a lot > trickier than I naively assumed at first. > > Thanks all, and thanks of course for go tool pprof in the first place, > it's a really excellent tool. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
