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
This comment has been minimized.
This comment has been minimized.
🟢 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".
| writer.name("otlp_traces_export_enabled"); | ||
| writer.value(config.isTraceOtlpExporterEnabled()); | ||
| writer.name("otlp_metrics_export_enabled"); | ||
| writer.value(config.isMetricsOtelEnabled() && config.isMetricsOtlpExporterEnabled()); |
There was a problem hiding this comment.
When users enable dd.otel.traces.span.metrics.enabled=true while leaving the OpenTelemetry metrics signal disabled, the tracer still routes client-side trace metrics through OtlpStatsMetricWriter in MetricsAggregatorFactory, but this startup-log field remains false because it only checks metrics.otel.enabled && metrics.otel.exporter=otlp. That makes the new diagnostic field under-report OTLP metrics export for traced traffic in exactly the explicit span-metrics override case, so support tooling or system tests reading otlp_metrics_export_enabled can conclude no OTLP metrics are being sent while the tracer is actually exporting them.
Useful? React with 👍 / 👎.
| writer.name("data_streams_transaction_extractors"); | ||
| writer.value(config.getDataStreamsTransactionExtractors()); | ||
| writer.name("otlp_traces_export_enabled"); | ||
| writer.value(config.isTraceOtlpExporterEnabled()); |
There was a problem hiding this comment.
When dd.trace.otel.exporter=otlp is combined with an explicit dd.writer.type override such as DDAgentWriter or LoggingWriter, Config still reports the OTLP exporter as selected here, but WriterFactory uses config.getWriterType() to build that non-OTLP writer instead. In that configuration the startup log now says otlp_traces_export_enabled=true even though trace payloads are not exported over OTLP, which makes the new cross-tracer diagnostic field misleading for users who override the writer.
Useful? React with 👍 / 👎.
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>
1 participant
What Does This Do
Adds three boolean fields to the "DATADOG TRACER CONFIGURATION" startup log emitted by
dd-trace-core'sStatusLogger.toJson:otlp_traces_export_enabled:config.isTraceOtlpExporterEnabled()otlp_metrics_export_enabled:config.isMetricsOtelEnabled() && config.isMetricsOtlpExporterEnabled()otlp_logs_export_enabled:config.isLogsOtelEnabled() && config.isLogsOtlpExporterEnabled()Also adds a new
StatusLoggerTestcovering the default (disabled) case, the fully-enabled case, and the case where the OTLP exporter is selected but the metrics and logs OTel signals stay disabled.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
Traces report directly from the OTLP exporter setting. Metrics and logs require both the OTel signal to be enabled and the OTLP exporter to be selected, so those two fields combine both checks.
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 issueRelated PRs — cross-tracer OTLP startup-log effort