Merge pull request #7492 from OpenLiberty/7459-mptel-logs

edits per review

modules/ROOT/pages/log-trace-configuration.adoc

@@ -611,7 +611,7 @@ If you specify a value of `false`, the date and time are formatted according to
 [#log_details]
 == Trace log detail levels
 
-You can specify the `traceSpecification` attribute for the logging element in your `server.xml` file to selectively enable trace and set the trace log detail level for specific components in your server configuration.
+You can specify the `traceSpecification` attribute for the `logging` element in your `server.xml` file to selectively enable trace and set the trace log detail level for specific components in your server configuration.
 The following example specifies a trace specification for two groups of components.
 
 [source,xml]

modules/ROOT/pages/microprofile-config-properties.adoc

@@ -623,6 +623,26 @@ For more information about collecting Open Liberty logs, metrics, and traces, se
 |===
 |Name |Description |When the runtime reads the property |Example
 
+|`otel.blrp.export.timeout`
+|Sets the delay interval in milliseconds between two consecutive exports from the link:https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#batch-logrecord-processor[Batch LogRecord Processor]. The default is `30000`.
+|Application startup
+|`otel.blrp.export.timeout=50000`
+
+|`otel.blrp.schedule.delay`
+|Sets the maximum allowed time in milliseconds to export data from the Batch LogRecord Processor. The default is `1000`.
+|Application startup
+|`otel.blrp.schedule.delay=5000`
+
+|`otel.blrp.max.queue.size`
+|Sets the maximum queue size for the Batch LogRecord Processor. The default is `2048`.
+|Application startup
+|`otel.blrp.max.queue.size=5000`
+
+|`otel.blrp.max.export.batch.size`
+|Sets the maximum batch size for the Batch LogRecord Processor. The default is `512`. The value must be Must be less than or equal to the value for `otel.blrp.max.queue.size`.
+|Application startup
+|`otel.blrp.max.export.batch.size=1024`
+
 |`otel.exporter.jaeger.endpoint`
 |Sets the endpoint for the Jaeger exporter. The default is \http://localhost:14250.
 |Application startup

modules/ROOT/pages/microprofile-telemetry.adoc

@@ -91,6 +91,17 @@ To enable MicroProfile Telemetry to collect and export logs in your Open Liberty
 +
 For more information, see <<#global,Enabling MicroProfile Telemetry for Open Liberty>>.
 
+. Optionally, enable the MicroProfile Telemetry feature to collect logs from different sources in the Open Liberty runtime environment.
++
+Configure the `source` attribute for the `mpTelemetry` element with a comma-separated list of comma-separated log sources:
++
+[source,xml]
+----
+<mpTelemetry source="message, trace, ffdc"/>
+----
++
+The `mpTelemetry` configuration element is optional. If you do not specify it, or if you do not include the `source` attribute, the default configuration source is `message`. For more information, see feature:mpTelemetry-2.0[display=Collect logs from a specified source].
+
 . Optionally, configure the log sources that MicroProfile Telemetry collects and where the logs are exported.
 +
 You can configure how MicroProfile Telemetry collects and exports logs by specifying configuration properties in any of the xref:external-configuration.adoc#default[config sources that are available to MicroProfile Config], or by specifying environment variables.
@@ -107,7 +118,7 @@ otel.sdk.disabled=false
 otel.logs.exporter=console
 ----
 +
-If it is set to `console`, all the logs are exported to standard out (`stdout`) and the `console.log` file. The `console.log` file the contains the usual logs, along with duplicate OpenTelemetry-mapped logs. This setting is only for debugging purposes because the `console.log` file does not roll over and might affect performance if it gets too large.
+If you set this property to `console`, all the logs are exported to standard out (`stdout`) and the `console.log` file. The `console.log` file contains the usual logs, along with duplicate OpenTelemetry-mapped logs. This setting is only for debugging purposes because the `console.log` file does not roll over and might affect performance if it gets too large. If you set this property to `none`, no logs are exported
 +
 .. Configure MicroProfile Telemetry to use the OpenTelemetry Batch LogRecord Processor.
 +

modules/ROOT/pages/mptel-log-events-list.adoc

@@ -30,7 +30,7 @@ The following table provides the fields for Liberty message events, a descriptio
 .Message event fields
 [options="header"]
 |=======================
-| Liberty message event fields | Description | Maps to OTel logs data model | OTel Java agent (JUL) mapping
+| Liberty message event fields | Description | Maps to OpenTelemetry logs data model | OpenTelemetry Java agent (JUL) mapping
 | type                             | A string that identifies the type of event. | Attributes[`io.openliberty.type`] | N/A
 | host                             | Host name of the server that is the source of the event. | Resource[`host.name`] | Resource[`host.name`]
 | message                          | The message from the log record, starting with the message ID. | Body | body
@@ -72,7 +72,7 @@ The following table provides the fields for Liberty trace events, a description
 .Trace event fields
 [options="header"]
 |=======================
-| Liberty trace event fields | Description | Maps to OTel Logs Data Model | OTel Java Agent JUL Mapping
+| Liberty trace event fields | Description | Maps to OpenTelemetry Logs Data Model | OpenTelemetry Java Agent JUL Mapping
 | type                             | A string that identifies the type of event. | Attributes[`io.openliberty.type`] | N/A
 | host                             | Host name of the server that is the source of the event. | Resource[`host.name`] | Resource[`host.name`]
 | message                          | The message from the log record, starting with the message ID. | Body | body
@@ -111,8 +111,9 @@ Attributes:
 The following table provides the fields for the first failure data capture (FFDC) events, a description for each fiel, and the mapping to the OpenTelemetry logs data model:
 
 .FFDC event fields
+[options="header"]
 |=======================
-| Liberty FFDC event fields | Description | Maps to OTel Logs Data Model
+| Liberty FFDC event fields | Description | Maps to OpenTelemetry Logs Data Model
 | type                     | A string that identifies the type of event. | Attributes[`io.openliberty.type`]
 | host                     | Host name of the server that is the source of the event. | Resource[`host.name`]
 | ibm_datetime             | Time at which the event occurred. | TimeStamp
@@ -151,7 +152,7 @@ Attributes:
 [#sevlev]
 == OpenTelemetry severity number mapping with Open Liberty log levels
 
-You can set the level of detail that your Open Liberty logs collect by configuring the `tracSpecification` attribute for the config:logging[] attribute in your `server.xml` file.  For more information about Liberty log levels, see xref:log-trace-configuration.adoc#log_details[Trace log detail levels].
+You can set the level of detail that your Open Liberty logs collect by configuring the `traceSpecification` attribute for the config:logging[] attribute in your `server.xml` file.  For more information about Liberty log levels, see xref:log-trace-configuration.adoc#log_details[Trace log detail levels].
 
 The following table describes how the different Liberty log levels map to severity numbers and short names from the OpenTelemetry specification.
 

modules/ROOT/pages/observability.adoc

@@ -17,6 +17,9 @@ When applications are observable, operations teams can identify and understand t
 
 The following topics provide information to help you develop observable applications with Open Liberty.
 
+xref:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry]::
+In microservice applications, sources of latency or inaccuracy can be difficult to determine because relationships and dependencies among the constituent services are not always obvious. MicroProfile Telemetry helps you collect data on the paths that application requests take through services. With MicroProfile Telemetry 2.0 and later, you can manage logs, metrics, and traces in a standardized way by using the OpenTelemetry protocol.
+
 xref:microservice-observability-metrics.adoc[Microservice observability with 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.
 
@@ -26,7 +29,4 @@ The Open Liberty MicroProfile Metrics 5.0 feature uses embedded Micrometer metri
 xref:health-check-microservices.adoc[Health checks for microservices]::
 A health check is a special REST API implementation that you can use to validate the status of a microservice and its dependencies. With MicroProfile Health, microservices can self-check their health and publish their overall status to a defined endpoint.
 
-xref:microprofile-telemetry.adoc[Enable observability with MicroProfile Telemetry]::
-In microservice applications, sources of latency or inaccuracy can be difficult to determine because relationships and dependencies among the constituent services are not always obvious. MicroProfile Telemetry helps you collect data on the paths that application requests take through services. With MicroProfile Telemetry 2.0 and later, you can manage logs, metrics, and traces in a standardized way by using the OpenTelemetry protocol.
-
 For hands-on tutorials on different observability configurations for Open Liberty, check out our link:/guides/#observability[Observability guides].