dynatrace: Support DQL

[JorTurFer]

Checklist

• Tests have been added
• Ensure make generate-scalers-schema has been run to update any outdated generated files.
• Changelog has been updated and is aligned with our changelog requirements
• A PR is opened to update the documentation on (repo) (if applicable) dynatrace: Support DQL keda-docs#1688
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #7377

[github-actions]

Thank you for your contribution! 🙏

Please understand that we will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected.

While you are waiting, make sure to:

• Add an entry in our changelog in alphabetical order and link related issue
• Update the documentation, if needed
• Add unit & e2e tests for your changes
• GitHub checks are passing
• Is the DCO check failing? Here is how you can fix DCO issues

Once the initial tests are successful, a KEDA member will ensure that the e2e tests are run. Once the e2e tests have been successfully completed, the PR may be merged at a later date. Please be patient.

Learn more about our contribution guide.

[JorTurFer]

/run-e2e dynatrace
Update: You can check the progress here

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[JorTurFer]

/run-e2e dynatrace
Update: You can check the progress here

[JorTurFer]

/run-e2e dynatrace
Update: You can check the progress here

[JorTurFer]

/run-e2e dynatrace
Update: You can check the progress here

[rickbrouwer]

/run-e2e dynatrace
Update: You can check the progress here

[JorTurFer]

PTAL @rickbrouwer
After a quick chat with my colleague in Dynatrace, he suggested me to expose the polling configuration so I've added the control parameters

[JorTurFer]

/run-e2e dynatrace
Update: You can check the progress here

[Copilot]

Pull request overview

This pull request adds support for Dynatrace Query Language (DQL) to the Dynatrace scaler, allowing users to query metrics using DQL in addition to the existing metricSelector approach. The implementation introduces a new query execution and polling mechanism for asynchronous DQL query processing.

Changes:

• Added DQL query support with polling-based result retrieval mechanism
• Introduced new metadata fields for DQL configuration (query, queryTimeoutSeconds, queryPollingWait, queryPollingTries)
• Made metricSelector and query mutually exclusive with proper validation

Reviewed changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
pkg/scalers/dynatrace_scaler.go	Core implementation of DQL query execution and polling logic, including new metadata fields and validation
pkg/scalers/dynatrace_scaler_test.go	Unit tests for DQL query execution covering various success and failure scenarios
tests/scalers/dynatrace_dql/dynatrace_dql_test.go	End-to-end integration tests for the DQL scaler functionality
schema/generated/scalers-schema.yaml	Schema updates adding new DQL-related parameters
schema/generated/scalers-schema.json	JSON schema updates mirroring the YAML changes
CHANGELOG.md	Changelog entry documenting the new DQL querying feature

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JorTurFer]

/run-e2e dynatrace
Update: You can check the progress here

[rickbrouwer]

Quick concern about the time.Sleep() in the polling .
I thought we avoid sleeps in scalers (but I am not fully sure about this, something struck me)?

But if it must remain, I think it ignores context cancellation and blocks reconciliation for up to 5s (5x1s). Should this use select with time.After() and ctx.Done() instead? Not sure if I'm overthinking it.

[JorTurFer]

Quick concern about the time.Sleep() in the polling . I thought we avoid sleeps in scalers (but I am not fully sure about this, something struck me)?

But if it must remain, I think it ignores context cancellation and blocks reconciliation for up to 5s (5x1s). Should this use select with time.After() and ctx.Done() instead? Not sure if I'm overthinking it.

actually, it makes sense since it's a configurable thing. I used the "rude for" because initially the values were fixed, but as soon as I've exposed them, I think that using select+after makes sense totally because a user could set crazy waiting times and cancelling the loop is needed.

I've updated the code :)

[JorTurFer]

/run-e2e dynatrace
Update: You can check the progress here