-
Notifications
You must be signed in to change notification settings - Fork 528
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
Move config reloading to beatcmd #9371
Conversation
This pull request does not have a backport label. Could you fix it @axw? 🙏
NOTE: |
beatcmd is now provided with a function that returns a "Runner", given some parameters: a complete configuration object containing both input and output configuration, a logger, and beat.Info. beatcmd registers with the libbeat management API for handling config changes. beatcmd takes care of stopping and starting Runners in response to config reloads. beater is now only responsible for running a single instance of the APM Server logic with a static configuration. beater does not depend on beatcmd by design. Some of the test helper code in beater has been moved to a new package, beatertest.
📚 Go benchmark reportDiff with the
report generated with https://pkg.go.dev/golang.org/x/perf/cmd/benchstat |
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.
Doubtlessly an improvement, I find the reloading and creation of the beater much easier to follow and also helps that some of the test creation of was moved to its own "test' package.
@@ -283,14 +257,25 @@ func (b *Beat) Run(ctx context.Context) error { | |||
}() | |||
defer logp.Info("%s stopped.", b.Info.Beat) | |||
|
|||
logger := logp.NewLogger("") | |||
if runtime.GOARCH == "386" { | |||
logger.Warn("" + |
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.
Is this empty concatenation necessary?
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.
Only necessary for my compulsion to have the proceeding strings lined up :)
I can get rid of it if you prefer?
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.
I'm fine with it, I was just curious to learn why.
logp.Info("%s started.", b.Info.Beat) | ||
b.Manager.SetStopCallback(cancel) | ||
return beater.Run(&b.Beat) | ||
if err := g.Wait(); err != nil && !errors.Is(err, context.Canceled) { |
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.
We're calling g.Wait
here and then on line 271
again. Is that intentional?
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.
It's intentional to ensure all goroutines have exited by the time the Run method returns. Not strictly necessary, but may avoid surprises in tests with code from prior tests still running. I'll add a comment.
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.
I think the comment will help clarify things for readers. I thought that was why, but wasn't sure.
- Don't overwrite ctx in Runner.Run while it's being read - Atomically increment "requests" in HTTP handler in test - Allow for extra log message in test
Motivation/summary
beatcmd is now provided with a function that returns a "Runner", given some parameters: a complete configuration object containing both input and output configuration, a logger, and beat.Info. beatcmd registers with the libbeat management API for handling config changes. beatcmd takes care of stopping and starting Runners in response to config reloads.
beater is now only responsible for running a single instance of the APM Server logic with a static configuration. beater does not depend on beatcmd by design. Some of the test helper code in beater has been moved to a new package, beatertest. In a followup we should rename beate", to clarify that it is no longer beat-centric.
Checklist
- [ ] Update CHANGELOG.asciidoc- [ ] Update package changelog.yml (only if changes toapmpackage
have been made)- [ ] Documentation has been updatedHow to test these changes
Non-functional change.
Related issues
Closes #8928