Skip to content

feat(traces): use DD_SERVICE for inferred spans when integration service names are removed - #1343

Merged
zarirhamza merged 3 commits into
mainfrom
zarir/dd-service-inferred-spans
Aug 27, 2026
Merged

feat(traces): use DD_SERVICE for inferred spans when integration service names are removed#1343
zarirhamza merged 3 commits into
mainfrom
zarir/dd-service-inferred-spans

Conversation

@zarirhamza

@zarirhamza zarirhamza commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Adds DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED (default false). When it is set and DD_SERVICE is configured, inferred (synthetic) event-source spans report the function's base service instead of the AWS resource/instance representation.
  • An explicit DD_SERVICE_MAPPING entry still takes precedence.
  • Applies to the wrapped inferred spans too (SQS→SNS, SQS→EventBridge, SNS→EventBridge).

Motivation

Customers currently need one DD_SERVICE_MAPPING entry per trigger type per function to get their event-source spans onto their own service name. This gives them a single setting that consolidates all of them at once.

Tracked by FRSLES-869. This repo is the only inferred-span implementation for Go, Java, .NET, and Ruby, which delegate inference to the extension entirely. Companion PRs: datadog-lambda-python#834, datadog-lambda-js#814.

Implementation note

Rather than thread two more parameters through Trigger::enrich_span and resolve_service_name (a ~200-line mechanical change across all 13 trigger modules and their tests), the override is applied in span_inferrer.rs immediately after enrichment.

To keep DD_SERVICE_MAPPING precedence expressed in one place, Trigger gains a default has_service_mapping_entry method that reuses the same specific/generic identifiers resolve_service_name looks up. Happy to switch to the full parameter-threading approach if reviewers prefer a single resolution ladder.

The override lowercases DD_SERVICE to match the invocation span built in processor.rs, so both spans land on the same service.

Scope

Service-name resolution only. complete_inferred_spans still sets peer.service to the invocation span's service as it does today; revisiting that pairing is deliberately left to a follow-up.

Test plan

  • 6 new tests in span_inferrer.rs: override applies, disabled by default, yields to DD_SERVICE_MAPPING, no-op without DD_SERVICE, lowercases DD_SERVICE, applies to wrapped spans
  • 3 new config tests: default off, from env, from YAML
  • cargo test --lib — 550 passed
  • cargo clippy --lib --tests -- -D warnings clean
  • cargo fmt --check clean

…ice names are removed

When DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED=true and DD_SERVICE is
set, inferred (synthetic) event-source spans report the function's base service
instead of the AWS resource/instance representation. This gives users a single
setting to consolidate every trigger span onto the function's service, rather
than requiring one DD_SERVICE_MAPPING entry per trigger type per function.

An explicit DD_SERVICE_MAPPING entry still takes precedence, and the flag
defaults to false, so existing behavior is unchanged.

This is the only inferred-span implementation for Go, Java, .NET, and Ruby,
which delegate span inference to the extension entirely.
Copilot AI lite review requested due to automatic review settings August 26, 2026 15:54
@zarirhamza
zarirhamza requested a review from a team as a code owner August 26, 2026 15:54
@zarirhamza
zarirhamza marked this pull request as draft August 26, 2026 15:56

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds an opt-in configuration that, when enabled and DD_SERVICE is set, forces inferred (synthetic) trigger spans (including wrapped spans) to report the function’s base service instead of the trigger’s AWS resource/instance-derived service—while preserving DD_SERVICE_MAPPING precedence.

Changes:

  • Introduces DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED (false by default) and wires it through env/YAML config loading.
  • Adds a post-enrichment override in span_inferrer.rs to set inferred-span service from DD_SERVICE unless an explicit service mapping exists.
  • Adds unit tests covering default behavior, override behavior, mapping precedence, and wrapped-span behavior.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
bottlecap/src/lifecycle/invocation/triggers/mod.rs Adds a helper on Trigger to detect whether DD_SERVICE_MAPPING targets a trigger (specific or generic key) to preserve precedence.
bottlecap/src/lifecycle/invocation/span_inferrer.rs Applies the new base-service override to inferred spans and wrapped inferred spans; adds targeted tests.
bottlecap/src/config/mod.rs Adds the new Lambda extension config flag with defaults and env/YAML parsing, plus config tests.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread bottlecap/src/lifecycle/invocation/span_inferrer.rs
… is disabled

Copilot flagged that the base-service override could diverge from the invocation
span when DD_TRACE_AWS_SERVICE_REPRESENTATION_ENABLED=false, since processor.rs
names the invocation span "aws.lambda" in that case. It does not: ChunkProcessor
rewrites any "aws.lambda" span to the lowercased DD_SERVICE from the tags map, so
both spans converge.

Adds a test on each side of that seam and corrects the doc comment, which
credited processor.rs alone for the match.
@datadog-prod-us1-5

datadog-prod-us1-5 Bot commented Aug 26, 2026

Copy link
Copy Markdown

Pipelines

⚠️ Warnings

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

🚦 1 Pipeline job failed

DataDog/datadog-lambda-extension | bottlecap (arm64, fips, alpine)

View more details · View in GitLab

Useful? React with 👍 / 👎

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

@zarirhamza
zarirhamza marked this pull request as ready for review August 27, 2026 15:00
@zarirhamza
zarirhamza requested a review from a team as a code owner August 27, 2026 15:00

@joeyzhao2018 joeyzhao2018 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

…rred-spans

