Monitoring Apache OpenMeetings with Vigilmon

Apache OpenMeetings is a full-featured open source web conferencing platform — offering video conferencing, audio conferencing, instant messaging, whiteboard collaboration, screen sharing, and recorded session playback all in a browser-based interface. When you self-host OpenMeetings, you're operating a multi-tier Java stack: the OpenMeetings web application on Apache Tomcat, the Red5 media server for real-time A/V streaming, a relational database for user and session data, and disk storage for recorded sessions. A failure in any of these components can silently disrupt a live meeting — or worse, bring down all conferencing without anyone knowing until callers start complaining. Vigilmon gives you independent external monitoring across every layer of the OpenMeetings stack.

What You'll Set Up

• HTTP uptime monitor for the OpenMeetings web application (Tomcat)
• Red5 media server health and RTMP port monitor
• Database connectivity monitor
• Recording storage disk space heartbeat
• JVM heap and application health checks
• Cron heartbeat for the recording pipeline (FFmpeg)
• Alert thresholds for each service tier

Prerequisites

• Apache OpenMeetings 6.x or later deployed on Tomcat
• Red5 media server running alongside OpenMeetings
• A relational database (PostgreSQL, MySQL, or Apache Derby) configured for production
• A free Vigilmon account

Step 1: Monitor the OpenMeetings Web Application

The OpenMeetings web application runs on Apache Tomcat and serves the conferencing UI, user management, and room orchestration. Monitoring the web root confirms Tomcat is alive and serving requests.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. URL: https://meetings.yourdomain.com/openmeetings/ (or http://your-server-ip:5080/openmeetings/).
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Under Keyword check, enter OpenMeetings to verify the application content loads, not just that the web server responds.
7. Enable Monitor SSL certificate and set the expiry alert threshold to 21 days.
8. Click Save.

If you have a dedicated health endpoint (e.g., via a custom servlet or the admin REST API), prefer it over the web root — a health endpoint that checks internal dependencies gives a richer signal than a static page load.

Step 2: Monitor the Red5 Media Server

Red5 is the RTMP media server that handles all real-time audio and video streaming in OpenMeetings. If Red5 crashes, every active conference room loses audio and video instantly — participants see frozen screens or disconnections.

Monitor the Red5 HTTP management port:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: http://your-server-ip:5080/ (Red5 shares port 5080 with OpenMeetings in the default configuration) or http://your-server-ip:5080/red5-management/ if running the management console.
3. Check interval: 1 minute
4. Expected HTTP status: 200
5. Click Save.

Monitor the RTMP port (TCP):

1. Click Add Monitor → TCP Port.
2. Host: your-server-ip or meetings.yourdomain.com.
3. Port: 1935 (default RTMP port).
4. Check interval: 1 minute
5. Click Save.

The RTMP TCP monitor is your primary signal for Red5 availability — if port 1935 goes down, browser participants using WebRTC fallback will fail ICE negotiation and lose media connectivity.

Step 3: Monitor Active Conference Room Count via Heartbeat

Active room count is the key operational metric for an OpenMeetings instance. You can query the OpenMeetings REST API to check the count and emit a heartbeat to Vigilmon.

