Monitoring Open-Xchange App Suite with Vigilmon

Open-Xchange (OX App Suite) is an enterprise-grade open source email and groupware platform that powers webmail for some of the largest ISPs in Europe — Telekom, 1&1, Web.de, and GMX among them. When you self-host OX App Suite, you're running a complex multi-tier stack: the OX Java middleware backend, an Apache HTTP Server as the frontend proxy, MySQL for configuration and user data, Dovecot for email storage, and a WebSocket-based push notification system for real-time inbox updates. Any layer silently failing — a JVM heap exhaustion, a stalled database connection pool, or a push delivery backlog — leaves users with a broken or stale webmail experience. Vigilmon gives you comprehensive monitoring across the entire Open-Xchange stack.

What You'll Set Up

• HTTP uptime monitor for the OX App Suite web interface (Apache)
• OX middleware backend health check (Java application server)
• MySQL connectivity monitor for configdb and userdb
• IMAP/Dovecot server connectivity monitor
• JVM heap utilization alert via cron heartbeat
• WebSocket push delivery health check
• Session store health and active session count monitor
• Database connection pool saturation alert
• Alert channels with appropriate thresholds

Prerequisites

• Open-Xchange App Suite installed and accessible via HTTP/HTTPS
• MySQL running with OX configdb and userdb schemas
• Dovecot or another IMAP server accessible from the OX middleware host
• A free Vigilmon account

Step 1: Monitor the Apache Frontend

Apache is the entry point for all OX App Suite traffic — it serves static frontend assets and proxies dynamic requests to the OX Java middleware. An Apache failure blocks every user from accessing webmail.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your OX App Suite URL: https://webmail.yourdomain.com (or http://your-server-ip).
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Under Keyword check, enter App Suite or Open-Xchange to verify the real application is responding, not just a default Apache page.
7. Click Save.

This monitor covers both Apache availability and the static asset serving path. A 200 here means users can reach the login screen.

Step 2: Monitor the OX Middleware (Java Backend)

The OX middleware Java application server (ox-grizzly) runs on localhost port 8009 by default and handles all business logic: email retrieval, calendar, contacts, and session management. Apache proxies to it — but a middleware crash silently returns 502 errors to users even if Apache is healthy.

Create a direct check against the OX middleware health endpoint:

1. Type: HTTP / HTTPS
2. URL: http://127.0.0.1:8009/ajax/system/ping (adjust port if you've customized it)
3. Expected HTTP status: 200
4. Keyword check: pong or true
5. Check interval: 1 minute

If your Vigilmon account monitors from an external probe, expose the middleware health endpoint through Apache with restricted access:

<Location /ox-health>
    ProxyPass http://127.0.0.1:8009/ajax/system/ping
    # Restrict to monitoring IPs if needed
</Location>

Then set the Vigilmon URL to https://webmail.yourdomain.com/ox-health.

A failed middleware ping with a healthy Apache response is the classic OX failure mode — the proxy is up but the Java application has crashed or stopped accepting connections.

Step 3: Monitor MySQL

Open-Xchange stores user configuration, calendar data, contacts, session state, and application settings in MySQL. OX uses two database schemas: configdb (global OX configuration, server registration) and userdb schemas (per-context user data). A MySQL outage prevents logins, breaks calendar and contacts, and corrupts in-flight session operations.

Create a monitoring user:

CREATE USER 'vigilmon'@'localhost' IDENTIFIED BY 'strong-password-here';
GRANT SELECT ON configdb.* TO 'vigilmon'@'localhost';
-- Grant on at least one userdb schema:
GRANT SELECT ON oxdatabase_1.* TO 'vigilmon'@'localhost';
FLUSH PRIVILEGES;

Add a health check script:

#!/bin/bash
# Check both configdb and a userdb schema
CONFIGDB=$(mysql -u vigilmon -pstrong-password-here -h 127.0.0.1 configdb \
  -sN -e "SELECT 1" 2>/dev/null)
USERDB=$(mysql -u vigilmon -pstrong-password-here -h 127.0.0.1 oxdatabase_1 \
  -sN -e "SELECT 1" 2>/dev/null)

if [ "$CONFIGDB" = "1" ] && [ "$USERDB" = "1" ]; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_DB_HEARTBEAT" > /dev/null
fi

* * * * * /usr/local/bin/check-ox-db.sh

Create the heartbeat in Vigilmon with a 2-minute grace period. Checking both configdb and a userdb schema catches schema-specific failures that a single database ping would miss.

Step 4: Monitor IMAP / Dovecot Connectivity

Open-Xchange connects to Dovecot (or another IMAP server) on behalf of users for all email read and send operations. If the IMAP connection fails, users see empty inboxes and cannot send email — but OX itself continues to respond to HTTP requests, masking the failure from a basic uptime monitor.

Add a TCP monitor for the IMAP port:

1. Type: TCP
2. Host: your Dovecot server hostname or IP
3. Port: 143 (IMAP) or 993 (IMAPS)
4. Check interval: 2 minutes
5. Click Save.

For a deeper IMAP authentication check (preferred):

#!/bin/bash
RESULT=$(curl -s --max-time 15 \
  --url "imaps://mail.yourdomain.com" \
  --user "ox-monitor@yourdomain.com:monitorpassword" \
  -X "EXAMINE INBOX" 2>&1)

if echo "$RESULT" | grep -q "OK"; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_IMAP_HEARTBEAT" > /dev/null
fi

*/2 * * * * /usr/local/bin/check-ox-imap.sh

Create the heartbeat with a 3-minute grace period. An authentication-level check validates TLS negotiation, Dovecot's auth backend, and the mailbox layer — the exact path OX uses for every user's mailbox access.

Step 5: Monitor JVM Heap Utilization

The OX middleware is a Java application — JVM heap exhaustion triggers aggressive garbage collection, causes request latency to spike, and eventually results in OutOfMemoryError crashes. Monitor heap utilization proactively and alert before the JVM reaches its limit.

Use the OX management API or JMX to read heap metrics. The simplest approach uses the OX health endpoint if it exposes memory data, or directly via jstat:

#!/bin/bash
# Get OX middleware PID
OX_PID=$(pgrep -f "com.openexchange")

if [ -z "$OX_PID" ]; then
    # OX is not running — don't send heartbeat
    exit 1
fi

# Read heap utilization via jstat (percent used)
HEAP_USED=$(jstat -gc "$OX_PID" 2>/dev/null | tail -1 | awk '{
    eden_used=$6; survivor0=$8; old_used=$10;
    eden_cap=$5; survivor1=$9; old_cap=$7;
    total_used=eden_used+survivor0+old_used;
    total_cap=eden_cap+survivor1+old_cap;
    print int(total_used/total_cap*100)
}')

THRESHOLD=85

if [ "$HEAP_USED" -lt "$THRESHOLD" ] 2>/dev/null; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_JVM_HEARTBEAT" > /dev/null
fi

* * * * * /usr/local/bin/check-ox-jvm.sh

Create the heartbeat in Vigilmon with a 2-minute grace period. When JVM heap exceeds 85%, OX begins spending significant CPU time on GC instead of serving requests — the heartbeat going silent gives you 2 minutes to investigate before users notice degraded performance.

Step 6: Monitor Push Notification Delivery

Open-Xchange uses WebSocket-based push notifications to update inboxes in real time — when push fails, users must manually refresh to see new emails. This is a quality-of-service failure that users notice immediately but that doesn't show up in basic uptime monitoring.

Check push delivery via the OX push health endpoint:

#!/bin/bash
PUSH_STATUS=$(curl -s --max-time 10 \
  "http://127.0.0.1:8009/ajax/push/status" \
  -H "Cookie: your-admin-session-cookie" 2>&1)

if echo "$PUSH_STATUS" | grep -q '"active"'; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_PUSH_HEARTBEAT" > /dev/null
fi

Alternatively, monitor the WebSocket port directly:

1. Type: TCP
2. Host: webmail.yourdomain.com
3. Port: 8099 (or your configured WebSocket port)
4. Check interval: 5 minutes

Push failures are often the first symptom of OX middleware degradation — the long-poll WebSocket connections are the first to be dropped when the JVM is under pressure.

Step 7: Monitor the Session Store

Open-Xchange manages user sessions internally. A session store failure logs out all active users simultaneously — a high-impact, immediately visible incident. Monitor active session count and session store availability:

#!/bin/bash
# Query active sessions via OX admin SOAP or management API
SESSION_COUNT=$(curl -s --max-time 10 \
  "http://127.0.0.1:8009/ajax/system/info" 2>&1 | \
  python3 -c "import sys,json; d=json.load(sys.stdin); print(d.get('sessions',{}).get('active',0))" 2>/dev/null)