# Conflicts:
#	bottlecap/src/config/mod.rs
#	bottlecap/src/lifecycle/invocation/span_inferrer.rs
@zarirhamza
zarirhamza merged commit 0e9ae36 into main Aug 27, 2026
38 of 47 checks passed
@zarirhamza
zarirhamza deleted the zarir/dd-service-inferred-spans branch August 27, 2026 19:19
smithclay added a commit to usetero/datadog-lambda-extension that referenced this pull request Sep 1, 2026
* fix(deps): bump h2 to 0.4.18 to fix RUSTSEC-2026-0258 (DataDog#1335)

The **Audit** check (`cargo-audit`) is failing on `main`:
[RUSTSEC-2026-0258](https://rustsec.org/advisories/RUSTSEC-2026-0258) —
`h2` accepts and queues empty DATA frames without limit, which can lead
to unbounded memory usage or a panic on length overflow. Low severity,
patched in `h2` 0.4.16.

This bumps `h2` 0.4.13 → 0.4.18 in `bottlecap/Cargo.lock`.
Lockfile-only; no source changes.

Notes on the diff:
- The diff is restricted to the two `h2` lines. Running `cargo update -p
h2` locally also re-resolved six unrelated `windows-sys` entries
downward (0.61.2 → 0.52.0/0.60.2); that churn was reverted, and `cargo
metadata --locked` confirms the lockfile is still self-consistent.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

* [SVLS-8070] Remove dormant GHCR publisher (DataDog#1330)

## Overview
* Removes the dormant GHCR publisher; companion to
https://github.com/DataDog/serverless-init-ci/pull/51
* Updates Bottlecap's locked `h2` dependency from 0.4.13 to 0.4.16 to
resolve
[RUSTSEC-2026-0258](https://rustsec.org/advisories/RUSTSEC-2026-0258),
which is blocking `main` and unrelated PRs

## Testing
* `cargo check --workspace --locked`

* chore: add PR size guidance to AGENTS.md (DataDog#1331)

## Overview

Adds a line to `AGENTS.md` asking agents to keep PRs small — usually no
more than 300 lines of core code, excluding tests, dependency updates,
and other generated changes — so reviews stay manageable.

## Testing

Docs-only change; no code affected.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

* feat(dsm): Add support for automatic DSM context extraction inside the extension (DataDog#1265)

**Please include Jira ticket in title.**

Update the trace context propagation support in universal
instrumentation to include the automatic extraction of Data Streams
Monitoring context for SQS, SNS, Kinesis and EventBridge.

Added unit tests. Manually tested the functionality for Java, Go and
.NET. Java and Go work correctly. [The .NET tracer needs updating to
support the 2.x version of
`Amazon.Lambda.RuntimeSupport`](DataDog/dd-trace-dotnet#8797)
so can't test that manually yet.

* feat(traces): use DD_SERVICE for inferred spans when integration service names are removed (DataDog#1343)

## Summary

- Adds `DD_TRACE_REMOVE_INTEGRATION_SERVICE_NAMES_ENABLED` (default
`false`). When it is set **and** `DD_SERVICE` is configured, inferred
(synthetic) event-source spans report the function's base service
instead of the AWS resource/instance representation.
- An explicit `DD_SERVICE_MAPPING` entry still takes precedence.
- Applies to the wrapped inferred spans too (SQS→SNS, SQS→EventBridge,
SNS→EventBridge).

## Motivation

Customers currently need one `DD_SERVICE_MAPPING` entry per trigger type
per function to get their event-source spans onto their own service
name. This gives them a single setting that consolidates all of them at
once.

Tracked by
[FRSLES-869](https://datadoghq.atlassian.net/browse/FRSLES-869). This
repo is the **only** inferred-span implementation for Go, Java, .NET,
and Ruby, which delegate inference to the extension entirely. Companion
PRs:
[datadog-lambda-python#834](DataDog/datadog-lambda-python#834),
[datadog-lambda-js#814](DataDog/datadog-lambda-js#814).

## Implementation note

Rather than thread two more parameters through `Trigger::enrich_span`
and `resolve_service_name` (a ~200-line mechanical change across all 13
trigger modules and their tests), the override is applied in
`span_inferrer.rs` immediately after enrichment.

To keep `DD_SERVICE_MAPPING` precedence expressed in one place,
`Trigger` gains a default `has_service_mapping_entry` method that reuses
the same specific/generic identifiers `resolve_service_name` looks up.
Happy to switch to the full parameter-threading approach if reviewers
prefer a single resolution ladder.

The override lowercases `DD_SERVICE` to match the invocation span built
in `processor.rs`, so both spans land on the same service.

## Scope

Service-name resolution only. `complete_inferred_spans` still sets
`peer.service` to the invocation span's service as it does today;
revisiting that pairing is deliberately left to a follow-up.

## Test plan

- [x] 6 new tests in `span_inferrer.rs`: override applies, disabled by
default, yields to `DD_SERVICE_MAPPING`, no-op without `DD_SERVICE`,
lowercases `DD_SERVICE`, applies to wrapped spans
- [x] 3 new config tests: default off, from env, from YAML
- [x] `cargo test --lib` — 550 passed
- [x] `cargo clippy --lib --tests -- -D warnings` clean
- [x] `cargo fmt --check` clean

[FRSLES-869]:
https://datadoghq.atlassian.net/browse/FRSLES-869?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

* chore(deps): update `libdatadog` to `72fa8685` and `serverless-components` to `9daae40` (DataDog#1332)

---------

Co-authored-by: Yiming Luo <10097700+lym953@users.noreply.github.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: E. Lewis <lewis.lewis@datadoghq.com>
Co-authored-by: James Eastham <dev@jameseastham.co.uk>
Co-authored-by: Zarir Hamza <zarir.hamza@datadoghq.com>
Co-authored-by: Lucas Pimentel <lucas.pimentel@datadoghq.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants