Open adonovan opened 4 months ago
Change https://go.dev/cl/555716 mentions this issue: gopls/internal/debug: integrate flight recorder
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.
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.
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