Document new DPA autoscaling metrics

[clamoriniere]

What does this PR do?

Documents three new Cluster Agent workload autoscaling metrics in datadog_cluster_agent/metadata.csv:

• datadog.cluster_agent.autoscaling.workload.objective.target (from datadog-agent PR #54465) — target value configured in a DatadogPodAutoscaler's spec.objectives, one point per objective. The unit column is intentionally left blank because the value is a percentage for value_type:utilization, millicores for absolute CPU, bytes for absolute memory, and the query-native unit for custom queries; the description spells this out.
• datadog.cluster_agent.autoscaling.workload.apply_mode (from datadog-agent PR #55475) — info-style gauge (always 1) tagged with dpa_mode (apply/preview) and dpa_dimension (horizontal/vertical).
• datadog.cluster_agent.autoscaling.workload.vertical_scaling.controlled_resources (from datadog-agent PR #55475) — info-style gauge (always 1), one point per container resource controlled by vertical autoscaling, using kube_container_name:all for wildcard or default container constraints.

Rows were inserted to preserve the file's alphabetical ordering. No change to METRIC_MAP in datadog_cluster_agent/datadog_checks/datadog_cluster_agent/check.py is required: these metrics are emitted directly through the Cluster Agent metrics store rather than the Prometheus endpoint, like the sibling DPA constraints/status metrics already listed in metadata.csv.

Motivation

The metrics ship in the Cluster Agent but were not listed in the integration metadata, so they did not appear in the documented metric list that the integration README points users to.

Describe how you validated your changes

• ddev validate metadata datadog_cluster_agent passes.
• Cross-checked each metric name, type, tag set, and value semantics against pkg/clusteragent/autoscaling/workload/metrics/generator.go and metrics.md at the merge commits of datadog-agent PRs #54465 and #55475.
• Documentation-only change, so no code tests apply.

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Add qa/required if this PR needs QA validation, or qa/skip-qa if it does not. Exactly one of the two is required.
• 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

---

PR by Bits - View session in Datadog

Comment @DataDog to request changes

[datadog-datadog-us1-prod]

View session in Datadog

Bits Code status: ✅ Done

CI Auto-fix: Disabled | Enable

Comment @DataDog to request changes

[datadog-official]

I can only run on private repositories.

[datadog-datadog-us1-prod]

   

⚠️ Warnings

❌ Your PR has failed checks. Please review the issues below and take necessary action before merging.

🚦 1 Pipeline job failed

Validate repository | Run Validations / Validate

View more details · View in GitHub Actions

Failed validation due to missing 'qa/required' or 'qa/skip-qa' label in the pull request.

ℹ️ Info

No other issues found (see more)

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 90.20% (+1.28%)

Useful? React with 👍 / 👎

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: ea034c2 | Docs | View more details | Give us feedback!}

[cit-pr-commenter-54b7da]

evalya-impact-summary

evalya impact analysis

Impact analysis: 0 selected, 0 skipped (of 0 test tasks)
Publish tasks:   2 (always emitted)
Diff (1 file):
  datadog_cluster_agent/metadata.csv

Debug a specific task: evalya plan impact --path <path> --task <task>

Learn more about CI impact filtering

[dd-octo-sts]

Validation Report

Validation	Description	Status
qa-label	Validate the pull request declares whether it needs QA for the next Agent release	❌

Run ddev validate all changed --fix to attempt to auto-fix supported validations.

Passed validations (20)

Validation	Description	Status
agent-reqs	Verify check versions match the Agent requirements file	✅
ci	Validate CI configuration and code coverage settings	✅
codeowners	Validate every integration has a CODEOWNERS entry	✅
config	Validate default configuration files against spec.yaml	✅
dep	Verify dependency pins are consistent and Agent-compatible	✅
http	Validate integrations use the HTTP wrapper correctly	✅
imports	Validate check imports do not use deprecated modules	✅
integration-style	Validate check code style conventions	✅
jmx-metrics	Validate JMX metrics definition files and config	✅
labeler	Validate PR labeler config matches integration directories	✅
legacy-signature	Validate no integration uses the legacy Agent check signature	✅
license-headers	Validate Python files have proper license headers	✅
licenses	Validate third-party license attribution list	✅
metadata	Validate metadata.csv metric definitions	✅
models	Validate configuration data models match spec.yaml	✅
openmetrics	Validate OpenMetrics integrations disable the metric limit	✅
package	Validate Python package metadata and naming	✅
readmes	Validate README files have required sections	✅
saved-views	Validate saved view JSON file structure and fields	✅
version	Validate version consistency between package and changelog	✅

View full run