search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
122.7k stars 17.49k forks source link

proposal: runtime: an http.Handler that implements 'go tool trace' in process #66843

Open adonovan opened 4 months ago

adonovan commented 4 months ago

For applications that already include a web server and generate event traces (e.g. gopls), it is convenient for the developer to be able to collect and view a trace of events from within the application itself. Unfortunately, the event trace viewer is currently only available through the 'go tool trace' command, which opens its own web server, complicating the integration and management of processes and lifetimes.

This proposal requests a package, maintained by the runtime team, that provides an http.Handler that can be added to the application's ServeMux to allow the developer to view event traces within the existing server.

Related:

@mknyszek

gopherbot commented 4 months ago

Change https://go.dev/cl/555716 mentions this issue: gopls/internal/debug: integrate flight recorder

prattmic commented 4 months ago

I like this idea. At it's core, it is about moving most of cmd/trace to an importable package to make it usable by other servers.

IMO, this would make the most sense as part of x/debug/trace (#62627). Perhaps x/debug/trace/http?

The current trace viewer needs multiple endpoints. /trace serves the HTML/JS UI and then the JS fetches the actual trace content from /jsontrace. I'm not sure the best way to avoid exposing that via the API. Can the package provide an http.ServeMux with all of the endpoints? I'm not sure if there is an easy way to use a ServeMux as "subdirectory" within another ServeMux? Edit: Oh, looks like ServeMux implements http.Handler, so I think this is actually trivial.

mknyszek commented 4 months ago

I think this is partly blocked by #65315 because we currently still have a pretty high memory requirement to working with traces, but it's at least no longer a hard requirement.

If we bundle this functionality with also taking a trace (or flight recorder snapshot), then we may want to consider requiring the trace to be written to a temporary os.File or something, again, to avoid memory footprint issues, especially for exploring bigger traces.