-
Notifications
You must be signed in to change notification settings - Fork 103
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
add dynamic buffer size for log publication #1630
Conversation
dfa5715
to
a581cec
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice -- this was easy to read/follow.
1d48771
to
7fe0e41
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty solid. Not sure if it's worth stashing the values for next startup.
currentBatchStartTime time.Time | ||
} | ||
|
||
func NewLogPublicationState(maxBytesPerBatch int) *logPublicationState { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need to be exported?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh good catch I had meant to ask for feedback here - technically none of these need to be exported (logic is entirely self-contained in osquery
). I opted to export some of these just to make it extremely clear which bits we expect to be used (NewLogPublicationState
-> StartBatch
-> EndBatch
) vs the bits that were internal to logPublicationState
. I can move those all to be internal only if people would prefer?
if lps.currentMaxBytesPerBatch >= lps.maxBytesPerBatch { | ||
return | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. I suspect we'll need to figure out how to grow beyond this -- some customers have it coded really small. But maybe this is fine to start, and we can make a real max value later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice
These changes are to address the log buffering fragility issue noted here.
The adjustment logic took a few different forms based on testing - i also have a version of this that keeps a queue of latest results if anyone is interested in going down that route let me know (I ended up trimming this down to a more simple mechanism after seeing the complexity there).
I am more than happy to take suggestions on the adjustment logic - it's easy to make the backoff more dramatic if desired but I found it to be safest to keep the changes to small increments, if the network is really in a bad state the batch limit will be adjusted eventually.
complications/lessons learned