edits

#7655

modules/ROOT/pages/microprofile-telemetry.adoc

@@ -24,11 +24,11 @@ OpenTelemetry is implemented in Open Liberty through the feature:mptelemtry[disp
 To collect and export logs, metrics, and traces with OpenTelemetry in your Open Liberty runtime, you must add the MicroProfile Telemetry feature to your `server.xml` file and specify the `otel.sdk.disabled=false` system property in one of the valid configuration sources. Depending on whether your runtime hosts a single application or multiple applications, you can specify this property at the runtime level or the application level. In most cases, runtime-level configuration is preferred because it includes both runtime-level telemetry and application-specific telemetry. The following table summarizes the benefits and use cases for each option.
 
 .OpenTelemetry configuration options
-[options="header"cols="4,2,6a,3a"]
+[options="header"cols="2,2,6a,6a"]
 |===
 |Configuration level | Use case | Description | Configuration sources
 
-| Runtime level
+| <<#runtime, Runtime level>>
 | One application per Liberty runtime
 | Collects and emits telemetry from both the runtime and the application.
 | * `bootstrap.properties` file
@@ -37,13 +37,14 @@ To collect and export logs, metrics, and traces with OpenTelemetry in your Open
 +
 If you choose to use the `server.env` file, specify the `OTEL_SDK_DISABLED=false` environment variable instead of the `otel.sdk.disabled=false` configuration property.
 
-| Application level
+| <<#app, Application level>>
 | Multiple applications in the same Liberty runtime
 | Collects and emits telemetry for a single application and does not include runtime-level data. Provides fine-grained control over data collection for each application.
 | * `microprofile-config.properties` file
 * `appProperties` attribute for the config:application[] element in the `server.xml` file.
 |===
 
+[#runtime]
 === Enabling OpenTelemetry for an Open Liberty runtime with a single application
 
 When your Open Liberty runtime hosts only one application, you can enable OpenTelemetry at the runtime level to collect and export logs, metrics, and traces for both the runtime and the application.
@@ -66,6 +67,7 @@ otel.sdk.disabled=false
 
 After you enable the MicroProfile Telemetry feature and set this system property, your runtime is ready to start collecting and exporting logs, metrics, and traces from the application and the runtime. For more information, see <<config,OpenTelemetry settings and configuration>>.
 
+[#app]
 === Enabling OpenTelemetry for multiple applications in the same Open Liberty runtime
 
 When your Liberty runtime hosts multiple applications, you might choose to enable OpenTelemetry to collect logs, metrics, and traces at the application level for each application. Although this option does not collect runtime-level telemetry, it gives you fine-grained control of the data you collect for each application.
@@ -122,16 +124,16 @@ After you enable the MicroProfile Telemetry feature and set the `otel.sdk.disabl
 [#config]
 == OpenTelemetry settings and configuration
 
-By default, all OpenTelemetry data is exported byb using the link:https://github.com/open-telemetry/oteps/blob/main/text/0035-opentelemetry-protocol.md[OpenTelemetry Protocol] (OTLP) at the `\http://localhost:4317` endpoint. You can configure alternative exporter settings by specifying MicroProfile Config properties and other system properties or environment variables. Open Liberty supports all link:https://opentelemetry.io/docs/languages/java/configuration/#environment-variables-and-system-properties[OpenTelemtry Java configuration properties].
+By default, all OpenTelemetry data is exported by using the link:https://github.com/open-telemetry/oteps/blob/main/text/0035-opentelemetry-protocol.md[OpenTelemetry Protocol] (OTLP) at the `\http://localhost:4317` endpoint. You can configure alternative exporter settings by specifying MicroProfile Config properties and other system properties or environment variables. Open Liberty supports all link:https://opentelemetry.io/docs/languages/java/configuration/#environment-variables-and-system-properties[OpenTelemtry Java configuration properties].
 
-To change the default endpoint that data is exported to, set the `otel.exporter.otlp.endpoint`. For example, you can set the following property in the `bootstrap.properties` file to change the endpoint for all logs, metrics, and traces from the `\http://localhost:4317` default to `\http://localhost:9080`:
+To change the default endpoint that data is exported to, set the `otel.exporter.otlp.endpoint` property. For example, you can set the following property in the `bootstrap.properties` file to change the endpoint for all logs, metrics, and traces from the `\http://localhost:4317` default to `\http://localhost:9080`:
 
 [source,properties]
 ----
 otel.exporter.otlp.endpoint=http://localhost:9080
 ----
 
-If you want to change the exporter that OpenTelemetry uses for logs, metrics, or traces, set the `otel.< _signal_ >.exporter` property, where _signal_ is the type of data that you want to change the exporter for: logs, metrics or traces. For example, If you use Zipkin to manage your trace data, you can set the following property in the `bootstrap.properties` file to export your application and runtime traces to a configured Zipkin server:
+If you want to change the exporter that OpenTelemetry uses for logs, metrics, or traces, set the `otel.< _signal_ >.exporter` property, where `_signal_` is the type of data that you want to change the exporter for: logs, metrics or traces. For example, If you use Zipkin to manage your trace data, you can set the following property in the `bootstrap.properties` file to export your application and runtime traces to a configured Zipkin server:
 
 [source,properties]
 ----
@@ -140,6 +142,8 @@ otel.traces.exporter=zipkin
 
 When you change the exporter value to `zipkin`, OpenTelemetry exports traces to the `\http://localhost:9411/api/v2/spans` endpoint instead of the OTLP default endpoint. You can configure a different endpoint by setting the `otel.exporter.zipkin.endpoint` property value to your chosen endpoint.
 
+For debugging purposes, you can also temporarily configure your logs, metrics, or traces to be exported to the `console.log` file. For more information, see xref:telemetry-troubleshooting.adoc#console[Exporting logs, metrics, or traces to the console for debugging purposes].
+
 For information about commonly-used configuration properties for logs, metrics, and trace settings, see xref:reference:microprofile-config-properties.adoc#telemetry[MicroProfile Config properties: MicroProfile Telemetry].
 
 [#traces]
@@ -151,7 +155,7 @@ Automatic instrumentation is available only for JAX-RS and Jakarta RESTful web s
 
 [#logs]
 === Logs defaults
-OpenTelemetry automatically collects any logs that are sent to the `java.util.logging` API. Any messages that are logged at a `java.util.logging.Level` log level of `INFO` and above are considered messages. Levels below `INFO` are considered trace. By default, OpenTelemetry logging automatically collects messages, but you can configure it to collect from other sources in your `server.xml` file. For more information, see link:/docs/latest/reference/feature/mpTelemetry-2.0.html#_collect_logs_from_a_specified_source[Collect logs from a specified source].
+OpenTelemetry automatically collects runtime and application logs that are sent to the `java.util.logging` API. Any events that are logged at a `java.util.logging.Level` log level of `INFO` and above are considered messages. Levels below `INFO` are considered trace. By default, OpenTelemetry logging automatically collects messages, but you can configure it to collect from other sources in your `server.xml` file. For more information, see link:/docs/latest/reference/feature/mpTelemetry-2.0.html#_collect_logs_from_a_specified_source[Collect logs from a specified source].
 
 For information about Liberty log event fields for OpenTelemetry, see xref:mptel-log-events-list.adoc[MicroProfile Telemetry log events reference list].
 
@@ -161,7 +165,7 @@ When you use the `otlp` default log exporter, the OpenTelemetry Batch LogRecord
 [#metrics]
 === Metrics defaults
 
-When you enable OpenTelemetry for Open Liberty,  a default set of metrics is automatically collected and exported according to the configured OpenTelemetry exporter settings. For more information about these metrics, see xref:mptelemetry-metrics-list.adoc[MicroProfile Telemetry metrics reference list]. You can also define additional xref:custom-mptelemetry-metrics.adoc[custom metrics] in your application code for OpenTelemetry to collect and export.
+When you enable OpenTelemetry for Open Liberty,  a default set of metrics is automatically collected and exported according to the configured OpenTelemetry exporter settings. OpenTelemetry collects both JVM runtime-environment metrics and HTTP metrics. For more information about these metrics, see the xref:mptelemetry-metrics-list.adoc[MicroProfile Telemetry metrics reference list]. You can also use the OpenTelemetry API to xref:custom-mptelemetry-metrics.adoc[define custom metrics] in your application code for OpenTelemetry to collect and export.
 
 You can configure the metrics exporter settings, including the export interval and timeout values, by setting system properties. For more information, see see xref:reference:microprofile-config-properties.adoc#telemetry[MicroProfile Config properties: MicroProfile Telemetry].
 

modules/ROOT/pages/observability.adoc

@@ -19,17 +19,21 @@ With MicroProfile Telemetry 2.0 and later, you can manage logs, metrics, and tra
 
 The following topics provide information to help you develop observable applications with Open Liberty.
 
+////
 xref:prepare-mptelemetry.adoc[Prepare your development environment for MicroProfile Telemetry]::
 Before you manually instrument your code to use MicroProfile Telemetry to collect metrics and traces, you must enable MicroProfile Telemetry in your development environment by editing your runtime configuration. You must also add the OpenTelemetry API and annotations as a dependency on your build path.
+////
 
 xref:custom-mptelemetry-metrics.adoc[Define custom MicroProfile Telemetry metrics]::
 You can use the OpenTelemetry metrics API to define custom metrics in your application code. When you enable the MicroProfile Telemetry feature 2.0 or later, you can then collect and emit these metrics to customize the observability of your application.
 
 xref:telemetry-trace.adoc[Code instrumentation for MicroProfile Telemetry tracing]::
 After you enable MicroProfile Telemetry and configure a trace server, you can instrument tracing in your application code. You can instrument your code automatically, manually, or by using the Java agent.
 
+////
 xref:mptelemetry-logging.adoc[Write logs with MicroProfile Telemetry logging]::
 You can use MicroProfile Telemetry to mange your logs, along with traces and metrics. When you enable the MicroProfile Telemetry feature version 2.0 or later, MicroProfile Telemetry automatically collects any logs that are sent to the `java.util.logging` API.
+////
 
 xref:microservice-observability-metrics.adoc[Microservice observability with MicroProfile metrics]::
 Open Liberty uses MicroProfile Metrics to provide metrics that describe the internal state of many Open Liberty components. MicroProfile Metrics provides a `/metrics` endpoint from which you can access all metrics that are emitted by an Open Liberty server and deployed applications.

modules/ROOT/pages/telemetry-troubleshooting.adoc

@@ -14,7 +14,7 @@
 
 The following information can help you determine the cause of common problems and error messages that are associated with OpenTelemetry logs, metrics, and tracing. To debug issues with your OpenTelemetry logs, metrics, or traces, you can configure this data to export to the console.
 
-
+[#console]
 == Exporting logs, metrics, or traces to the console for debugging purposes
 
 By default, all OpenTelemetry data is exported to the `otlp` exporter. For debugging purposes, you can temporarily change the export destination to the `console.log` file by setting the `otel.<_signal_>.exporter=console` property at the application or the runtime level.