back to all blogsSee all blog posts

Configure server logs in JSON format to simplify dashboards on Open Liberty 19.0.0.10

image of author image of author
Yasmin Aumeeruddy and Thomas Jennings on Oct 11, 2019
announcements , microprofile , release , metrics , monitoring ,
Post available in languages:

Open Liberty 19.0.0.10 provides the useful option to configure JSON field names so they can best match with other data and can all be viewed in the same visualisation in the logs. The update also allows custom login modules for JCA and JMS connection factories. Give it a try in Open Liberty 19.0.0.10.

In Open Liberty 19.0.0.10:

If you’re curious about what’s coming in future Open Liberty releases, take a look at our previews in the latest development builds. In particular, get an early insight into support for the MicroProfile Metrics 2.1 specification.

View the list of fixed bugs from 19.0.0.10

Run your apps using 19.0.0.10

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>19.0.0.10</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[19.0.0.10,)'
}

Or if you’re using Docker:

docker pull open-liberty

Or take a look at our Downloads page.

Ask a question on Stack Overflow

Configurable JSON log field names

Logging configuration in Open Liberty has been updated. Server logs can now be formatted in basic or JSON format. When logs are in JSON format, the sources (message, trace, accessLog, ffdc, audit) to send to messages.log or console.log/standard-out must be specified.

The option to configure JSON field names in Open Liberty is extremely useful, since Open Liberty field names may differ from other container field names. For example, an Open Liberty message is referred to by the field name message, while another container’s message ends up in a field called log. Previously, two different visualisations of the messages would show in the logs on a dashboard; however, you can now modify the Open Liberty output field names. This means that they can best match with other data and can all be viewed in the same visualisation.

When logs are in JSON format, you can use the jsonFieldMappings attribute to replace default field names with new field names. To configure the new field name for all sources, use the following format:

defaultFieldName:newFieldName

To configure the new field name for a specific source, use the following format:

source:defaultFieldName:newFieldName

where source is the source you want to specify (such as message, trace, accessLog, ffdc, audit).

An example of configuring JSON field name by adding the following to bootstrap.properties:

com.ibm.ws.logging.json.field.mappings=trace:message:log,ibm_datetime:datetime

For more information on logging:

Custom login modules for JCA and JMS connection factories (jca-1.7 and jms-2.0)

An update to the Java Connector Architecture (JCA) and Java Message Service (JMS) features allows you to specify, within the server configuration, a default JAAS custom login module to use for container managed authentication to JCA and JMS connection factories.

Prior to this release, a JAAS custom login module could only be specified within the application itself for JCA and JMS connection factories. With this release, the following server configuration elements have added the ability to specify a default JAAS custom login module:

Beside these, dataSource element already had this capability prior to this release.

To enable the feature in the server.xml file:

  <featureManager>
    <feature>appSecurity-2.0</feature>
    <feature>jca-1.7</feature>
    ... other features
  </featureManager>
  <resourceAdapter id="myAdapter" location="${server.config.dir}/resourceadapters/example-adapter.rar"/>
  <connectionFactory jndiName="eis/cf" jaasLoginContextEntryRef="customLoginEntry">
    <properties.myAdapter hostName="myhost.openliberty.io" portNumber="8765"/>
  </connectionFactory>
  <jaasLoginContextEntry id="customLoginEntry" name="customLoginEntry" loginModuleRef="customLoginModule"/>
  <jaasLoginModule id="customLoginModule" className="org.example.MyLoginModule" controlFlag="REQUIRED">
    <library>
      <file name="${server.config.dir}/myCustomLoginModule.jar"/>
    </library>
  </jaasLoginModule>

For more information:

Previews of early implementations available in development builds

You can now also try out early implementations of some new capabilities in the latest Open Liberty development builds:

These early implementations are not available in 19.0.0.10 but you can try them out in our daily Docker image by running docker pull openliberty/daily. Let us know what you think!

Provide your own health check procedures (MicroProfile Health Check 2.1)

MicroProfile Health Check 2.1 enables you to provide your own health check procedures to be invoked by Liberty, to verify the health of your microservice.

HealthCheckResponse.up("myCheck");

In previous versions, to define a simple successful/failed named health check response, the application level code is always expected to use several static methods together from the HealthCheckResponse API, to retrieve a HealthCheckResponseBuilder used to construct a HealthCheck response.

In mpHealth-2.1 feature for OpenLiberty, you can now use convenient and simpler methods from standard Java APIs, to construct UP/DOWN named health check responses, in your applications, such as;

HealthCheckResponse.named(“myCheck”).up().build();

To make it work include the following in the server.xml file:

<feature>mpHealth-2.1</feature>

Applications are expected to provide health check procedures, by implementing the HealthCheck interface with the @Liveness or @Readiness annotations, which will be used by Liberty to verify the Liveness or Readiness of the application, respectively. Add the logic of your health check in the call() method, and return the HealthCheckResponse object, by constructing using the simple up()/down() methods from the API. To view the status of each health check, access the either the http://<hostname>:<port>/health/live or http://<hostname>:<port>/health/ready endpoints.

**Liveness Check**
@Liveness
@ApplicationScoped
public class AppLiveCheck implements HealthCheck {
...
    @Override
     public HealthCheckResponse call() {
       ...
       HealthCheckResponse.up("myCheck");
       ...
     }
}

For more information:

Monitor microservice applications easily wth metrics (MicroProfile Metrics 2.1 )

MicroProfile Metrics 2.1 allows you to instrument metrics in microservice applications for easy monitoring. Previously, the Gauge metric was intended to sample numerical values only, but users could sample non-numeric values (such as String). MicroProfile Metrics 2.1 restricts the scope such that Gauge can only sample numbers now.

Previously, the MetadataBuilder API had reusable() and notReusable() method to set the reusable field to true or false. The MetadataBuilder API has been changed to include a new setter method for the reusable attribute. This change is implemented so the MetadataBuilder API follows the builder pattern.

To enable the feature in the server.xml file:

<feature>mpMetrics-2.1</feature>

The following is an example of how to set the reusable field with the MetadataBuilder API:

MetadataBuilder mdb = Metadata.builder();
mdb = mdb.withName("metricName").withType(MetricType.COUNTER)
  .reusable(resolveIsReusable());

For more information:

Get Liberty 19.0.0.10 now

Available through Maven, Gradle, Docker, and as a downloadable archive.