feat(config): support OTEL_SERVICE_NAME as alias for DD_SERVICE#266
Draft
bm1549 wants to merge 12 commits into
Draft
feat(config): support OTEL_SERVICE_NAME as alias for DD_SERVICE#266bm1549 wants to merge 12 commits into
bm1549 wants to merge 12 commits into
Conversation
… DD_SERVICE OTEL_SERVICE_NAME is a standard OpenTelemetry env var that other dd-trace-* libraries accept as a first-class DD_SERVICE alias. Previously, dd-trace-rs only handled it indirectly via the OTel SDK resource detection (which set the span service name post-init, but not config-level fields like RC service targeting or telemetry service name at startup). This adds OTEL_SERVICE_NAME as a proper alias in supported-configurations.json and updates the code generator to distinguish non-deprecated aliases (aliases field) from deprecated old names (deprecated_aliases field), so users setting OTEL_SERVICE_NAME do not see a spurious deprecation warning. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… comments - docs/add_configurations.md: document the new deprecated_aliases field and correct the now-stale "aliases are auto-deprecated" rule - configuration.rs: add service_is_default() assertion to precedence test; add test documenting DD_SERVICE="" behavior (empty primary does not fall through to OTEL_SERVICE_NAME alias) - local_config_map_generate.py: use extend/.get() idiom for consistency - span_processor.rs: clarify comment to document the two service-name intake paths (env-var alias vs programmatic Resource) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
🎉 All green!🧪 All tests passed 🔗 Commit SHA: 56bfd33 | Docs | Datadog PR Page | Give us feedback! |
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The FPD (Feature Parity Dashboard) validation checks that local aliases are a subset of aliases registered in the FPD registry. Since the FPD treats OTEL_SERVICE_NAME as a separate config (not an alias of DD_SERVICE), declaring it in the aliases field causes the validation to fail. Follow the pattern of other Datadog tracers (Python, Go, Java): register OTEL_SERVICE_NAME as its own top-level entry (version B) and implement the DD_SERVICE -> OTEL_SERVICE_NAME fallback explicitly in code. The behavior is identical to the alias-based approach: - DD_SERVICE set -> use it - DD_SERVICE absent -> try OTEL_SERVICE_NAME - DD_SERVICE="" (empty) -> use default (fallback suppressed) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…rator Remove the deprecated_aliases field introduced for DD_REMOTE_CONFIGURATION_ENABLED now that OTEL_SERVICE_NAME is a top-level supportedConfigurations entry — the automatic heuristic (mark an alias deprecated if it is not itself a top-level key) handles all existing cases correctly without requiring an explicit field. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…fallback Replaces the inline match in the Config struct literal with a reusable ConfigItemSourceUpdater helper, so the service field reads as a one-liner consistent with the surrounding fields. The fallback key (OTEL_SERVICE_NAME) now also requires a non-empty value; an empty OTEL_SERVICE_NAME="" produces the default, matching DD_SERVICE="" behavior. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Treat an empty value on either key the same as the key being absent, so the service is the first non-empty value among [DD_SERVICE, OTEL_SERVICE_NAME], else the default. This simplifies the fallback helper (both keys handled uniformly) and matches dd-trace-go's behavior for DD_SERVICE="". Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Pick the result (primary if non-empty, else fallback) first, then apply it once if non-empty. Removes the nested match and duplicated apply_result call. Also drops the now-redundant comment at the service field; the helper doc covers the precedence. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
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
1 participant
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.
What does this PR do?
Registers
OTEL_SERVICE_NAMEas a first-class configuration entry, withDD_SERVICEtaking precedence andOTEL_SERVICE_NAMEused as a fallback whenDD_SERVICEis absent or empty. This matches how other Datadog tracers (Python, Go, Java, .NET, Node.js) handle it.Previously,
OTEL_SERVICE_NAMEwas not a tracer config value. It was picked up only via the OpenTelemetry SDK's resource detection and applied post-init inset_resource, as aCalculated-origin override on the service config plus the span resource. Because the Remote Config worker starts beforeset_resourceruns and builds its request lazily, the initial RC request(s) could be sent with the wrong (default orDD_SERVICE) service name. ResolvingOTEL_SERVICE_NAMEat config-initialization time removes that startup window, so Remote Config targeting and all config-level consumers use the correct service name from the start.Changes:
supported-configurations.json: AddsOTEL_SERVICE_NAMEas a top-level entry (version B, matching the FPD registry), alongside the existing OTel config entries. It is registered as a separate config rather than aDD_SERVICEalias because the FPD treats OTel env vars as distinct configs, not aliases (using thealiasesfield caused the FPD validation CI job to fail).configuration.rs: Adds aupdate_non_empty_string_with_fallbackhelper onConfigItemSourceUpdaterand uses it for theservicefield. The service is the first non-empty value among[DD_SERVICE, OTEL_SERVICE_NAME], else the default. An empty value on either key is treated as unset.supported_configurations.rs: Regenerated,OTEL_SERVICE_NAMEis now aSupportedConfigurationsenum variant.Motivation
Users who configure their services via
OTEL_SERVICE_NAME(a standard OpenTelemetry env var) expect dd-trace-rs to honor it the same way the other Datadog tracers do.Additional Notes
Service-name precedence tests cover:
OTEL_SERVICE_NAMEalone is used as the service nameDD_SERVICE+OTEL_SERVICE_NAMEmeansDD_SERVICEwinsDD_SERVICE=""+OTEL_SERVICE_NAMEset falls through toOTEL_SERVICE_NAME(emptyDD_SERVICEis treated as unset, matching dd-trace-go)OTEL_SERVICE_NAME=""alone uses the default