Apache OFBiz (Open For Business) is one of the most comprehensive open-source enterprise platforms, covering eCommerce, order management, manufacturing (MRP), accounting (GL/AR/AP), inventory, procurement, HR, project management, and CRM — all integrated in a single Java EE application running on an embedded Tomcat server. Its depth is its strength and its monitoring challenge: a JVM heap spike, a Quartz job failure, or a stalled service engine can silently break entire business workflows across modules that appear superficially healthy. Vigilmon closes that gap by watching the application, database, service engine, job scheduler, JVM, and eCommerce storefront from the outside.
What You'll Set Up
- HTTP uptime monitor for the OFBiz application
- Database connectivity heartbeat (PostgreSQL or MySQL)
- Service engine health heartbeat
- Quartz job scheduler heartbeat
- JVM heap and GC monitoring
- eCommerce WebStore health check (if in use)
- Disk space monitor for logs and uploads
- Active session count heartbeat
Prerequisites
- Apache OFBiz running and accessible (default HTTPS port 443 or 8443)
- A free Vigilmon account
Step 1: Monitor the OFBiz Application
OFBiz runs as a Java EE application inside its embedded Tomcat server. The primary health indicator is whether the web application responds to HTTP requests.
- Log in to vigilmon.online and click Add Monitor.
- Set Type to
HTTP / HTTPS. - Enter your OFBiz URL:
https://your-server-ip:8443/webtools/control/main. - Set Expected HTTP status to
200. - Enable Monitor SSL certificate and set the alert threshold to
30 days. - Set Check interval to
1 minute. - Click Save.
If OFBiz is behind a load balancer or reverse proxy on a standard port:
https://erp.yourdomain.com/webtools/control/main
The /webtools/control/main path exercises the OFBiz controller framework (not just a static file), confirming the Java application itself is alive and the component system has initialized. A Tomcat that started but whose OFBiz components failed to initialize returns a 500 here.
Step 2: Monitor Database Connectivity
OFBiz's Entity Engine routes all database operations through its custom ORM. Every business operation — posting a GL entry, fulfilling an order, running MRP — requires the database. A loss of connectivity cascades across all modules simultaneously.
- In Vigilmon, click Add Monitor → Cron Heartbeat.
- Set the expected interval to
5 minutes. - Copy the heartbeat URL.
PostgreSQL
#!/bin/bash
# /usr/local/bin/ofbiz-db-check.sh
DB_HOST="localhost"
DB_PORT="5432"
DB_NAME="ofbiz"
DB_USER="ofbiz"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-db-heartbeat"
RESULT=$(psql -h "$DB_HOST" -p "$DB_PORT" -U "$DB_USER" -d "$DB_NAME" \
-c "SELECT 1;" -t -A 2>/dev/null)
if [ "$RESULT" = "1" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "ERROR: OFBiz database connectivity check failed"
fi
MySQL
#!/bin/bash
# /usr/local/bin/ofbiz-db-check.sh
DB_HOST="localhost"
DB_USER="ofbiz"
DB_PASS="your-password"
DB_NAME="ofbiz"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-db-heartbeat"
RESULT=$(mysql -h "$DB_HOST" -u "$DB_USER" -p"$DB_PASS" \
-e "SELECT 1;" "$DB_NAME" 2>/dev/null | tail -1)
if [ "$RESULT" = "1" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "ERROR: OFBiz MySQL connectivity check failed"
fi
Make executable and schedule every 5 minutes:
chmod +x /usr/local/bin/ofbiz-db-check.sh
crontab -e
# Add:
*/5 * * * * /usr/local/bin/ofbiz-db-check.sh
Step 3: Monitor the Service Engine
OFBiz's Service Engine is its ERP bus: all business logic runs as registered services (Java classes or Groovy scripts). The Service Engine handles synchronous and asynchronous service invocations. A stalled service engine means ERP transactions — order creation, inventory adjustments, GL postings — cannot complete.
Add a heartbeat that verifies the Service Engine is accepting invocations via the OFBiz REST API:
- In Vigilmon, create a Cron Heartbeat with a
10 minuteexpected interval. - Copy the heartbeat URL.
#!/bin/bash
# /usr/local/bin/ofbiz-service-check.sh
OFBIZ_URL="https://localhost:8443"
USERNAME="admin"
PASSWORD="ofbiz"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-service-heartbeat"
# Call a lightweight service endpoint to verify the Service Engine responds
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" -k -m 15 \
-u "$USERNAME:$PASSWORD" \
"$OFBIZ_URL/webtools/control/main")
if [ "$HTTP_CODE" = "200" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "WARNING: OFBiz service engine returned HTTP $HTTP_CODE"
fi
Schedule every 10 minutes:
*/10 * * * * /usr/local/bin/ofbiz-service-check.sh
To monitor the async service queue depth directly, query the RUNTIME_DATA or JOB_SANDBOX tables (OFBiz stores async job state in these Entity Engine tables):
psql -U ofbiz -d ofbiz -c "
SELECT count(*) AS pending_jobs
FROM JOB_SANDBOX
WHERE RUN_STATUS_ID = 'SERVICE_PENDING';
" -t -A
Alert if pending jobs exceed 500 — a backlog that large indicates the async service queue is not draining.
Step 4: Monitor the Quartz Job Scheduler
OFBiz uses a Quartz-based job scheduler for critical recurring operations: MRP runs (material requirements planning), recurring billing, report generation, and data synchronization. A missed MRP run or billing job has direct financial and operational consequences.
Add a dedicated heartbeat for your most critical scheduled job. The pattern is: a wrapper cron job runs the check and pings Vigilmon after confirming the OFBiz scheduler job ran successfully.
- In Vigilmon, create a Cron Heartbeat — set the expected interval to match your most critical job (e.g.,
24 hoursfor daily MRP,1 hourfor recurring billing). - Copy the heartbeat URL.
#!/bin/bash
# /usr/local/bin/ofbiz-scheduler-check.sh
# Checks that the OFBiz job scheduler ran its most critical job within the last 26 hours
DB_HOST="localhost"
DB_USER="ofbiz"
DB_NAME="ofbiz"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-scheduler-heartbeat"
JOB_NAME="MRP Run" # Replace with your critical job name
# Query last successful run of the critical scheduler job
LAST_RUN=$(psql -h "$DB_HOST" -U "$DB_USER" -d "$DB_NAME" -t -A -c "
SELECT LAST_UPDATED_STAMP
FROM JOB_SANDBOX
WHERE JOB_NAME = '$JOB_NAME'
AND RUN_STATUS_ID = 'SERVICE_FINISHED'
ORDER BY LAST_UPDATED_STAMP DESC
LIMIT 1;
" 2>/dev/null)
if [ -z "$LAST_RUN" ]; then
echo "ERROR: No successful run found for job: $JOB_NAME"
exit 1
fi
# Check if last run was within 26 hours
LAST_RUN_EPOCH=$(date -d "$LAST_RUN" +%s 2>/dev/null)
NOW_EPOCH=$(date +%s)
AGE_HOURS=$(( (NOW_EPOCH - LAST_RUN_EPOCH) / 3600 ))
if [ "$AGE_HOURS" -lt 26 ]; then
curl -s "$HEARTBEAT_URL"
else
echo "WARNING: Critical job '$JOB_NAME' last ran ${AGE_HOURS}h ago"
fi
Schedule this check to run every 30 minutes:
*/30 * * * * /usr/local/bin/ofbiz-scheduler-check.sh
Step 5: Monitor JVM Heap Health
OFBiz is a Java application with a large in-memory entity cache. JVM heap pressure causes GC pauses that freeze request processing for hundreds of milliseconds, cascading into slow page loads and eventually OutOfMemoryError crashes. Monitoring heap usage gives you early warning before degradation is visible to users.
Add a heartbeat that reads OFBiz JVM metrics:
#!/bin/bash
# /usr/local/bin/ofbiz-jvm-check.sh
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-jvm-heartbeat"
HEAP_THRESHOLD=85 # percent
OFBIZ_PID=$(pgrep -f "ofbiz.jar" | head -1)
if [ -z "$OFBIZ_PID" ]; then
echo "ERROR: OFBiz process not found"
exit 1
fi
# Use jstat to get heap usage percentage
HEAP_USED=$(jstat -gc "$OFBIZ_PID" 2>/dev/null | awk 'NR==2 {
used = $3 + $4 + $6 + $8
capacity = $1 + $2 + $5 + $7
printf "%.0f", (used/capacity)*100
}')
if [ -n "$HEAP_USED" ] && [ "$HEAP_USED" -lt "$HEAP_THRESHOLD" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "WARNING: OFBiz JVM heap at ${HEAP_USED}% (threshold ${HEAP_THRESHOLD}%)"
fi
Schedule every 5 minutes:
*/5 * * * * /usr/local/bin/ofbiz-jvm-check.sh
If OFBiz exposes JMX, use jmxterm or the OFBiz admin console to fetch GC pause times and alert if GC pause exceeds 500 ms.
Step 6: Monitor the eCommerce WebStore
If your OFBiz deployment includes the built-in WebStore (B2B/B2C eCommerce fully integrated with OFBiz inventory, pricing, and order management), monitor it as a separate surface — storefront failures affect revenue directly.
- In Vigilmon, click Add Monitor → HTTP / HTTPS.
- Enter:
https://your-server-ip:8443/ecommerce/control/main. - Set Expected HTTP status to
200. - Enable Response body must contain and enter a string from your store's homepage (your store name or
</html>). - Set Check interval to
2 minutes. - Click Save.
For add-to-cart API health:
#!/bin/bash
# /usr/local/bin/ofbiz-webstore-check.sh
OFBIZ_URL="https://localhost:8443"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-webstore-heartbeat"
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" -k -m 10 \
"$OFBIZ_URL/ecommerce/control/main")
if [ "$HTTP_CODE" = "200" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "WARNING: OFBiz WebStore returned HTTP $HTTP_CODE"
fi
Step 7: Monitor Disk Space
OFBiz generates extensive log files (including entity engine debug logs and service engine traces) and stores uploaded media assets. Full disks cause Java I/O exceptions that crash the application.
- In Vigilmon, create a Cron Heartbeat with a
30 minuteexpected interval. - Copy the heartbeat URL.
#!/bin/bash
# /usr/local/bin/ofbiz-disk-check.sh
OFBIZ_HOME="/opt/ofbiz"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-disk-heartbeat"
DISK_THRESHOLD=80 # percent
USAGE=$(df "$OFBIZ_HOME" | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -lt "$DISK_THRESHOLD" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "WARNING: OFBiz disk usage ${USAGE}% (threshold ${DISK_THRESHOLD}%)"
fi
Schedule every 30 minutes:
*/30 * * * * /usr/local/bin/ofbiz-disk-check.sh
OFBiz log rotation should be configured in framework/catalina/ofbiz-containers.xml — without rotation, log files fill the disk within weeks.
Step 8: Monitor Active Session Count
OFBiz web sessions represent concurrent ERP users. An unexpectedly high session count can indicate a session leak (sessions not expiring), while a sudden drop to zero can indicate a Tomcat crash that hasn't yet caused the HTTP monitor to fail (brief recovery window).
#!/bin/bash
# /usr/local/bin/ofbiz-sessions-check.sh
OFBIZ_URL="https://localhost:8443"
HEARTBEAT_URL="https://vigilmon.online/heartbeat/your-sessions-heartbeat"
MAX_SESSIONS=500 # adjust to your licensed/expected concurrent user count
USERNAME="admin"
PASSWORD="ofbiz"
# Query Tomcat manager for active sessions (requires Tomcat manager to be enabled)
SESSIONS=$(curl -s -k -u "$USERNAME:$PASSWORD" \
"$OFBIZ_URL/manager/status?XML=true" 2>/dev/null \
| grep -oP '(?<=activeSessions=")[^"]+' | head -1)
if [ -n "$SESSIONS" ] && [ "$SESSIONS" -le "$MAX_SESSIONS" ]; then
curl -s "$HEARTBEAT_URL"
else
echo "WARNING: Active sessions: ${SESSIONS:-unknown} (limit $MAX_SESSIONS)"
fi
Schedule every 10 minutes:
*/10 * * * * /usr/local/bin/ofbiz-sessions-check.sh
Step 9: Configure Alert Channels
- Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
- Set Consecutive failures before alert to
2on the application HTTP monitor — a brief Tomcat GC pause can cause a single miss. - Set Consecutive failures before alert to
1on the database and JVM heap monitors — these escalate quickly.
Route monitors to urgency channels:
- Application down, database failure, JVM heap > 90% → Slack #erp-critical (immediate, wake on-call)
- Scheduler job missed, service engine stalled → Slack #erp-ops (urgent within 1 hour)
- Disk space, WebStore slowness → email (investigate at next shift)
Summary
| Monitor | Target | What It Catches |
|---|---|---|
| Application HTTP | /webtools/control/main 200 | OFBiz Tomcat crash |
| Database heartbeat | SELECT 1 every 5 min | Entity Engine DB failure |
| Service engine heartbeat | Admin API every 10 min | ERP business logic stalled |
| Scheduler heartbeat | JOB_SANDBOX query every 30 min | MRP/billing job failures |
| JVM heap | jstat every 5 min | Memory pressure before OOM |
| WebStore HTTP | /ecommerce/control/main | eCommerce storefront down |
| Disk space | df every 30 min | Log/media filling disk |
| Session count | Tomcat manager every 10 min | Session leak or quiet crash |
OFBiz's depth — hundreds of integrated tables, a Quartz scheduler, a custom ORM, and an embedded Tomcat — means failures are often narrow but high-impact. Vigilmon gives you visibility into each layer so a stalled MRP run or a heap pressure spike gets caught hours before it becomes a production incident.