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.

Sign up for GitHub

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

Jump to bottom

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

Open
adonovan opened this issue Apr 15, 2024 · 3 comments
Open

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

adonovan opened this issue Apr 15, 2024 · 3 comments
Labels
Proposal
Milestone
Proposal

Comments

@adonovan
Copy link
Member

adonovan commented Apr 15, 2024 •
edited

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 gopherbot added this to the Proposal milestone Apr 15, 2024
@gopherbot
Copy link

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

@prattmic
Copy link
Member

prattmic commented Apr 18, 2024 •
edited

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
Copy link
Contributor

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
Assignees
No one assigned
Labels
Proposal
Projects
Proposals
Status: Incoming
Milestone
Proposal
Development

No branches or pull requests
4 participants
@mknyszek @prattmic @adonovan @gopherbot