tutorial

Monitoring YATE (Yet Another Telephony Engine) with Vigilmon

YATE's modular plugin architecture powers softswitch, IVR, and VoIP gateway deployments — but a crashed module or unresponsive RManager goes undetected until calls fail. Here's how to monitor YATE engine health, SIP signaling, call success rate, and RManager with Vigilmon.

YATE (Yet Another Telephony Engine) is an open source telephony platform built around a message-passing architecture: modules communicate by routing messages like call.route, call.execute, and chan.dtmf through a shared engine. This design makes YATE extremely flexible for softswitch, IVR, VoIP gateway, and telecom billing deployments — and it makes monitoring non-trivial, because a failed plugin or message routing breakdown may not immediately surface as a process crash. Vigilmon lets you monitor YATE at the process level, through its RManager telnet interface, and via probe scripts that catch the failure modes the OS can't see.

What You'll Set Up

  • Process-level YATE health check via RManager TCP monitor
  • Active call count monitoring via engine.status
  • SIP module health check for ysipchan registrations
  • Call success rate heartbeat
  • RManager response latency probe
  • Module load health check at startup
  • Disk usage monitor for call recordings
  • YATE log error rate alert

Prerequisites

  • YATE installed and running on a Linux server
  • RManager enabled in yate.conf (typically on 127.0.0.1:5038)
  • A free Vigilmon account
  • SSH access to the YATE server

Step 1: Monitor YATE Engine Health via RManager

YATE's RManager is a telnet-based management interface that exposes live status, module control, and debugging. If RManager is unreachable, the YATE engine has crashed or is in an unrecoverable state.

First, enable RManager in /etc/yate/rmanager.conf if not already active:

[general]
addr=127.0.0.1
port=5038
password=your_rmanager_password

Then add a TCP port monitor in Vigilmon:

  1. Log in to vigilmon.online and click Add Monitor.
  2. Set Type to TCP Port.
  3. Enter the YATE server IP and set Port to 5038.
  4. Set Check interval to 1 minute.
  5. Click Save.

A successful TCP connection to port 5038 confirms the YATE engine is running and its RManager listener is active. If YATE crashes, the port closes within seconds.

Step 2: Monitor Active Call Count via engine.status

YATE's engine.status command returns current engine statistics including active calls. Monitoring call count lets you detect both zero-call states (engine is idle when it shouldn't be) and overload conditions.

Create a probe script:

#!/bin/bash
# /usr/local/bin/check-yate-calls.sh
RMANAGER_HOST="127.0.0.1"
RMANAGER_PORT=5038
RMANAGER_PASS="your_rmanager_password"
CALL_LIMIT=500
VIGILMON_HEARTBEAT="https://vigilmon.online/heartbeat/YOUR_CALL_HEARTBEAT_ID"

# Send status command via RManager
STATUS=$(echo -e "password $RMANAGER_PASS\nstatus\nquit" | \
  nc -w 3 "$RMANAGER_HOST" "$RMANAGER_PORT" 2>/dev/null)

if [ -z "$STATUS" ]; then
    echo "YATE RManager unreachable at $(date)" >> /var/log/yate-monitor.log
    exit 1
fi

# Extract active call count from engine.status output
CALLS=$(echo "$STATUS" | grep -oP 'calls=\K\d+' | head -1)
CALLS=${CALLS:-0}

if [ "$CALLS" -gt "$CALL_LIMIT" ]; then
    echo "Active calls ($CALLS) exceeds limit ($CALL_LIMIT)" >> /var/log/yate-monitor.log
    exit 1
fi

curl -s "$VIGILMON_HEARTBEAT" > /dev/null

Register the heartbeat in Vigilmon with a 2-minute interval and add a cron entry:

chmod +x /usr/local/bin/check-yate-calls.sh
echo "* * * * * root /usr/local/bin/check-yate-calls.sh" > /etc/cron.d/yate-calls

Step 3: SIP Module Health Check (ysipchan)

YATE's SIP support is provided by the ysipchan plugin. If ysipchan fails to load or loses its SIP account registrations, all SIP signaling stops. Monitor it via RManager:

#!/bin/bash
# /usr/local/bin/check-yate-sip.sh
RMANAGER_HOST="127.0.0.1"
RMANAGER_PORT=5038
RMANAGER_PASS="your_rmanager_password"
VIGILMON_HEARTBEAT="https://vigilmon.online/heartbeat/YOUR_SIP_HEARTBEAT_ID"

# Query ysipchan module status
SIP_STATUS=$(echo -e "password $RMANAGER_PASS\nstatus ysipchan\nquit" | \
  nc -w 3 "$RMANAGER_HOST" "$RMANAGER_PORT" 2>/dev/null)

