Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

adonovan opened this issue Apr 15, 2024 · 3 comments


Copy link

adonovan commented Apr 15, 2024

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.



@gopherbot gopherbot added this to the Proposal milestone Apr 15, 2024
Copy link

Change mentions this issue: gopls/internal/debug: integrate flight recorder

Copy link

prattmic commented Apr 18, 2024

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.

Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Status: Incoming

No branches or pull requests

4 participants