tutorial

Monitoring Payara Micro with Vigilmon

Payara Micro is a bootable-JAR Jakarta EE runtime with built-in Hazelcast clustering — but cluster partitions, pool exhaustion, and silent deployment failures need active monitoring. Here's how to monitor Payara Micro health, Hazelcast data grid, and JDBC pools with Vigilmon.

Payara Micro is a standalone, bootable-JAR Jakarta EE runtime for microservices. Pass your WAR file to the Payara Micro JAR and it starts a full Jakarta EE container — with Hazelcast-based clustering between instances, MicroProfile Health, MicroProfile Metrics, and MicroProfile Fault Tolerance built in. When a Hazelcast cluster splits, distributed sessions silently diverge. When a JDBC pool drains, requests block with no error visible from the outside. Vigilmon gives you the monitoring layer to catch these failures before they reach users.

What You'll Set Up

  • MicroProfile Health liveness and readiness monitoring
  • HTTP request throughput synthetic checks
  • Hazelcast cluster member count alerts
  • JVM heap and GC pressure monitoring
  • JDBC connection pool availability checks

Prerequisites

  • Payara Micro 6.x (Jakarta EE 10) or 5.x (Jakarta EE 8)
  • MicroProfile Health enabled (included in Payara Micro by default)
  • A free Vigilmon account

Why Monitor Payara Micro?

Payara Micro's embedded architecture and Hazelcast clustering introduce failure modes that aren't covered by basic process monitoring:

  • Hazelcast cluster partitions cause different instances to operate on different views of distributed session data — users see inconsistent state with no errors thrown.
  • JDBC pool exhaustion causes new requests to queue at the pool wait threshold, making the application appear to slow down rather than fail outright.
  • CDI and EJB deployment failures leave the instance running but the application partially deployed — MicroProfile Health returns DOWN but only if you have custom health checks that verify deployment.
  • Hazelcast data grid memory pressure causes evictions and rebalancing that spike latency across the entire cluster without individual instance failures.
  • Instance count drift — expected 3 instances, got 2 after an OOM kill — is invisible unless you're actively monitoring cluster membership.

Vigilmon monitors the endpoints and heartbeats that expose these conditions.

Key Metrics to Monitor

| Metric | What It Reveals | |---|---| | /health/live | JVM alive, Payara Micro process not deadlocked | | /health/ready | Application deployed, datasources available | | HTTP request throughput | Drop indicating routing or deployment failure | | Hazelcast cluster member count | Member departure indicating partition or crash | | Hazelcast data grid memory usage | Memory approaching Hazelcast heap limit | | JVM heap utilization | Heap >85% before OOM kill | | GC pause duration | Pause >500ms causing latency spikes | | JDBC pool availability | Pool exhaustion causing request blocking | | Deployment success rate | CDI/EJB deployment failures | | Instance count vs. expected | Scale-down or crash reducing cluster size |

Step 1: Enable MicroProfile Health in Payara Micro

Payara Micro includes MicroProfile Health out of the box. Add a custom readiness check that verifies your JDBC datasource:

import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Readiness;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.annotation.Resource;
import javax.sql.DataSource;
import java.sql.Connection;

@Readiness
@ApplicationScoped
public class DatabaseReadinessCheck implements HealthCheck {

    @Resource(lookup = "jdbc/myDataSource")
    DataSource dataSource;

    @Override
    public HealthCheckResponse call() {
        try (Connection conn = dataSource.getConnection()) {
            boolean valid = conn.isValid(2);
            return valid
                ? HealthCheckResponse.up("datasource")
                : HealthCheckResponse.down("datasource");
        } catch (Exception e) {
            return HealthCheckResponse.named("datasource")
                .down()
                .withData("error", e.getMessage())
                .build();
        }
    }
}

Package this with your WAR and start Payara Micro:

java -jar payara-micro.jar --deploy myapp.war --port 8080

The health endpoints are available at:

  • http://localhost:8080/health — combined
  • http://localhost:8080/health/live — liveness
  • http://localhost:8080/health/ready — readiness

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>:8080/health/live
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Under Response body check, enter: UP.
  7. Click Save.

Readiness Monitor

Repeat with /health/ready. The readiness endpoint verifies your datasource check passes — catching JDBC pool issues that liveness checks miss.

Step 3: Add a Synthetic Request Throughput Check

Add a lightweight JAX-RS health ping to your application:

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

@Path("/health/ping")
@ApplicationScoped
public class PingEndpoint {

    @GET
    @Produces(MediaType.APPLICATION_JSON)
    public String ping() {
        return "{\"status\":\"ok\"}";
    }
}

Add a Vigilmon monitor for http://<your-server>:8080/health/ping with a 1-minute interval. This tests the full JAX-RS request path, not just the MicroProfile Health subsystem.

Step 4: Monitor Hazelcast Cluster Health

Payara Micro exposes Hazelcast cluster information via the Payara Micro Management REST API. Enable it by starting with the --enableRequestTracing flag or via the admin console:

