OpenLiberty · ramkumar-k-9286 · Jan 24, 2025 · Dec 17, 2024 · Dec 18, 2024 · Dec 18, 2024
diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc
@@ -49,13 +49,11 @@
   ** xref:distributed-session-caching.adoc[Distributed session caching]
   ** xref:configuring-infinispan-support.adoc[Configuring Infinispan as a JCache provider]
 * xref:observability.adoc[Observability]
-//  ** xref:prepare-mptelemetry.adoc[Prepare your development environment for MicroProfile Telemetry]
+  ** xref:health-check-microservices.adoc[Health checks for microservices]
   ** xref:custom-mptelemetry-metrics.adoc[Define custom MicroProfile Telemetry metrics]
   ** xref:telemetry-trace.adoc[Code instrumentation for MicroProfile Telemetry tracing]
-//  ** xref:mptelemetry-logging.adoc[Write logs with MicroProfile Telemetry logging]
   ** xref:microservice-observability-metrics.adoc[Microservice observability with MicroProfile Metrics]
     *** xref:micrometer-metrics.adoc[Choose your own monitoring tools with MicroProfile Metrics]
-  ** xref:health-check-microservices.adoc[Health checks for microservices]
   ** https://openliberty.io/guides/#observability[Guides: Observability]
 * xref:integration-testing.adoc[Testing]
   ** https://openliberty.io/guides/#test[Guides: Testing]

diff --git a/modules/ROOT/pages/custom-mptelemetry-metrics.adoc b/modules/ROOT/pages/custom-mptelemetry-metrics.adoc
@@ -1,4 +1,4 @@
-// Copyright (c) 2022 IBM Corporation and others.
+// Copyright (c) 2022, 2025 IBM Corporation and others.
 // Licensed under Creative Commons Attribution-NoDerivatives
 // 4.0 International (CC BY-ND 4.0)
 //   https://creativecommons.org/licenses/by-nd/4.0/
@@ -12,13 +12,13 @@
 :page-type: general
 = 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.
+When you enable MicroProfile Telemetry 2.0 or later, Open Liberty automatically collects and exports a default set of metrics. Additionally, you can use the OpenTelemetry API to define custom metrics in your application code, if needed.
 
 For more information about collecting and emitting metrics with MicroProfile Telemetry, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
 
 Before you can use OpenTelemetry to define custom metrics metrics, you must make 3rd party APIs visible in your runtime environment by editing your runtime configuration. For more information, see link:/docs/latest/reference/feature/mpTelemetry-2.0.html#dev[Customize your application telemetry with the OpenTelemetry API].
 
-The following example defines a custom counter metric:
+The following example defines a custom counter metric in the application:
 
 [source,java]
 ----

diff --git a/modules/ROOT/pages/instanton.adoc b/modules/ROOT/pages/instanton.adoc
@@ -1,4 +1,4 @@
-// Copyright (c) 2023 IBM Corporation and others.
+// Copyright (c) 2025 IBM Corporation and others.
 // Licensed under Creative Commons Attribution-NoDerivatives
 // 4.0 International (CC BY-ND 4.0)
 //    https://creativecommons.org/licenses/by-nd/4.0/
@@ -389,15 +389,20 @@ In addition to the features that are enabled in the MicroProfile and Jakarta con
 - feature:appAuthorization-2.1[]
 - feature:appSecurity-1.0[]
 - feature:audit-1.0[]
+- feature:batch-1.0[]
+- feature:batch-2.0[]
+- feature:batch-2.1[]
 - feature:bells-1.0[]
 - feature:connectors-2.0[]
 - feature:connectors-2.1[]
+- feature:connectorsInboundSecurity-2.0[]
 - feature:crac-1.4[]
 - feature:distributedMap-1.0[]
 - feature:federatedRegistry-1.0[]
 - feature:javaMail-1.6[]
 - feature:jaxws-2.2[]
 - feature:jca-1.7[]
+- feature:jcaInboundSecurity-1.0[]
 - feature:jdbc-4.1[]
 - feature:jdbc-4.3[]
 - feature:jms-2.0[]

diff --git a/modules/ROOT/pages/introduction-monitoring-metrics.adoc b/modules/ROOT/pages/introduction-monitoring-metrics.adoc
@@ -1,4 +1,4 @@
-// Copyright (c) 2020, 2023 IBM Corporation and others.
+// Copyright (c) 2020, 2025 IBM Corporation and others.
 // Licensed under Creative Commons Attribution-NoDerivatives
 // 4.0 International (CC BY-ND 4.0)
 //   https://creativecommons.org/licenses/by-nd/4.0/
@@ -16,15 +16,14 @@
 Three kinds of metrics are available to monitor your Open Liberty applications: OpenTelemetry metrics from MicroProfile Telemetry, REST endpoint-style metrics from MicroProfile Metrics, and Java Management Extensions (JMX) metrics. OpenTelemetry provides a standardized solution to manage metrics, logs, and traces. MicroProfile Metrics and JMX metrics can be used separately or in conjunction to improve the observability of your application systems.
 
 
-MicroProfile Telemetry 2.0 and later exports metrics to the configured OpenTelemetry metrics exporter, which can send metrics to the backend service of your choice. You might prefer this option if you also use MicroProfile Telemetry to manage your logs and traces. The following information pertains to MicroProfile Metrics and JMX Metrics. For information about using OpenTelemetry and MicroProfile Telemetry to collect and export metrics, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
+MicroProfile Telemetry 2.0 and later exports metrics to the configured OpenTelemetry metrics exporter, which can send metrics to the backend service of your choice. You might prefer this option if you also use MicroProfile Telemetry to manage your logs and traces. The information in this topic pertains to MicroProfile Metrics and JMX Metrics. For information about instead using OpenTelemetry and MicroProfile Telemetry to collect and export metrics, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
 
 MicroProfile Metrics can be accessed by monitoring tools, such as Prometheus, or by any client that can make REST requests.
 <<#jmx,JMX metrics>> are suitable for use by Java-based monitoring tools that can communicate with JMX servers, or by custom JMX clients.
 