1. Click Add Monitor → Cron Heartbeat in Vigilmon.
2. Set the expected interval to 5 minutes.
3. Copy the heartbeat URL (e.g., https://vigilmon.online/heartbeat/abc123).
4. Create a cron job or systemd timer that calls the OpenMeetings REST API and pings the heartbeat URL:

#!/bin/bash
# /usr/local/bin/check-openmeetings.sh
# Ping Vigilmon heartbeat — only if the rooms API responds
ROOMS=$(curl -sf \
  "http://localhost:5080/openmeetings/services/room/public?sid=YOUR_SESSION_ID" \
  | grep -c "room")
if [ "$ROOMS" -ge "0" ] 2>/dev/null; then
  curl -sf "https://vigilmon.online/heartbeat/abc123" > /dev/null
fi

Add to crontab:

*/5 * * * * /usr/local/bin/check-openmeetings.sh

If no heartbeat ping reaches Vigilmon within the expected interval, Vigilmon alerts you — signaling that either the OpenMeetings REST API has stopped responding or the cron job itself has died.

Step 4: Monitor the Database

OpenMeetings stores all user accounts, room definitions, calendar events, and session data in its database. A database failure will prevent users from logging in and rooms from being created.

For PostgreSQL:

1. Click Add Monitor → TCP Port.
2. Host: localhost (or your DB host).
3. Port: 5432
4. Check interval: 1 minute
5. Click Save.

For MySQL/MariaDB:

1. Click Add Monitor → TCP Port.
2. Host: localhost
3. Port: 3306
4. Check interval: 1 minute
5. Click Save.

Combine the DB TCP monitor with the Tomcat application monitor from Step 1 — if the application becomes unhealthy at the same time the DB port drops, database failure is the root cause.

Step 5: Monitor Recording Storage Capacity

OpenMeetings records sessions as FLV or MP4 files using FFmpeg, saving them to a local directory (typically $OPENMEETINGS_HOME/webapps/openmeetings/upload/). Storage exhaustion silently kills new recordings without any visible error to conference participants.

1. Click Add Monitor → Cron Heartbeat in Vigilmon.
2. Set the expected interval to 30 minutes.
3. Copy the heartbeat URL.
4. Create a script that checks disk usage and only pings Vigilmon if space is available:

#!/bin/bash
# /usr/local/bin/check-om-storage.sh
RECORDING_PATH="/opt/openmeetings/webapps/openmeetings/upload"
USAGE=$(df -h "$RECORDING_PATH" | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -lt 80 ]; then
  curl -sf "https://vigilmon.online/heartbeat/your-storage-heartbeat-id" > /dev/null
fi

*/30 * * * * /usr/local/bin/check-om-storage.sh

When disk usage exceeds 80%, the heartbeat stops pinging and Vigilmon alerts you — giving you time to archive or delete old recordings before the storage fills completely and new recordings begin failing silently.

Step 6: Monitor User Authentication Health

OpenMeetings supports LDAP and Active Directory for user authentication. Authentication failures affect every meeting participant who uses SSO login.

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://meetings.yourdomain.com/openmeetings/services/user/login (the OpenMeetings login REST endpoint).
3. Method: POST
4. Request body: {"SID":"","username":"health_check_user","userpass":"health_check_pass","type":"user"}
5. Expected HTTP status: 200
6. Keyword check: serviceName (confirms the SOAP/REST response envelope is present, regardless of login success or failure)
7. Check interval: 2 minutes
8. Click Save.

A 500 or timeout here — rather than a valid authentication response — indicates the LDAP connection or authentication pipeline has broken.

Step 7: Monitor FFmpeg Recording Health via Heartbeat

OpenMeetings uses FFmpeg to transcode and save recordings. FFmpeg failures cause sessions to record silently but produce corrupt or missing output files. Monitor the FFmpeg recording pipeline with a process heartbeat.

1. Click Add Monitor → Cron Heartbeat.
2. Set the expected interval to 15 minutes.
3. Copy the heartbeat URL.
4. Create a script that verifies FFmpeg is available and emit the heartbeat:

#!/bin/bash
# /usr/local/bin/check-ffmpeg.sh
if command -v ffmpeg &>/dev/null && ffmpeg -version &>/dev/null; then
  curl -sf "https://vigilmon.online/heartbeat/your-ffmpeg-heartbeat-id" > /dev/null
fi

*/15 * * * * /usr/local/bin/check-ffmpeg.sh

Step 8: Monitor JVM Heap via Heartbeat

OpenMeetings is a Java application. JVM heap exhaustion causes increasing garbage collection pauses, then eventually an OutOfMemoryError that crashes Tomcat. Monitor heap usage via a scheduled JMX or REST-based check.

1. Click Add Monitor → Cron Heartbeat.
2. Set the expected interval to 10 minutes.
3. Copy the heartbeat URL.
4. Create a script using jmxterm or Tomcat's manager API to check heap and ping Vigilmon:

#!/bin/bash
# /usr/local/bin/check-jvm-heap.sh
# Uses Tomcat Manager REST endpoint if enabled
HEAP_PERCENT=$(curl -sf -u tomcat-manager-user:password \
  "http://localhost:5080/manager/status?XML=true" \
  | grep -oP 'memoryUsed="\K[0-9]+' | head -1)
HEAP_MAX=$(curl -sf -u tomcat-manager-user:password \
  "http://localhost:5080/manager/status?XML=true" \
  | grep -oP 'memoryMax="\K[0-9]+' | head -1)

if [ -n "$HEAP_PERCENT" ] && [ -n "$HEAP_MAX" ]; then
  PCT=$((HEAP_PERCENT * 100 / HEAP_MAX))
  if [ "$PCT" -lt 80 ]; then
    curl -sf "https://vigilmon.online/heartbeat/your-jvm-heartbeat-id" > /dev/null
  fi
fi

*/10 * * * * /usr/local/bin/check-jvm-heap.sh

When heap exceeds 80%, the heartbeat stops and Vigilmon alerts you before Tomcat enters GC thrash or crashes.

Step 9: Configure Alert Channels and Thresholds

1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook endpoint.
2. For the Tomcat web application and Red5 HTTP port, set Consecutive failures before alert to 2 — Java application restarts cause brief probe gaps.
3. For the RTMP TCP port (1935), set to 1 — RTMP loss means live meetings have no audio or video; this is immediately critical.
4. For the database TCP monitors, set to 1 — database loss is an immediate, complete service failure.
5. For cron heartbeats (storage, JVM, FFmpeg), leave at the default — Vigilmon alerts when the expected ping window expires.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Tomcat web app | /openmeetings/ HTTP | Application crash, Tomcat failure | | Red5 HTTP port | :5080/ HTTP | Red5 process failure | | RTMP TCP port | :1935 TCP | Media streaming connectivity loss | | Room API heartbeat | REST API cron | API availability, cron liveness | | PostgreSQL TCP | :5432 TCP | Database connectivity loss | | MySQL TCP | :3306 TCP | Database connectivity loss | | Recording storage | Disk usage cron | Storage >80% blocking new recordings | | Auth endpoint | Login REST API | LDAP/AD authentication failure | | FFmpeg heartbeat | Process check cron | Recording pipeline failure | | JVM heap heartbeat | Tomcat Manager API | Heap >80% before OOM crash |

OpenMeetings brings professional web conferencing to your own infrastructure, but its multi-tier Java stack — Tomcat, Red5, FFmpeg, and a relational database — means there are several independent failure points, any of which can silently degrade or kill live meetings. With Vigilmon monitoring every tier, you get alerts before a media server crash turns into a support ticket, before disk fills silently kill recordings, and before JVM heap exhaustion brings Tomcat down mid-conference.