-
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
Clarify the enabled property in database_metrics configuration descriptions for sqlserver #19288
Clarify the enabled property in database_metrics configuration descriptions for sqlserver #19288
Conversation
The changelog type |
The changelog type |
…b.com:DataDog/integrations-core into allen.zhou/update_sqlserver_spec_descriptions
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
Flags with carried forward coverage won't be shown. Click here to find out more. |
…b.com:DataDog/integrations-core into allen.zhou/update_sqlserver_spec_descriptions
…ptions for sqlserver (DataDog#19288) * Clarify the enabled property in database_metrics configuration * changelog * database_metrics don't require dbm * Delete sqlserver/changelog.d/19288.changed * changelog * Sync configs * Delete sqlserver/changelog.d/19288.added * Review comments * sync instance change aa9bd4e
What does this PR do?
Add the enabled property to description of database_metrics configuration descriptions for sqlserver
Motivation
Realized thanks to help from @willstrickfaden and Faizan Hussain in the support channel, that the conf.yaml.example does not sufficiently surface the properties available for the database_metrics configurations. Most critically, it is not clear that in order to enable an metric, the format must look something like this (with the
enabled
property set to true):This PR explicitly states each of the properties available for each database_metric configuration, making this more clear.
Please note, the
include_xyz_metrics: true
configuration format will still continue to work in future agent releases as well, in order to maintain backwards compatibility of conf.yaml files.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