Made some minor edits for clarity and brevity.

* Made minor changes according to style guide.
* Inserted anchors for headings.
* Changed hierarchy of headings so they are all siblings. This may not be accurate, but it seems like each of these sections are parallel.
* Made minor wording changes.

src/content/docs/integrations/open-source-telemetry-integrations/opentelemetry/opentelemetry-logs.mdx

@@ -6,33 +6,34 @@ tags:
   - OpenTelemetry
 ---
 
-## Introduction
+Logs are one of the core data types in OpenTelemetry. They may represent application logs, machine generated events, or system logs. The logging [data model](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md) describes them in detail.
 
-Logs are one of the core data types in OpenTelemetry. They may represent application logs, machine generated events, system logs. The logging [data model](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md) describes them in detail.
+Let's look at how to send logs, correlate them with applications, and view them in New Relic.
 
-### Sending Logs to New Relic
+## Send logs to New Relic [#send-logs]
 
 The [New Relic Exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/newrelicexporter) for the [OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) supports exporting logs to New Relic. The general pattern is to configure the collector to:
 
-1. Receive logs from any of the log receivers. Some of the receiver options include [Filelog Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/filelogreceiver), [Fluent Forward Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/fluentforwardreceiver), [Syslog Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/syslogreceiver).
-2. Process logs, potentially annotating them with resource information. Some of the processor options include [Resource Detection Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/resourcedetectionprocessor), and [Resource Processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/resourceprocessor).
+1. Receive logs from any of the log receivers. Some of the receiver options include [Filelog Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/filelogreceiver), [Fluent Forward Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/fluentforwardreceiver), and [Syslog Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/syslogreceiver).
+2. Process logs, potentially annotating them with resource information. Some of the processor options include [Resource Detection Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/resourcedetectionprocessor) and [Resource Processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/resourceprocessor).
 3. Export logs via the [New Relic Exporter](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/exporter/newrelicexporter).
 
-#### Application Log Correlation
+## Application log correlation [#log-correlation]
 
-Application logs are more useful if they're correlated with other telemetry data produced by the application. The OpenTelemetry [semantic convention for services](https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/resource/semantic_conventions#service) specifies `service.name` as a required field. All application metric, trace, and log data sent to New Relic with the same `service.name` will be assocaited with the same [entity](/docs/new-relic-one/use-new-relic-one/core-concepts/what-entity-new-relic).
+Application logs are more useful if they're correlated with other telemetry data produced by the application. The OpenTelemetry [semantic convention for services](https://github.com/open-telemetry/opentelemetry-specification/tree/main/specification/resource/semantic_conventions#service) specifies `service.name` as a required field. All application metric, trace, and log data sent to New Relic with the same `service.name` are associated with the same [entity](/docs/new-relic-one/use-new-relic-one/core-concepts/what-entity-new-relic).
 
-The specifics of how logs get annotated with the `service.name` resource attribute will depend on the application's environment:
+The specifics of how logs get annotated with the `service.name` resource attribute depends on the application's environment:
 
-- Applications may produce structured JSON logs which can be configured to include `service.name` as another field.
-- Applications may be deployed alongside a dedicated [Collector Agent](https://opentelemetry.io/docs/collector/getting-started/#agent) instance, which can be configured with a [Resource Processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/resourceprocessor) to annotate logs with the `service.name` attribute.
+- Applications may produce structured JSON logs, which you can configure to include `service.name` as another field.
+- You can deploy applications alongside a dedicated [Collector Agent](https://opentelemetry.io/docs/collector/getting-started/#agent) instance, which you can configure with a [Resource Processor](https://github.com/open-telemetry/opentelemetry-collector/tree/main/processor/resourceprocessor) to annotate logs with the `service.name` attribute.
 
-Optionally, additional application [trace context](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/overview.md#log-correlation) (sometimes called execution context) can be propogated to log messages. The setup and availability of this will be dependent on the language and logging framework used by the application. The general strategy is to setup the application to write structured JSON logs, and to configure it to extract trace context into specified [trace context fields](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#trace-context-fields) on logs messages when available.
+Optionally, additional application [trace context](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/overview.md#log-correlation) (sometimes called execution context) can be propogated to log messages. The setup and availability of this depends on the language and logging framework used by the application. The general strategy is to set up the application to write structured JSON logs and to configure it to extract trace context into specified [trace context fields](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/logs/data-model.md#trace-context-fields) on available logs messages.
 
 The [Logs in Context With Log4j2](https://github.com/newrelic/newrelic-opentelemetry-examples/tree/main/java/logs-in-context-log4j2) example demonstrates an end-to-end working example for a simple Java application using Log4j2.
 
-### Viewing OpenTelemetry Logs
+## View OpenTelemetry logs [#view-logs]
 
-OpenTelemetry logs can be viewed in the [Logs UI](http://localhost:8000/docs/logs/log-management/ui-data/use-logs-ui/).
+Here are two ways you can view logs:
 
-If logs are correlated with an application, they can viewed in the [context of the application](/docs/integrations/open-source-telemetry-integrations/opentelemetry/view-your-opentelemetry-data-new-relic.mdx#logs).
+* Look in the [Logs UI](http://localhost:8000/docs/logs/log-management/ui-data/use-logs-ui/).
+* If your logs are correlated with an application, view them in the [context of the application](/docs/integrations/open-source-telemetry-integrations/opentelemetry/view-your-opentelemetry-data-new-relic#logs).