feat(stats)!: implement additional metric tags in libdd-trace-stats by duncanpharvey · Pull Request #2170 · DataDog/libdatadog

duncanpharvey · 2026-06-26T19:06:02Z

What does this PR do?

Add additional metric tags to the stats aggregation key. For each configured key, the matching span meta tag is included in the key and populates ClientGroupedStats.additional_metric_tags.
Limit the number of keys for additional_metric_tags to 4, not configurable.
Limit the maximum length of individual additional_metric_tags values to 200 characters, not configurable. Values exceeding this are replaced with tracer_blocked_value.

Motivation

Allow Serverless Compatibility Layer to send additional metric tags on trace stats. See RFC.
feat: implement additional metric tags for trace stats serverless-components#140 to follow.
https://datadoghq.atlassian.net/browse/SVLS-8787

Additional Notes

Additional metric tags still need to be implemented in libdd-data-pipeline. Omitted from this PR since the goal of this PR is to support additional metric tags tags for Serverless without affecting other teams.

libdatadog/libdd-data-pipeline/src/trace_exporter/stats.rs

Line 146 in 42e3296

vec![],

Per-field cardinality limit for additional metric tags will be implemented in a following PR, #2211.

Limit the number of distinct aggregation entries per bucket that carry additional metric tags to 100 by default, configurable via additional_metric_tags_max_entries. Once exceeded, new entries have their tag values masked to tracer_blocked_value.

Implementing additional metric tags instead of span derived primary tags. See previous PR for span derived primary tags - #1815.

How to test the change?

Unit tests
Deploy to Azure Functions with the following environment variables and validate that additional tags appear on trace metrics
- DD_TAGS: custom.primary:val,workload:azure_functions
- DD_TRACE_EXPERIMENTAL_FEATURES_ENABLED: true
- DD_TRACE_STATS_ADDITIONAL_TAGS: custom.primary,workload

datadog-datadog-prod-us1-2 · 2026-06-26T19:06:55Z

Tests

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 97.64%
• Overall Coverage: 74.79% (+0.05%)

_{This comment will be updated automatically if new data arrives.

🔗 Commit SHA: 8280c19 | Docs | Datadog PR Page | Give us feedback!}

github-actions · 2026-06-26T19:08:16Z

📚 Documentation Check Results

⚠️ 3032 documentation warning(s) found

📦 `libdd-data-pipeline` - 1206 warning(s)

📦 `libdd-trace-protobuf` - 227 warning(s)

📦 `libdd-trace-stats` - 866 warning(s)

📦 `libdd-trace-utils` - 733 warning(s)

Updated: 2026-07-15 16:24:37 UTC | Commit: d389389 | missing-docs job results

github-actions · 2026-06-26T19:09:58Z

🔒 Cargo Deny Results

⚠️ 7 issue(s) found, showing only errors (advisories, bans, sources)

📦 `libdd-data-pipeline` - 3 error(s)

Show output

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:75:1
   │
75 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.1.0
                     │   ├── libdd-capabilities-impl v3.0.0
                     │   │   ├── libdd-data-pipeline v7.0.0
                     │   │   ├── libdd-shared-runtime v2.0.0
                     │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   │   │   ├── libdd-telemetry v6.0.0
                     │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   │   │   │   └── libdd-trace-stats v6.0.0
                     │   │   │   │       └── libdd-data-pipeline v7.0.0 (*)
                     │   │   │   └── libdd-trace-stats v6.0.0 (*)
                     │   │   ├── libdd-trace-stats v6.0.0 (*)
                     │   │   └── libdd-trace-utils v9.0.0
                     │   │       ├── libdd-data-pipeline v7.0.0 (*)
                     │   │       ├── libdd-trace-obfuscation v5.0.0
                     │   │       │   └── libdd-trace-stats v6.0.0 (*)
                     │   │       ├── libdd-trace-stats v6.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
                     │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   ├── libdd-dogstatsd-client v4.0.0
                     │   │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   │   └── libdd-trace-stats v6.0.0 (*)
                     │   ├── libdd-shared-runtime v2.0.0 (*)
                     │   ├── libdd-telemetry v6.0.0 (*)
                     │   ├── libdd-trace-obfuscation v5.0.0 (*)
                     │   ├── libdd-trace-stats v6.0.0 (*)
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-data-pipeline v7.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.0
                     │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   ├── libdd-telemetry v6.0.0 (*)
                     │   └── libdd-trace-stats v6.0.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.0
                     │   ├── libdd-data-pipeline v7.0.0 (*)
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v5.0.0 (*)
                     ├── (dev) libdd-trace-stats v6.0.0 (*)
                     └── (dev) libdd-trace-utils v9.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:218:1
    │
