Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update OTel service entry span mapping docs #23088

Merged
merged 2 commits into from
May 13, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@
Datadog uses [service-entry spans][1] throughout the platform for features such as [Trace Metrics][2] and the [APM Trace Explorer][3]. This convention is unique to Datadog, but can be mapped from the [`SpanKind`][4] attribute in OpenTelemetry by following the opt-in guide below.

## Opting in to the feature
To opt into the **public beta**, enable the config option depending on the ingestion path.
This feature has been released with OTel Collector Contrib v0.100.0 and Datadog Agent v7.53.0. To opt into the **public beta**, enable the config option depending on the ingestion path.

Check notice on line 20 in content/en/opentelemetry/schema_semantics/service_entry_spans.md

View workflow job for this annotation

GitHub Actions / vale

Datadog.sentencelength

Suggestion: Try to keep your sentence length to 25 words or fewer.
liustanley marked this conversation as resolved.
Show resolved Hide resolved

{{< tabs >}}
{{% tab "OTel Collector and Datadog Exporter" %}}
Expand Down Expand Up @@ -51,7 +51,7 @@

This new service-entry span identification logic may increase the number of spans that generate trace metrics, which may affect existing monitors that are based on trace metrics. Users who only have internal spans will see a decrease in trace metrics.

If you have existing monitors based on trace metrics, you can update them after upgrading since this change introduces more consistency in trace metrics. If you only have internal span, update your instrumentation according to the above table to receive trace metrics and service-entry spans.
If you have existing monitors based on trace metrics, you can update them after upgrading since this change introduces more consistency in trace metrics. If you only have internal spans, update your instrumentation according to the above table to receive trace metrics and service-entry spans.

[`SpanKind`][4] is typically set when a span is created, but can also be updated by using the [transform processor][5] in the OpenTelemetry Collector to control the mapping above. For example, if trace metrics are desired for an internal span, the following configuration transforms an internal span with `http.path: "/health"` into a client span:
```yaml
Expand Down