Hello, I would like to know if It's possible to stop MON to listen on udp and tcp. I've tried to comment some part on the code ( listen(SERVER,OCONNECT) by example) but all my tests have ended with my CPU at 100% ... Please, help me to resolve this problem. NoCraCk
On Thu, 11 Oct 2007, board.divers wrote: > Hello, > > I would like to know if It's possible to stop MON to listen on udp and tcp. > > I've tried to comment some part on the code ( listen(SERVER,OCONNECT) by > example) but all my tests have ended with my CPU at 100% ... you can't do that, but if you don't want external things talking to it from the network you can tell it to bind to only 127.0.0.1. look at the "serverbind" and "trapbind" settings in the man page.
Hello, I am using mon to monitor several services on multiple hosts in a network. Each host runs a mon daemon with a mon.cf configured according to the services to watch; this depends of the kind of apps. installed on this host. An application may need access to (a service on) an other host, so there is a watch checking for this remote service. When such a "server host" goes down (or crashes, or ...) , than there can (will) be several alerts raised, one on each "client host". This will, for example, result in duplicated and redondant email messages. How can such a behavior avoided ?. I am thinking about forwarding all alerts to a "master-mon" where some filtering would happend before emitting an alert. This "master-mon" must be dynamically elected in order to avoid a single-point of failure, handle a failure resulting in a network split, a mail-server failure, a.s.o. ..... Are there features the current mon (1.2 ?) provides that can be hepful to implement such a thing ?, maybe there are better ways to achieve what I need ? Thank's for any hint.
On 10/17/07, Jacques Klein <jk <at> dalim.com> wrote: > Each host runs a mon daemon with a mon.cf configured according to the > services to watch; > this depends of the kind of apps. installed on this host. > An application may need access to (a service on) an other host, so there > is a watch checking for this remote service. > When such a "server host" goes down (or crashes, or ...) , than there > can (will) be several alerts raised, one on each "client host". > This will, for example, result in duplicated and redondant email messages. > How can such a behavior avoided ?. If I am reading you right, then you want the "depend" definition in your watch group: http://mon.wiki.kernel.org/index.php/Mon_Manual depend dependexpression The depend keyword is used to specify a dependency expression, which evaluates to either true of false, in the boolean sense. Dependencies are actual Perl expressions, and must obey all syn- tactical rules. The expressions are evaluated in their own pack- age space so as to not accidentally have some unwanted side- effect. If a syntax error is found when evaluating the expres- sion, it is logged via syslog. Before evaluation, the following substitutions on the expression occur: phrases which look like "group:service" are substituted with the value of the current operational status of that speci- fied service. These opstatus substitutions are computed recur- sively, so if service A depends upon service B, and service B(Continue reading)
Augie Schwer wrote: > If I am reading you right, then you want the "depend" definition in > your watch group: > > http://mon.wiki.kernel.org/index.php/Mon_Manual > > depend dependexpression > The depend keyword is used to specify a dependency expression, > ................................................................ > This feature can be used to control alerts for services which > are dependent on other services, e.g. an SMTP test which is > dependent upon the machine being ping-reachable. > > > Well, not really, or not enough in fact. If I understand the "depend", it's a way to avoid multiple alerts by specifying dependencies between services in ONE mon. If I take this concept, then it would have to be extended to dependencies between services in a GROUP of mon(s) (one per host)...., interesting.... but seems very complicated.
On Wed, 17 Oct 2007, Jacques Klein wrote: > If I understand the "depend", it's a way to avoid multiple alerts by > specifying dependencies between services in ONE mon. > If I take this concept, then it would have to be extended to > dependencies between services in a GROUP of mon(s) (one per host)...., > interesting.... but seems very complicated. Yes, one of the ways you could implement this functionality is by using traps to feed the status to a mon server which uses this input to control the alerts and implement the dependencies. You are on the right track in what you said in your previous mail.
On 10/17/07, Jacques Klein <jk <at> dalim.com> wrote:
> Well, not really, or not enough in fact.
> If I understand the "depend", it's a way to avoid multiple alerts by
> specifying dependencies between services in ONE mon.
> If I take this concept, then it would have to be extended to
> dependencies between services in a GROUP of mon(s) (one per host)....,
> interesting.... but seems very complicated.
>
If you configure each of your mon servers to send traps to all of the
others on status updates, then you can use dependencies on each server
based on state changes from other servers.
If they're all one one LAN you could probably even do that by sending
the status updates as broadcast packets. I've never tried that, it
might take minor coding in Mon to make it process broadcast packets.
Of course even better would be multicast, but that would definitely
require some code changes.
The best way to cause all status updates to get propagated is by using
the 'redistribute' config option. From the manual:
redistribute alert [arg...]
A service may have one redistribute option, which is a special
form of an an alert definition. This alert will be called on
every service status update, even sequential success status
updates. This can be used to integrate Mon with another moni-
toring system, or to link together multiple Mon servers via an
alert script that generates Mon traps. See the "ALERT PROGRAMS"
section above for a list of the parameters mon will pass auto-
(Continue reading)
Yes, it seems mon does not detect many problems of the cf file. For exemple a single empty line inserted by mistake before the second 'service' of a 'watch' and only the first service is used without any error or warning message. We had to write a stand alone checker for the cf file to avoid this kind of mistake. I think we could put it in the contrib section (after some minor rewritting). Of course, a better solution would be to improve the parser of mon itself. Denis Choulette. Quoting William Taylor <williamt <at> corp.sonic.net>: > Do any better tools exist for parsing/validating mon.cf? > test_config() doesn't seem to catch a lot of errors like random > text entered on lines. > > > Thanks, > William > > _______________________________________________ > mon mailing list > mon <at> linux.kernel.org > http://linux.kernel.org/mailman/listinfo/mon >(Continue reading)
HI what is the best way to fix mon for a host where /usr/lib/sendmail does not exist? Should I (symlink or) patch all the files for now? Note, this is how my particular netbsd host is setup; * there is no /usr/lib/sendmail * sendmail is a symlink to mailwrapper * mailwrapper is a binary which reads /etc/mailer.conf for exec binary mailwrapper is in netbsd base, to accommodate using postfix, qmail or whatever else has sendmail emulators. root <at> trot:/root ls -l /usr/lib/sendmail ls: /usr/lib/sendmail: No such file or directory root <at> trot:/root which sendmail /usr/sbin/sendmail root <at> trot:/root ls -l `which sendmail` lrwxr-xr-x 1 root wheel 21 Mar 25 12:23:09 2007 /usr/sbin/sendmail <at> -> /usr/sbin/mailwrapper root <at> trot:/root cat /etc/mailer.conf # This file configures /usr/sbin/mailwrapper sendmail /var/qmail/bin/sendmail send-mail /var/qmail/bin/sendmail mailq /var/qmail/bin/sendmail newaliases /sbin/nologin hoststat /sbin/nologin(Continue reading)
RSS Feed1 | |
|---|---|
15 | |
16 | |
4 | |
7 | |
2 | |
15 | |
15 | |
3 | |
3 | |
4 | |
5 | |
1 | |
2 | |
27 | |
29 | |
14 | |
11 | |
10 | |
24 | |
31 | |
29 | |
1 | |
1 | |
6 | |
1 | |
1 | |
4 | |
3 | |
1 | |
6 | |
6 | |
2 | |
6 | |
5 | |
13 | |
17 | |
4 | |
2 | |
16 | |
1 | |
14 | |
8 | |
20 | |
21 | |
8 | |
1 | |
7 | |
6 | |
1 | |
4 | |
25 | |
6 | |
18 | |
28 | |
17 | |
21 | |
1 | |
14 | |
9 | |
8 | |
31 | |
13 | |
10 | |
54 | |
29 | |
31 | |
11 | |
47 | |
45 | |
30 | |
47 | |
62 | |
2 |
