DebugCollector: first class file archival #9555
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
Author
|
Marking this draft because I still want to do some testing on a4x2 or a racklette. |
Collaborator
Author
|
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: |
Collaborator
Author
|
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:
|
Collaborator
Author
|
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. |
Collaborator
Author
|
I watched the global zone files get rotated as expected: then a few minutes later: |
jgallagher
reviewed
Jan 13, 2026
Contributor
jgallagher
left a comment
jgallagher
left a comment
There was a problem hiding this comment.
LGTM - happy to review again once this is out of draft.
|
|
||
| #[derive(Debug, Error)] | ||
| #[error("string is not a valid filename (has slashes or is '.' or '..')")] | ||
| pub(crate) struct BadFilename; |
Contributor
There was a problem hiding this comment.
Nit - maybe include the invalid filename itself?
|
|
||
| tokio::io::copy(&mut src_f, &mut dest_f).await?; | ||
|
|
||
| dest_f.sync_all().await?; |
Contributor
There was a problem hiding this comment.
Do we also need to sync dest_f's parent directory?
Collaborator
Author
|
I've discovered some minor confusion in this PR. For some reason that I did not write down, at some point I concluded incorrectly that Sled Agent writes kernel crash dumps to the "crash" dataset on the M.2. I suspect I concluded this because on dogfood, sled 13 has two crash dumps there: If this were the normal process, then I would expect that both the old code (in But that's not what happens. The block comment: omicron/sled-agent/config-reconciler/src/debug_collector/worker.rs Lines 49 to 80 in e6961bc seems to reflect what really happens, which is that we have Edit: you might wonder why sled 13 still has those dumps in that directory, instead of them being archived and deleted? The answer is that sled agent doesn't know about any U.2s because the control plane hasn't been initialized there because it hasn't been part of the control plane in years. Commit 71e24bc updates this PR to remove a crash dump from the test data. @jgallagher does all this make sense to you? I'm just a little nervous because if I'm wrong, then I'm afraid the new code would clobber crash dumps where the old one wouldn't have. But I don't think that's the case based on my current understanding. (I'm still not sure how a crash dump got into a cores dataset on that one sled.) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back 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.