Skip to content

Conversation

edengorevoy
Copy link
Contributor

@edengorevoy edengorevoy commented Sep 9, 2025

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 the custom_queries config option. (Note: dbm queries are not gated by this flag. It is assumed that if the check instance has only_custom_queries enabled, it will not have DBM enabled. This follows the MySQL implementation.)

This PR:

  1. Splits out basic metric fetching from collect_metrics into its own function, load_basic_metrics, which takes the cursor as a parameter.
  2. Updates collect_metrics to call load_basic_metrics and later submit them only if only_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, checks only_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:

            {"sqlserver": {
              "instances": [
                {
                  "host": "dbm-orders-local-sqlserver-primary-${USER}",
                  "port": 1433,
                  "username": "datadog",
                  "password": "SomethingElse$",
                  "connector": "odbc",
                  "driver": "ODBC Driver 18 for SQL Server",
                  "connection_string": "TrustServerCertificate=yes",
                  "tags": [
                    "env:local"
                  ],
                  "only_custom_queries": true,
                  "reported_hostname": "dbm-orders-local-sqlserver-primary-${USER}-custom-queries-only",
                  "custom_queries": [
                    {
                      "query": "SELECT 1;",
                      "columns": [
                        {"name": "custom_queries.test", "type": "gauge"}
                      ]
                    }
                  ]
                }
              ]
            }}

and ensured that sqlserver.custom_queries.test was recorded for that host but no other metrics.

Review checklist (to be filled by reviewers)

  • Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
  • Add the qa/skip-qa label if the PR doesn't need to be tested during QA.
  • If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

@edengorevoy edengorevoy force-pushed the eden.gorevoy/enable-only-custom-queries-option branch from c36a70c to 302e263 Compare September 10, 2025 20:01
Copy link

codecov bot commented Sep 10, 2025

Codecov Report

❌ Patch coverage is 90.90909% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.31%. Comparing base (aaa9182) to head (b099de0).
⚠️ Report is 11 commits behind head on master.

Additional details and impacted files
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@edengorevoy edengorevoy force-pushed the eden.gorevoy/enable-only-custom-queries-option branch from 1612a16 to 9085766 Compare September 10, 2025 23:07
@edengorevoy edengorevoy changed the title Enable only_custom_queries for sqlserver DBMON-5625 Enable only_custom_queries for sqlserver Sep 10, 2025
@edengorevoy edengorevoy marked this pull request as ready for review September 10, 2025 23:47
@edengorevoy edengorevoy requested review from a team as code owners September 10, 2025 23:47
@@ -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
Copy link
Contributor

@sangeetashivaji sangeetashivaji Sep 11, 2025

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?

Copy link
Contributor Author

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?

Copy link
Contributor Author

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

Copy link
Contributor

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!

Copy link
Contributor Author

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)

@edengorevoy
Copy link
Contributor Author

/merge

@dd-devflow-routing-codex
Copy link

dd-devflow-routing-codex bot commented Sep 12, 2025

View all feedbacks in Devflow UI.

2025-09-12 13:30:02 UTC ℹ️ Start processing command /merge


2025-09-12 13:30:18 UTC ℹ️ MergeQueue: waiting for PR to be ready

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.
Note: if you pushed new commits since the last approval, you may need additional approval.
You can remove it from the waiting list with /remove command.


2025-09-12 13:51:57 UTC ⚠️ MergeQueue: This merge request was unqueued

[email protected] unqueued this merge request

Copy link
Contributor

@eric-weaver eric-weaver left a 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.
Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Contributor

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):
Copy link
Contributor

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)
Copy link
Contributor

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.

Comment on lines +527 to +530
# 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)
Copy link
Contributor

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

@edengorevoy
Copy link
Contributor Author

/merge -c

@dd-devflow-routing-codex
Copy link

dd-devflow-routing-codex bot commented Sep 12, 2025

View all feedbacks in Devflow UI.

2025-09-12 13:51:49 UTC ℹ️ Start processing command /merge -c

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants