Get more metrics from your apps and servers so you can monitor your microservices more effectively with MicroProfile 1.2 and 2.0 in WebSphere Liberty 18.0.0.3. You can now get metrics to monitor the fault tolerance responses of your microservices and collect metrics from your microservices in IBM Cloud. There's also support now for reactive programming in a type-safe RESTful client, you can dynamically update your microservices configuration, and much more.

Take a look and see... WebSphere Liberty includes full support for both MicroProfile 1.4 with Java EE 7 and MicroProfile 2.0 with Java EE 8 and is now available to download. WebSphere Liberty is built on the open source Open Liberty project.

Join Our Free Webcast

Learn about Liberty V18.0.0.3, try it out, and ask questions of the team (choose the date that suits your timezone):

Download WebSphere Liberty 18.0.0.3 Now

• Download WebSphere Liberty 18.0.0.3

• Ask a question on Stack Overflow

What's New in WebSphere Liberty 18.0.0.3?

WebSphere Liberty is built on Open Liberty, so everything new in Open Liberty is here too:

• Monitor faults in your microservices (MicroProfile Fault Tolerance 1.1)
• Get Liberty component metrics from /metrics endpoint (Monitor 1.0 with MP Metrics 1.1)
• Disable authenticaton on /metrics during development (MicroProfile Metrics 1.1 update)
• Reactive programming in a type-safe RESTful client (MicroProfile Rest Client 1.1)
• Verify security tokens in a container-neutral way to simplify deployment (MicroProfile JWT 1.1)
• Automatically trace JAX-RS requests between microservices (MicroProfile Open Tracing 1.1)
• Dynamically update your microservice configuration (MicroProfile Config 1.3)
• Conveniently enable all MicroProfile 2.0 or MicroProfile 1.4 features
• Provide social media single sign-on options to app users (Social Login 1.0)
• Use a java.sql.Driver as a data source (JDBC 4.2, 4.1, 4.0)

Find out more on the Open Liberty website.

Plus, only in WebSphere Liberty:

• Collect metrics from your microservices in IBM Cloud

• Ensure integrity and accountability in your business computing environment (Audit 1.0)

• Collect audit data in logs for analysis (Logstash Collector 1.0)

• Update to the pluginUtility merge command

• Specify a root directory when packaging servers

• Get Liberty support for MDBs (z/OS WLM 1.0)

• Configure Liberty to interact with z/OS WLM Health APIs (z/OS WLM 1.0)

• Submit usage metrics from a Liberty server to IBM Cloud Private

Collect Metrics From Your Microservices in IBM Cloud

A new option for accessing /metrics without authentication makes it easier for developers and administrators to set up monitoring of Liberty servers in situations where security isn't required. Tools such as Prometheus or Collectd can be set up quickly to scrape metrics from Liberty.

MicroProfile Metrics in Liberty provides metrics for application developers and administrators to monitor their applications. Metrics are often collected and stored in a time series database such as Prometheus. Previously, the /metrics endpoint provided by Liberty required basic authentication. Administrators needed to add the username and password to Prometheus's configuration in order for Prometheus to scrape the metrics from Liberty.

An optional configuration attribute is now available to turn off the basic authentication of the /metrics endpoint. This makes metrics collection in IBM Cloud Private a lot easier. Prometheus can automatically discover Liberty's /metrics endpoint without modifying its configuration.

To turn off basic authentication for the /metrics endpoint, add to server.xml.

In IBM Cloud Private, if you select the Monitoring checkbox in the Liberty Helm chart, mpMetrics-1.1 and monitor-1.0 feature are added to server.xml with authentication disabled for the /metrics endpoint. In addition, an enhancement in 18.0.0.3 exposes metrics from monitor-1.0 to MicroProfile Metrics vendor scope. Metrics such as servlet and thread pool statistics are included in /metrics and /metrics/vendor endpoints.

For more info, see the Knowledge Center:

• Monitoring with MicroProfile metrics

• MicroProfile Metrics 1.1 vendor metrics

• Monitoring with monitor-1.0

Ensure Integrity and Accountability in Your Business Computing Environment (Audit 1.0)

The audit feature provides a mechanism to:

• Ensure the integrity of the business computing environment, including providing evidence for non-repudiation
• Promote user accountability
• Do incident investigation and vulnerability analysis
• Support compliance requirements many large customers have to provide and maintain security audit and business transaction records over long periods of time for regulatory reasons

To enable auditing capability, add the audit-1.0 feature to the server.xml:

<featureManager>
        <feature>audit-1.0</feature>
</featureManager>

Collect Audit Data in Logs for Analysis (Logstash Collector 1.0)

Liberty administrators can now see audit data in their logs and analyze it using popular log analysis tools like the Elastic stack. For example, this will help quickly pinpoint attempts to access resources by unauthorized users, view the scope of user activity across a set of Liberty servers, or highlight attempts to use a compromised user ID.

The new audit-1.0 feature is able to track authentication, authorization, and other events within the Liberty server. Diagnosing issues in real time is hard to do by just looking at a stream of audit events in a file. When audit-1.0 is enabled, audit events can now be forwarded to Logstash using logstashCollector-1.0 feature or can be written to stdout by changing the settings in the server.xml logging element. As a result, audit events from multiple Liberty servers can be aggregated to an Elastic logging stack or other log analysis solution similar to log events. For servers running in IBM Cloud Private, Liberty's audit events from each pod will be collected and forwarded to the built-in Elastic logging stack. Administrators can analyze the audit events to find and investigate suspicious activity on their servers.

