docs: copy edit deployment pages (#8400)

Co-authored-by: Tiffany Hrabusa <[email protected]>
Co-authored-by: otelbot <[email protected]>

Author: 3 people

content/en/docs/collector/deployment/_index.md

@@ -1,21 +1,22 @@
 ---
-title: Deployment
-description: Patterns you can apply to deploy the OpenTelemetry collector
+title: Deploy the Collector
+linkTitle: Deploy
+description: Patterns you can apply to deploy the OpenTelemetry Collector
 weight: 3
 ---
 
-The OpenTelemetry Collector consists of a single binary which you can use in
-different ways, for different use cases. This section describes deployment
-patterns, their use cases along with pros and cons and best practices for
-collector configurations for cross-environment and multi-backend deployments.
-For deployment security considerations, see [Collector hosting best
+The OpenTelemetry Collector consists of a single binary that you can deploy in
+different ways for different use cases. This section describes common deployment
+patterns, their use cases, and pros and cons. It also provides best practices
+for configuring the Collector in cross-environment and multi-backend scenarios.
+For deployment-related security considerations, see the [Collector hosting best
 practices][security].
 
-## Resources
+## Additional resources
 
-- KubeCon NA 2021 Talk on [OpenTelemetry Collector Deployment
+- KubeCon NA 2021 talk on [OpenTelemetry Collector Deployment
   Patterns][y-patterns]
-- [Deployment Patterns][gh-patterns] accompanying the talk
+  - [Deployment patterns][gh-patterns] accompanying the talk
 
 [security]: /docs/security/hosting-best-practices/
 [gh-patterns]:

content/en/docs/collector/deployment/agent.md

@@ -6,35 +6,37 @@ weight: 2
 cSpell:ignore: prometheusremotewrite
 ---
 
-The agent collector deployment pattern consists of applications —
-[instrumented][instrumentation] with an OpenTelemetry SDK using [OpenTelemetry
-protocol (OTLP)][otlp] — or other collectors (using the OTLP exporter) that send
-telemetry signals to a [collector][] instance running with the application or on
-the same host as the application (such as a sidecar or a daemonset).
+In the agent deployment pattern, telemetry signals can come from
 
-Each client-side SDK or downstream collector is configured with a collector
-location:
+- Applications [instrumented][instrumentation] with an OpenTelemetry SDK using
+  the [OpenTelemetry Protocol (OTLP)][otlp]
+- Collectors using the OTLP exporter
+
+The signals are sent to a [Collector][collector] instance that runs alongside
+the application or on the same host, such as a sidecar or DaemonSet.
+
+Each client-side SDK or downstream Collector is configured with the address of a
+Collector instance:
 
 ![Decentralized collector deployment concept](../../img/otel-agent-sdk.svg)
 
-1. In the app, the SDK is configured to send OTLP data to a collector.
-1. The collector is configured to send telemetry data to one or more backends.
+1. In the application, the SDK is configured to send OTLP data to a Collector.
+1. The Collector is configured to send telemetry data to one or more backends.
 
 ## Example
 
-A concrete example of the agent collector deployment pattern could look as
-follows: you manually instrument, say, a [Java application to export
-metrics][instrument-java-metrics] using the OpenTelemetry Java SDK. In the
-context of the app, you would set the `OTEL_METRICS_EXPORTER` to `otlp` (which
-is the default value) and configure the [OTLP exporter][otlp-exporter] with the
-address of your collector, for example (in Bash or `zsh` shell):
+In this example of the agent deployment pattern, begin by manually instrumenting
+a [Java application to export metrics][instrument-java-metrics] using the
+OpenTelemetry Java SDK, including the default `OTEL_METRICS_EXPORTER` value,
+`otlp`. Next, configure the [OTLP exporter][otlp-exporter] with the address of
+your Collector. For example:
 
 ```shell
 export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.example.com:4318
 ```
 
-The collector serving at `collector.example.com:4318` would then be configured
-like so:
+Next, configure the Collector running at `collector.example.com:4318` as
+follows:
 
 {{< tabpane text=true >}} {{% tab Traces %}}
 
@@ -103,20 +105,22 @@ service:
 
 {{% /tab %}} {{< /tabpane >}}
 
-If you want to try it out for yourself, you can have a look at the end-to-end
-[Java][java-otlp-example] or [Python][py-otlp-example] examples.
+To explore this pattern end to end, see the [Java][java-otlp-example] or
+[Python][py-otlp-example] examples.
+
+## Trade-offs
 
-## Tradeoffs
+Here are the key pros and cons of using an agent collector:
 
 Pros:
 
-- Simple to get started
-- Clear 1:1 mapping between application and collector
+- Straightforward to get started
+- Clear one-to-one mapping between application and Collector
 
 Cons:
 
-- Scalability (human and load-wise)
-- Inflexible
+- Limited scalability for teams and infrastructure resources
+- Inflexible for complex or evolving deployments
 
 [instrumentation]: /docs/languages/
 [otlp]: /docs/specs/otel/protocol/

content/en/docs/collector/deployment/no-collector.md

@@ -1,32 +1,34 @@
 ---
 title: No Collector
-description: Why and how to send signals directly from app to backends
+description:
+  Why and how to send signals directly from an application to backends
 weight: 1
 ---
 
-The simplest pattern is not to use a collector at all. This pattern consists of
-applications [instrumented][instrumentation] with an OpenTelemetry SDK that
-export telemetry signals (traces, metrics, logs) directly into a backend:
+The most direct deployment pattern doesn't use a Collector at all. In this
+approach, applications [instrumented][instrumentation] with an OpenTelemetry SDK
+export telemetry signals (traces, metrics, and logs) straight to a backend:
 
 ![No collector deployment concept](../../img/otel-sdk.svg)
 
 ## Example
 
-See the [code instrumentation for programming languages][instrumentation] for
-concrete end-to-end examples for how to export signals from your app directly
-into a backend.
+See the [instrumentation documentation][instrumentation] for end-to-end examples
+that show how to export signals directly from your application to a backend.
 
-## Tradeoffs
+## Trade-offs
+
+Here are the key pros and cons of skipping the Collector:
 
 Pros:
 
-- Simple to use (especially in a dev/test environment)
-- No additional moving parts to operate (in production environments)
+- Straightforward to use, especially in development and test environments
+- No additional moving parts to deploy or operate
 
 Cons:
 
-- Requires code changes if collection, processing, or ingestion changes
-- Strong coupling between the application code and the backend
-- There are limited number of exporters per language implementation
+- Requires code changes if collection, processing, or ingestion needs change
+- Strong coupling between application code and backend storage or visualization
+- Each language implementation supports only a limited number of exporters
 
 [instrumentation]: /docs/languages/