if [ -z "$SIP_STATUS" ]; then
    echo "Failed to reach YATE RManager" >> /var/log/yate-monitor.log
    exit 1
fi

# Check for module not loaded or error state
if echo "$SIP_STATUS" | grep -qiE "not found|error|failed"; then
    echo "ysipchan module error: $SIP_STATUS" >> /var/log/yate-monitor.log
    exit 1
fi

# Check that at least one SIP account is registered
if echo "$SIP_STATUS" | grep -q "registered=0"; then
    echo "ysipchan: no SIP accounts registered" >> /var/log/yate-monitor.log
    # Only alert if registrations are expected
    # Adjust this logic for your deployment
fi

curl -s "$VIGILMON_HEARTBEAT" > /dev/null

chmod +x /usr/local/bin/check-yate-sip.sh
echo "*/2 * * * * root /usr/local/bin/check-yate-sip.sh" > /etc/cron.d/yate-sip

Set the heartbeat interval to 4 minutes.

Step 4: Call Success Rate Monitoring

YATE routes calls via the call.route message. A high rate of unrouted calls indicates dialplan misconfiguration, SIP peer failure, or a module crash in the routing chain.

Monitor call routing by parsing YATE's log for route failures:

#!/bin/bash
# /usr/local/bin/check-yate-callrate.sh
YATE_LOG="/var/log/yate.log"
WINDOW_MINUTES=5
FAILURE_THRESHOLD=10
VIGILMON_HEARTBEAT="https://vigilmon.online/heartbeat/YOUR_CALLRATE_HEARTBEAT_ID"

# Count call.route failures in the last N minutes
RECENT_FAILURES=$(awk -v cutoff="$(date -d "-${WINDOW_MINUTES} minutes" '+%Y-%m-%d %H:%M')" \
  '$0 >= cutoff && /call\.route.*failed/' "$YATE_LOG" 2>/dev/null | wc -l)

if [ "${RECENT_FAILURES:-0}" -gt "$FAILURE_THRESHOLD" ]; then
    echo "High call failure rate: ${RECENT_FAILURES} failures in ${WINDOW_MINUTES}min" >> /var/log/yate-monitor.log
    exit 1
fi

curl -s "$VIGILMON_HEARTBEAT" > /dev/null

chmod +x /usr/local/bin/check-yate-callrate.sh
echo "*/5 * * * * root /usr/local/bin/check-yate-callrate.sh" > /etc/cron.d/yate-callrate

Step 5: RManager Response Time Probe

A YATE engine under severe load may keep its RManager port open but respond very slowly — an early warning of an impending hang or crash. Monitor RManager response latency:

#!/bin/bash
# /usr/local/bin/check-yate-rmanager-latency.sh
RMANAGER_HOST="127.0.0.1"
RMANAGER_PORT=5038
RMANAGER_PASS="your_rmanager_password"
MAX_LATENCY_MS=2000
VIGILMON_HEARTBEAT="https://vigilmon.online/heartbeat/YOUR_RMANAGER_HEARTBEAT_ID"

START=$(date +%s%3N)
RESPONSE=$(echo -e "password $RMANAGER_PASS\nstatus\nquit" | \
  nc -w 5 "$RMANAGER_HOST" "$RMANAGER_PORT" 2>/dev/null)
END=$(date +%s%3N)
LATENCY=$((END - START))

if [ -z "$RESPONSE" ] || [ "$LATENCY" -gt "$MAX_LATENCY_MS" ]; then
    echo "RManager slow or unresponsive: ${LATENCY}ms" >> /var/log/yate-monitor.log
    exit 1
fi

curl -s "$VIGILMON_HEARTBEAT" > /dev/null

chmod +x /usr/local/bin/check-yate-rmanager-latency.sh
echo "* * * * * root /usr/local/bin/check-yate-rmanager-latency.sh" > /etc/cron.d/yate-rmanager

Step 6: Module Load Health at Startup

YATE's functionality depends entirely on its plugins loading successfully. A critical module (ysipchan, ysig, iaxchan) that fails to load at startup will silently disable an entire protocol.

Create a startup check that verifies required modules are loaded:

#!/bin/bash
# /usr/local/bin/check-yate-modules.sh
# Run once after YATE starts (e.g., in a systemd ExecStartPost or delayed cron)
REQUIRED_MODULES=("ysipchan" "regexroute" "pbx")
RMANAGER_HOST="127.0.0.1"
RMANAGER_PORT=5038
RMANAGER_PASS="your_rmanager_password"
VIGILMON_HEARTBEAT="https://vigilmon.online/heartbeat/YOUR_MODULES_HEARTBEAT_ID"

