I've attached a screen shot of the 'info' page of the host that's red.
Strangely enough the notifications.log file suddenly has some data in it now that I stripped some options out of the alerts.cfg file.
Here's some of the notifications.log data. I X'd out the IP that was showing.
Sat Nov 9 11:50:47 2013 VM-Firewall.ssh (x.x.x.x) support at innovateteam.com[2] 1384026647 722 Sat Nov 9 12:12:48 2013 VM-Firewall.ssh (x.x.x.x) support at innovateteam.com[2] 1384027968 722 Sat Nov 9 12:20:57 2013 VM-Firewall.ssh (x.x.x.x) support at innovateteam.com[2] 1384028457 722 Sat Nov 9 12:35:59 2013 VM-Firewall.ssh (x.x.x.x) support at innovateteam.com[2] 1384029359 722 Sat Nov 9 14:31:55 2013 VM-Firewall.ssh (x.x.x.x) support at innovateteam.com[2] 1384036315 722
Thank you.
*Kris Springer* *=======================*
On Sat, Nov 9, 2013 at 1:02 PM, Henrik Størner <henrik at hswn.dk> wrote:
On 09-11-2013 19:49, Kris Springer wrote:
Here's my new alerts.cfg file. It didn't change anything though. I'm still not receiving alerts. To force a trouble situation I've got a line in my hosts file that's checking for ssh on a machine that has it turned off so it will cause a red alert.
HOST=* MAIL support at innovateteam.com <mailto:support at innovateteam.com> COLOR=red RECOVERED NOTICE
First, check the "info" status column for that host: The alert must be shown there, or your configuration is not being picked up.
Second, check the notifications.log logfile to see if the alerts are being sent. If they are, then you need to look into the mail logs.
Third, try running xymond_alert with the "--test HOSTNAME SERVICE" option to see what rules get picked up; see the man-page.
Regards, Henrik