# As long as we can query sessions, the store is healthy
if [ $? -eq 0 ]; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_SESSION_HEARTBEAT" > /dev/null
fi

*/2 * * * * /usr/local/bin/check-ox-sessions.sh

Create the heartbeat with a 3-minute grace period. A sudden drop in active session count (not matched by a corresponding drop in login activity) indicates the session store has been reset or flushed.

Step 8: Monitor Database Connection Pool

Open-Xchange maintains connection pools to MySQL — one pool per configured database schema. When a pool is exhausted, new requests queue and eventually time out, causing intermittent errors that are difficult to diagnose without pool-level visibility.

Check pool utilization via the OX performance monitoring endpoint or via MySQL's SHOW PROCESSLIST:

#!/bin/bash
# Count active OX connections to MySQL
CONNECTIONS=$(mysql -u vigilmon -pstrong-password-here \
  -sN -e "SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE USER='openexchange'" 2>/dev/null)

MAX_CONNECTIONS=$(mysql -u vigilmon -pstrong-password-here \
  -sN -e "SELECT @@max_connections" 2>/dev/null)

# Alert if OX connections exceed 70% of MySQL max_connections
THRESHOLD=$(echo "$MAX_CONNECTIONS * 0.70" | bc | cut -d. -f1)

if [ "$CONNECTIONS" -lt "$THRESHOLD" ] 2>/dev/null; then
    curl -fsS "https://vigilmon.online/api/v1/heartbeat/YOUR_POOL_HEARTBEAT" > /dev/null
fi

* * * * * /usr/local/bin/check-ox-pool.sh

Create the heartbeat with a 2-minute grace period. Pool exhaustion typically precedes OX middleware errors by several minutes — catching it early gives you time to investigate before users see failures.

Step 9: Configure Alert Channels

Set up alert routing in Vigilmon for the OX stack:

1. Go to Alert Channels and add email, Slack, or PagerDuty.
2. Apply thresholds:

| Monitor | Alert After | Severity | |---|---|---| | Apache frontend | 2 consecutive failures (2 min) | Critical | | OX middleware ping | 2 consecutive failures (2 min) | Critical | | MySQL heartbeat | 1 missed beat | Critical | | IMAP TCP / auth | 3 consecutive failures (6 min) | High | | JVM heap heartbeat | 1 missed beat | Warning | | Push delivery heartbeat | 2 missed beats | Warning | | Session store heartbeat | 2 missed beats | High | | DB connection pool | 1 missed beat | Warning |

3. For Apache and OX middleware failures, configure escalation to on-call if the incident lasts more than 5 minutes — these directly block all users from accessing email.

Step 10: Create a Status Page

Show ISP customers or internal users a real-time health view of their webmail service:

1. In Vigilmon, go to Status Pages → New Status Page.
2. Group monitors by tier:
   • Web Layer: Apache frontend, OX middleware
   • Data Layer: MySQL, IMAP/Dovecot
   • Real-Time Features: Push delivery, session store
   • Infrastructure: Connection pool, JVM heap
3. Set a custom domain (e.g., status.mail.yourdomain.com).
4. Share with support staff and users.

Why Monitoring Open-Xchange Matters

OX App Suite is a mission-critical email platform — when it fails, users lose access to their primary communication channel. The risks specific to OX:

JVM GC pauses masking as slowness: Java GC pressure manifests as intermittent response time spikes, not hard failures. A heap monitor at 85% gives you 5–15 minutes of warning before a full OutOfMemoryError crash.

IMAP failure invisible to Apache monitors: OX App Suite responds to HTTP health checks even when it cannot connect to Dovecot. An empty inbox is the symptom; the IMAP monitor is the detection. Without it, you're diagnosing IMAP failures through user complaints.

WebSocket push is the first casualty: Under memory pressure or connection pool exhaustion, OX drops WebSocket push connections first. Users see stale inboxes before they see errors. A push monitor is your earliest degradation signal.

Vigilmon closes all three visibility gaps, giving you early warning across the entire OX stack before failures cascade to users.

Ready to monitor your Open-Xchange App Suite deployment? Create a free Vigilmon account and have all monitors running in under 20 minutes.