Monitoring GeoServer with Vigilmon

GeoServer is the backbone of open source geospatial infrastructure. National mapping agencies, city GIS departments, and spatial data platforms all rely on it to serve WMS map tiles, WFS vector features, and WCS raster coverage via OGC-standard APIs. When GeoServer goes down, every map client that depends on it goes dark. When it slows down, map renders stall and GetFeature queries time out. Vigilmon gives you the continuous checks, latency tracking, and alerting to catch problems before your users do.

What You'll Set Up

• HTTP uptime monitor for the GeoServer web application
• WMS and WFS endpoint latency checks
• PostGIS data store connectivity monitoring
• GeoWebCache tile hit rate tracking
• JVM heap utilization alerts
• GetCapabilities health checks

Prerequisites

• GeoServer 2.20+ running on Apache Tomcat or Jetty (accessible over HTTP/HTTPS)
• GeoServer REST API enabled (it is by default)
• A free Vigilmon account

Step 1: Monitor GeoServer Web Application Health

GeoServer exposes its web interface at /geoserver/web/. This is your primary uptime signal — if Tomcat or Jetty is down, or if the GeoServer WAR failed to deploy, this request will fail.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the URL: https://geoserver.yourdomain.com/geoserver/web/
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

For a more targeted health check, the GeoServer REST API exposes a system status endpoint:

GET /geoserver/rest/about/status

This returns a JSON/XML document confirming GeoServer modules are loaded and operational. Use it as your monitor URL if you want application-level confirmation rather than a plain HTTP check.

Step 2: Monitor WMS GetCapabilities and Request Latency

The WMS GetCapabilities request is what every map client calls first to discover available layers. Slow or failed GetCapabilities breaks every downstream map request.

Add a monitor for your primary workspace WMS:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://geoserver.yourdomain.com/geoserver/ows?service=WMS&version=1.3.0&request=GetCapabilities
3. Check interval: 2 minutes.
4. Expected HTTP status: 200.
5. Under Advanced, set Response must contain: WMS_Capabilities (confirms a valid capabilities document, not an exception).
6. Save.

For WMS GetMap latency, add a monitor that actually renders a tile from a known layer:

GET /geoserver/ows?service=WMS&version=1.3.0&request=GetMap
  &layers=yourlayer
  &bbox=-180,-90,180,90
  &width=256&height=256
  &srs=EPSG:4326
  &format=image/png

Replace yourlayer with a lightweight layer in your GeoServer instance. Set a Response time alert threshold of 3000ms — p95 above 3 seconds indicates a rendering bottleneck.

Step 3: Monitor WFS GetFeature Latency

WFS serves vector features and typically involves PostGIS queries. Slow WFS responses indicate either large result sets, missing spatial indexes, or PostGIS connectivity issues.

1. Add a monitor for WFS GetCapabilities:

GET /geoserver/ows?service=WFS&version=2.0.0&request=GetCapabilities

Set Response must contain: WFS_Capabilities.

2. For a representative WFS GetFeature check, use a small bounding box query:

GET /geoserver/ows?service=WFS&version=2.0.0&request=GetFeature
  &typeName=yournamespace:yourlayer
  &count=1
  &outputFormat=application/json

The count=1 limit keeps the response small while still exercising the full query path including PostGIS. Set a response time alert of 5000ms — p95 above 5 seconds indicates a data store or indexing problem.

Step 4: Monitor PostGIS Data Store Connectivity

Most GeoServer deployments connect to PostGIS as the primary vector data store. You can verify PostGIS reachability through the GeoServer REST API:

# Check a specific data store status
curl -u admin:geoserver \
  https://geoserver.yourdomain.com/geoserver/rest/workspaces/yourworkspace/datastores/yourstore.json

Add a Vigilmon monitor against this REST endpoint:

1. Type: HTTP / HTTPS
2. URL: https://geoserver.yourdomain.com/geoserver/rest/workspaces/yourworkspace/datastores/yourstore.json
3. Add HTTP header: Authorization: Basic <base64(admin:password)>
4. Response must contain: "enabled":true
5. Check interval: 2 minutes

If PostGIS is down, GeoServer will still respond to the REST API call but the datastore enabled status will reflect connectivity issues. A missing or false value triggers the alert.

For direct PostGIS monitoring, add a TCP monitor:

1. Type: TCP Port Check
2. Host: your-postgis-host
3. Port: 5432
4. Check interval: 1 minute

Step 5: Track GeoWebCache Tile Hit Rate

GeoWebCache (GWC), bundled with GeoServer, pre-renders and caches map tiles. A hit rate below 50% means most requests are being re-rendered live, creating rendering load that GeoServer was not designed to sustain at scale.

