Epic: In product collection of workspace logs

[loujaybee]

We commonly get issues from customers / users and have to subsequently ask users for logs, the time of the issue, the workspace etc. We have in product mechanisms for gaining ad-hoc feedback and collecting logs, as detailed in troubleshooting. However, the process is:

• Still to hard / requires users to do manual work to extract logs
• Must consider self-hosted where we don't have access to logs
• Must still provide timeframes

It would be good if there were some way (in product) to mark a troubled workspace, and to automatically run the required steps to grab logs and performance data from the client (appropriately sanitised).

https://www.gitpod.io/docs/troubleshooting

Related internal discussion regarding using WireShark for debugging networking issues.

And related internal discussion on perf improvements.

Relates to:

• https://github.com/gitpod-io/website/issues/2246
• Epic: JetBrains Prebuilds for Maven #6740
• Investigate reported performance of JetBrains  #8704

[loujaybee]

CC: @lucasvaltl would be good to know if this makes most in replicated, or whether we should roll our own here.

[lucasvaltl]

👋 Hey @loujaybee
Speaking of Self-Hosted: replicated has a feature called support bundles which allows us to get data from a running installation/cluster. We are already using this. We have some control over what data gets included in there, and can actively expanding the data that is included doing (e.g. #10399).

Where do expect the logs to come from? If they are coming from a users machine (i.e. they are using a desktop IDE, or downloading the logs from VS code web to their machine), replicated support bundles won't help. If we expect the logs to come from the workspace, it might be possible to include workspace logs in these bundles. In order to actually get validation here, it is worth having a design discussion with someone from the self-hosted team. Happy to find someone that has 30 minutes if you like.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.