-
Notifications
You must be signed in to change notification settings - Fork 1.5k
DBMON-5625 Enable only_custom_queries for sqlserver #21304
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
base: master
Are you sure you want to change the base?
DBMON-5625 Enable only_custom_queries for sqlserver #21304
Conversation
ba14a59
to
991052a
Compare
8228037
to
c36a70c
Compare
c36a70c
to
302e263
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files🚀 New features to boost your workflow:
|
1612a16
to
9085766
Compare
@@ -506,6 +506,41 @@ def test_custom_queries(aggregator, dd_run_check, instance_docker, custom_query, | |||
aggregator.assert_metric(metric_name, **kwargs) | |||
|
|||
|
|||
@pytest.mark.integration |
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 guessing when store procedure checks are enabled and when only_custom_queries
are enabled we do not collect stored procedure metrics? Should we test that?
Also what happens when the only_custom_queries
is set and no custom_queries
are given?
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.
If stored procedure checks are enabled and only_custom_queries
is enabled, we would collect stored procedure metrics. The idea is that if a user has a check instance with only_custom_queries
enabled they'd be removing the other collection parameters.
I think it would be good to validate these things in the config init though; I can add those situations as warning logs. What do you think?
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.
also, will definitely add tests for that regardless
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 it would be good to validate these things in the config init though; I can add those situations as warning logs. What do you think?
Yeah I think we should definitely do that. Thank you!
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.
Made the config validation change! I added a test for log output given a certain config, rather than adding extra only_custom_queries
gates around dbm metrics, sproc metrics. Since we're technically leaking only_custom_queries
outside of the QueryManager I figured it'd be best to gate with it only where there's no disabling config option (ie for base metrics only)
/merge |
View all feedbacks in Devflow UI.
This merge request is not mergeable yet, because of pending checks/missing approvals. It will be added to the queue as soon as checks pass and/or get approvals.
[email protected] unqueued this merge request |
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.
Left a couple of minor comments, I want to sync with @sethsamuel on the config changes before merging
@@ -0,0 +1 @@ | |||
Support `only_custom_queries` configuration option in sqlserver integration. |
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 new config option. We need to change the changelog to added
and not fixed
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 technically not a new config option since it exists in the sqlserver conf.yaml already & customers were reporting that it doesnt work as expected. But it's definitely new functionality if it works now so I see how added
makes more sense
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.
Ah I see yeah it looks like it was added to a bunch of configs in the past, but I don't see how it was ever actually wired up. I'm fine with fixed
in that case
@@ -271,3 +274,21 @@ def _build_database_metrics_configs(self, instance): | |||
if value is not None: | |||
config[key] = value | |||
return configurable_metrics | |||
|
|||
def _validate_only_custom_queries(self, instance): |
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.
Let's wait for @sethsamuel to return from PTO Monday on this one. We're in the process of reworking config handling / validation for surfacing agent health work. Want to make sure this will play nice with the pattern we're working towards
@pytest.mark.usefixtures('dd_environment') | ||
def test_only_custom_queries(aggregator, dd_run_check, instance_docker): | ||
"""Test that only_custom_queries=True skips regular metrics but executes custom queries.""" | ||
instance = copy(instance_docker) |
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'll clean this up in a follow up since it's already done all over but just want to point out that this copy(instance_docker)
is technically susceptible to mutation issues between tests because we're doing a shallow copy of a dictionary that we're regularly mutating deeper levels within the tests.
# Verify that regular integration metrics are NOT collected | ||
# (These would normally be collected by default) | ||
aggregator.assert_metric('sqlserver.cache.hit_ratio', count=0) | ||
aggregator.assert_metric('sqlserver.broker_activation.tasks_running', count=0) |
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 should be able to avoid asserting count=0 on these by calling aggregator.assert_all_metrics_covered()
after your assertion on custom queries. This will ensure we've checked all metrics emitted explicitly and will fail if anything else goes through. It will be more future proof
/merge -c |
View all feedbacks in Devflow UI.
|
What does this PR do?
This PR enables
only_custom_queries
in the sqlserver integration. If enabled, the check will only execute queries defined in thecustom_queries
config option. (Note: dbm queries are not gated by this flag. It is assumed that if the check instance hasonly_custom_queries
enabled, it will not have DBM enabled. This follows the MySQL implementation.)This PR:
collect_metrics
into its own function,load_basic_metrics
, which takes the cursor as a parameter.collect_metrics
to callload_basic_metrics
and later submit them only ifonly_custom_queries
is disabled.Context:
In SQLServer
custom_queries
are handled by a QueryManager object. This has always been true in sqlserver: pr. For postgres the functionality was migrated to the QueryManager last year: pr.The QueryManager object is inited with a list of custom queries and the instance config. In its own
execute()
logic, it flips through the queries that were passed in, checksonly_custom_queries
, and filter sout non-custom queries assuming they are also handled by the QueryManager. However, since we execute non-custom queries outside of the QueryManager, they are not filtered out. We need to check the config ourselves and gate these metrics manually in metric collection.Testing
I spun up a local sqlserver instance with the following config:
and ensured that
sqlserver.custom_queries.test
was recorded for that host but no other metrics.Review checklist (to be filled by reviewers)
qa/skip-qa
label if the PR doesn't need to be tested during QA.backport/<branch-name>
label to the PR and it will automatically open a backport PR once this one is merged