218 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v5.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── libdd-data-pipeline v7.0.0
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   ├── libdd-telemetry v6.0.0
      │   │   │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   │   │   └── libdd-trace-stats v6.0.0
      │   │   │   │       └── libdd-data-pipeline v7.0.0 (*)
      │   │   │   └── libdd-trace-stats v6.0.0 (*)
      │   │   ├── libdd-trace-stats v6.0.0 (*)
      │   │   └── libdd-trace-utils v9.0.0
      │   │       ├── libdd-data-pipeline v7.0.0 (*)
      │   │       ├── libdd-trace-obfuscation v5.0.0
      │   │       │   └── libdd-trace-stats v6.0.0 (*)
      │   │       ├── libdd-trace-stats v6.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-dogstatsd-client v4.0.0
      │   │   ├── libdd-data-pipeline v7.0.0 (*)
      │   │   └── libdd-trace-stats v6.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   ├── libdd-trace-obfuscation v5.0.0 (*)
      │   ├── libdd-trace-stats v6.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-data-pipeline v7.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   └── libdd-trace-stats v6.0.0 (*)
      ├── (dev) libdd-trace-normalization v3.0.0
      │   ├── libdd-data-pipeline v7.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-trace-stats v6.0.0 (*)
      ├── libdd-trace-utils v9.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-tinybytes v1.1.1
              ├── libdd-data-pipeline v7.0.0 (*)
              ├── (dev) libdd-tinybytes v1.1.1 (*)
              └── libdd-trace-utils v9.0.0 (*)

error[vulnerability]: Denial of Service via Stack Exhaustion
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:287:1
    │
287 │ time 0.3.41 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2026-0009
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
    ├ ## Impact
      
      When user-provided input is provided to any type that parses with the RFC 2822 format, a denial of
      service attack via stack exhaustion is possible. The attack relies on formally deprecated and
      rarely-used features that are part of the RFC 2822 format used in a malicious manner. Ordinary,
      non-malicious input will never encounter this scenario.
      
      ## Patches
      
      A limit to the depth of recursion was added in v0.3.47. From this version, an error will be returned
      rather than exhausting the stack.
      
      ## Workarounds
      
      Limiting the length of user input is the simplest way to avoid stack exhaustion, as the amount of
      the stack consumed would be at most a factor of the length of the input.
    ├ Announcement: https://github.com/time-rs/time/blob/main/CHANGELOG.md#0347-2026-02-05
    ├ Solution: Upgrade to >=0.3.47 (try `cargo update -p time`)
    ├ time v0.3.41
      └── tracing-appender v0.2.3
          └── libdd-log v1.0.0
              └── (dev) libdd-data-pipeline v7.0.0

advisories FAILED, bans ok, sources ok

📦 `libdd-trace-protobuf` - ✅ No issues

📦 `libdd-trace-stats` - 2 error(s)

Show output

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:66:1
   │
66 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.1.0
                     │   ├── libdd-capabilities-impl v3.0.0
                     │   │   ├── libdd-shared-runtime v2.0.0
                     │   │   │   ├── libdd-telemetry v6.0.0
                     │   │   │   │   └── libdd-trace-stats v6.0.0
                     │   │   │   └── libdd-trace-stats v6.0.0 (*)
                     │   │   ├── libdd-trace-stats v6.0.0 (*)
                     │   │   └── libdd-trace-utils v9.0.0
                     │   │       ├── libdd-trace-obfuscation v5.0.0
                     │   │       │   └── libdd-trace-stats v6.0.0 (*)
                     │   │       ├── libdd-trace-stats v6.0.0 (*)
                     │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
                     │   ├── libdd-dogstatsd-client v4.0.0
                     │   │   └── libdd-trace-stats v6.0.0 (*)
                     │   ├── libdd-shared-runtime v2.0.0 (*)
                     │   ├── libdd-telemetry v6.0.0 (*)
                     │   ├── libdd-trace-obfuscation v5.0.0 (*)
                     │   ├── libdd-trace-stats v6.0.0 (*)
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-ddsketch v1.1.0
                     │   ├── libdd-telemetry v6.0.0 (*)
                     │   └── libdd-trace-stats v6.0.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.0
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-trace-obfuscation v5.0.0 (*)
                     ├── (dev) libdd-trace-stats v6.0.0 (*)
                     └── (dev) libdd-trace-utils v9.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:198:1
    │