LOADED_MODULES=$(echo -e "password $RMANAGER_PASS\nstatus\nquit" | \
  nc -w 5 "$RMANAGER_HOST" "$RMANAGER_PORT" 2>/dev/null)

FAILED=0
for MODULE in "${REQUIRED_MODULES[@]}"; do
    if ! echo "$LOADED_MODULES" | grep -q "$MODULE"; then
        echo "Required module not loaded: $MODULE" >> /var/log/yate-monitor.log
        FAILED=1
    fi
done

[ "$FAILED" -eq 0 ] && curl -s "$VIGILMON_HEARTBEAT" > /dev/null

Add to your systemd service as a post-start check, or run via cron 2 minutes after system boot.

Step 7: Call Recording Disk Space

If YATE is configured to record calls (via the wavefile or filetransfer modules), recordings accumulate quickly. A full disk stops recording silently.

#!/bin/bash
# /usr/local/bin/check-yate-recordings.sh
RECORDING_PATH="/var/spool/yate/recordings"
ALERT_THRESHOLD=80
VIGILMON_HEARTBEAT="https://vigilmon.online/heartbeat/YOUR_RECORDINGS_DISK_HEARTBEAT_ID"

if [ ! -d "$RECORDING_PATH" ]; then
    # Recording directory not present — feature not in use
    curl -s "$VIGILMON_HEARTBEAT" > /dev/null
    exit 0
fi

USAGE=$(df "$RECORDING_PATH" | awk 'NR==2 {print $5}' | tr -d '%')

if [ "${USAGE:-0}" -gt "$ALERT_THRESHOLD" ]; then
    echo "Recording disk at ${USAGE}% — exceeds ${ALERT_THRESHOLD}% threshold" >> /var/log/yate-monitor.log
    exit 1
fi

curl -s "$VIGILMON_HEARTBEAT" > /dev/null

echo "*/15 * * * * root /usr/local/bin/check-yate-recordings.sh" > /etc/cron.d/yate-recordings

Step 8: YATE Log Error Rate Alert

YATE logs engine errors and signaling warnings to its log file. A spike in error rate is an early warning of configuration problems or signaling failures.

#!/bin/bash
# /usr/local/bin/check-yate-errors.sh
YATE_LOG="/var/log/yate.log"
WINDOW_MINUTES=5
ERROR_THRESHOLD=20
VIGILMON_HEARTBEAT="https://vigilmon.online/heartbeat/YOUR_ERRORS_HEARTBEAT_ID"

RECENT_ERRORS=$(awk -v cutoff="$(date -d "-${WINDOW_MINUTES} minutes" '+%Y-%m-%d %H:%M')" \
  '$0 >= cutoff' "$YATE_LOG" 2>/dev/null | grep -cE '\b(ERROR|CRIT)\b')

if [ "${RECENT_ERRORS:-0}" -gt "$ERROR_THRESHOLD" ]; then
    echo "High YATE error rate: ${RECENT_ERRORS} errors in ${WINDOW_MINUTES}min" >> /var/log/yate-monitor.log
    exit 1
fi

curl -s "$VIGILMON_HEARTBEAT" > /dev/null

echo "*/5 * * * * root /usr/local/bin/check-yate-errors.sh" > /etc/cron.d/yate-errors

Step 9: Configure Alert Channels

  1. In Vigilmon, go to Alert Channels and add your preferred notification channels (email, Slack, PagerDuty, webhook).
  2. For the RManager TCP monitor, set Consecutive failures before alert to 1 — a closed RManager port is an immediate engine failure.
  3. For heartbeat monitors, set the grace period to match the cron interval plus one full minute to avoid false alerts from cron scheduling jitter.
  4. For the error rate monitor, set Consecutive failures before alert to 2 to filter transient error bursts.

Summary

| Monitor | Target | What It Catches | |---|---|---| | TCP port | RManager :5038 | YATE engine crash | | Cron heartbeat | Active call count script | Call capacity overload, engine stall | | Cron heartbeat | ysipchan status script | SIP module failure, registration loss | | Cron heartbeat | Call failure rate script | Dialplan failures, routing breakdown | | Cron heartbeat | RManager latency script | Engine slowdown before crash | | Cron heartbeat | Module load check | Critical plugin not loaded at startup | | Cron heartbeat | Recording disk script | Storage full, silent recording loss | | Cron heartbeat | Error rate script | Configuration errors, signaling problems |

YATE's plugin-based architecture means failures are often silent at the process level — a module that crashes may leave the YATE binary running while an entire protocol stack goes dark. Vigilmon's heartbeat monitors, driven by RManager queries and log analysis, catch these failures at the signaling layer rather than waiting for user complaints.

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