feat[datadog_metric_tag_configuration]: add data source#3783
Open
mdb wants to merge 1 commit into
Open
Conversation
Wraps the ListTagConfigurationByName endpoint
(GET /api/v2/metrics/{metric_name}/tags), which is the only API that
authoritatively answers "does a tag configuration exist for this
metric?". None of the existing metric data sources do:
- datadog_metric_tags returns ingested tag values, unrelated to the
managed tag configuration.
- datadog_metric_metadata returns metric metadata, also unrelated.
- datadog_metric_active_tags_and_aggregations returns active ingested
data, also unrelated.
The data source returns successfully on 404 with exists = false rather
than emitting a diagnostic error. This is a deliberate deviation from
the convention used by e.g. data_source_datadog_incident_type, because
the one purpose served by this data source is existence checking — a data
source that errors when its target doesn't exist cannot be used inside
a for_each filter to discriminate.
Motivating use case: callers that dynamically discover metric names
via datadog_metrics and want to import {} the subset that already have
a tag configuration. Today that import fails when any discovered
metric lacks a tag configuration; this data source lets callers filter
on .exists before populating the for_each set.
Signed-off-by: Mike Ball <mikedball@gmail.com>
cswatt
approved these changes
May 15, 2026
Contributor
Author
|
@cswatt Thanks for the review! What are next steps for stewarding this along towards being merged/released? Anything I can help with? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses #3790 to implement a
datadog_metric_tag_configurationby using theListTagConfigurationByNameendpoint(
GET /api/v2/metrics/{metric_name}/tags) to surface "does a tag configuration exist for this metric?"None of the existing metric data sources offer this insight:
The data source returns successfully on 404 with exists = false rather than emitting a diagnostic error. This is a deliberate deviation from the convention used by e.g. data_source_datadog_incident_type, becaus one purpose served by this data source is existence checking — a data source that errors when its target doesn't exist cannot be used inside a
for_eachfilter to discriminate.Example motivating use case (other examples exist; this is just one):
Callers that dynamically discover metric names via
datadog_metricsand want toimport {}the subset that already have a tag configuration. Today, that import fails when any discovered metric lacks a tag configuration; this data source lets callers filter on.existsbefore populating thefor_eachset.