tutorial

Monitoring Open Liberty Applications with Vigilmon

Open Liberty is IBM's open source Jakarta EE and MicroProfile runtime — but thread pool exhaustion, CDI failures, and datasource pool drain are silent killers. Here's how to monitor Open Liberty health, request throughput, JVM metrics, and circuit breakers with Vigilmon.

Open Liberty is IBM's open source, cloud-native Java application server implementing Jakarta EE and Eclipse MicroProfile. Its composable feature model means only the features you configure are loaded — but that also means issues like feature load failure, thread pool exhaustion, and datasource pool drain can surface at startup or under load rather than being caught early. Vigilmon gives you continuous runtime monitoring for Open Liberty without requiring a full APM stack.

What You'll Set Up

  • MicroProfile Health endpoint monitoring (liveness and readiness)
  • HTTP request throughput and latency checks
  • Thread pool and JVM heap alert thresholds
  • Open Liberty log error rate monitoring
  • Admin REST API reachability checks

Prerequisites

  • Open Liberty 24.x (or WebSphere Liberty 24.x)
  • MicroProfile Health feature enabled (mpHealth-4.0 or later in server.xml)
  • A free Vigilmon account

Why Monitor Open Liberty?

Open Liberty's feature-based composition and self-tuning thread pool make it resilient — but introduce failure modes that are unique to its architecture:

  • Feature load failures at startup leave the server up but with missing functionality, and are only visible in messages.log.
  • Thread pool saturation under the self-tuning pool algorithm can cause request queuing that isn't visible as an error — just as slow responses.
  • CDI injection failures during application deployment leave the app partially functional, with some injection points silently returning null.
  • Datasource pool exhaustion causes JDBC calls to block indefinitely while the application remains responsive to the health endpoint.
  • Circuit breakers from MicroProfile Fault Tolerance open silently, causing downstream dependencies to fast-fail instead of waiting — which may be correct behavior or may be masking a real outage.

Vigilmon surfaces these via MicroProfile Health endpoints, heartbeats, and log-based alerting.

Key Metrics to Monitor

| Metric | What It Reveals | |---|---| | /health/live response | Server liveness — JVM alive, server not deadlocked | | /health/ready response | Readiness — features loaded, datasources available | | HTTP request throughput | Drop in requests indicating upstream routing failure | | p99 response time | Latency spike indicating thread pool or GC pressure | | Thread pool queue depth | Queue >100 indicating thread pool exhaustion | | JVM heap utilization | Heap >85% indicating memory pressure before OOM | | GC pause duration | Pause >500ms indicating full GC stalls | | Feature load duration | Slow startup indicating misconfiguration | | CDI exception rate | CDI injection failures during request processing | | Admin REST API reachability | Management API down blocking operational tooling |

Step 1: Enable MicroProfile Health in Open Liberty

Add the MicroProfile Health feature to your server.xml:

<server description="Open Liberty Server">
  <featureManager>
    <feature>mpHealth-4.0</feature>
    <feature>jaxrs-3.1</feature>
    <feature>cdi-4.0</feature>
    <!-- add other features your application needs -->
  </featureManager>

  <httpEndpoint id="defaultHttpEndpoint"
                host="*"
                httpPort="9080"
                httpsPort="9443" />
</server>

Open Liberty automatically exposes /health, /health/live, and /health/ready on port 9080 when mpHealth-4.0 is loaded. Add a custom health check to verify your datasource:

import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Readiness;
import javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;
import javax.sql.DataSource;
import java.sql.Connection;

@Readiness
@ApplicationScoped
public class DatabaseHealthCheck implements HealthCheck {

    @Inject
    DataSource dataSource;

    @Override
    public HealthCheckResponse call() {
        try (Connection c = dataSource.getConnection()) {
            return HealthCheckResponse.up("database");
        } catch (Exception e) {
            return HealthCheckResponse.down("database");
        }
    }
}

Step 2: Add Liveness and Readiness Monitors in Vigilmon