198 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── libdd-common v5.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   ├── libdd-shared-runtime v2.0.0
      │   │   │   ├── libdd-telemetry v6.0.0
      │   │   │   │   └── libdd-trace-stats v6.0.0
      │   │   │   └── libdd-trace-stats v6.0.0 (*)
      │   │   ├── libdd-trace-stats v6.0.0 (*)
      │   │   └── libdd-trace-utils v9.0.0
      │   │       ├── libdd-trace-obfuscation v5.0.0
      │   │       │   └── libdd-trace-stats v6.0.0 (*)
      │   │       ├── libdd-trace-stats v6.0.0 (*)
      │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
      │   ├── libdd-dogstatsd-client v4.0.0
      │   │   └── libdd-trace-stats v6.0.0 (*)
      │   ├── libdd-shared-runtime v2.0.0 (*)
      │   ├── libdd-telemetry v6.0.0 (*)
      │   ├── libdd-trace-obfuscation v5.0.0 (*)
      │   ├── libdd-trace-stats v6.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-ddsketch v1.1.0
      │   ├── libdd-telemetry v6.0.0 (*)
      │   └── libdd-trace-stats v6.0.0 (*)
      ├── (dev) libdd-trace-normalization v3.0.0
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-trace-stats v6.0.0 (*)
      ├── libdd-trace-utils v9.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-tinybytes v1.1.1
              ├── (dev) libdd-tinybytes v1.1.1 (*)
              └── libdd-trace-utils v9.0.0 (*)

advisories FAILED, bans ok, sources ok

📦 `libdd-trace-utils` - 2 error(s)

Show output

error[vulnerability]: Invalid pointer dereference in `fmt::Pointer` impl for `Atomic` and `Shared` when the underlying pointer is invalid
   ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:61:1
   │
61 │ crossbeam-epoch 0.9.18 registry+https://github.com/rust-lang/crates.io-index
   │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
   │
   ├ ID: RUSTSEC-2026-0204
   ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0204
   ├ Affected versions of `fmt::Display` dereference the underlying pointer. This causes a invalid pointer dereference e.g., when a pointer created with `Atomic::null` or `Shared::null`. `fmt::Debug` impls and pre-0.9 `fmt::Display` impls, which do not dereference pointers, are not affected by this issue.
   ├ Announcement: https://github.com/crossbeam-rs/crossbeam/pull/1276
   ├ Solution: Upgrade to >=0.9.20 (try `cargo update -p crossbeam-epoch`)
   ├ crossbeam-epoch v0.9.18
     └── crossbeam-deque v0.8.5
         └── rayon-core v1.12.1
             └── rayon v1.10.0
                 └── criterion v0.5.1
                     ├── libdd-common v5.1.0
                     │   ├── libdd-capabilities-impl v3.0.0
                     │   │   └── libdd-trace-utils v9.0.0
                     │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
                     │   └── libdd-trace-utils v9.0.0 (*)
                     ├── (dev) libdd-trace-normalization v3.0.0
                     │   └── libdd-trace-utils v9.0.0 (*)
                     └── (dev) libdd-trace-utils v9.0.0 (*)

error[unsound]: Rand is unsound with a custom logger using `rand::rng()`
    ┌─ /home/runner/work/libdatadog/libdatadog/Cargo.lock:181:1
    │
