Rework and consolidate OTLP configuration related pages

CONTRIBUTING.md

@@ -43,7 +43,7 @@ There are several ways you can contribute:
 
 - If you wish to make documentation edits or add new
 documentation, follow our [documentation contribution guidelines](https://docs.newrelic.com/docs/style-guide/writing-guidelines/create-edit-content/#edit-doc).
-- If you'd like to to make code contributions, or make content contributions locally, follow the contribution guidelines below.
+- If you'd like to make code contributions, or make content contributions locally, follow the contribution guidelines below.
 
 ## Getting started
 
@@ -63,7 +63,7 @@ The first time you build the site locally, it will take upwards of 20 minutes. T
 
 ### Dependencies
 
-Node v16 is used in this project as specified in [.nvmrc](https://github.com/newrelic/developer-website/blob/master/.nvmrc).
+Node v18 is used in this project as specified in [.nvmrc](https://github.com/newrelic/developer-website/blob/master/.nvmrc).
 
 ### Unit tests
 

src/content/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/best-practices/opentelemetry-best-practices-traces.mdx

@@ -158,4 +158,4 @@ NRQL query representation
 
 The most important thing to notice with resource attributes is the potential difference in the size of the payload being sent compared to what is stored in NRDB. All resource attribute values will be applied to every span in the OTLP payload. The example above only shows a single span being sent but if the payload contained 100 spans, each one of them would have `process.command_line` and `service.name` applied to them.
 
-For some Java based applications, the default `process.command_line` attribute can be thousands of characters long which may result in a significant and unexpected increase in billable bytes. If these resource attributes do not provide value they can be disabled by following the [OpenTelemetry and attribute lengths: Best Practices](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/best-practices/opentelemetry-best-practices-attributes/)
+For some Java based applications, the default `process.command_line` attribute can be thousands of characters long which may result in a significant and unexpected increase in billable bytes. If these resource attributes do not provide value they can be disabled by following the [OpenTelemetry and attribute lengths: Best Practices](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/best-practices/opentelemetry-otlp/#attribute-limits)

src/content/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/best-practices/opentelemetry-implementation-guide.mdx

@@ -53,7 +53,7 @@ Next, it's time to deploy the OpenTelemetry Collector, which is recommended for
 Here are some tips on configuring the OpenTelemetry Collector:
 
 * <DoNotTranslate>**Use the right endpoint**</DoNotTranslate>. It should be configured to export OTLP data to our endpoint. This is explained in [our docs on sending data from an OpenTelemetry Collector](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/get-started/opentelemetry-set-up-your-app/#review-settings).
-* <DoNotTranslate>**Avoided dropped data**</DoNotTranslate>.To avoid data being dropped, we recommend [truncating](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/best-practices/opentelemetry-best-practices-attributes) any attributes greater than 4095 characters in length. For an example of applying these practices, see [this collector config](https://github.com/newrelic/newrelic-opentelemetry-examples/tree/main/other-examples/collector/nr-config).
+* <DoNotTranslate>**Avoided dropped data**</DoNotTranslate>.To avoid data being dropped, we recommend [truncating](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/best-practices/opentelemetry-otlp/#attribute-limits) any attributes greater than 4095 characters in length. For an example of applying these practices, see [this collector config](https://github.com/newrelic/newrelic-opentelemetry-examples/tree/main/other-examples/collector/nr-config).
 * <DoNotTranslate>**Infrastructure**</DoNotTranslate>. To collect infrastructure metrics, include the [host metrics receiver](/docs/more-integrations/open-source-telemetry-integrations/opentelemetry/collector/opentelemetry-collector-infra-hosts) in the collector config. When using the host receiver as part of the collector configuration, we automatically detect host metrics as part of a host entity and synthesize its golden metrics (in short, you get the same experience as you would with our infrastructure agent).
 * <DoNotTranslate>**Scaling**</DoNotTranslate>. Large OpenTelemetry deployments will need to choose a strategy for scaling the collector, both for performance and resiliency benefits. For details on scaling the collector, see [the OpenTelemetry docs](https://opentelemetry.io/docs/collector/scaling).
 * <DoNotTranslate>**Kubernetes**</DoNotTranslate>.If your OpenTelemetry-instrumented services are running in a Kubernetes environment, follow the steps in [Link OpenTelemetry-instrumented applications to Kubernetes](/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/link-otel-applications-kubernetes). This ensures that your Kubernetes data will be correlated with OpenTelemetry data.
@@ -114,7 +114,7 @@ For more tips on alerting:
 
 New Relic [workloads](/docs/new-relic-solutions/new-relic-one/workloads/workloads-isolate-resolve-incidents-faster) let you group related entities, providing aggregated health and activity data from frontend to backend services across your entire stack. Workloads help you [understand the status of complex systems](/docs/new-relic-solutions/new-relic-one/workloads/use-workloads), [detect issues](/docs/new-relic-solutions/new-relic-one/workloads/workload-status-views-notifications), understand the cause and impact of an incident, and resolve those issues quickly.
 
-We recommend creating workloads to group OpenTelemetry services together with related entities. This could include entities monitored by our infrastructure monitoring, <InlinePopover type="apm" />, Kubernetes monitoring, <InlinePopover type="browser" />, and other entities. Workloads help you group entities into more manageable chunks, typically aligned with the teams responsible for those entities. This is especially valuable for large environments, which might have thousands of monitored entities. 
+We recommend creating workloads to group OpenTelemetry services together with related entities. This could include entities monitored by our infrastructure monitoring, <InlinePopover type="apm" />, Kubernetes monitoring, <InlinePopover type="browser" />, and other entities. Workloads help you group entities into more manageable chunks, typically aligned with the teams responsible for those entities. This is especially valuable for large environments, which might have thousands of monitored entities.
 
 Creating workloads unlocks other valuable features in New Relic, such as [errors inbox](/docs/errors-inbox/errors-inbox). With errors inbox, your teams can proactively detect, triage, and take action on all errors before they impact your customers. Errors are intelligently grouped to cut down on noise and ensure that critical errors are detected quickly and efficiently. This allows your team to resolve errors from across your stack, including errors from APM, browser (RUM), mobile, serverless (AWS Lambda) data, and OpenTelemetry, displayed on one screen.