Clean up OpenTelemetry content

solutions/observability/apps/apm-server-binary.md

@@ -754,9 +754,9 @@ const apm = initApm({
 ::::::
 
 ::::::{tab-item} OpenTelemetry
-Elastic integrates with OpenTelemetry, allowing you to reuse your existing instrumentation to easily send observability data to the {{stack}}.
+Elastic integrates with OpenTelemetry using the Elastic Distribution of OpenTelemetry (EDOT), allowing you to reuse your existing instrumentation to easily send observability data to the {{stack}}.
 
-For more information on how to combine Elastic and OpenTelemetry, see [OpenTelemetry integration](use-opentelemetry-with-apm.md).
+For more information on how to combine Elastic and OpenTelemetry, see the [EDOT documentation](https://elastic.github.io/opentelemetry/).
 ::::::
 
 :::::::

solutions/observability/apps/fleet-managed-apm-server.md

@@ -801,9 +801,9 @@ const apm = initApm({
 ::::::
 
 ::::::{tab-item} OpenTelemetry
-Elastic integrates with OpenTelemetry, allowing you to reuse your existing instrumentation to easily send observability data to the {{stack}}.
+Elastic integrates with OpenTelemetry using the Elastic Distribution of OpenTelemetry (EDOT), allowing you to reuse your existing instrumentation to easily send observability data to the {{stack}}.
 
-For more information on how to combine Elastic and OpenTelemetry, see [OpenTelemetry integration](use-opentelemetry-with-apm.md).
+For more information on how to combine Elastic and OpenTelemetry, see the [EDOT documentation](https://elastic.github.io/opentelemetry/).
 ::::::
 
 :::::::

solutions/observability/apps/managed-intake-service-event-api.md

@@ -19,7 +19,6 @@ The managed intake service exposes endpoints for:
 * [Elastic APM events intake API](#observability-apm-server-api-events-intake-api)
 * [OpenTelemetry intake API](#observability-apm-server-api-opentelemetry-api)
 
-
 ## Server information API [observability-apm-server-api-server-information-api]
 
 The managed intake service exposes an API endpoint to query general server information. This lightweight endpoint is useful as a server up/down health check.
@@ -4480,8 +4479,6 @@ The managed intake service uses JSON Schema to validate requests. The specificat
 
 ::::
 
-
-
 ## OpenTelemetry API [observability-apm-server-api-opentelemetry-api]
 
 Elastic supports receiving traces, metrics, and logs over the [OpenTelemetry Protocol (OTLP)](https://opentelemetry.io/docs/specs/otlp/). OTLP is the default transfer protocol for OpenTelemetry and is supported natively by the managed intake service.
@@ -4510,8 +4507,5 @@ The managed intake service supports two OTLP communication protocols on the same
 | OTLP logs intake | `/v1/logs` |
 
 ::::{tip}
-See our [OpenTelemetry docs](upstream-opentelemetry-collectors-language-sdks.md) to learn how to send data to the managed intake service from an OpenTelemetry agent OpenTelemetry collector.
-
-::::
-
-
+See our [OpenTelemetry documentation](https://elastic.github.io/opentelemetry/) to learn how to send data to the managed intake service.
+::::

solutions/observability/apps/opentelemetry-intake-api.md

@@ -1,8 +1,6 @@
 ---
 mapped_pages:
   - https://www.elastic.co/guide/en/observability/current/apm-api-otlp.html
-applies_to:
-  stack:
 ---
 
 # OpenTelemetry intake API [apm-api-otlp]
@@ -33,7 +31,7 @@ APM Server supports two OTLP communication protocols on the same port:
 | OTLP logs intake | `/v1/logs` |
 
 ::::{tip}
-See our OpenTelemetry documentation to learn how to send data to the APM Server from an [OpenTelemetry agent](upstream-opentelemetry-collectors-language-sdks.md#apm-instrument-apps-otel) or [OpenTelemetry collector](upstream-opentelemetry-collectors-language-sdks.md#apm-connect-open-telemetry-collector).
+See our [OpenTelemetry documentation](https://elastic.github.io/opentelemetry/) to learn how to send data to the APM Server.
 ::::
 
 

solutions/observability/apps/traces.md

@@ -40,12 +40,6 @@ In this example, Elastic’s Ruby agent communicates with Elastic’s Java agent
 :alt: How traceparent propagation works
 :::
 
-In this example, Elastic’s Ruby agent communicates with OpenTelemetry’s Java agent. Both support the `traceparent` header, and trace data is successfully propagated.
-
-:::{image} /solutions/images/observability-dt-trace-ex2.png
-:alt: How traceparent propagation works
-:::
-
 In this example, the trace meets a piece of middleware that doesn’t propagate the `traceparent` header. The distributed trace ends and any further communication will result in a new trace.
 
 :::{image} /solutions/images/observability-dt-trace-ex3.png

solutions/observability/apps/transaction-sampling.md

@@ -79,24 +79,6 @@ In the example in *Figure 4*, `Service A` and `Service B` are Elastic-monitored
 :title: Using the `restart` trace continuation strategy
 :::
 
-
-### OpenTelemetry [_opentelemetry]
-
-Head-based sampling is implemented directly in the APM agents and SDKs. The sample rate must be propagated between services and the managed intake service in order to produce accurate metrics.
-
-OpenTelemetry offers multiple samplers. However, most samplers do not propagate the sample rate. This results in inaccurate span-based metrics, like APM throughput, latency, and error metrics.
-
-For accurate span-based metrics when using head-based sampling with OpenTelemetry, you must use a [consistent probability sampler](https://opentelemetry.io/docs/specs/otel/trace/tracestate-probability-sampling/). These samplers propagate the sample rate between services and the managed intake service, resulting in accurate metrics.
-
-::::{note}
-OpenTelemetry does not offer consistent probability samplers in all languages. OpenTelemetry users should consider using tail-based sampling instead.
-
-Refer to the documentation of your favorite OpenTelemetry agent or SDK for more information on the availability of consistent probability samplers.
-
-::::
-
-% Stateful only for tail-based sampling
-
 ## Tail-based sampling [apm-tail-based-sampling]
 ```{applies_to}
 stack: all
@@ -129,13 +111,6 @@ In this example, `Service A` initiates four transactions. If our sample rate is
 :alt: Distributed tracing and tail based sampling example one
 :::
 
-
-### OpenTelemetry with tail-based sampling [_opentelemetry_with_tail_based_sampling]
-
-Tail-based sampling is implemented entirely in APM Server, and will work with traces sent by either Elastic APM agents or OpenTelemetry SDKs.
-
-Due to [OpenTelemetry tail-based sampling limitations](../../../solutions/observability/apps/limitations.md#apm-open-telemetry-tbs) when using [tailsamplingprocessor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/tailsamplingprocessor), we recommend using APM Server tail-based sampling instead.
-
 ### Tail-based sampling performance and requirements [_tail_based_sampling_performance_and_requirements]
 
 Tail-based sampling (TBS), by definition, requires storing events locally temporarily, such that they can be retrieved and forwarded when a sampling decision is made.