Alerts: Difference between revisions

From VoIPmonitor.org
(Add documentation for Sensors alert type - monitoring probe/sniffer status)
(Add comprehensive troubleshooting section for email alerts including CLI testing, MTA status, mail logs, and queue inspection)
Line 52: Line 52:


CDR records table lists cases, with alert flags: (M)OS, (J)itter, (P)acket loss, (D)elay.
CDR records table lists cases, with alert flags: (M)OS, (J)itter, (P)acket loss, (D)elay.
=== Troubleshooting Email Alerts ===
If email alerts are not being sent, the issue is typically with the Mail Transfer Agent (MTA) rather than VoIPmonitor. Follow these steps to diagnose and fix the problem.
==== Test Email Delivery from Command Line ====
Before investigating complex issues, verify your server can send emails at all:
{{{
# Test sending an email using the 'mail' command
echo "Test email body" | mail -s "Test Subject" your.email@example.com
}}}
If this fails, the issue is with your MTA (Postfix, Exim, or Sendmail) and not with VoIPmonitor.
==== Check Mail Transfer Agent (MTA) Status ====
Ensure the MTA service is running:
{{{
# For Postfix (most common)
sudo systemctl status postfix
# For Exim
sudo systemctl status exim4
# For Sendmail
sudo systemctl status sendmail
}}}
If the service is not running or not installed, install and configure it according to your Linux distribution's documentation.
==== Check Mail Logs ====
Examine the MTA logs for specific error messages that indicate why emails are failing:
{{{
# Debian/Ubuntu (default mail log location)
tail -f /var/log/mail.log
# RHEL/CentOS/Alma/Rocky
tail -f /var/log/maillog
# Look for errors such as:
# - "Connection refused" - MTA not running or firewall blocking
# - "Relay access denied" - SMTP relay misconfiguration
# - "Authentication failed" - Incorrect credentials for external relay
# - "Host or domain name lookup failed" - DNS issues
# - "Greylisted" - Temporary rejection, may retry later
}}}
Common issues found in logs:
*'''Authentication Issues''': If relaying through an external SMTP server, verify your credentials in `/etc/postfix/sasl_passwd` or the Exim equivalent.
*'''Network Problems''': Check firewall rules (`iptables` or `firewalld`) to ensure outbound SMTP (port 25) is allowed.
*'''DNS Resolution''': If the MTA cannot resolve recipient domains, check `/etc/resolv.conf` and network connectivity.
==== Check Mail Queue ====
Emails may be stuck in the queue if delivery is failing:
{{{
# View the mail queue
mailq
# Force immediate delivery attempt
postqueue -f
}}}
If the queue shows many deferred or failed messages, those messages contain error details explaining why delivery failed.
==== Verify Cronjob ====
Ensure the alert processing script runs every minute:
{{{
crontab -l
}}}
You should see a line similar to:
{{{
* * * * * root php /var/www/html/php/run.php cron
}}}
If missing, add it:
{{{
crontab -e
# Add this line:
* * * * * root php /var/www/html/php/run.php cron
}}}
Reload the cron daemon:
{{{
killall -HUP cron
}}}
==== Verify Alert Configuration ====
After confirming the MTA works, check that alerts are configured correctly in the GUI:
1. Navigate to '''GUI > Alerts'''
2. Verify alert conditions are enabled
3. Check that recipient email addresses are valid
4. Go to '''GUI > Alerts > Sent Alerts''' to see if alerts were triggered and handed off to the MTA
If entries appear in "Sent Alerts" but recipients never receive emails, the MTA is the issue. If no entries appear, check the alert conditions or cronjob.
==== Testing with PHP ====
You can test PHP's mail() function directly to isolate the issue:
{{{
php -r "mail('your.email@example.com', 'Test from PHP', 'This is a test email');"
}}}
If this works but VoIPmonitor alerts don't, check the GUI cronjob and alert configuration. If it fails, the issue is purely MTA-related.


=== AI Summary for RAG ===
=== AI Summary for RAG ===