181 │ rand 0.8.5 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ unsound advisory detected
    │
    ├ ID: RUSTSEC-2026-0097
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0097
    ├ It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:
      
      - The `log` and `thread_rng` features are enabled
      - A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
      - The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
      - The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
      - Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed
      
      `TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
    ├ Announcement: https://github.com/rust-random/rand/pull/1763
    ├ Solution: Upgrade to >=0.10.1 OR <0.10.0, >=0.9.3 OR <0.9.0, >=0.8.6 (try `cargo update -p rand`)
    ├ rand v0.8.5
      ├── (dev) libdd-common v5.1.0
      │   ├── libdd-capabilities-impl v3.0.0
      │   │   └── libdd-trace-utils v9.0.0
      │   │       └── (dev) libdd-trace-utils v9.0.0 (*)
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── (dev) libdd-trace-normalization v3.0.0
      │   └── libdd-trace-utils v9.0.0 (*)
      ├── libdd-trace-utils v9.0.0 (*)
      └── proptest v1.5.0
          └── (dev) libdd-tinybytes v1.1.1
              ├── (dev) libdd-tinybytes v1.1.1 (*)
              └── libdd-trace-utils v9.0.0 (*)

advisories FAILED, bans ok, sources ok

Updated: 2026-07-15 16:24:37 UTC | Commit: d389389 | dependency-check job results

dd-octo-sts · 2026-06-29T15:54:02Z

Artifact Size Benchmark Report

aarch64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.so	7.88 MB	7.88 MB	+0% (+48 B) 👌
/aarch64-alpine-linux-musl/lib/libdatadog_profiling.a	86.16 MB	86.30 MB	+.15% (+138.86 KB) 🔍

aarch64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.62 MB	10.62 MB	+.02% (+3.10 KB) 🔍
/aarch64-unknown-linux-gnu/lib/libdatadog_profiling.a	97.41 MB	97.55 MB	+.13% (+139.52 KB) 🔍

libdatadog-x64-windows

Artifact	Baseline	Commit	Change
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.dll	25.55 MB	25.59 MB	+.17% (+46.50 KB) 🔍
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.lib	88.85 KB	88.85 KB	0% (0 B) 👌
/libdatadog-x64-windows/debug/dynamic/datadog_profiling_ffi.pdb	185.33 MB	185.55 MB	+.12% (+232.00 KB) 🔍
/libdatadog-x64-windows/debug/static/datadog_profiling_ffi.lib	957.28 MB	958.58 MB	+.13% (+1.29 MB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.dll	8.36 MB	8.37 MB	+.18% (+15.50 KB) 🔍
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.lib	88.85 KB	88.85 KB	0% (0 B) 👌
/libdatadog-x64-windows/release/dynamic/datadog_profiling_ffi.pdb	24.73 MB	24.76 MB	+.12% (+32.00 KB) 🔍
/libdatadog-x64-windows/release/static/datadog_profiling_ffi.lib	49.23 MB	49.29 MB	+.13% (+67.58 KB) 🔍

libdatadog-x86-windows

Artifact	Baseline	Commit	Change
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.dll	22.20 MB	22.24 MB	+.18% (+42.00 KB) 🔍
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.lib	90.24 KB	90.24 KB	0% (0 B) 👌
/libdatadog-x86-windows/debug/dynamic/datadog_profiling_ffi.pdb	189.78 MB	190.03 MB	+.13% (+256.00 KB) 🔍
/libdatadog-x86-windows/debug/static/datadog_profiling_ffi.lib	945.96 MB	946.69 MB	+.07% (+745.65 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.dll	6.46 MB	6.47 MB	+.15% (+10.50 KB) 🔍
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.lib	90.24 KB	90.24 KB	0% (0 B) 👌
/libdatadog-x86-windows/release/dynamic/datadog_profiling_ffi.pdb	26.55 MB	26.59 MB	+.17% (+48.00 KB) 🔍
/libdatadog-x86-windows/release/static/datadog_profiling_ffi.lib	46.84 MB	46.90 MB	+.13% (+65.41 KB) 🔍

x86_64-alpine-linux-musl

Artifact	Baseline	Commit	Change
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.a	76.98 MB	77.09 MB	+.14% (+112.94 KB) 🔍
/x86_64-alpine-linux-musl/lib/libdatadog_profiling.so	8.81 MB	8.82 MB	+.08% (+8.06 KB) 🔍

x86_64-unknown-linux-gnu

Artifact	Baseline	Commit	Change
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.a	92.39 MB	92.50 MB	+.12% (+115.03 KB) 🔍
/x86_64-unknown-linux-gnu/lib/libdatadog_profiling.so	10.72 MB	10.74 MB	+.13% (+14.32 KB) 🔍

# What does this PR do? - Update protobufs to be in sync with datadog-agent * `containerDebug` * `additional_metric_tags` - Update `DATADOG_AGENT_TAG` for protobufs comparison to DataDog/datadog-agent@fdc29d4 # Motivation Out of sync protobufs with datadog-agent. Needed for #2170. # Additional Notes <img width="788" height="301" alt="Screenshot 2026-06-29 at 3 03 21 PM" src="https://github.com/user-attachments/assets/ac605731-2338-4919-a078-1cb31de9b2d0" /> # How to test the change? - Weekly test to compare protobufs to main: https://github.com/DataDog/libdatadog/actions/workflows/weekly-verify-proto-files.yml - Per PR test to compare protobugs to specified commit: https://github.com/DataDog/libdatadog/actions/workflows/verify-proto-files.yml Co-authored-by: duncan.harvey <duncan.harvey@datadoghq.com>

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 42e3296aa3

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

# What does this PR do? - Update protobufs to be in sync with datadog-agent * `containerDebug` * `additional_metric_tags` - Update `DATADOG_AGENT_TAG` for protobufs comparison to DataDog/datadog-agent@fdc29d4 # Motivation Out of sync protobufs with datadog-agent. Needed for #2170. # Additional Notes <img width="788" height="301" alt="Screenshot 2026-06-29 at 3 03 21 PM" src="https://github.com/user-attachments/assets/ac605731-2338-4919-a078-1cb31de9b2d0" /> # How to test the change? - Weekly test to compare protobufs to main: https://github.com/DataDog/libdatadog/actions/workflows/weekly-verify-proto-files.yml - Per PR test to compare protobugs to specified commit: https://github.com/DataDog/libdatadog/actions/workflows/verify-proto-files.yml Co-authored-by: duncan.harvey <duncan.harvey@datadoghq.com> Signed-off-by: Taegyun Kim <taegyun.kim@datadoghq.com>

#2170

…VALUE_MAX_LEN

…ries

pr-commenter · 2026-07-15T16:45:30Z

Benchmarks

Comparison

Benchmark execution time: 2026-07-15 16:53:39

Comparing candidate commit 8280c19 in PR branch duncan-harvey/libdd-trace-stats-additional-metric-tags with baseline commit 407f8f2 in branch main.

Found 8 performance improvements and 1 performance regressions! Performance is the same for 132 metrics, 0 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

🟩 = significantly better candidate vs. baseline
🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:otlp/e2e_json/1x1000

🟩 execution_time [-258.020µs; -256.509µs] or [-6.005%; -5.970%]

scenario:otlp/encode_json/1x1000

🟩 execution_time [-285.012µs; -284.464µs] or [-14.384%; -14.356%]

scenario:vec_map/as_deduped_map/already_deduped/16

🟩 execution_time [-1.024ns; -1.003ns] or [-4.176%; -4.090%]

scenario:vec_map/as_deduped_map/already_deduped/8

🟩 execution_time [-1.019ns; -1.000ns] or [-6.847%; -6.717%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_10/8

🟩 execution_time [-15.970ns; -15.782ns] or [-4.292%; -4.241%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_2/8

🟩 execution_time [-19.798ns; -19.562ns] or [-4.078%; -4.030%]

scenario:vec_map/as_deduped_map/needs_dedup_1_in_4/8

🟩 execution_time [-19.623ns; -19.454ns] or [-4.776%; -4.735%]

scenario:vec_map/get_miss/16

🟥 execution_time [+0.788ns; +0.864ns] or [+8.386%; +9.199%]

scenario:vec_map/get_miss/8

🟩 execution_time [-1.514ns; -1.476ns] or [-20.174%; -19.667%]

Benchmark execution time: 2026-07-15 16:53:15

Comparing candidate commit 8280c19 in PR branch duncan-harvey/libdd-trace-stats-additional-metric-tags with baseline commit 407f8f2 in branch main.

Found 5 performance improvements and 0 performance regressions! Performance is the same for 87 metrics, 10 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

🟩 = significantly better candidate vs. baseline
🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

scenario:glob_matcher/ascii_case_insensitive_match/wall_time

🟩 execution_time [-2.338ns; -2.295ns] or [-7.900%; -7.754%]

scenario:glob_matcher/ascii_exact_match/wall_time

🟩 execution_time [-2.239ns; -2.198ns] or [-7.560%; -7.421%]

scenario:glob_matcher/ascii_exact_miss/wall_time

🟩 execution_time [-1.271ns; -1.226ns] or [-8.903%; -8.586%]

scenario:trace_buffer/4_senders/no_delay

🟩 execution_time [-145.680µs; -119.828µs] or [-5.882%; -4.838%]
🟩 throughput [+74821.897op/s; +91402.349op/s] or [+5.145%; +6.285%]

Candidate

Omitted due to size.

Baseline

Omitted due to size.

Eldolfin · 2026-07-15T17:07:12Z

+            .iter()
+            .filter_map(|key| match span.get_meta(key.as_str()) {
+                Some(v) if !v.is_empty() => {
+                    if v.chars().count() > ADDITIONAL_METRIC_TAG_VALUE_MAX_LEN {


Suggested change

if v.chars().count() > ADDITIONAL_METRIC_TAG_VALUE_MAX_LEN {

if v.len() > ADDITIONAL_METRIC_TAG_VALUE_MAX_LEN {

perf: Could we instead use byte length here instead ?

This deviates from the spec but I feel like this is a hot path and so we should avoid iterating on unbounded strings.

github-actions Bot added the data-pipeline label Jun 26, 2026

duncanpharvey mentioned this pull request Jun 26, 2026

feat(stats)!: implement span derived primary tags in libdd-trace-stats #1815

Closed

duncanpharvey force-pushed the duncan-harvey/libdd-trace-stats-additional-metric-tags branch 2 times, most recently from c020593 to 82959f7 Compare June 29, 2026 14:47

github-actions Bot added ci-build mini-agent labels Jun 29, 2026

duncanpharvey force-pushed the duncan-harvey/libdd-trace-stats-additional-metric-tags branch from 82959f7 to 9977516 Compare June 29, 2026 15:13

duncanpharvey mentioned this pull request Jun 29, 2026

feat: implement additional metric tags for trace stats DataDog/serverless-components#140

Open

duncanpharvey force-pushed the duncan-harvey/libdd-trace-stats-additional-metric-tags branch from fb6b20d to b3d13e5 Compare June 29, 2026 16:02

duncanpharvey mentioned this pull request Jun 30, 2026

chore!: update protobufs to be in sync with datadog-agent #2180

Merged

duncanpharvey force-pushed the duncan-harvey/libdd-trace-stats-additional-metric-tags branch from b3d13e5 to def0a56 Compare July 6, 2026 16:47

github-actions Bot removed the ci-build label Jul 6, 2026

duncanpharvey force-pushed the duncan-harvey/libdd-trace-stats-additional-metric-tags branch from def0a56 to 42e3296 Compare July 6, 2026 18:13

duncanpharvey marked this pull request as ready for review July 6, 2026 19:51

duncanpharvey requested review from a team as code owners July 6, 2026 19:51

duncanpharvey requested review from a team, apiarian-datadog and lucaspimentel and removed request for a team July 6, 2026 19:52

chatgpt-codex-connector Bot reviewed Jul 6, 2026

View reviewed changes

Comment thread libdd-data-pipeline/src/trace_exporter/stats.rs

Comment thread libdd-trace-stats/src/span_concentrator/aggregation.rs Outdated

Comment thread libdd-trace-stats/src/span_concentrator/aggregation.rs

duncanpharvey force-pushed the duncan-harvey/libdd-trace-stats-additional-metric-tags branch from 42e3296 to a7a73a5 Compare July 6, 2026 20:47

Eldolfin added a commit that referenced this pull request Jul 10, 2026

fix: link span derived primary tags ticket and pr

7e65d08

#2170

Eldolfin added a commit that referenced this pull request Jul 10, 2026

fix: link span derived primary tags ticket and pr

08652b2

#2170

Eldolfin added a commit that referenced this pull request Jul 10, 2026

fix: link span derived primary tags ticket and pr

edf1e0c

#2170

Eldolfin reviewed Jul 13, 2026

View reviewed changes

Comment thread libdd-trace-stats/src/span_concentrator/aggregation.rs Outdated

duncanpharvey added 4 commits July 14, 2026 15:05

implement additional_metric_tags in libdd-trace-stats

f0b74ea

use character limit rather than byte limit for ADDITIONAL_METRIC_TAG_…

86774a7

…VALUE_MAX_LEN

apply formatting

f053f70

remove per field cardinality limits in additional_metric_tags_max_ent…

143f090

…ries

duncanpharvey force-pushed the duncan-harvey/libdd-trace-stats-additional-metric-tags branch from a7a73a5 to 143f090 Compare July 15, 2026 16:10

fix tests

8280c19

Eldolfin reviewed Jul 15, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(stats)!: implement additional metric tags in libdd-trace-stats#2170

feat(stats)!: implement additional metric tags in libdd-trace-stats#2170
duncanpharvey wants to merge 5 commits into
mainfrom
duncan-harvey/libdd-trace-stats-additional-metric-tags

duncanpharvey commented Jun 26, 2026 •

edited

Loading

Uh oh!

datadog-datadog-prod-us1-2 Bot commented Jun 26, 2026 •

edited by datadog-datadog-prod-us1 Bot

Loading

Uh oh!

github-actions Bot commented Jun 26, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jun 26, 2026 •

edited

Loading

Uh oh!

dd-octo-sts Bot commented Jun 29, 2026 •

edited

Loading

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pr-commenter Bot commented Jul 15, 2026 •

edited

Loading

Explanation

More details about the CI and significant changes

Explanation

More details about the CI and significant changes

Uh oh!

Eldolfin Jul 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

	if v.chars().count() > ADDITIONAL_METRIC_TAG_VALUE_MAX_LEN {
	if v.len() > ADDITIONAL_METRIC_TAG_VALUE_MAX_LEN {

Uh oh!

Conversation

duncanpharvey commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What does this PR do?

Motivation

Additional Notes

How to test the change?

Uh oh!

datadog-datadog-prod-us1-2 Bot commented Jun 26, 2026 • edited by datadog-datadog-prod-us1 Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📚 Documentation Check Results

📦 libdd-data-pipeline - 1206 warning(s)

📦 libdd-trace-protobuf - 227 warning(s)

📦 libdd-trace-stats - 866 warning(s)

📦 libdd-trace-utils - 733 warning(s)

Uh oh!

github-actions Bot commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🔒 Cargo Deny Results

📦 libdd-data-pipeline - 3 error(s)

📦 libdd-trace-protobuf - ✅ No issues

📦 libdd-trace-stats - 2 error(s)

📦 libdd-trace-utils - 2 error(s)

Uh oh!

dd-octo-sts Bot commented Jun 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Artifact Size Benchmark Report

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pr-commenter Bot commented Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Benchmarks

Comparison

Explanation

More details about the CI and significant changes

scenario:otlp/e2e_json/1x1000

scenario:otlp/encode_json/1x1000

scenario:vec_map/as_deduped_map/already_deduped/16

scenario:vec_map/as_deduped_map/already_deduped/8

scenario:vec_map/as_deduped_map/needs_dedup_1_in_10/8

scenario:vec_map/as_deduped_map/needs_dedup_1_in_2/8

scenario:vec_map/as_deduped_map/needs_dedup_1_in_4/8

scenario:vec_map/get_miss/16

scenario:vec_map/get_miss/8

Explanation

More details about the CI and significant changes

scenario:glob_matcher/ascii_case_insensitive_match/wall_time

scenario:glob_matcher/ascii_exact_match/wall_time

scenario:glob_matcher/ascii_exact_miss/wall_time

scenario:trace_buffer/4_senders/no_delay

Candidate

Baseline

Uh oh!

Eldolfin Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

duncanpharvey commented Jun 26, 2026 •

edited

Loading

datadog-datadog-prod-us1-2 Bot commented Jun 26, 2026 •

edited by datadog-datadog-prod-us1 Bot

Loading

github-actions Bot commented Jun 26, 2026 •

edited

Loading

📦 `libdd-data-pipeline` - 1206 warning(s)

📦 `libdd-trace-protobuf` - 227 warning(s)

📦 `libdd-trace-stats` - 866 warning(s)

📦 `libdd-trace-utils` - 733 warning(s)

github-actions Bot commented Jun 26, 2026 •

edited

Loading

📦 `libdd-data-pipeline` - 3 error(s)

📦 `libdd-trace-protobuf` - ✅ No issues

📦 `libdd-trace-stats` - 2 error(s)

📦 `libdd-trace-utils` - 2 error(s)

dd-octo-sts Bot commented Jun 29, 2026 •

edited

Loading

pr-commenter Bot commented Jul 15, 2026 •

edited

Loading