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

x/tools/gopls: add a debug endpoint to download diagnostic information #45602

Open
findleyr opened this issue Apr 16, 2021 · 0 comments
Open
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@findleyr
Copy link
Contributor

findleyr commented Apr 16, 2021

A few patterns have emerged related to troubleshooting gopls issues:

  • Someone files a gopls issue, and our first response is to ask them to attach logs. More than half the time (I'd guess), we don't get a follow up response from the person filing the issue.
  • Someone encounters a bug, but can't repro in a fresh session and it's too late to capture logs in their current session.
  • Someone has memory problems, and they have to grab a heap dump / profile. Again, this is a burden on users that often leads to disengagement.

EDIT: after a couple years, we have new ideas and new problems. Coopting this feature request for the v0.12.0 milestone.

Especially with the new gopls performance work, we need a way to collect debug information from an already running gopls. We've seen that custom commands are a good way to achieve this, as they leverage the LSP protocol and therefore don't need any additional endpoints. A custom debuging command should enable the following:

  • Collecting memory statistics (I actually added such a command in https://go.dev/cl/468935)
  • Collecting pprof information.
  • Collecting exported metrics from the debug package.
  • Collecting recent logs from a ring buffer.
    • We should consider including 'trace' level logs that aren't reflected to the LSP client.
  • Collecting bugs observed on the server (via bug package)

With #45518, we'll be able to dynamically start the gopls debug server. This means that users should always be able to access a user interface into internals of the running gopls process. We should leverage this to make it easier to collect diagnostic information.

This is the idea we've discussed:
1. add a new endpoint to the debug server that provides a form allowing the user to select different types of diagnostic information (off the top of my head: RPC logs, heap dump, profile, execution traces), and specify a collection period.
2. when this form is submitted, start collecting this information for the specified period.
3. after collection completes, redirect the user to download a zipped payload that they can send to us.

@findleyr findleyr added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. gopls Issues related to the Go language server, gopls. labels Apr 16, 2021
@findleyr findleyr added this to the gopls/v1.0.0 milestone Apr 16, 2021
@gopherbot gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Apr 16, 2021
@stamblerre stamblerre added this to To Do in gopls on-deck Jul 15, 2021
@findleyr findleyr modified the milestones: gopls/later, gopls/v0.12.0 Mar 2, 2023
@findleyr findleyr modified the milestones: gopls/v0.12.0, gopls/v0.13.0 Mar 27, 2023
@findleyr findleyr modified the milestones: gopls/v0.14.0, gopls/v0.15.0 Aug 16, 2023
@findleyr findleyr modified the milestones: gopls/v0.15.0, gopls/v0.16.0 Dec 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
No open projects
Development

No branches or pull requests

3 participants