Report OTLP export status in tracer startup log - #12062
Conversation
Report whether the tracer exports each telemetry signal over OTLP in the "DATADOG TRACER CONFIGURATION" startup log via three boolean fields: otlp_traces_export_enabled, otlp_metrics_export_enabled, and otlp_logs_export_enabled. Metrics and logs require both the OTel signal to be enabled and the OTLP exporter to be selected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
bm1549
added
type: feature
|
🎯 Code Coverage (details) 🔗 Commit SHA: c884de5 | Docs | Datadog PR Page | Give us feedback! |
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
![datadog-official[bot]](https://avatars.githubusercontent.com/in/1358509?s=60&v=4){kind=small}
There was a problem hiding this comment.
More details
The startup log fields match the runtime activation rules: traces follow OTLP exporter selection, while metrics and logs require both their OTel signal and OTLP exporter to be enabled. Alternate exporters, mixed signal states, and case variations are handled by the existing accessors; no diff-only behavioral regression was identified.
🤖 Datadog Autotest · Commit a4287c5 · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a4287c54a9
ℹ️ 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".
Report otlp_traces_export_enabled from the resolved writer type (OtlpWriter) rather than the OTLP exporter selection, since an explicit dd.writer.type override wins over dd.trace.otel.exporter=otlp in WriterFactory. Also report otlp_metrics_export_enabled when client-side span metrics are enabled, since those are exported over OTLP via OtlpStatsMetricWriter independently of the OTel metrics signal. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PerfectSlayer
left a comment
PerfectSlayer
left a comment
There was a problem hiding this comment.
Minor comments about style
Move the three derived booleans out of StatusLogger.toJson and into Config accessors: isOtlpTracesExportEnabled, isOtlpMetricsExportEnabled, and isOtlpLogsExportEnabled. Every other field toJson emits forwards a Config getter, so keeping the conjunctions inline made this method the only place in the file that derives a value it writes. Fix otlp_traces_export_enabled. It compared dd.writer.type to OtlpWriter for equality, so MultiWriter:OtlpWriter,DDAgentWriter reported false even though WriterFactory builds a real OtlpWriter for it. isOtlpTracesExportEnabled now mirrors WriterFactory's dispatch: a writer type that does not start with MultiWriter is compared to OtlpWriter directly, and one that does has every literal MultiWriter: removed before the remainder is split on commas and each sub-type compared. Removing every occurrence rather than a single leading prefix matches what MultiWriter itself does, so a repeated prefix such as MultiWriter:DDAgentWriter,MultiWriter:OtlpWriter resolves the same way in both places. Drop the two comment blocks in StatusLogger explaining writer precedence and span-metrics routing, and the three in StatusLoggerTest. StatusLogger carries no comments anywhere else, and the reasoning belongs in the commit message and pull request, which both record it. Expand StatusLoggerTest to 13 tests and assert with assertFalse and assertTrue instead of assertEquals against boolean literals. The new cases pin the writer type grammar: a MultiWriter list that includes OtlpWriter, one that excludes it, a repeated MultiWriter prefix, a padded sub-type, a sub-type that only prefixes OtlpWriter, a comma-separated list without the MultiWriter prefix, and a TraceStructureWriter value that WriterFactory dispatches before it ever reaches the MultiWriter branch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| if (!writerType.startsWith(MULTI_WRITER_TYPE)) { | ||
| return OTLP_WRITER_TYPE.equals(writerType); | ||
| } | ||
| String multiWriterConfig = MULTI_WRITER_PREFIX.matcher(writerType).replaceAll(""); |
There was a problem hiding this comment.
| String multiWriterConfig = MULTI_WRITER_PREFIX.matcher(writerType).replaceAll(""); | |
| String multiWriterConfig = writerType.substring(MULTI_WRITER_TYPE.length() + 1); |
saves needing the extra regex, which almost all the time will never be used.
There was a problem hiding this comment.
Dropped both regexes in 4db8aa4, but went with Strings.replace(writerType, MULTI_WRITER_TYPE + ":", "") rather than the substring. MultiWriter strips every MultiWriter: occurrence before splitting, not just the leading one, so MultiWriter:DDAgentWriter,MultiWriter:OtlpWriter really does build an OtlpWriter and the substring would miss it (tracesExportedWhenMultiWriterPrefixRepeats covers that). Substring also throws on a bare MultiWriter with no colon. Strings.replace is the same helper WriterFactory already uses for the TraceStructureWriter prefix, and nothing gets compiled at class-init now.
| private static final Pattern COLON = Pattern.compile(":"); | ||
| private static final Pattern COMMA = Pattern.compile(","); | ||
| private static final Pattern MULTI_WRITER_PREFIX = | ||
| Pattern.compile(MULTI_WRITER_TYPE + ":", Pattern.LITERAL); |
There was a problem hiding this comment.
This will never be used for most deployments, and is the same as dropping the same number of characters as the matched string (+ 1) from the string.
| return OTLP_WRITER_TYPE.equals(writerType); | ||
| } | ||
| String multiWriterConfig = MULTI_WRITER_PREFIX.matcher(writerType).replaceAll(""); | ||
| for (String subWriterType : COMMA.split(multiWriterConfig)) { |
There was a problem hiding this comment.
Given that almost all deployments will never reach this code, is it worth pre-compiling the regex and always taking that hit - rather than just using multiWriterConfig.split(","); and doing it lazily?
There was a problem hiding this comment.
Dropped in 4db8aa4 - it's multiWriterConfig.split(",") now. A single non-metacharacter argument takes String.split's fast path, so no Pattern gets compiled there either.
Remove the COMMA and MULTI_WRITER_PREFIX Patterns. Both were compiled in
Config's static initializer, so every deployment paid for them even though only
a MultiWriter writer type reaches the branch that used them.
Strip the prefix with Strings.replace, the same helper WriterFactory already
uses to strip the TraceStructureWriter prefix, and split with String.split(","),
whose single non-metacharacter argument takes the fast path that compiles no
Pattern. Strings.replace deletes every occurrence rather than only the leading
one, so it stays output-identical to the Pattern it replaces and keeps mirroring
what MultiWriter does; a leading substring would report false for
MultiWriter:DDAgentWriter,MultiWriter:OtlpWriter, which does build an
OtlpWriter, and would throw on a bare MultiWriter with no colon.
Behavior is unchanged and the 13 StatusLoggerTest cases pass untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-authored-by: Stuart McCulloch <stuart.mcculloch@datadoghq.com>
Co-authored-by: Stuart McCulloch <stuart.mcculloch@datadoghq.com>
3 participants
What Does This Do
Adds three boolean fields to the
DATADOG TRACER CONFIGURATIONstartup log emitted bydd-trace-core'sStatusLogger:otlp_traces_export_enabledConfig.isOtlpTracesExportEnabled()OtlpWriter, directly or as a flatMultiWritersub-writerotlp_metrics_export_enabledConfig.isOtlpMetricsExportEnabled()(isMetricsOtelEnabled() && isMetricsOtlpExporterEnabled()) || isOtelTracesSpanMetricsEnabled()otlp_logs_export_enabledConfig.isOtlpLogsExportEnabled()isLogsOtelEnabled() && isLogsOtlpExporterEnabled()The three accessors live on
Config, matching the other values thatStatusLogger.toJsonwrites.StatusLoggerTestadds 12 tests for the default and fully enabled cases, disabled OTel signals, both routes to metrics export, writer-type precedence, and seven direct or flatMultiWriterconfigurations.Motivation
Part of a cross-tracer effort to report OTLP export status in each tracer's startup log. The JSON keys are identical across the dd-trace-* libraries so the fields can be read the same way regardless of language.
Additional Notes
The traces field cannot read
dd.trace.otel.exporteralone because an explicitdd.writer.typetakes precedence.isOtlpTracesExportEnabledfollows that resolved setting and recognizesOtlpWriterin the supported flatMultiWriter:a,bform.Metrics export has two triggers: the OTel metrics signal paired with the OTLP exporter, or
dd.trace.otel.span.metrics.enabled, which routes span metrics over OTLP on its own.Validated with the focused
StatusLoggerTest,:internal-api:forbiddenApisMain, and Spotless checks forinternal-apianddd-trace-core.This is a diagnostic logging change and does not alter tracer runtime behavior.
Contributor Checklist
type:and (comp:orinst:) labels in addition to any other useful labelsclose,fix, or any linking keywords when referencing an issueUse
solvesinstead, and assign the PR milestone to the issueJira ticket: N/A
Related PRs