-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
QueryManager - Prevent queries leaking between check instances #7750
Conversation
Codecov Report
|
c039855
to
91aa761
Compare
91aa761
to
33f3b43
Compare
Is this different than: #7739 |
Different implementation to choose from indeed. This one requires modification to every single integration but is a bit cleaner. The other one doesn't require changes to integrations but is a bit more hacky. |
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 option looks good IMO, but couldn't this break any extra or marketplace integration that's using the query manager?
It would, but no extras or marketplace integration is currently using that |
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, but maybe the changelog label should be set to changed
then
0d3def2
to
6667ef7
Compare
Much nicer indeed |
* QueryManager - Prevent queries leaking between check instances * Fix snowflake c9c2151
Database checks pass instances of 'Query' directly to the QueryManager for them to be 'compiled' and used.
The QueryManager modifies those 'Query' instances in-place which means that multiple instances of a same check will share the same references to those 'Query' objects.
It wouldn't be a problem if those Query did not contain references to bounded methods of the check.
Impact:
Any check currently using the QueryManager with multiple configuration instances will see metrics that should be submitted with one instance being submitted with another one. This is transparent to users, metrics will be sent to Datadog app anyway.
If the check is using autodiscovery, configuration instances are generated dynamically. Instances can be unscheduled and that leads to integrations trying to report metrics through another un-existing check instance which the agent refuses to send.