'''Summary:''' This article covers VoIPmonitor's Alerts & Reports for email notifications on QoS/SIP issues, daily/ad hoc reports, crontab setup, alert configuration (RTP/SIP/Sensors types, filters), and viewing sent alerts with metrics and CDR details.
'''Summary:''' This article covers VoIPmonitor's Alerts & Reports for email notifications on QoS/SIP issues, daily/ad hoc reports, crontab setup, alert configuration (RTP/SIP/Sensors types, filters), viewing sent alerts with metrics and CDR details, and troubleshooting email delivery issues including MTA status, mail logs, queue inspection, and CLI/PHP email testing.


'''Keywords:''' alerts, reports, email notifications, QoS metrics, SIP responses, crontab, RTP alerts, SIP alerts, sensors alerts, filters, history, MTA configuration
'''Keywords:''' alerts, reports, email notifications, QoS metrics, SIP responses, crontab, RTP alerts, SIP alerts, sensors alerts, filters, history, MTA configuration, troubleshooting, email not working, mail command, postfix, exim, sendmail, mail queue, mail logs


'''Key Questions:'''
'''Key Questions:'''
Line 67: Line 183:
* What do alert flags in CDR mean?
* What do alert flags in CDR mean?
* How do I monitor the status of remote VoIPmonitor sensors and probes?
* How do I monitor the status of remote VoIPmonitor sensors and probes?
* Why are email alerts not being sent?
* How do I test email delivery from command line?
* How do I troubleshoot MTA (Postfix/Exim/Sendmail) email issues?
* How do I check mail logs and mail queue?

Revision as of 08:26, 4 January 2026

Alerts & Reports

Alerts & Reports generate email notifications based on QoS parameters or SIP error conditions. It includes daily reports, ad hoc reports, and stores all generated items in history.

Emails use PHP's "mail" function, relying on the server's MTA (e.g., Exim, Postfix, Sendmail). Configure MTA per your Linux distribution documentation.

Process alerts via a PHP script in crontab:

For CentOS & Debian:

echo "* * * * * root php /var/www/html/php/run.php cron" >> /etc/crontab

(Adjust path to run.php based on VoIPmonitor GUI installation.)

Reload crontab: killall -HUP cron (or crond).

Configure Alerts

Email alerts trigger on SIP protocol or RTP QoS metrics. Types: RTP alerts and SIP signaling.

Common filters: Call duration, IP addresses, numbers, and email recipients.

  • RTP Alerts: Trigger on MOS, packet loss, jitter, delay, one-way calls (answered but one RTP stream missing), or missing RTP (answered but both streams missing). Alert if thresholds exceeded and incidents > set value or CDR percent > threshold.

  • SIP Response Alerts: Trigger on SIP response codes. Empty response: All call attempts per filters. Response 0: Unreplied INVITEs.

  • Sensors Alerts: Built-in alert type for monitoring the status and health of VoIPmonitor probes and sniffer instances. This is the most reliable method to check if remote sensors are online and actively monitoring traffic. Unlike simple network port monitoring (which may show a port is open even if the process is frozen or unresponsive), sensors alerts verify that the sensor instance is actively communicating with the VoIPmonitor GUI server. Configure sensors in Settings > Sensors, then create a sensors alert to be notified when a probe goes offline or becomes unresponsive.
  • Filters:
 - IP/Number Group: Apply to defined groups (from Groups menu).
 - IP Addresses/Numbers: Individual IPs, numbers, or ranges (delimited by Enter).
 - Email Group: Send to group-defined emails.
 - Emails: Individual emails (delimited by Enter).

Sent Alerts

Sent alerts are saved in history, matching email content.

Parameters table shows QoS metrics with bad values highlighted.

CDR records table lists cases, with alert flags: (M)OS, (J)itter, (P)acket loss, (D)elay.

Troubleshooting Email Alerts

If email alerts are not being sent, the issue is typically with the Mail Transfer Agent (MTA) rather than VoIPmonitor. Follow these steps to diagnose and fix the problem.

Test Email Delivery from Command Line

Before investigating complex issues, verify your server can send emails at all:

mail -s "Test Subject" your.email@example.com


If this fails, the issue is with your MTA (Postfix, Exim, or Sendmail) and not with VoIPmonitor.

