Repository navigation
Conversation
bm1549
added
the
AI Generated
github-actions
Bot
added
the
area:tracer
This was referenced Jul 24, 2026
BenchmarksBenchmark execution time: 2026-07-30 16:09:04 Comparing candidate commit dccbbd8 in PR branch Found 0 performance improvements and 1 performance regressions! Performance is the same for 71 metrics, 0 unstable metrics, 60 known flaky benchmarks, 66 flaky benchmarks without significant changes.
|
Execution-Time Benchmarks Report ⏱️Execution-time results for samples comparing This PR (8936) and master. ✅ No regressions detected |
andrewlock
reviewed
Jul 27, 2026
Emit otlp_traces_export_enabled, otlp_metrics_export_enabled, and otlp_logs_export_enabled booleans in the DATADOG TRACER CONFIGURATION startup log, aligning the .NET tracer with the shared cross-tracer diagnostic-log schema. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
bm1549
force-pushed
the
brian.marks/otlp-export-startup-log
branch
from
July 29, 2026 23:56
a50aa5f to
e0e537d
Compare
gh-worker-dd-mergequeue-cf854d Bot
pushed a commit
to DataDog/dd-trace-go
that referenced
this pull request
Aug 4, 2026
### What does this PR do? Adds three boolean fields to the `DATADOG TRACER CONFIGURATION` startup log: - `otlp_traces_export_enabled` reports whether the tracer selected the OTLP trace writer. - `otlp_metrics_export_enabled` reports whether the tracer will start OTel runtime metrics. - `otlp_logs_export_enabled` reports whether OTel logs are enabled in the tracer configuration. Updates the startup-log expectations, clears the OTLP-related environment variables in `TestStartupLog`, and tests the metrics startup gate with and without the OTel metrics hook installed. ### Motivation Part of the cross-tracer work to use the same OTLP export-status fields in each tracer's startup diagnostics. The fields show which signals a service exports over OTLP. Related PRs: - dd-trace-js: DataDog/dd-trace-js#9517 - dd-trace-py: DataDog/dd-trace-py#19265 - dd-trace-java: DataDog/dd-trace-java#12062 - dd-trace-dotnet: DataDog/dd-trace-dotnet#8936 - dd-trace-rb: DataDog/dd-trace-rb#6096 - dd-trace-php: DataDog/dd-trace-php#4056 - system-tests: DataDog/system-tests#7376 - dd-trace-py OTLP logs fix: DataDog/dd-trace-py#19266 ### Reviewer's Checklist - [x] Changed code has unit tests for its functionality at or near 100% coverage. - [ ] [System-Tests](https://github.com/DataDog/system-tests/) covering this feature have been added and enabled with the va.b.c-dev version tag. (N/A: startup diagnostic-log fields only.) - [ ] There is a benchmark for any new code, or changes to existing code. (N/A: no hot-path or performance-sensitive code.) - [ ] If this interacts with the agent in a new way, a system test has been added. (N/A: no new agent interaction.) - [ ] New code is free of linting errors. You can check this by running `make lint` locally. (Full lint not run; `gofmt` and `git diff --check` are clean.) - [x] New code doesn't break existing tests. You can check this by running `make test` locally. (`go test ./ddtrace/tracer -count=1` passes.) - [ ] Add an appropriate team label so this PR gets put in the right place for the release notes. - [ ] All generated files are up to date. You can check this by running `make generate` locally. (N/A: no generated files changed.) - [ ] Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild. Make sure all nested modules are up to date by running `make fix-modules` locally. (N/A: no module changes.) Co-authored-by: dario.castane <dario.castane@datadoghq.com>
bm1549
marked this pull request as ready for review
August 12, 2026 20:19
andrewlock
reviewed
Aug 28, 2026
| OpenTelemetryLogsEnabled = OpenTelemetryLogsEnabled && OtelLogsExporterEnabled; | ||
| #else | ||
| OpenTelemetryLogsEnabled = false; | ||
| #endif |
Member
There was a problem hiding this comment.
We probably shouldn't do this, as this bypases all the telemetry. It also makes doing all the above work kind of pointless if we're never going to even use the values? 🤔 Should all the extraction be gated by this? Also, is it really supported on .NET Core 3.1, or should it be .NET 6 like the metrics below?
| } | ||
| } | ||
|
|
||
| [TestingAndPrivateOnly] |
Member
There was a problem hiding this comment.
I don't think this warrants being a separate method. Either inline this and remove the TracerManagerTests.cs tests (my preference, seeing as you're already testing this in system tests)
Although, shouldn't we be pushing to use service config to debug this stuff anyway, instead of the logs? 🤷♂️
Comment on lines
+1057
to
+1096
| [Theory] | ||
| #if NET6_0_OR_GREATER | ||
| [InlineData("true", null, true)] | ||
| [InlineData("true", "otlp", true)] | ||
| #else | ||
| [InlineData("true", null, false)] | ||
| [InlineData("true", "otlp", false)] | ||
| #endif | ||
| [InlineData("true", "none", false)] | ||
| [InlineData("false", "otlp", false)] | ||
| public void OtlpMetricsExportEnabled(string metricsEnabled, string exporter, bool expected) | ||
| { | ||
| var source = CreateConfigurationSource( | ||
| (ConfigurationKeys.FeatureFlags.OpenTelemetryMetricsEnabled, metricsEnabled), | ||
| (ConfigurationKeys.OpenTelemetry.MetricsExporter, exporter)); | ||
| var settings = new TracerSettings(source); | ||
|
|
||
| settings.OtlpMetricsExportEnabled.Should().Be(expected); | ||
| } | ||
|
|
||
| [Theory] | ||
| #if NETCOREAPP3_1_OR_GREATER | ||
| [InlineData("true", null, true)] | ||
| [InlineData("true", "otlp", true)] | ||
| #else | ||
| [InlineData("true", null, false)] | ||
| [InlineData("true", "otlp", false)] | ||
| #endif | ||
| [InlineData("true", "none", false)] | ||
| [InlineData("false", "otlp", false)] | ||
| public void OpenTelemetryLogsEnabled(string logsEnabled, string exporter, bool expected) | ||
| { | ||
| var source = CreateConfigurationSource( | ||
| (ConfigurationKeys.FeatureFlags.OpenTelemetryLogsEnabled, logsEnabled), | ||
| (ConfigurationKeys.OpenTelemetry.LogsExporter, exporter)); | ||
| var settings = new TracerSettings(source); | ||
|
|
||
| settings.OpenTelemetryLogsEnabled.Should().Be(expected); | ||
| } | ||
|
|
Member
There was a problem hiding this comment.
meh, not sure we need to test an && clause, given the conversion from string -> setting is tested elsewhere here anyway
Member
There was a problem hiding this comment.
meh, I don't think this is worth testin
MilanGarnier
added a commit
that referenced
this pull request
Oct 9, 2026
## Summary of changes Expose resolved OpenTelemetry configuration as flat uppercase fields in the existing `DATADOG TRACER CONFIGURATION` startup JSON. Added feature gates: - `OTEL_ENABLED` - `DD_TRACE_OTEL_ENABLED` - `DD_METRICS_OTEL_ENABLED` - `DD_LOGS_OTEL_ENABLED` - `DD_TRACE_OTEL_SEMANTICS_ENABLED` Added exporter settings, emitted for each enabled OTLP pipeline: - `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` - `OTEL_EXPORTER_OTLP_TRACES_PROTOCOL` - `OTEL_EXPORTER_OTLP_TRACES_HEADERS` - `OTEL_EXPORTER_OTLP_METRICS_ENDPOINT` - `OTEL_EXPORTER_OTLP_METRICS_PROTOCOL` - `OTEL_EXPORTER_OTLP_METRICS_HEADERS` - `OTEL_EXPORTER_OTLP_LOGS_ENDPOINT` - `OTEL_EXPORTER_OTLP_LOGS_PROTOCOL` - `OTEL_EXPORTER_OTLP_LOGS_HEADERS` Added shared and trace settings: - `OTEL_LOG_LEVEL` - `OTEL_SERVICE_NAME` - `OTEL_RESOURCE_ATTRIBUTES` - `OTEL_PROPAGATORS`, when injection and extraction use the same sequence - `OTEL_TRACES_SAMPLER`, when the managed sampler has a supported global rate - `OTEL_TRACES_SAMPLER_ARG`, for rates strictly between zero and one Added logs settings: - `OTEL_LOGS_EXPORTER` - `OTEL_BLRP_SCHEDULE_DELAY`, when OTLP logs export is enabled - `OTEL_BLRP_MAX_QUEUE_SIZE`, when OTLP logs export is enabled - `OTEL_BLRP_MAX_EXPORT_BATCH_SIZE`, when OTLP logs export is enabled Added metrics settings, emitted when OTLP metrics export is enabled: - `OTEL_METRIC_EXPORT_INTERVAL` - `OTEL_EXPORTER_OTLP_METRICS_TEMPORALITY_PREFERENCE` ## Reason for change [OTEL-3367](https://datadoghq.atlassian.net/browse/OTEL-3367): make the configuration used by OTel integrations and exporters visible at startup, including existing defaults, precedence, and fallback behavior. This extends the idea in [#8936](#8936) to cover exporter, trace, logs, and metrics settings. Whenever possible, it uses the matching "OTEL_" env var name (the main target here is onboarding OTel consumers). ## Implementation details - Share metrics/logs export predicates, including framework support, between runtime code and startup logging; reuse the existing trace export predicate. - Share sampling-rate validation through `EffectiveGlobalSamplingRate` and read propagator names from resolved instances. Emit `OTEL_PROPAGATORS` only when injection and extraction match. - Reuse existing exporter, logs batching, and metrics getters. Redact header values and report intervals in milliseconds. `OTEL_BLRP_*` fields reflect existing `DD_LOGS_DIRECT_SUBMISSION_*` settings, without adding new inputs. - Read the effective log level, service name, and global tags. Resource attributes use the existing `key:value` array representation. ## Test coverage Startup-log coverage is maintained in [system-tests #7978](DataDog/system-tests#7978). No new assertions or test-only serialization methods are added in this PR. Existing configuration, sampling, propagation, and exporter tests were run locally, and the managed targets and integration-test project compiled. A local run against [#7978](DataDog/system-tests#7978) with the tracer built from the earlier implementation revision completed with 15 passed and 12 failed. The missing fields fall into these categories: - Generic `OTEL_EXPORTER_OTLP_*`: report per-signal effective values instead. - Additional `DD_*` fields and `OTEL_TRACES_EXPORTER`: supported settings whose uppercase startup-log fields are not added by this PR. - `OTEL_SEMCONV_STABILITY_OPT_IN` and `DD_DBM_TRACE_PREPARED_STATEMENTS`: unsupported configuration inputs in .NET. - `OTEL_TRACES_SAMPLER_ARG`: only emitted for ratio sampling; the test requires it for `always_on` too. - `OTEL_BLRP_EXPORT_TIMEOUT`: no equivalent setting in the batching sink. ## Other details Uses the existing startup-log emission and controls. Generic OTLP transport fields are omitted because exporters can have different finalized values. `OTEL_BLRP_EXPORT_TIMEOUT` is omitted because the sink has no equivalent finalized setting. The added getters and interface member are internal. [OTEL-3367]: https://datadoghq.atlassian.net/browse/OTEL-3367?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ
This branch has not been deployed
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
2 participants
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.
Summary of changes
Adds
otlp_traces_export_enabled,otlp_metrics_export_enabled, andotlp_logs_export_enabledto theDATADOG TRACER CONFIGURATIONstartup log.Reason for change
The cross-tracer startup-log schema now reports whether each signal is exported with OTLP.
Implementation details
The trace field uses
ExporterSettings.IsOtlpTraceExport. Metrics use a shared, target-awareOtlpMetricsExportEnabledsetting for both pipeline startup and diagnostics. Logs use the effectiveOpenTelemetryLogsEnabledsetting and reportfalseon unsupported target frameworks.Test coverage
Other details
Related system-tests coverage: DataDog/system-tests#7376