Query GWC statistics via the GeoWebCache REST API:

curl -u admin:geoserver \
  https://geoserver.yourdomain.com/geoserver/gwc/rest/statistics

This returns tile hit/miss counts per layer. Use the GeoServer REST API to expose these as a custom metric, or add a cron heartbeat to a script that calculates hit rate and posts to Vigilmon:

#!/bin/bash
# Post GWC hit rate as a heartbeat signal
HITS=$(curl -s -u admin:password https://geoserver.yourdomain.com/geoserver/gwc/rest/statistics | jq '.hit_count')
MISSES=$(curl -s -u admin:password https://geoserver.yourdomain.com/geoserver/gwc/rest/statistics | jq '.miss_count')
TOTAL=$((HITS + MISSES))
RATE=$((HITS * 100 / TOTAL))

if [ "$RATE" -lt 50 ]; then
  echo "GWC hit rate ${RATE}% below threshold"
  exit 1
fi

# Post heartbeat on success
curl -s "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN"

In Vigilmon, create a Cron Heartbeat monitor with an interval of 5 minutes and point it at the URL you generated in the dashboard.

Step 6: Monitor JVM Heap Utilization

GeoServer is a Java application. JVM heap pressure causes increased garbage collection pauses, slow tile rendering, and OutOfMemoryError crashes. Monitor heap via the GeoServer REST system status API:

GET /geoserver/rest/about/status

The response includes JVM memory statistics. A cron heartbeat script can extract and threshold-check heap utilization:

#!/bin/bash
STATUS=$(curl -s -u admin:password \
  -H "Accept: application/json" \
  https://geoserver.yourdomain.com/geoserver/rest/about/status)

# Extract heap used percentage
HEAP_USED=$(echo "$STATUS" | jq '.about.status[] | select(.name=="jvm.memory.heap.used") | .value')
HEAP_MAX=$(echo "$STATUS" | jq '.about.status[] | select(.name=="jvm.memory.heap.max") | .value')
HEAP_PCT=$((HEAP_USED * 100 / HEAP_MAX))

if [ "$HEAP_PCT" -gt 80 ]; then
  echo "JVM heap ${HEAP_PCT}% exceeds threshold"
  exit 1
fi

curl -s "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN"

Set the alert threshold at 80% heap utilization. Above that, GC overhead increases sharply and rendering performance degrades.

Step 7: Configure Alerting

In Vigilmon, configure alerts for each monitor:

| Monitor | Alert Condition | Severity | |---|---|---| | GeoServer web UI | Status ≠ 200 | Critical | | WMS GetCapabilities | Status ≠ 200 or response time >2s | High | | WMS GetMap | Response time p95 >3s | High | | WFS GetFeature | Response time p95 >5s | Medium | | PostGIS TCP | Port unreachable | Critical | | PostGIS datastore REST | enabled not true | Critical | | GWC hit rate heartbeat | Heartbeat missed | Medium | | JVM heap heartbeat | Heartbeat missed | High |

For the GeoServer web UI and PostGIS monitors, set notification channels to immediately page your on-call engineer — these failures take down your entire map service. For latency alerts, use a slightly longer check window (3 consecutive failures) to avoid alerting on transient spikes.

Step 8: Layer-Count Sanity Check

Large GeoServer deployments publish hundreds of layers. Accidentally deleting a workspace or data store wipes all layers in that group. Add a cron heartbeat that checks published layer count:

#!/bin/bash
LAYER_COUNT=$(curl -s -u admin:password \
  -H "Accept: application/json" \
  https://geoserver.yourdomain.com/geoserver/rest/layers.json \
  | jq '.layers.layer | length')

# Alert if count drops below expected minimum
if [ "$LAYER_COUNT" -lt 10 ]; then
  echo "Layer count dropped to ${LAYER_COUNT}"
  exit 1
fi

curl -s "https://vigilmon.online/api/heartbeat/YOUR_HEARTBEAT_TOKEN"

Tune the threshold to a value safely below your normal layer count.

Conclusion

A GeoServer outage or slowdown immediately impacts every application and user that depends on your OGC services. With Vigilmon, you have continuous uptime checks on the web application and individual OGC endpoints, latency tracking to catch rendering bottlenecks before they become timeouts, PostGIS connectivity alerts to catch data store failures, and JVM heap monitoring to prevent GC-induced slowdowns. Set up these monitors in under 15 minutes and have the confidence that your geospatial infrastructure is working — even when no one is actively looking at the maps.

Get started at vigilmon.online.