-
Notifications
You must be signed in to change notification settings - Fork 55
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
feat(logfwd): add log labels #312
Conversation
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 like a good change. Just need to consider the problem we discovered next week.
- evaluate labels in log manager
- ensure request is received in test
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.
Few minor suggestions and a suggested fix for the SetLabels
concurrency problem.
- update tests
- flush client on PlanChanged
- new ServiceData struct
- add testService.data() method
This comment was marked as resolved.
This comment was marked as resolved.
This reverts commit ca0afa1.
- remove gatherer.flushCh - set timeoutCurrentFlush in TestTimelyShutdown
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.
Changes look good, thanks for sticking with this.
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.
Thanks for the updates. Some further notes on one unrelated change done, though:
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've gone through this once more and added a bunch of nit comments. Let's fix those up and get the PR description into shape, do final QA, and then ping me and we can try to merge this week!
@@ -218,6 +219,92 @@ func (s *gathererSuite) TestRetryLoki(c *C) { | |||
} | |||
} | |||
|
|||
// Test to catch race conditions in gatherer | |||
func (s *gathererSuite) TestRace(c *C) { |
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.
Can we make this name more specific, like TestXyzRace
with what it's actually testing a race in or for? And after that let's remove the redundant doc 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.
This is a pretty non-specific test, it's just designed to hammer the log gatherer and find any potential race conditions. It's now finding some artificial race conditions though. Needs a rewrite.
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 rewrote the test so it passes. I'm still not sure what to call it though - do you have any suggestions?
- gatherer.targetName should be constant, to avoid race conditions
- rename TestRace -> TestConcurrency
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 good! I'd like @hpidcock to give this one last look, but I'm ready to merge.
The i/o timeout was coming from the context being cancelled during the "dial" stage. Increase the context timeout to avoid this.
This PR builds on the previous log forwarding PRs (#209, #252, #256, #267) by allowing the user to specify labels for logs forwarded from Pebble.
Labels will be defined in a new field
labels
inside the log target:Labels will support environment variable substitutions ($ENV_VAR), and these will be interpreted "dynamically" in the context of the relevant service.
Notes on the design
Labels can contain
$ENVIRONMENT_VARIABLES
, which will be substituted in the environment of the relevant service. However, the "service environment" could mean:environment
map as defined in the planWe decided to use (1) instead, as it is more explicit, can be "statically" evaluated just from the plan, and doesn't require extra data to be passed through from the service manager and cached.
Furthermore, anytime we change the labels, we first flush any logs currently in the buffer, so that these logs are sent with the correct (old) labels.
QA steps
Set up a simple logging service:
Set up a plan using labels and environment variables:
Run Pebble:
and verify that the labels are being correctly interpreted.
Links
Jira card: JUJU-4643