Monitoring MediaCMS with Vigilmon

MediaCMS is a full-featured open source video platform built with Django, Celery, and FFmpeg — a self-hosted alternative to YouTube or Vimeo that handles uploads, transcoding, HLS streaming, and a complete CMS backend. That richness means more moving parts: a Django/gunicorn application layer, PostgreSQL database, Redis broker, Celery transcoding workers, FFmpeg pipelines, and nginx in front of all of it. Vigilmon lets you watch every layer from a single dashboard, so a stalled transcode queue or a failed disk mount triggers an alert before your users notice.

What You'll Set Up

• nginx web server and HTTPS availability monitoring
• Django application health endpoint monitoring
• PostgreSQL and Redis connectivity checks
• Celery worker heartbeat monitoring via cron pings
• HLS stream endpoint health checks
• Upload and authentication API monitoring
• SSL/TLS certificate expiry alerts
• Media storage backend accessibility monitoring

Prerequisites

• MediaCMS deployed and accessible over HTTPS (Docker Compose or bare-metal)
• PostgreSQL, Redis, Celery, and nginx all running
• A free Vigilmon account

Step 1: Monitor the nginx Web Server

The nginx reverse proxy is the front door to MediaCMS. If it goes down, the entire platform is unreachable.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your MediaCMS URL: https://media.yourdomain.com.
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Enable Monitor SSL certificate and set Alert when certificate expires in less than 21 days.
7. Click Save.

This single monitor catches nginx crashes, network outages, and Let's Encrypt renewal failures.

Step 2: Add a Django Application Health Endpoint

MediaCMS runs Django behind gunicorn or uWSGI. Add a lightweight health view that confirms the application layer is alive and the database is reachable:

# In your MediaCMS project, add to urls.py or a dedicated health app:
from django.http import JsonResponse
from django.db import connection

def health(request):
    try:
        connection.ensure_connection()
        db_ok = True
    except Exception:
        db_ok = False
    status = 200 if db_ok else 503
    return JsonResponse({"status": "ok" if db_ok else "degraded", "db": db_ok}, status=status)

Wire it in urls.py:

from django.urls import path
from . import health_views

urlpatterns = [
    path('health/', health_views.health),
    # ... existing URLs
]

Add a Vigilmon monitor for the health endpoint:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://media.yourdomain.com/health/
3. Expected HTTP status: 200
4. Check interval: 1 minute
5. Click Save.

A 503 response here means Django is running but the database is unreachable — a subtly different failure from a total outage.

Step 3: Monitor Redis Connectivity

Redis is MediaCMS's Celery broker and cache layer. A Redis failure stalls all video transcoding jobs even if Django itself responds normally.

Add a TCP monitor to confirm the Redis port is open:

1. Click Add Monitor → TCP Port.
2. Hostname: localhost (or your Redis host IP).
3. Port: 6379.
4. Check interval: 1 minute.
5. Click Save.

For a deeper check, extend the Django health endpoint to probe Redis:

import redis as redis_client

def health(request):
    # ... existing db check
    try:
        r = redis_client.Redis(host='localhost', port=6379)
        r.ping()
        redis_ok = True
    except Exception:
        redis_ok = False
    all_ok = db_ok and redis_ok
    status = 200 if all_ok else 503
    return JsonResponse({"db": db_ok, "redis": redis_ok}, status=status)

Step 4: Heartbeat Monitoring for Celery Transcoding Workers

Celery workers process every video upload through the FFmpeg transcoding pipeline. Workers can silently stop consuming tasks — jobs pile up in the queue and uploads appear to hang with no error shown to the user.

Use Vigilmon's cron heartbeat to confirm workers are alive:

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set Expected interval to 5 minutes.
3. Copy the heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).

Add a periodic Celery task that pings the heartbeat URL:

# tasks.py
import requests
from celery import shared_task

@shared_task
def worker_heartbeat():
    requests.get('https://vigilmon.online/heartbeat/abc123', timeout=5)

Schedule it in your Celery beat configuration:

# celery.py or settings.py
CELERY_BEAT_SCHEDULE = {
    'worker-heartbeat': {
        'task': 'myapp.tasks.worker_heartbeat',
        'schedule': 300.0,  # every 5 minutes
    },
}

If all Celery workers crash or lose Redis connectivity, the heartbeat task never runs — Vigilmon alerts after 5 minutes of silence.

Step 5: Monitor HLS Stream Endpoints

MediaCMS generates HLS playlists for adaptive bitrate streaming. A failure in the transcoding pipeline or the media storage mount means HLS manifests return 404 or 500 errors.

After a successful test upload, note the HLS playlist URL:

https://media.yourdomain.com/media/original/video-slug/master.m3u8

Add a monitor for a known-good video's HLS manifest:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: the master playlist URL for a pinned test video.
3. Expected HTTP status: 200.
4. Check interval: 5 minutes.
5. Click Save.

A 404 here means either the media storage volume is unmounted or the transcoding job for that video was never completed successfully.

Step 6: Monitor the Upload and Authentication API

MediaCMS exposes REST API endpoints for uploads and user management. Monitor the API root to confirm the application is serving authenticated routes:

1. Click Add Monitor → HTTP / HTTPS.
2. URL: https://media.yourdomain.com/api/v1/media/?format=json
3. Expected HTTP status: 200
4. Check interval: 5 minutes
5. Click Save.

For the upload endpoint, monitor it separately with a TCP check on port 80/443 to verify nginx is accepting connections for large file uploads (nginx has a client_max_body_size that can silently reject uploads if misconfigured).

Step 7: Monitor Media Storage Backend Accessibility

MediaCMS stores original and transcoded video files on local disk or an S3-compatible backend. A full disk or broken S3 credentials causes silent upload failures.

For local disk storage, add a heartbeat from a cron job that checks disk usage and pings Vigilmon only when space is available:

#!/bin/bash
# /etc/cron.d/mediacms-storage-check
USED=$(df /opt/mediacms/media_files | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USED" -lt 90 ]; then
    curl -s https://vigilmon.online/heartbeat/storage123
fi

1. In Vigilmon, add a Cron Heartbeat monitor with Expected interval 10 minutes.
2. If disk usage exceeds 90%, the heartbeat stops — Vigilmon alerts.

For S3 storage, extend the Django health endpoint to attempt an S3 head_object against a known key and include the result in the health response.

Step 8: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add Slack, email, or PagerDuty.
2. Set Consecutive failures before alert to 2 on the main web monitor to avoid false positives from transient network blips.
3. Set it to 1 on the Celery heartbeat — a missed beat means all transcoding has stopped.

Use Maintenance windows during MediaCMS upgrades:

curl -X POST https://vigilmon.online/api/maintenance \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{"monitor_id": "MONITOR_ID", "duration_minutes": 15}'

Summary

| Monitor | Target | What It Catches | |---|---|---| | nginx uptime | https://media.yourdomain.com | Web server crash, network outage | | Django health | /health/ | App crash, database disconnect | | Redis TCP | localhost:6379 | Redis crash, broker failure | | Celery heartbeat | Heartbeat URL | All workers stopped, queue stalled | | HLS endpoint | Master playlist URL | Transcoding failures, storage unmount | | API endpoint | /api/v1/media/ | REST API failures | | Storage heartbeat | Disk / S3 check | Full disk, broken S3 credentials | | SSL certificate | Main domain | Let's Encrypt renewal failure |

MediaCMS's power comes from its multi-process architecture — but each process is a potential failure point. With Vigilmon covering nginx, Django, Redis, Celery workers, HLS delivery, and storage in parallel, you'll know exactly which layer failed and can restore video service before your audience notices the stall.