-
Notifications
You must be signed in to change notification settings - Fork 40
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
support bundles #2235
Labels
Milestone
Comments
|
See also: #1600 |
|
This was referenced Mar 3, 2023
|
jordanhendricks
added
the
Debugging
For when you want better data in debugging an issue (log messages, post mortem debugging, and more)
label
Aug 11, 2023
Host team would like to collect the things in here: https://github.com/oxidecomputer/customer-support/issues/39 See also: #2478 |
twinfees
added
the
customer
For any bug reports or feature requests tied to customer requests
label
Dec 17, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There's wide room to scope this up or down for MVP (including possibly nothing for MVP). Many of us have had good past experiences with a built-in facility to collect information from deployed systems and make it directly available to our support and engineering teams. Much needs to be considered around customer consent and security (see RFDs 94 and 354).
Examples of stuff that's pretty easy and valuable to collect:
zpool get all
for all zpoolszfs get all
for all zfs datasetssvcs -Zap
for all sleds (all SMF service states in all zones, plus running processes)ptree
for all sleds (all processes)pargs
,pargs -e
,pstack
pfiles
(but see below)Slightly more invasive but probably safe enough would also be:
gcore
for any processes we care particularly about (e.g., Nexus, Sled Agent)cockroach debug zip
(their own support bundles)This sounds like a lot, but I think it's fairly straightforward to collect most of this. More of the work seems like figuring out the security and privacy issues, temporary storage while we're assembling the bundles, and then putting them somewhere that we can access.
We can also start with very little and augment the collection facility with software updates. In past systems I've used, we tagged different kinds of data. A standard service bundle would collect a default set of tags. More specific bundles could be requested that would collect more data that was either too invasive or too expensive to do by default.
It could be we do none of this for MVP and move this to MVP+1. I think that's basically what RFD 354 proposes.
The text was updated successfully, but these errors were encountered: