Replace upstream with contrib

solutions/observability/apm/upstream-opentelemetry-collectors-language-sdks.md

@@ -11,20 +11,20 @@ products:
   - id: cloud-serverless
 ---
 
-# Upstream OpenTelemetry Collectors and language SDKs [apm-open-telemetry-direct]
+# Contrib OpenTelemetry Collectors and language SDKs [apm-open-telemetry-direct]
 
 The {{stack}} natively supports the OpenTelemetry protocol (OTLP). This means logs, metrics, and trace data collected from your applications and infrastructure can be sent directly to the {{stack}}.
 
-* Send data to Elastic from an upstream [OpenTelemetry Collector](/solutions/observability/apm/upstream-opentelemetry-collectors-language-sdks.md#apm-connect-open-telemetry-collector)
-* Send data to Elastic from an upstream [OpenTelemetry language SDK](/solutions/observability/apm/upstream-opentelemetry-collectors-language-sdks.md#apm-instrument-apps-otel)
+* Send data to Elastic from a contrib [OpenTelemetry Collector](/solutions/observability/apm/upstream-opentelemetry-collectors-language-sdks.md#apm-connect-open-telemetry-collector)
+* Send data to Elastic from a contrib [OpenTelemetry language SDK](/solutions/observability/apm/upstream-opentelemetry-collectors-language-sdks.md#apm-instrument-apps-otel)
 
 To compare approaches and choose the best approach for your use case, refer to [OpenTelemetry](/solutions/observability/apm/use-opentelemetry-with-apm.md).
 
 ::::{important}
-The Elastic Distribution of OpenTelemetry Collector (EDOT Collector) include additional features and configurations to seamlessly integrate with Elastic. Refer to [EDOT compared to upstream OpenTelemetry](opentelemetry:///reference/compatibility/edot-vs-upstream.md) for a comparison.
+The Elastic Distribution of OpenTelemetry Collector (EDOT Collector) include additional features and configurations to seamlessly integrate with Elastic. Refer to [EDOT compared to contrib OpenTelemetry](opentelemetry:///reference/compatibility/edot-vs-upstream.md) for a comparison.
 ::::
 
-## Send data from an upstream OpenTelemetry Collector [apm-connect-open-telemetry-collector]
+## Send data from a contrib OpenTelemetry Collector [apm-connect-open-telemetry-collector]
 
 Connect your OpenTelemetry Collector instances to Elastic {{observability}} or {{obs-serverless}} using the OTLP exporter:
 
@@ -147,10 +147,10 @@ You’re now ready to export traces and metrics from your services and applicati
 When using the OpenTelemetry Collector, send data through the [`OTLP` exporter](https://github.com/open-telemetry/opentelemetry-collector/tree/main/exporter/otlphttpexporter). Using other methods, like the [`elasticsearch` exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/elasticsearchexporter), bypasses all of the validation and data processing that Elastic performs. In addition, your data will not be viewable in your Observability project if you use the `elasticsearch` exporter.
 ::::
 
-## Send data from an upstream OpenTelemetry SDK [apm-instrument-apps-otel]
+## Send data from a contrib OpenTelemetry SDK [apm-instrument-apps-otel]
 
 ::::{note}
-The following instructions show how to send data directly from an upstream OpenTelemetry SDK to Elastic, which is appropriate when getting started. However, sending data from an OpenTelemetry SDK to the OpenTelemetry Collector is preferred, as the Collector processes and exports data to Elastic. Read more about when and how to use a collector in the [OpenTelemetry documentation](https://opentelemetry.io/docs/collector/#when-to-use-a-collector).
+The following instructions show how to send data directly from a contrib OpenTelemetry SDK to Elastic, which is appropriate when getting started. However, sending data from an OpenTelemetry SDK to the OpenTelemetry Collector is preferred, as the Collector processes and exports data to Elastic. Read more about when and how to use a collector in the [OpenTelemetry documentation](https://opentelemetry.io/docs/collector/#when-to-use-a-collector).
 ::::
 
 To export traces and metrics to Elastic, instrument your services and applications with the OpenTelemetry API, SDK, or both. For example, if you are a Java developer, you need to instrument your Java app with the [OpenTelemetry agent for Java](https://github.com/open-telemetry/opentelemetry-java-instrumentation). See the [OpenTelemetry Instrumentation guides](https://opentelemetry.io/docs/instrumentation/) to download the OpenTelemetry agent or SDK for your language.
@@ -174,7 +174,7 @@ java -javaagent:/path/to/opentelemetry-javaagent-all.jar \
      com.mycompany.checkout.CheckoutServiceServer
 ```
 
-1. The OpenTelemetry logs intake via APM Server is currently in technical preview. {applies_to}`product: preview`
+1. The OpenTelemetry logs intake through the APM Server is currently in technical preview. {applies_to}`product: preview`
 
 `OTEL_RESOURCE_ATTRIBUTES`
 :   Fields that describe the service and the environment that the service runs in. See [attributes](/solutions/observability/apm/attributes.md) for more information.
@@ -215,7 +215,7 @@ java -javaagent:/path/to/opentelemetry-javaagent-all.jar \
      com.mycompany.checkout.CheckoutServiceServer
 ```
 
-1. The OpenTelemetry logs intake via Elastic is currently in technical preview. {applies_to}`product: preview`
+1. The OpenTelemetry logs intake through Elastic is currently in technical preview. {applies_to}`product: preview`
 
 `OTEL_RESOURCE_ATTRIBUTES`
 :   Fields that describe the service and the environment that the service runs in. See [attributes](/solutions/observability/apm/attributes.md) for more information.
@@ -262,7 +262,7 @@ Many L7 load balancers handle HTTP and gRPC traffic separately and rely on expli
 * Use the `otlp` exporter in the EDOT collector. Set annotation `nginx.ingress.kubernetes.io/backend-protocol: "GRPC"` on the K8s Ingress object proxying to APM Server.
 * Use the `otlphttp` exporter in the EDOT collector. Set annotation `nginx.ingress.kubernetes.io/backend-protocol: "HTTP"` (or `"HTTPS"` if APM Server expects TLS) on the K8s Ingress object proxying to APM Server.
 
-The preferred approach is to deploy a L4 (TCP) load balancer (e.g. [NLB](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) on AWS) in front of APM Server, which forwards raw TCP traffic transparently without protocol inspection.
+The preferred approach is to deploy a L4 (TCP) load balancer (for example, [NLB](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) on AWS) in front of APM Server, which forwards raw TCP traffic transparently without protocol inspection.
 
 For more information on how to configure an AWS ALB to support gRPC, see this AWS blog post: [Application Load Balancer Support for End-to-End HTTP/2 and gRPC](https://aws.amazon.com/blogs/aws/new-application-load-balancer-support-for-end-to-end-http-2-and-grpc/).
 

solutions/observability/apm/use-opentelemetry-with-apm.md

@@ -22,7 +22,7 @@ Elastic offers several distributions of OpenTelemetry. Each Elastic Distribution
 
 With an Elastic Distribution of OpenTelemetry language SDK you have access to all the features of the OpenTelemetry SDK that it customizes, plus:
 
-* You can get access to SDK improvements and bug fixes contributed by the Elastic team before the changes are available upstream in the OpenTelemetry repositories.
+* You can get access to SDK improvements and bug fixes contributed by the Elastic team before the changes are available in the OpenTelemetry repositories.
 * The distribution configures the collection of tracing and metrics signals, applying opinionated defaults, such as which sources are collected by default.
 * By sending data through the [EDOT Collector](opentelemetry://reference/edot-collector/index.md), you make sure to onboard infrastructure logs and metrics.
 
@@ -38,27 +38,27 @@ Get started with an Elastic Distribution of OpenTelemetry language SDK:
 For a complete overview of OpenTelemetry and Elastic, explore [**Elastic Distributions of OpenTelemetry**](opentelemetry://reference/index.md).
 ::::
 
-## Upstream OpenTelemetry Collector and SDKs [apm-otel-upstream]
+## Contrib OpenTelemetry Collector and SDKs [apm-otel-upstream]
 
 The {{stack}} natively supports the OpenTelemetry protocol (OTLP). This means trace data and metrics collected from your applications and infrastructure by an OpenTelemetry Collector or OpenTelemetry language SDK can be sent to the {{stack}}.
 
 You can set up an [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/), instrument your application with an [OpenTelemetry language SDK](https://opentelemetry.io/docs/languages/) that sends data to the Collector, and use the Collector to process and export the data to either the [Managed OTLP endpoint](opentelemetry://reference/motlp.md) or {{apm-server-or-mis}}.
 
-This approach works well when you need to instrument a technology that Elastic doesn’t provide a solution for. For example, if you want to instrument C or C++ you could use the [OpenTelemetry C++ client](https://github.com/open-telemetry/opentelemetry-cpp). However, there are some limitations when using upstream OpenTelemetry collectors and language SDKs, including:
+This approach works well when you need to instrument a technology that Elastic doesn’t provide a solution for. For example, if you want to instrument C or C++ you could use the [OpenTelemetry C++ client](https://github.com/open-telemetry/opentelemetry-cpp). However, there are some limitations when using contrib OpenTelemetry collectors and language SDKs, including:
 
-* Elastic can’t provide implementation support on how to use upstream OpenTelemetry tools.
+* Elastic can’t provide implementation support on how to use contrib OpenTelemetry tools.
 * You won’t have access to Elastic enterprise APM features.
 * You may experience problems with performance efficiency.
 
-For more on the limitations associated with using upstream OpenTelemetry tools, refer to [Limitations](/solutions/observability/apm/limitations.md).
+For more on the limitations associated with using contrib OpenTelemetry tools, refer to [Limitations](/solutions/observability/apm/limitations.md).
 
-[**Get started with upstream OpenTelemetry Collectors and language SDKs →**](/solutions/observability/apm/upstream-opentelemetry-collectors-language-sdks.md)
+[**Get started with contrib OpenTelemetry Collectors and language SDKs →**](/solutions/observability/apm/upstream-opentelemetry-collectors-language-sdks.md)
 
 :::{note}
-To understand the differences between Elastic Distributions of OpenTelemetry and upstream OpenTelemetry, refer to [EDOT compared to upstream OpenTelemetry](opentelemetry://reference/compatibility/edot-vs-upstream.md).
+To understand the differences between Elastic Distributions of OpenTelemetry and contrib OpenTelemetry, refer to [EDOT compared to contrib OpenTelemetry](opentelemetry://reference/compatibility/edot-vs-upstream.md).
 :::
 
-## Upstream OpenTelemetry with Elastic APM agent [apm-otel-api-sdk-elastic-agent]
+## Contrib OpenTelemetry with Elastic APM agent [apm-otel-api-sdk-elastic-agent]
 
 You can use the OpenTelemetry API/SDKs with [Elastic APM agents](/solutions/observability/apm/apm-server-fleet-managed.md#_step_3_install_apm_agents) to translate OpenTelemetry API calls to Elastic APM API calls. This allows you to reuse your existing OpenTelemetry instrumentation to create Elastic APM transactions and spans, avoiding vendor lock-in and having to redo manual instrumentation.
 

solutions/observability/get-started/quickstart-elastic-cloud-otel-endpoint.md

@@ -95,7 +95,7 @@ The final step is to use the {{motlp}} endpoint and your Elastic API key to send
 ::::{tab-set}
 
 :::{tab-item} OpenTelemetry Collector example
-To send data to the {{motlp}} from the {{edot}} Collector or the upstream Collector, configure the `otlp` exporter:
+To send data to the {{motlp}} from the {{edot}} Collector or the contrib Collector, configure the `otlp` exporter:
 
 ```yaml
 exporters:
@@ -109,7 +109,7 @@ Set the API key as an environment variable or directly in the configuration as s
 :::
 
 :::{tab-item} OpenTelemetry SDK example
-To send data to the {{motlp}} from {{edot}} SDKs or upstream SDKs, set the following variables in your application's environment:
+To send data to the {{motlp}} from {{edot}} SDKs or contrib SDKs, set the following variables in your application's environment:
 
 ```bash
 export OTEL_EXPORTER_OTLP_ENDPOINT="https://<motlp-endpoint>"

solutions/observability/get-started/quickstart-monitor-your-application-performance.md

@@ -22,7 +22,7 @@ In this quickstart guide, you’ll learn how to instrument your application usin
 
 * An {{es}} cluster for storing and searching your data, and {{kib}} for visualizing and managing your data. This quickstart is available for all Elastic deployment models. The quickest way to get started with this quickstart is using a trial project on [Elastic serverless](/solutions/observability/get-started.md).
 * A user with the **Admin** role or higher—required to onboard system logs and metrics. To learn more, refer to [User roles and privileges](/deploy-manage/users-roles/cloud-organization/user-roles.md).
-* An Elastic Distribution of OpenTelemetry (EDOT) Collector or the upstream OpenTelemetry Collector running on the host.
+* An Elastic Distribution of OpenTelemetry (EDOT) Collector or the contrib OpenTelemetry Collector running on the host.
 
 :::
 
@@ -31,7 +31,7 @@ In this quickstart guide, you’ll learn how to instrument your application usin
 
 * An {{observability}} project. To learn more, refer to [Create an Observability project](/solutions/observability/get-started.md).
 * A user with the **Admin** role or higher—required to onboard system logs and metrics. To learn more, refer to [Assign user roles and privileges](/deploy-manage/users-roles/cloud-organization/user-roles.md#general-assign-user-roles).
-* An Elastic Distribution of OpenTelemetry (EDOT) Collector or the upstream OpenTelemetry Collector running on the host.
+* An Elastic Distribution of OpenTelemetry (EDOT) Collector or the contrib OpenTelemetry Collector running on the host.
 
 :::
 ::::
@@ -106,6 +106,6 @@ After using the **Applications** page and **Discover** to confirm you’ve inges
 
 * In [Service Map](/solutions/observability/apm/service-map.md), explore how your services are connected and check health indicators. You can also:
 
-* Use [machine learning](/solutions/observability/apm/machine-learning.md) to quickly pinpoint anomalous transactions and see the health of any upstream and downstream services.
+* Use [machine learning](/solutions/observability/apm/machine-learning.md) to quickly pinpoint anomalous transactions and see the health of any contrib and downstream services.
 
 Refer to the [Elastic Observability](/solutions/observability.md) for a description of other useful features.

troubleshoot/ingest/opentelemetry/edot-collector/collector-not-starting.md

@@ -119,5 +119,5 @@ If you're deploying the EDOT Collector using the Elastic Helm charts, try to:
 
 ## Resources
 
-* [Upstream Collector configuration documentation](https://opentelemetry.io/docs/collector/configuration/)  
+* [Collector configuration documentation](https://opentelemetry.io/docs/collector/configuration/)
 * [Elastic Stack Kubernetes Helm Charts](https://github.com/elastic/helm-charts)

troubleshoot/ingest/opentelemetry/edot-sdks/dotnet/index.md

@@ -23,7 +23,7 @@ If you have an Elastic support contract, create a ticket in the [Elastic Support
 
 For most problems, such as when you don't see data in your Elastic Observability backend, first check the EDOT .NET logs. These logs show initialization details and OpenTelemetry SDK events. If you don't see any warnings or errors in the EDOT .NET logs, switch the log level to `Trace` to investigate further.
 
-The {{edot}} .NET includes built-in diagnostic logging. You can direct logs to a file, STDOUT, or, in common scenarios, an `ILogger` instance. EDOT .NET also observes the built-in diagnostics events from the upstream OpenTelemetry SDK and includes those in its logging output. You can collect the log output and use it to diagnose issues locally during development or when working with Elastic support channels.
+The {{edot}} .NET includes built-in diagnostic logging. You can direct logs to a file, STDOUT, or, in common scenarios, an `ILogger` instance. EDOT .NET also observes the built-in diagnostics events from the contrib OpenTelemetry SDK and includes those in its logging output. You can collect the log output and use it to diagnose issues locally during development or when working with Elastic support channels.
 
 ## ASP.NET Core (generic host) logging integration
 
@@ -178,7 +178,7 @@ The following known issues affect EDOT .NET.
 
 ### Missing log records
 
-The upstream SDK currently does not [comply with the spec](https://github.com/open-telemetry/opentelemetry-dotnet/issues/4324) regarding the deduplication of attributes when exporting log records. When you create a log within multiple scopes, each scope may store information using the same logical key. In this situation, the exported data will have duplicated attributes.
+The contrib SDK currently does not [comply with the spec](https://github.com/open-telemetry/opentelemetry-dotnet/issues/4324) regarding the deduplication of attributes when exporting log records. When you create a log within multiple scopes, each scope may store information using the same logical key. In this situation, the exported data will have duplicated attributes.
 
 You are most likely to see this when you log in the scope of a request and enable the `OpenTelemetryLoggerOptions.IncludeScopes` option. ASP.NET Core adds the `RequestId` to multiple scopes. We recommend that you don't enable `IncludeScopes` until the SDK fixes this. When you use the EDOT Collector or the [{{motlp}}](opentelemetry://reference/motlp.md) in serverless, non-compliant log records will fail to be ingested.
 

troubleshoot/ingest/opentelemetry/edot-sdks/java/index.md

@@ -52,7 +52,7 @@ As debugging output is verbose and might produce noticeable overhead on the appl
 - In case of a technical issue or exception with the agent, use [agent debugging](#agent-debugging).
 - If you need details on the captured data, use [per-signal debugging](#per-signal-debugging).
 
-In case of missing data, check first that the technology used in the application is supported in [upstream OpenTelemetry Java Instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md) and in [EDOT Java](opentelemetry://reference/edot-sdks/java/supported-technologies.md).
+In case of missing data, check first that the technology used in the application is supported in [OpenTelemetry Java Instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/supported-libraries.md) and in [EDOT Java](opentelemetry://reference/edot-sdks/java/supported-technologies.md).
 
 ### Agent debugging
 
@@ -122,7 +122,7 @@ Executing the agent jar as an application with `java -jar elastic-otel-javaagent
 
 Also, you can inspect the `Implementation-Version` entry in `META-INF/MANIFEST.MF` file of the agent jar, for example with `unzip -p elastic-otel-javaagent.jar META-INF/MANIFEST.MF|grep 'Implementation-Version'`.
 
-## Versions of the OpenTelemetry upstream dependencies
+## Versions of the OpenTelemetry contrib dependencies
 
 Because EDOT Java is a distribution of [OpenTelemetry Java instrumentation](https://github.com/open-telemetry/opentelemetry-java-instrumentation), it includes the following dependencies: