Remove gratuitous TODO

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

@@ -8,9 +8,7 @@ tags:
 
 ## Introduction
 
-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. 
-
-TODO
+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.
 
 ### Sending Logs to New Relic
 
@@ -22,19 +20,19 @@ The [New Relic Exporter](https://github.com/open-telemetry/opentelemetry-collect
 
 #### Application 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` will be assocaited 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:
 
-- 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 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.
 
-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 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.
 
 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
 
-OpenTelemetry logs can be viewed in the [Logs UI](http://localhost:8000/docs/logs/log-management/ui-data/use-logs-ui/). 
+OpenTelemetry logs can be viewed in the [Logs UI](http://localhost:8000/docs/logs/log-management/ui-data/use-logs-ui/).
 
-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).
+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).