-
Notifications
You must be signed in to change notification settings - Fork 347
Emit additional metric tags on the OTLP stats export path (client-side stats) #12069
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
base: master
Are you sure you want to change the base?
Changes from all commits
49f7a64
ad8e42a
9994e8f
94e310e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -228,6 +228,13 @@ private void emitDataPointAttributes( | |
| if (entry.hasGrpcStatusCode()) { | ||
| emitStringAttribute(metric, RPC_RESPONSE_STATUS_CODE, entry.getGrpcStatusCode()); | ||
| } | ||
| // Additional metric tags: user-configured span-derived dimensions, carried as packed | ||
| // "key:value" UTF8 strings in schema order. Emitted in both modes as plain OTLP string | ||
| // attributes keyed by the tag name. NOTE: the attribute-key representation (raw tag name vs a | ||
| // datadog.* namespace) is an open cross-team question with the OTLP/agent side -- see the PR. | ||
| for (UTF8BytesString additionalTag : entry.getAdditionalTags()) { | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
OTLP client-side metric points can have corrupted HTTP semantic attributes or be rejected when a valid user configuration overlaps a standard OTLP key. Assertion details
Was this helpful? React 👍 or 👎
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @dougqh Is this a valid concern? Should we handle this the same way that native CSS handles it?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had Claude do an analysis of this for both the Datadog & OTLP serialization. Here are the findings... Yes, it's a valid concern — but it's specific to the OTLP path, and native doesn't have it by design. On the native msgpack path ( OTLP data-point attributes are a single flat The two ways to reproduce native's separation on a flat bag are (a) a key namespace like One implementation note: this reservation must live in I'll push that change; happy to revisit if we ever reintroduce a namespace. |
||
| emitAdditionalTag(metric, additionalTag); | ||
| } | ||
| // Default (Datadog) mode: emit datadog.* per-point attributes | ||
| if (!otelSemanticsMode) { | ||
| emitStringAttribute(metric, DATADOG_OPERATION_NAME, entry.getOperationName()); | ||
|
|
@@ -239,6 +246,21 @@ private void emitDataPointAttributes( | |
| } | ||
| } | ||
|
|
||
| // Splits a packed "key:value" additional-tag string at the first ':' (keys cannot contain ':', | ||
| // values may) and emits it as an OTLP string attribute. Skips only malformed slots with no ':' or | ||
| // an empty key. An empty value ("key:") is emitted as key="": the aggregation path treats an | ||
| // explicitly-empty tag as a distinct dimension from an absent one, so dropping it here would | ||
| // export two separately-aggregated rows with identical OTLP attribute sets. | ||
| private static void emitAdditionalTag(OtlpMetricVisitor metric, UTF8BytesString additionalTag) { | ||
| String packed = additionalTag.toString(); | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not thrilled with the need to split here, but I'm leaving client-side stats optimized for interaction with Datadog agent and our protocol for the moment. The problems also run deeper than just the split. That's probably solvable with the our UTF8 cache, but I'm leaving that to another PR. |
||
| int separator = packed.indexOf(':'); | ||
| if (separator <= 0) { | ||
| return; | ||
| } | ||
| metric.visitAttribute( | ||
| STRING_ATTRIBUTE, packed.substring(0, separator), packed.substring(separator + 1)); | ||
|
Comment on lines
+260
to
+261
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When Useful? React with 👍 / 👎.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same as the above Datadog comment. |
||
| } | ||
|
|
||
| // accepts both String literals and UTF8BytesString (both CharSequence); skips null values | ||
| private static void emitStringAttribute( | ||
| OtlpMetricVisitor metric, String key, @Nullable CharSequence value) { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed w/ Munir - let's keep the raw key instead of
datadog.*