-  the
 [#endpoint]
 == MicroProfile Metrics and the metrics endpoint
-Open Liberty uses MicroProfile Metrics to expose metrics that describe the internal state of many Open Liberty components. Developers can also use the MicroProfile Metrics API to expose metrics from their applications.
+When you enable the MicroProfile Metrics feature, Open Liberty uses MicroProfile Metrics to expose metrics that describe the internal state of many Open Liberty components. Developers can also use the MicroProfile Metrics API to expose metrics from their applications.
 For more information about adding these metrics to your applications, see xref:microservice-observability-metrics.adoc#add[Adding metrics to your applications] and the link:/guides/microprofile-metrics.html[Providing metrics from a microservice] guide. For a list of all REST endpoint-style metrics that are available for Open Liberty, see the xref:metrics-list.adoc[Metrics reference list].
 
 The MicroProfile Metrics feature provides a `/metrics` REST interface that conforms to the MicroProfile Metrics specification. You can access MicroProfile Metrics with Open Liberty by feature:mpMetrics[display=enabling the MicroProfile Metrics feature]. Real-time values of all metrics are available by calling the `/metrics` endpoint, which provides formatted metric data that can be consumed as time-series data by external monitoring  tools.

diff --git a/modules/ROOT/pages/jdbc-tracing.adoc b/modules/ROOT/pages/jdbc-tracing.adoc
@@ -85,13 +85,14 @@ In this example, the custom `traceLevel` attribute for the DB2 JCC driver is set
 The following subsections contain JDBC driver specific configuration.
 
 * <<#DB2JCC,DB2 JCC>>
+  ** <<#DB2Custom,DB2 JCC customized tracing>>
 * <<#Derby,Derby>>
 * <<#InformixJDBC,Informix using JDBC>>
 * <<#InformixDB2JCC,Informix using DB2 JCC>>
 * <<#SQLServerJDBCdriver,Microsoft SQL Server JDBC driver>>
 * <<#SQLServerDataDirectdriver,Microsoft SQL Server DataDirect driver>>
 * <<#Oracle,Oracle>>
-  ** <<#OracleCustom, Oracle customized tracing>>
+  ** <<#OracleCustom,Oracle customized tracing>>
 * <<#PostgreSQL,PostgreSQL>>
 * <<#Sybase,Sybase>>
 * <<#Otherdatabases,Other databases>>
@@ -113,6 +114,35 @@ The DB2 JCC does not support the `java.util.logging` library. This driver has it
 
 For more information about valid values for the `traceLevel` attribute, see https://www.ibm.com/support/pages/collecting-data-tracing-ibm-data-server-driver-jdbc-and-sqlj[Table 1. DB2 JDBC trace constants].
 
+[#DB2Custom]
+=== DB2 JCC customized tracing
+
+By default, DB2 JCC driver tracing is combined with Liberty tracing because the Liberty-provided DB2 logwriter directs trace output to the same file. However, Liberty also offers the option to separate DB2 JCC trace from Liberty trace. You can use this option to provide a stand-alone DB2 JCC JDBC trace to DB2 support, if needed.
+
+You can set this customized tracing for each configured DataSource in your `server.xml` file, as shown in the following example:
+
+[source, xml]
+----
+<logging traceSpecification="*=info:RRA=all" />
+
+<datasource ... >
+  <properties.db2.jcc
+    traceLevel="-1" traceDirectory="${server.output.dir}/logs/" traceFile="jcc.trace"
+    traceFileAppend="true" traceOption="0"/>
+</datasource>
+----
+
+The following attributes customize the configuration of the DB2 driver trace output:
+
+- `traceLevel` (required): This property specifies the level of trace.
+- `traceDirectory` (required): This property specifies the directory where trace is written.
+- `traceFile` (required): This property specifies the name of the trace output file.
+- `traceFileAppend` (optional): This property specifies whether to append to (`true`) or overwrite (`false`) the trace output to the specified file. Default value is `false`.
+- `traceOption` (optional) : When this property is set to `0`, the `traceFileSize` and `traceFileCount` properties are ignored, and a single trace file with no size limit is generated. To enable circular tracing, set this property to `1`. Default value is `0`.
+- `traceFileSize` (optional) : This property specifies the maximum size of each trace file, for circular tracing (in bytes). Default value is `10485760` (10 MB).
+- `traceFileCount` (optional) : This property specifies the maximum number of trace files for circular tracing. Default value is `2`.
+
+For more information about these properties and other configuration settings, see link:https://www.ibm.com/docs/en/db2/latest?topic=information-data-server-driver-jdbc-sqlj-configuration-properties[IBM Data Server Driver for JDBC and SQLJ configuration properties].
 
 [#Derby]
 === Derby
@@ -232,7 +262,7 @@ Add the following required properties to the `jvm.options` file to enable a new
 - `oracleLogFileName` : This property specifies the file name for custom logging. For example, `oracle.log`.
 - `oracleLogPackageName` : This property specifies the package to trace. For example, `oracle`, `oracle.jdbc`, or `oracle.net`
 
-You can also customize the configured trace in the `jvm.options` file by using optional properties. 
+You can also customize the configured trace in the `jvm.options` file by using optional properties.
 
 [source, txt]
 ----

diff --git a/modules/ROOT/pages/log-trace-configuration.adoc b/modules/ROOT/pages/log-trace-configuration.adoc
@@ -50,7 +50,7 @@ The following sections provide more information about configuring your Open Libe
 [#mptel]
 == Logging with MicroProfile Telemetry
 
-When you enable the MicroProfile Telemetry feature version 2.0 and later, you can manage your logs, metrics, and traces in a standardized way with the OpenTelemetry protocol. For more information, see xref:microprofile-telemetry[Enable observability with MicroProfile Telemetry].
+When you enable the MicroProfile Telemetry feature version 2.0 and later, you can manage your logs, metrics, and traces in a standardized way with the OpenTelemetry protocol. For more information, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
 
 [#configuaration]
 == Logging configuration

diff --git a/modules/ROOT/pages/microprofile-telemetry.adoc b/modules/ROOT/pages/microprofile-telemetry.adoc
@@ -1,4 +1,4 @@
-// Copyright (c) 2024 IBM Corporation and others.
+// Copyright (c) 2024, 2025 IBM Corporation and others.
 // Licensed under Creative Commons Attribution-NoDerivatives
 // 4.0 International (CC BY-ND 4.0)
 //   https://creativecommons.org/licenses/by-nd/4.0/
@@ -49,7 +49,7 @@ If you choose to use the `server.env` file, specify the `OTEL_SDK_DISABLED=false
 [#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.
+When your Open Liberty runtime hosts only one application, as is typical in containerized environments, you can enable OpenTelemetry at the runtime level. This configuration collects and exports logs, metrics, and traces for both the runtime and the application.
 
 . Enable the feature:mpTelemetry[display=MicroProfile Telemetry] feature version 2.0 or later in the `featureManager` element of your `server.xml` file.
 
@@ -64,7 +64,7 @@ After you enable the MicroProfile Telemetry feature and set this system property
 [#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.
+When your Liberty runtime hosts multiple applications, which is typically associated with virtual machine environments, you might choose to enable OpenTelemetry 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.
 
 . Enable the feature:mpTelemetry[display=MicroProfile Telemetry] feature version 2.0 or later in the `featureManager` element of the `server.xml` file of each application that you want to collect telemetry for.
 

diff --git a/modules/ROOT/pages/microservice-observability-metrics.adoc b/modules/ROOT/pages/microservice-observability-metrics.adoc
@@ -1,4 +1,4 @@
-// Copyright (c) 2019, 2023 IBM Corporation and others.
+// Copyright (c) 2019, 2025 IBM Corporation and others.
 // Licensed under Creative Commons Attribution-NoDerivatives
 // 4.0 International (CC BY-ND 4.0)
 //   https://creativecommons.org/licenses/by-nd/4.0/
@@ -13,9 +13,13 @@
 :page-type: general
 = Microservice observability with metrics
 
-Open Liberty uses MicroProfile Metrics to provide metrics that describe the internal state of many Open Liberty components.
+Open Liberty  can use 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 runtime and deployed applications.
 
+As an alternative to MicroProfile metrics, you can collect and export metrics with MicroPRofile Telemetry using the OpenTelemetry protocol. When you enable OpenTelemetry for Open Liberty, a default set of metrics is automatically collected and exported according to the configured OpenTelemetry exporter settings. The advantage of using MicroPRofile Telemetry is that it provides a single comprehensive solution for traces, metrics, and logging. For more information, see xref:microprofile-telemetry.adoc[Collect logs, metrics, and traces with OpenTelemetry].
+
+== Viewing metrics from the MicroProfile Metrics endpoints
+
 When MicroProfile Metrics is enabled and an application is running, you can view metric data from any browser by accessing the `/metrics` endpoint. An example of this endpoint is `\https://localhost:9443/metrics`, where `9443` is the port number for your application.
 
 You can narrow the scope of the metrics by using the `scope` query parameter with the `/metrics` endpoint to specify the metric registry scope. For example, to view the metric data for the `base` metric registry, use the `/metrics?scope=base` endpoint. This pattern is used to access all runtime-provided scopes  (`base`, `application`, and `vendor`) and any <<customscope, user-defined metric registry scopes>>.