java -jar payara-micro.jar \
  --deploy myapp.war \
  --port 8080 \
  --clusterName my-cluster

Create a cluster health check script that monitors the expected member count:

#!/bin/bash
# check-hazelcast.sh — run every 5 minutes via cron
EXPECTED_MEMBERS=3
VIGILMON_HEARTBEAT="https://vigilmon.online/api/heartbeat/YOUR_ID"

# Query Hazelcast management center or REST API for member count
# For Payara Micro, use the Hazelcast Management Center or query via JMX
ACTUAL_MEMBERS=$(curl -s "http://localhost:8080/hazelcast/rest/cluster" \
  | python3 -c "import sys,json; d=json.load(sys.stdin); print(len(d.get('members', [])))" 2>/dev/null)

if [ "$ACTUAL_MEMBERS" -ge "$EXPECTED_MEMBERS" ]; then
  curl -s "$VIGILMON_HEARTBEAT"
fi

Create a Vigilmon Heartbeat monitor with a 10-minute expected interval. If any member drops below the expected count, the heartbeat stops and Vigilmon alerts you.

Step 5: Monitor Hazelcast Data Grid Memory

Add a custom MicroProfile Health check for Hazelcast data grid memory:

import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.HazelcastInstance;
import com.hazelcast.cluster.ClusterState;
import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Liveness;
import jakarta.enterprise.context.ApplicationScoped;

@Liveness
@ApplicationScoped
public class HazelcastHealthCheck implements HealthCheck {

    @Override
    public HealthCheckResponse call() {
        HazelcastInstance hz = Hazelcast.getAllHazelcastInstances()
            .stream().findFirst().orElse(null);
        if (hz == null) {
            return HealthCheckResponse.down("hazelcast");
        }
        boolean clusterOk = hz.getCluster().getClusterState() == ClusterState.ACTIVE;
        int memberCount = hz.getCluster().getMembers().size();
        return HealthCheckResponse.named("hazelcast")
            .status(clusterOk && memberCount >= 1)
            .withData("members", memberCount)
            .withData("state", hz.getCluster().getClusterState().toString())
            .build();
    }
}

This surfaces cluster partition and member count via the /health/live endpoint that Vigilmon already monitors.

Step 6: Monitor JVM Heap via MicroProfile Metrics

Payara Micro exposes MicroProfile Metrics at /metrics. Add a Vigilmon monitor to verify the endpoint is reachable:

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

For threshold-based JVM heap alerting, pipe the Prometheus-format metrics to an Alertmanager rule:

# prometheus-rules.yml
- alert: PayaraMicroHeapHigh
  expr: jvm_memory_used_bytes{area="heap"} / jvm_memory_max_bytes{area="heap"} > 0.85
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Payara Micro heap usage above 85%"

Step 7: Monitor Multiple Instances with Named Monitors

In a multi-instance Payara Micro deployment, create named Vigilmon monitors per instance:

| Monitor Name | URL | Interval | |---|---|---| | payara-micro-1-live | http://10.0.1.11:8080/health/live | 1 min | | payara-micro-2-live | http://10.0.1.12:8080/health/live | 1 min | | payara-micro-3-live | http://10.0.1.13:8080/health/live | 1 min | | payara-cluster-heartbeat | Heartbeat URL | 10 min |

The per-instance monitors catch individual instance failures. The cluster heartbeat catches overall cluster degradation when the member count drops.

Step 8: Configure Alert Notifications

Go to Settings → Notifications in Vigilmon and configure:

| Monitor | Alert Condition | Severity | |---|---|---| | /health/live per instance | 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 | | Cluster heartbeat | Missed for >10 minutes | High |

Step 9: Test Your Monitoring Setup

Test Instance Failure Alert

# Kill one Payara Micro instance
pkill -f "payara-micro.jar"

# Verify the per-instance liveness alert fires within 2 minutes
# Restart the instance
java -jar payara-micro.jar --deploy myapp.war --port 8080 &

Test Readiness Alert (Database Outage)

# Stop your database
sudo systemctl stop postgresql

# /health/ready should return DOWN
# Verify Vigilmon fires the readiness alert
sudo systemctl start postgresql

Test Cluster Heartbeat

Stop enough instances that the member count drops below the threshold in your heartbeat script. Verify the heartbeat stops and Vigilmon alerts within the expected interval.

Conclusion

Payara Micro's embedded Hazelcast clustering and MicroProfile integration make it powerful for multi-instance Jakarta EE deployments — but cluster health, data grid memory, and JDBC pool availability are invisible without active monitoring. With Vigilmon you get:

  • Per-instance liveness and readiness alerts from MicroProfile Health
  • Hazelcast cluster integrity monitoring via member count heartbeats
  • JDBC datasource health surfaced through the readiness endpoint
  • Metrics endpoint availability confirming the Micrometer pipeline is running
  • Full cluster coverage with named per-instance monitors

Start with the MicroProfile Health monitors (/health/live and /health/ready) for each instance, then add the cluster heartbeat. Those three monitors catch the majority of Payara Micro production failure modes.

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