Check Mail Transfer Agent (MTA) Status

Ensure the MTA service is running:

{{{

  1. For Postfix (most common)

sudo systemctl status postfix

  1. For Exim

sudo systemctl status exim4

  1. For Sendmail

sudo systemctl status sendmail }}}

If the service is not running or not installed, install and configure it according to your Linux distribution's documentation.

Check Mail Logs

Examine the MTA logs for specific error messages that indicate why emails are failing:

{{{

  1. Debian/Ubuntu (default mail log location)

tail -f /var/log/mail.log

  1. RHEL/CentOS/Alma/Rocky

tail -f /var/log/maillog

  1. Look for errors such as:
  2. - "Connection refused" - MTA not running or firewall blocking
  3. - "Relay access denied" - SMTP relay misconfiguration
  4. - "Authentication failed" - Incorrect credentials for external relay
  5. - "Host or domain name lookup failed" - DNS issues
  6. - "Greylisted" - Temporary rejection, may retry later

}}}

Common issues found in logs:

  • Authentication Issues: If relaying through an external SMTP server, verify your credentials in `/etc/postfix/sasl_passwd` or the Exim equivalent.
  • Network Problems: Check firewall rules (`iptables` or `firewalld`) to ensure outbound SMTP (port 25) is allowed.
  • DNS Resolution: If the MTA cannot resolve recipient domains, check `/etc/resolv.conf` and network connectivity.

Check Mail Queue

Emails may be stuck in the queue if delivery is failing:

{{{

  1. View the mail queue

mailq

  1. Force immediate delivery attempt

postqueue -f }}}

If the queue shows many deferred or failed messages, those messages contain error details explaining why delivery failed.

Verify Cronjob

Ensure the alert processing script runs every minute:

{{{ crontab -l }}}

You should see a line similar to: {{{

  • * * * * root php /var/www/html/php/run.php cron

}}}

If missing, add it: {{{ crontab -e

  1. Add this line:
  • * * * * root php /var/www/html/php/run.php cron

}}}

Reload the cron daemon: {{{ killall -HUP cron }}}

Verify Alert Configuration

After confirming the MTA works, check that alerts are configured correctly in the GUI:

1. Navigate to GUI > Alerts 2. Verify alert conditions are enabled 3. Check that recipient email addresses are valid 4. Go to GUI > Alerts > Sent Alerts to see if alerts were triggered and handed off to the MTA

If entries appear in "Sent Alerts" but recipients never receive emails, the MTA is the issue. If no entries appear, check the alert conditions or cronjob.

Testing with PHP

You can test PHP's mail() function directly to isolate the issue:

{{{ php -r "mail('your.email@example.com', 'Test from PHP', 'This is a test email');" }}}

If this works but VoIPmonitor alerts don't, check the GUI cronjob and alert configuration. If it fails, the issue is purely MTA-related.

AI Summary for RAG

Summary: This article covers VoIPmonitor's Alerts & Reports for email notifications on QoS/SIP issues, daily/ad hoc reports, crontab setup, alert configuration (RTP/SIP/Sensors types, filters), viewing sent alerts with metrics and CDR details, and troubleshooting email delivery issues including MTA status, mail logs, queue inspection, and CLI/PHP email testing.

Keywords: alerts, reports, email notifications, QoS metrics, SIP responses, crontab, RTP alerts, SIP alerts, sensors alerts, filters, history, MTA configuration, troubleshooting, email not working, mail command, postfix, exim, sendmail, mail queue, mail logs

Key Questions:

  • How do I set up email alerts in VoIPmonitor?
  • What are the types of alerts (RTP vs. SIP vs. Sensors)?
  • How do I configure crontab for alert processing?
  • What filters can I use for alerts?
  • How are sent alerts stored and viewed?
  • What do alert flags in CDR mean?
  • How do I monitor the status of remote VoIPmonitor sensors and probes?
  • Why are email alerts not being sent?
  • How do I test email delivery from command line?
  • How do I troubleshoot MTA (Postfix/Exim/Sendmail) email issues?
  • How do I check mail logs and mail queue?