feat: initial support for otelc instrumentation#4998
Conversation
Config Audit |
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 2220394 | Docs | Datadog PR Page | Give us feedback! |
BenchmarksBenchmark execution time: 2026-07-16 21:35:57 Comparing candidate commit 2220394 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 326 metrics, 0 unstable metrics, 1 flaky benchmarks without significant changes.
|
67fe74c to
b23daf5
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b23daf5462
ℹ️ 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".
| contrib_path="${integration//_//}" | ||
| if [[ -d "${CONTRIB_DIR}/${contrib_path}" ]] && [[ -n "$(find "${CONTRIB_DIR}/${contrib_path}" -type f -name otelc.yaml -print -quit)" ]]; then |
There was a problem hiding this comment.
Derive OTelc test selection from real contrib paths
I checked the current contrib layout, and this transformation only replaces underscores, so integration dirs such as gin and go-redis.v9 are checked as contrib/gin and contrib/go-redis.v9 even though the real instrumentation dirs are contrib/gin-gonic/gin and contrib/redis/go-redis.v9. When those integrations add otelc.yaml, this workflow will silently skip their packages and can report success without running most OTelc integration tests.
Useful? React with 👍 / 👎.
| __dd_span_ctx := context.TODO() | ||
| __dd_span, __dd_span_ctx = tracer.StartSpanFromContext(__dd_span_ctx, "{{FuncName}}") |
There was a problem hiding this comment.
Propagate existing contexts in directive spans
When an annotated function is passed a context or request that already carries the active span, this template always starts from context.TODO(), so StartSpanFromContext cannot parent the new span to the caller's trace and the //otelc:span span is emitted as a separate root trace. This breaks trace hierarchy for the common case of adding directive spans inside handlers or request-scoped helpers; use the function's context/request when available before falling back to TODO.
Useful? React with 👍 / 👎.
|
|
||
| # Add otelc version if in otelc mode | ||
| if [[ "$MODE" == "otelc" ]]; then | ||
| JSON=$(echo "$JSON" | jq --arg otelc_version "$OTELC_VERSION" '. + {otelc_version: $otelc_version}') |
There was a problem hiding this comment.
Publish the OTelc version tag with metrics
This records otelc_version in the JSON artifact, but scripts/publish_build_metrics.sh only reads and tags orchestrion_version, so the new OTelc build-metric jobs publish Datadog metrics without the tool version. When the script clones OTelc from moving main, those metrics cannot be correlated to the OTelc revision that produced them unless the publish path consumes this field too.
Useful? React with 👍 / 👎.
What does this PR do?
Provides initial
otelcsupport using dd-trace-go, including://otelc:spandirectiveotelc.yamlto exist in contrib directories)otelcto the Build Metrics pipeline (currently does nothing, as no integrations haveotelcinstrumentation)Motivation
Provide
otelcsupport for customersReviewer's Checklist
make lintlocally.make testlocally.make generatelocally.make fix-moduleslocally.Unsure? Have a question? Request a review!