fix(OTEL): Collector feedback from SME

src/content/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/collector/opentelemetry-collector-basic.mdx

@@ -9,7 +9,7 @@ metaDescription: Here is a simple Docker example to set up an OpenTelemetry coll
 
 Instead of sending telemetry from your apps directly to New Relic, you can first send it to an OpenTelemetry collector. You can use the collector to process your telemetry data, and then export it to New Relic (or any other back-end). To learn about what kinds of processing you can do in the collector, see our [introduction](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/collector/opentelemetry-collector-intro).
 
-For a basic setup of the collector if you are **not** monitoring infrastructure hosts, follow the Docker example below.
+The Docker example below is meant to serve as starting point from which you can extend, customize, and validate configurations before using them in production.
 
 The collector setup is part of the larger process of setting up OpenTelemetry with New Relic. If you haven't already done so, make sure you've completed "Step 2. Instrument your service with OpenTelemetry" in our [primary instructions](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-quick-start/#instrument). Then, as a substitute for "Step 3. Export your telemetry data to New Relic," complete the steps below:
 

src/content/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/collector/opentelemetry-collector-infra-hosts.mdx

@@ -125,7 +125,10 @@ CPU, load, memory and disk utilization metrics require otelcol-contri release `v
     </tbody>
 </table>
 
-Here is a sample configuration YAML file:
+Here is a sample configuration YAML file. Be sure to do the following:
+
+  * Replace <var>OTLP_ENDPOINT_HERE</var> with the appropriate [endpoint](#review-settings.
+  * Replace <var>YOUR_KEY_HERE</var> with your account's [license key](https://one.newrelic.com/launcher/api-keys-ui.launcher).
 
 ```
 extensions:
@@ -178,11 +181,11 @@ processors:
   resourcedetection:
     detectors: [env, system]
 
-exporters: 
+exporters:
   otlp:
-    endpoint: otlp.nr-data.net:4317
+    endpoint: <var>OTLP_ENDPOINT_HERE</var>
     headers:
-      api-key: *****INGEST_LICENSE_KEY*****
+      api-key: <var>YOUR_KEY_HERE</var>
 
 service:
   pipelines:
@@ -224,54 +227,6 @@ The following NRQL queries show examples to help you explore the metrics you rec
 
 Learn more about [querying the metric data type](/docs/data-apis/understand-data/metric-data/query-metric-data-type).
 
-## Additional settings [#additional-settings]
-
-A variety of other settings are available for your setup.
-
-### Health Check [#health-check]
-
-The health check is an extension to the primary functionality of the collector and ensures the collector is working.
-
-For setup details, see [health_check (GitHub)](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/troubleshooting.md#health-check)
-
-When enabled, the local endpoint using localhost:13133 returns the following response:
-
-```
-{
-  "status": "Server available",
-  "upSince": "2015-10-21T12:00:00.6847174Z",
-  "uptime": "50.0123456s"
-}
-```
-
-### Environment variables [#env-variables]
-
-The collector configuration supports the use and expansion of environment variables. For example:
-
-```
-processors:
-  attributes/example:
-    actions:
-      - key: "${DB_KEY}"
-        action: "${OPERATION}"
-```
-
-### Proxy support [#proxy-support]
-
-Exporters that leverage the net/http package respect the following proxy environment variables:
-
-  * HTTP_PROXY
-  * HTTPS_PROXY
-  * NO_PROXY
-
-If these environment variables are set when the collector starts, then exporters, regardless of protocol, will or will not proxy traffic.
-
-### Authentication [#authentication]
-
-Most `receivers` exposing an HTTP or gRPC port can be protected using the collector’s [authentication mechanism](https://opentelemetry.io/docs/collector/configuration/#authentication), and most `exporters` using HTTP or gRPC clients can add authentication data to the outgoing requests.
-
-For a list of known authenticators, use the [Registry](https://opentelemetry.io/registry/?s=authenticator&component=extension&language=) available in the OpenTelemetry website.
-
 ## Troubleshooting the OpenTelemetry collector [#troubleshooting-collector]
 
 The best place for troubleshooting tips and monitoring practices is the up-to-date guidelines in the OpenTelemetry community.

src/content/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/collector/opentelemetry-collector-intro.mdx

@@ -23,6 +23,8 @@ In many cases, the collector is an optional component, but you may need it for a
     * To ingest signals in a variety of formats (Jaeger, Prometheus, Fluent Bit, etc).
     * To send data to multiple observability back-ends.
     * To transform metrics or change the names of spans before exporting them to an observability back-end.
+    * To offload the work of sending data over the network when you're running resource-intensive services.
+    * To enrich telemetry (metrics, traces and logs) with additional metadata.
 
 ## Learn about how the collector works [#learn]
 

src/content/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/collector/opentelemetry-general-coll-configs.mdx

@@ -0,0 +1,54 @@
+---
+title: "General OpenTelemetry collector configurations"
+tags:
+  - Integrations
+  - Open source telemetry integrations
+  - OpenTelemetry
+metaDescription: Here are some general configurations for your collector.
+---
+
+A variety of general configurations are available for your collector setup.
+
+### Health Check [#health-check]
+
+The health check is an extension to the primary functionality of the collector and ensures the collector is working.
+
+For setup details, see [health_check (GitHub)](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/troubleshooting.md#health-check)
+
+When enabled, the local endpoint using localhost:13133 returns the following response:
+
+```
+{
+  "status": "Server available",
+  "upSince": "2015-10-21T12:00:00.6847174Z",
+  "uptime": "50.0123456s"
+}
+```
+
+### Environment variables [#env-variables]
+
+The collector configuration supports the use and expansion of environment variables. For example:
+
+```
+processors:
+  attributes/example:
+    actions:
+      - key: "${DB_KEY}"
+        action: "${OPERATION}"
+```
+
+### Proxy support [#proxy-support]
+
+Exporters that leverage the net/http package respect the following proxy environment variables:
+
+  * HTTP_PROXY
+  * HTTPS_PROXY
+  * NO_PROXY
+
+If these environment variables are set when the collector starts, then exporters, regardless of protocol, will or will not proxy traffic.
+
+### Authentication [#authentication]
+
+Most `receivers` exposing an HTTP or gRPC port can be protected using the collector’s [authentication mechanism](https://opentelemetry.io/docs/collector/configuration/#authentication), and most `exporters` using HTTP or gRPC clients can add authentication data to the outgoing requests.
+
+For a list of known authenticators, use the [Registry](https://opentelemetry.io/registry/?s=authenticator&component=extension&language=) available in the OpenTelemetry website.

src/nav/integrations.yml

@@ -24,6 +24,8 @@ pages:
             path: /docs/more-integrations/open-source-telemetry-integrations/opentelemetry/collector/opentelemetry-collector-basic
           - title: Collector for host monitoring
             path: /docs/more-integrations/open-source-telemetry-integrations/opentelemetry/collector/opentelemetry-collector-infra-hosts
+          - title: General collector configurations
+            path: /docs/more-integrations/open-source-telemetry-integrations/opentelemetry/collector/opentelemetry-general-coll-configs
       - title: Reference architecture
         path: /docs/more-integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-ref-architecture
       - title: Troubleshooting