implement mvp for span derived primary tags#11358
Conversation
| } | ||
|
|
||
| public List<String> getTraceStatsAdditionalTags() { | ||
| return tryMakeImmutableList(configProvider.getList(TRACE_STATS_ADDITIONAL_TAGS)); |
There was a problem hiding this comment.
Instead of a List where something like region,tenant_id and tenant_id,region would be seen as different values and duplicates would be preserved, instead we can define this as a Set? assuming order and duplicates do not matter. For example,
public Set<String> getTraceStatsAdditionalTags() {
return tryMakeImmutableSet(configProvider.getList(TRACE_STATS_ADDITIONAL_TAGS));
}
similar to https://github.com/DataDog/dd-trace-java/blob/master/internal-api/src/main/java/datadog/trace/api/Config.java#L5107. Claude recommended the following change as well to dd-trace-core/src/main/java/datadog/trace/common/metrics/ConflatingMetricsAggregator.java so that additionalTagKeys is still iterable while maintaining no duplicates, no config-order sensitivity, and stable payload/key ordering:
List<String> orderedAdditionalTagKeys = new ArrayList<>(additionalTagKeys);
Collections.sort(orderedAdditionalTagKeys);
this.additionalTagKeys = Collections.unmodifiableList(orderedAdditionalTagKeys);
and corresponding tests that check duplicate keys / same keys but re-ordered return the expected result 🤔
| final boolean hasGrpcStatusCode = key.getGrpcStatusCode() != null; | ||
| final int mapSize = | ||
| 15 | ||
| 16 |
There was a problem hiding this comment.
A future improvement can be to make this conditional such as hasServiceSource and hasHttpMethod below. Otherwise, most customers will always get an empty additional tag and thus an unnecessarily large payload
| boolean includeEndpointInMetrics) { | ||
| this.ignoredResources = ignoredResources; | ||
| this.additionalTagKeys = | ||
| additionalTagKeys == null ? Collections.emptyList() : additionalTagKeys; |
There was a problem hiding this comment.
We could also add a MAX_ADDITIONAL_TAG_KEYS value limiting the number of tag keys that customers can set to prevent "infinite" tag keys and possible exploitation(? - not sure if exploitation is possible here but a limit and warning once you hit the limit seems safe)
2 participants
What Does This Do
Motivation
Additional Notes
Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: [PROJ-IDENT]
Note: Once your PR is ready to merge, add it to the merge queue by commenting
/merge./merge -ccancels the queue request./merge -f --reason "reason"skips all merge queue checks; please use this judiciously, as some checks do not run at the PR-level. For more information, see this doc.