-
Notifications
You must be signed in to change notification settings - Fork 64
DebugCollector: first class file archival #9555
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
base: main
Are you sure you want to change the base?
Conversation
|
Marking this draft because I still want to do some testing on a4x2 or a racklette. |
|
I deployed this to
Regarding sled 14, I did briefly see the process core dump here: As expected, that disappeared and the archived copy showed up: On the sled where I induced a system panic: In terms of log files: back on sled 14: |
|
I started a VM and was surprised to immediately see some rotated files in the debug dataset, but it turns out that yes, cron had run logadm despite this zone being only minutes old: Out in the GZ: What I've yet to confirm:
|
|
I tried restarting sled-agent on sled 14, expecting to see that the restart would bounce control plane zones and archive their live log files, but I don't seem to see the live log files archived. I need to do more digging on that. |
|
I watched the global zone files get rotated as expected: then a few minutes later: |
This PR adds a more first-class file archival mechanism inside the debug collector within sled agent. The reason I did this is that in the past when I wanted to modify the files that Sled Agent collects, I found it tricky to do because:
Altogether I basically felt like even when making a pretty small change, you essentially had to test in a real deployment, which is a much slower dev workflow than it needs to be (and it'd be very easy to break without breaking CI).
This is coming up because I'm planning to implement RFD 613 Debug Dropbox shortly.
After this PR, there's a new
file_archivermodule:rulessubmodule) that describe what files to collect. I hope it's easy to add new things to this.It's arguably overengineered at this point but I'm hopeful that this will make it a lot easier to augment the set of files that get archived in this way.
As a first step, I tried to preserve the existing behavior as much as possible. There are several oddities that we might want to fix in follow-up work:
vmdump.0.something.mtimeinstead ofsomething.log.mtimethe way that rotated log files do. This isn't a huge deal but does breakoxlog(oxlog does not find archived live log files #9271). I'm not sure what we should do here. We could use the same convention but then we'd lose the distinction between live vs. rotated log files. I'm not sure if that's important.