Enable logging in JSON to stdout or change the format of messages.log to JSON.

For example, you enable writing JSON formatted audit and message events to stdout by setting the following in server.env:

WLP_LOGGING_CONSOLE_FORMAT=json
WLP_LOGGING_CONSOLE_LOGLEVEL=info
WLP_LOGGING_CONSOLE_SOURCE=audit,message

You can use logstashCollector-1.0 in conjunction with the audit-1.0 feature to forward audit events to a Logstash server. Example server configuration:

<featureManager>
        <feature>audit-1.0</feature>
        <feature>logstashCollector-1.0</feature>
</featureManager>

<logstashCollector 
source="audit" 
hostName="logstashHostname" 
port="5043" 
sslRef="mySSLConfig"
</logstashCollector>

For more info, see the Knowledge Center:

• Enabling JSON logging

• Enabling Logstash Collector

Update to the pluginUtility Merge Command

It is common to provide workload balancing and failover of application requests by running the same application in multiple application server processes, a pattern referred to as an application cluster. In such a topology, the web server plug-in must share the requests across all the application servers in the cluster, and it can be directed to do so by using a configuration that contains information about all of the application servers. This configuration is known as a merged plug-in configuration because it involves merging routing information from multiple application servers. You can use the pluginUtility command to collect the automatically generated plug-in configuration files and merge them.

As requested by users, the pluginUtility merge tool now works with just one source input file. This change allows for simpler use and automation of the tool. Users can now invoke the merge command with just one plugin configuration file as input; the command now generates a merged plugin configuration file given just one input file. In previous releases, the tool would return an error code if fewer than two files were requested to be merged. This change allows the tool to behave more predictably for a wider range of input scenarios.

Run pluginUtility merge --sourcePath=PLUGIN_DIR with just one plugin configuration file in PLUGIN_DIR. A merged configuration file is created.

For more info, see the Knowledge Center:

• Merging web server plug-in configuration files from the command line

Specify a Root Directory When Packaging Servers

When packaging a server from the command line using the server package command, you can now optionally specify the Liberty root directory in the archive. This enables you to extract the archive into your directory structure and not have to manually modify it to fit your naming scheme.

For example, to obtain an archive called myServerPackage.zip which contains the archived Liberty server with the folder structure /MyRoot/... instead of /wlp/..., run the command:

server package myServer --archive=myServerPackage.zip --server-root=MyRoot

For more info, see the Knowledge Center:

• Packaging a Liberty server from the command line

Get Liberty Support for MDBs (z/OS WLM 1.0)

z/OS System Programmers can now assign MDB work to z/OS WLM services and report classes so that they can monitor response times and other related information about MDB workload relative to SLA (Service Level Agreement) goals defined in z/OS WLM.

To enable the support, add the zosWlm-1.0 feature and defining MDB classification rules in the configuration. For example:

<server>
    <featureManager>
        <feature>zosWlm-1.0</feature>
    </featureManager>
    ...
    <wlmClassification>
       <mdbClassification transactionClass="CLASMDB1" jmsActivationSpec="Banking/personal/deposit"/>
      ....
       <mdbClassification transactionClass="CLASMDBN" jmsActivationSpec="*"/>
    </wlmClassification>
...
</server>

For more info, see the Knowledge Center:

• WLM classification for z/OS

Configure Liberty to Interact With z/OS WLM Health APIs (z/OS WLM 1.0)

The new support added to leverage z/OS WLM Health APIs allows z/OS work routing mechanisms that consider z/OS WLM advice (e.g. Sysplex Distributor) to gradually increase work to a newly started server so that overall response times are not adversely affected by starting a new server.

To enable z/OS WLM 1.0, add the definition to your server.xml:

<server>
    <featureManager>
        <feature>zosWlm-1.0</feature>
    </featureManager>
    ...
    <zosWlmHealth interval="1m" increment="15"/> 
</server>

For more info, see the Knowledge Center:

Submit Usage Metrics From a Liberty Server to IBM Cloud Private

The new usageMetering-1.0 feature adds the capability to register a Liberty server with an IBM Cloud Private metering service and submit usage metrics.

IBM Cloud Private metering enhances the way IBM middleware products can be registered and tracked. It helps track product instances and report usage metrics. Using IBM Cloud Private metering, organizations will have the opportunity to extend and achieve the benefits of cloud environments. For example, IT administrators will be able to register all of their products in a single dashboard, simplifying the management tasks. And capacity planners will be able to right-size their environments based on usage data. In addition, enabling usage metering with IBM Cloud Private metering provides support for the new hourly pricing option for container deployments.

For more info, see the WebSphere Liberty Knowledge Center docs on enabling the metering service for Liberty applications.

Request for Enhancements (RFEs) Completed in WebSphere Liberty 18.0.0.3

In this release, the following RFEs were completed for WebSphere Liberty:

• Download Liberty 18.0.0.3

• Ask a question on Stack Overflow

We'd love you to get involved in any way that you can, such as testing the code in ways that you use Liberty and raising issues on GitHub, or create pull requests on the code and documentation. You can contribute to discussions about Open Liberty on the mailing list.