Hi,
I think it will be better to delegate the alert delivery to M/Monit: you can create alert rule for "rhel6-watchers", "license-admins", etc. that will include only services they need to watch. These few rules will work for all 1300+ hosts, no need for Monit-side alert configuration.
Example of rule that will send alert to given mail address if something happened with apache, nfs filesystem or mysql:
It is also possible to create exclude lists, where alert for every service except the given one will be send, you can also use service groups, hostgroups and event state/type to restrict the alert.
Best regards,
Martin
On 11 Apr 2017, at 00:40, Billy Vitro <address@hidden> wrote:Here's how I've set up Monit (eventually to be on 1300+ servers):
I've got the file monitrc.master, which includes everything in ../conf.d/monitrc.*
In conf.d, I've got the files broken up by class - so I've got a monitrc.license (for license servers), and monitrc.rhel6 (for rhel 6 hosts), a monitrc.admin (for general things I watch on admin hosts), and possibly a monitrc.hostname for host-specific monitoring.
A potential host might have license + rhel6 + admin installed on it, or hostname + admin + rhel5, or some other combination.
The alerting for each of those class files should go to specific groups, so I can set up aliases to particular people based on the class of the host.
So, for things that I want to watch and perform an action, but really never want an alert, every monitrc.* file would have to have noalert statements for each potential mail alias that might be in any monitrc.* file on that host. I would need to add 'noalert address@hidden' AND 'noalert address@hidden' AND 'noalert address@hidden' to the rhel6, and rhel5, and hostname, and ...
This becomes a maintenance headache, and then I end up sending out 1300 alerts to people who are rapidly getting tired of hearing that the monitrc file was updated.
I assume at this point that this is a feature request - so I guess that's the justification for that feature to be added.
Thanks,
BV.Message: 1
Date: Wed, 5 Apr 2017 18:04:00 +0200
From: Martin Pala <address@hidden>
To: This is the general mailing list for monit
<address@hidden>
Subject: Re: noalert * ?
Message-ID: <address@hidden>
Content-Type: text/plain; charset=us-ascii
Hello Billy,
you can setup an external mailing list / group alias, which you'll use as an alert recipient in Monit. That way you can have one global "set alert <mygroup>" entry in monit configuration file and disable alerts in specific service context easily with single "noalert <mygroup>" entry.
Another option could be to use M/Monit and delegate alert delivery to it ... it has more flexible alert rules then Monit.
Best regards,
MartinOn 3 Apr 2017, at 18:11, Billy Vitro <address@hidden> wrote:
I'd love to be able to specify 'noalert *' or something for a specific service check. This way I don't have to maintain a list of all possible email addresses I may have configured for alerting.
Any suggestions on how I could do that?
Thanks,
--
Billy Vitro | cisco Systems, Inc.
address@hidden | (408) 526-4817
http://www.linkedin.com/in/bvitro | Illegitimus non carborundum.
LSF Farm Case Creation:
http://eda-tools.cisco.com/remedy8-createEDAcase.html?Type=EDA-LSF%20Farm
--
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general
------------------------------
Subject: Digest Footer
_______________________________________________
monit-general mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/monit-general
------------------------------
End of monit-general Digest, Vol 171, Issue 3
*********************************************
--
Billy Vitro | cisco Systems, Inc.
address@hidden | (408) 526-4817
http://www.linkedin.com/in/bvitro | Illegitimus non carborundum.
LSF Farm Case Creation:
http://eda-tools.cisco.com/remedy8-createEDAcase.html?Type=EDA-LSF%20Farm
--
To unsubscribe:
https://lists.nongnu.org/mailman/listinfo/monit-general