Liveness Monitor

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter: http://<your-server>:9080/health/live
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Under Response body check, enter: UP (Vigilmon will alert if the body doesn't contain UP).
  7. Click Save.

Readiness Monitor

Repeat the above with /health/ready. The readiness endpoint checks that all registered @Readiness health checks pass — including your database check above.

Step 3: Monitor HTTP Request Throughput with a Synthetic Check

Add a lightweight synthetic endpoint that Vigilmon can probe to verify the application is processing requests:

import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
import jakarta.ws.rs.core.Response;
import jakarta.enterprise.context.ApplicationScoped;

@Path("/ping")
@ApplicationScoped
public class PingResource {

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public Response ping() {
        return Response.ok("pong").build();
    }
}

Add a Vigilmon monitor for http://<your-server>:9080/api/ping with a 1-minute interval. This verifies the JAX-RS layer is functional, not just the health endpoint.

Step 4: Enable MicroProfile Metrics for JVM and Thread Pool

Add mpMetrics-5.0 (Micrometer-based) to your server.xml:

<featureManager>
  <feature>mpMetrics-5.0</feature>
  <!-- other features -->
</featureManager>

Open Liberty exposes metrics at /metrics. Key JVM metrics are available under the jvm scope. To check heap utilization, add a Vigilmon monitor that validates the metrics endpoint is reachable:

  1. Click Add Monitor in Vigilmon.
  2. Set Type to HTTP / HTTPS.
  3. Enter: http://<your-server>:9080/metrics
  4. Set Expected HTTP status to 200.
  5. Click Save.

For actual threshold alerting on JVM heap and thread pool depth, configure MicroProfile Metrics alerts in your metrics pipeline (Prometheus + Alertmanager) and use Vigilmon as a complementary availability layer.

Step 5: Monitor the Admin REST API

Open Liberty's admin REST API runs on port 9443 (HTTPS) by default and requires the restConnector-2.0 feature:

<featureManager>
  <feature>restConnector-2.0</feature>
</featureManager>

<basicRegistry id="basic" realm="BasicRealm">
  <user name="admin" password="{xor}PTA9Lyc=" />
</basicRegistry>

<administrator-role>
  <user>admin</user>
</administrator-role>

Add a Vigilmon monitor for the admin API:

  1. Click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter: https://<your-server>:9443/ibm/api
  4. Set Expected HTTP status to 401 (unauthenticated — the endpoint is up but requires auth).
  5. Click Save.

A 401 response confirms the admin API is reachable. Any other response (connection refused, 503) indicates the admin REST feature failed to load.

Step 6: Monitor Critical Background Jobs with Heartbeats

If your Open Liberty application runs background jobs (EJB timers, ManagedScheduledExecutorService, batch jobs), add heartbeat pings:

import jakarta.ejb.Schedule;
import jakarta.ejb.Singleton;
import org.eclipse.microprofile.config.inject.ConfigProperty;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

@Singleton
public class HeartbeatJob {

    @ConfigProperty(name = "vigilmon.heartbeat.url")
    String heartbeatUrl;

    @Schedule(minute = "*/5", hour = "*", persistent = false)
    public void ping() throws Exception {
        HttpClient.newHttpClient().send(
            HttpRequest.newBuilder(URI.create(heartbeatUrl)).GET().build(),
            HttpResponse.BodyHandlers.discarding()
        );
    }
}

Set vigilmon.heartbeat.url in your Open Liberty server.env or via MicroProfile Config. Create a Vigilmon Heartbeat monitor with a 10-minute expected interval.

Step 7: Monitor Open Liberty Log Error Rate

Open Liberty logs errors to /logs/messages.log and /logs/console.log. Set up a file-based heartbeat that Vigilmon indirectly monitors via a log-watcher script:

#!/bin/bash
# Run as a cron job every minute
LOG_FILE="/opt/ol/wlp/usr/servers/defaultServer/logs/messages.log"
VIGILMON_HEARTBEAT_URL="https://vigilmon.online/api/heartbeat/YOUR_ID"

# Count ERROR lines in the last minute
ERROR_COUNT=$(awk -v d="$(date -d '1 minute ago' '+%Y-%m-%d %H:%M')" \
  '$0 > d && /\[ERROR\]/' "$LOG_FILE" | wc -l)

if [ "$ERROR_COUNT" -eq 0 ]; then
  # No errors — ping the heartbeat (all-clear)
  curl -s "$VIGILMON_HEARTBEAT_URL"
fi

Create a Vigilmon Heartbeat monitor with a 2-minute interval. If errors accumulate, the heartbeat stops firing and Vigilmon alerts you.

Step 8: Configure Alert Notifications

In Vigilmon, go to Settings → Notifications and configure:

| Monitor | Alert Condition | Severity | |---|---|---| | /health/live | Non-200 or body missing UP | Critical | | /health/ready | Non-200 or body missing UP | High | | Synthetic /ping | Non-200 | High | | /metrics endpoint | Non-200 | Medium | | Admin REST API | Non-401 and non-200 | High | | Background job heartbeat | Missed for >10 minutes | High | | Log error rate heartbeat | Missed for >2 minutes | Medium |

Step 9: Test Your Monitoring Setup

Test Liveness Alert

# Stop the Open Liberty server
/opt/ol/wlp/bin/server stop defaultServer

# Verify Vigilmon fires a liveness alert within 2 minutes
# Restart
/opt/ol/wlp/bin/server start defaultServer

Test Readiness Alert

Simulate a database outage:

# Stop your database
sudo systemctl stop postgresql

# The /health/ready endpoint should return DOWN within one health check cycle
# Verify Vigilmon fires a readiness alert
sudo systemctl start postgresql

Test Background Job Heartbeat

Comment out the @Schedule annotation temporarily, redeploy, and verify the heartbeat alert fires after the expected interval.

Conclusion

Open Liberty's MicroProfile Health integration makes it one of the most monitoring-friendly Java runtimes available — but that only helps you if you're actively watching the endpoints. With Vigilmon you get:

  • Instant liveness and readiness alerts from MicroProfile Health without any custom probe configuration
  • Thread pool and JVM visibility via the metrics endpoint availability check
  • Admin API reachability monitoring ensuring operational tooling stays available
  • Background job health via heartbeat monitors covering EJB timers and batch jobs
  • Log error rate alerting catching exception spikes that health endpoints don't surface

Start with the /health/live and /health/ready monitors, then add the synthetic ping and admin API checks. Those four monitors cover the majority of Open Liberty failure modes in production.

Sign up for Vigilmon — the first monitor is free.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles