tutorial

Monitoring Apache OpenMeetings with Vigilmon

Apache OpenMeetings powers self-hosted video conferencing and collaboration — but it has no built-in uptime dashboard. Here's how to monitor every critical service layer with Vigilmon.

Apache OpenMeetings is a mature open-source web conferencing platform that supports video meetings, whiteboard collaboration, screen sharing, and presentation upload — all running on your own infrastructure. With so many interdependent services (WebRTC media, RTMP streaming, LibreOffice conversion, LDAP auth, and more), a single component failure can silently break meetings for everyone. Vigilmon lets you watch every layer so you catch problems before your next standup.

What You'll Set Up

  • Web server availability monitor (port 5080)
  • WebRTC media server health check
  • RTMP streaming service monitor
  • Screen sharing service monitor
  • Database connectivity check
  • Document conversion service heartbeat
  • WebSocket endpoint monitor
  • LDAP/AD integration health check
  • Background meeting scheduler heartbeat

Prerequisites

  • Apache OpenMeetings 7.x installed and accessible (default port 5080)
  • A database (MySQL or PostgreSQL) configured for OpenMeetings
  • A free Vigilmon account

Step 1: Monitor Web Server Availability

The OpenMeetings web application runs on a Tomcat/Spring servlet container accessible on port 5080 by default. Start with a simple HTTP availability check:

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to HTTP / HTTPS.
  3. Enter the URL: http://your-server:5080/openmeetings/ (or your configured domain with SSL).
  4. Set Check interval to 1 minute.
  5. Set Expected HTTP status to 200.
  6. Click Save.

If you front OpenMeetings with nginx or Apache httpd as a reverse proxy, also monitor port 5080 directly with a TCP monitor to distinguish proxy failures from application failures:

  1. Click Add Monitor → TCP Port.
  2. Host: your-server, Port: 5080.
  3. Set Check interval to 1 minute.
  4. Click Save.

Step 2: Monitor the WebRTC Media Server

OpenMeetings relies on a WebRTC media server (Kurento or OpenVidu in modern deployments) to handle real-time audio and video streams. If this service is down, users can join meetings but will have no audio or video — a failure mode that is easy to miss with a simple HTTP check.

Add a TCP monitor for the media server port (Kurento defaults to 8888):

  1. Click Add Monitor → TCP Port.
  2. Host: your-server, Port: 8888.
  3. Set Check interval to 2 minutes.
  4. Click Save.

If Kurento exposes an HTTP health path (check your deployment docs), prefer an HTTP monitor over TCP — it gives you a richer signal:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: http://your-server:8888/health (if available).
  3. Set Expected HTTP status to 200.
  4. Click Save.

Step 3: Monitor RTMP Streaming

OpenMeetings uses RTMP for streaming recorded sessions and broadcasting. Red5 or a dedicated RTMP server typically listens on port 1935.

  1. Click Add Monitor → TCP Port.
  2. Host: your-server, Port: 1935.
  3. Set Check interval to 2 minutes.
  4. Click Save.

A TCP timeout on 1935 means recordings cannot be streamed and live broadcast features will silently fail.

Step 4: Monitor the Screen Sharing Service

Screen sharing in OpenMeetings runs through a separate Java applet bridge or WebRTC screen capture path. The screen sharing service typically exposes a dedicated port (often 5003 or configurable in openmeetings.properties).

  1. Click Add Monitor → TCP Port.
  2. Host: your-server, Port: 5003 (adjust to your configuration).
  3. Set Check interval to 2 minutes.
  4. Click Save.

Check your openmeetings.properties for the screen.viewer.port and screen.sharer.port settings and add a monitor for each configured port.

Step 5: Monitor Database Connectivity

OpenMeetings stores meeting metadata, user records, and recordings in MySQL or PostgreSQL. Database connectivity issues cause login failures and meeting creation errors. Monitor the database port directly:

For MySQL:

  1. Click Add Monitor → TCP Port.
  2. Host: your-db-server, Port: 3306.
  3. Set Check interval to 1 minute.
  4. Click Save.

For PostgreSQL:

  1. Click Add Monitor → TCP Port.
  2. Host: your-db-server, Port: 5432.
  3. Set Check interval to 1 minute.
  4. Click Save.

Pair the TCP check with an HTTP monitor on the OpenMeetings login endpoint — a 500 error on the login page often indicates a database connectivity failure:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: http://your-server:5080/openmeetings/signin.xhtml.
  3. Set Expected HTTP status to 200.
  4. Click Save.

Step 6: Heartbeat for the Document Conversion Service

OpenMeetings uses LibreOffice (via JODConverter) to convert uploaded presentations and documents for whiteboard display. This conversion service runs as a background pool — it has no HTTP interface.

Use Vigilmon's cron heartbeat to confirm conversions are completing:

  1. In Vigilmon, click Add Monitor → Cron Heartbeat.
  2. Set the expected ping interval to 10 minutes.
  3. Copy the heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).
  4. Add a conversion health check to a cron job on the OpenMeetings server:
#!/bin/bash
# test_libreoffice.sh — run every 10 minutes via cron
# Check that LibreOffice is running as expected by OpenMeetings
SOFFICE_PID=$(pgrep -f soffice)

if [ -n "$SOFFICE_PID" ]; then
  curl -s https://vigilmon.online/heartbeat/abc123
fi

If LibreOffice crashes or runs out of memory, soffice processes disappear and the ping stops.

Step 7: Monitor the WebSocket Endpoint

OpenMeetings uses WebSockets for real-time meeting controls (raise hand, mute, participant list updates). Add a WebSocket upgrade check:

  1. Click Add Monitor → HTTP / HTTPS.
  2. URL: http://your-server:5080/openmeetings/ws (or your configured WebSocket path).
  3. Set Expected HTTP status to 101.
  4. Set Check interval to 2 minutes.
  5. Click Save.

A failure here means participants cannot raise their hand, see updated participant lists, or receive real-time meeting control events.

Step 8: Monitor LDAP/Active Directory Integration

If your OpenMeetings deployment authenticates users against LDAP or Active Directory, an LDAP outage locks out all managed users. Monitor the LDAP port:

  1. Click Add Monitor → TCP Port.
  2. Host: your-ldap-server, Port: 389 (or 636 for LDAPS).
  3. Set Check interval to 2 minutes.
  4. Click Save.

For LDAPS (port 636), also enable SSL certificate monitoring in Vigilmon to catch certificate expiry before it breaks LDAP authentication:

  1. Open the TCP monitor for port 636.
  2. Enable Monitor SSL certificate.
  3. Set Alert when certificate expires in less than 21 days.
  4. Click Save.

Step 9: Heartbeat for the Meeting Scheduler

OpenMeetings includes a background meeting scheduler that sends reminder emails, starts recordings, and manages recurring meetings. If this scheduler thread dies, meetings miss their auto-start and nobody gets reminders.

  1. In Vigilmon, click Add Monitor → Cron Heartbeat.
  2. Set the expected ping interval to 5 minutes.
  3. Copy the heartbeat URL.
  4. Add a scheduler health check to a cron job:
#!/bin/bash
# check_om_scheduler.sh — run every 5 minutes
# Verify the OpenMeetings application is responding (scheduler is internal to the JVM)
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" \
  http://localhost:5080/openmeetings/services/info/server 2>/dev/null)

if [ "$HTTP_CODE" = "200" ]; then
  curl -s https://vigilmon.online/heartbeat/abc123
fi

The scheduler is an internal Quartz component, so this check uses the application liveness as a proxy for scheduler health — if the JVM is alive and responding, the scheduler is running.

Step 10: Configure Alert Channels

  1. Go to Alert Channels in Vigilmon and add Slack, email, or a webhook.
  2. Set Consecutive failures before alert to 2 on media server and RTMP monitors — brief Tomcat GC pauses can cause single-probe misses.
  3. Create a dedicated alert group for monitors that affect active meetings (WebRTC, WebSocket, RTMP) with a shorter escalation window than infrastructure-level monitors.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Web server | Port 5080 HTTP | Application crash, Tomcat down | | WebRTC media | Port 8888 TCP | No audio/video in meetings | | RTMP streaming | Port 1935 TCP | Recording and broadcast failure | | Screen sharing | Port 5003 TCP | Screen share broken | | Database | Port 3306/5432 TCP | Login and data failures | | LibreOffice | Cron heartbeat | Document conversion silently broken | | WebSocket | /ws HTTP 101 | Real-time controls failure | | LDAP/AD | Port 389/636 TCP | Managed user lockout | | Meeting scheduler | Cron heartbeat | Missed reminders, auto-start failures |

Apache OpenMeetings is a powerful platform that keeps your collaboration data on-premises — but every layer you self-host is a layer you monitor. With Vigilmon covering the full stack from WebRTC media to the meeting scheduler, you know about failures before the next meeting is about to start.

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