-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Cluster-checks: patch configurations on schedule #2862
Conversation
e893a1f
to
5015cef
Compare
Codecov Report
@@ Coverage Diff @@
## master #2862 +/- ##
=========================================
- Coverage 57.4% 57.4% -0.01%
=========================================
Files 392 392
Lines 25616 25662 +46
=========================================
+ Hits 14705 14730 +25
- Misses 9943 9957 +14
- Partials 968 975 +7
|
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.
LGTM overall, just one question
func (d *dispatcher) patchConfiguration(in integration.Config) (integration.Config, error) { | ||
out := in | ||
out.ADIdentifiers = nil | ||
out.ClusterCheck = false |
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.
Why do we do this? Don't we want to be able to identify these? 🤔
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.
The check collector ignores configurations with that flag. This is needed to avoid having them run in the DCA's collector.
The patching logic is taking a cluster-check configuration and outputting a "classic" check configuration ready to run on a node.
We are able to identify them on the node-agent's configcheck
via their source (the clusterchecks
config provider), see an example output in https://docs-staging.datadoghq.com/xvello/cchecks/agent/autodiscovery/clusterchecks/#autodiscovery-in-the-node-based-agent
What does this PR do?
When configurations enter the clusterchecks dispatcher from the AD, make the following changes:
empty_default_hostname
option to all instances, so metrics are submitted with no hostnamecluster_name
tag in all instancesDoing the modifications here make digests different between the DCA's AD and the clusterchecks logic, but ensure they will be identical between the DCA and the node-agnets, which will be more useful for debugging.
This step of the pipeline has been chosen because this is the earliest point in the pipeline all necessary information is available to batch all required changes in one operation.