gmane.comp.monitoring.mon.general

Infocon monitor v0.2 Released

Nathan Gibbs — 2011-08-03T01:42:08

The ISC changed the infocon file on their site to a redirect, so we had
to adjust the code.
:-)

http://www.cmpublishers.com/oss/#infocon.monitor

Enjoy

Re: Syslog problems

Davide Brini — 2011-07-28T07:52:11

On Wed, 27 Jul 2011 20:37:06 +0200, Dario Minnucci <midget< at >debian.org>
wrote:


Well, apparently Ubuntu 11.04 doesn't have it (yet?).

http://packages.ubuntu.com/natty/mon

But I'm ok with my manual fix for now. I might open a bug in the Ubuntu
tracker. Thanks for all the answers.

Re: Syslog problems

Jim Trocki — 2011-07-27T19:35:19


It's in the CVS HEAD, has been for a while, which is newer than mon-1.2.0.
Time for a 1.2.1 I guess.

Re: Syslog problems

Dario Minnucci — 2011-07-27T18:37:06

Hi Davide,

On 07/27/2011 04:55 PM, Davide Brini wrote:


BTW, it was fixed under mon 1.2.0-2 as stated under Debian BTS #611751 [0]

So, consider update mon to 1.2.0-2

Regards,


[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611751

Re: Syslog problems

Dario Minnucci — 2011-07-27T18:34:05

Hi list,

On 07/27/2011 07:38 PM, Allan Wind wrote:


The issue was reported [0] and patch attached to be considered.

I don't really know if was applied on upstream sources yet.

Regards,



[0] http://sourceforge.net/tracker/?func=detail&aid=3177976&group_id=170&atid=100170

Re: Syslog problems

Allan Wind — 2011-07-27T17:38:46

Debian fixed this with Bug#611751 I believe.  Surprised if that 
did not make it upstream.


/Allan

Syslog problems

Davide Brini — 2011-07-27T14:55:29

Hi, I'm using the stable mon-1.2.0-1 under Ubuntu 11.04 (Perl 5.10.1), and I
noticed that mon wasn't logging anything at all in syslog. Further
inspection revealed that the problem seems to be in the redefined syslog()
function:

no warnings; # Redefining syslog
sub syslog {
   eval {
       local $SIG{"__DIE__"}= sub { }; 
       my < at >log = map { s/\%//mg; } < at >_;
       Sys::Syslog::syslog(< at >log);
   }
}

since $_ is aliased in a map {} block, when the function is passed constant
strings, the map {} on < at >_ fails with a "modification of a read-only value
attempted". However this is not apparent, not even in debug mode, since it
happens inside the eval{} block.

Suggested change (for example):

no warnings; # Redefining syslog
sub syslog {
   eval {
       local $SIG{"__DIE__"}= sub { };
       my < at >log = < at >_;
       s/\%//mg for (< at >log);
       Sys::Syslog::syslog(< at >log);
   }
}

Regards,

Re: Defunct children after sending alert

Giampaolo Rodolà — 2011-07-20T13:07:33

Yep! It worked.
Thanks a lot for the fast response and the patch.

- Giampaolo

2011/7/19 Jim Trocki <trockij< at >gmail.com>

_______________________________________________
mon mailing list
mon< at >linux.kernel.org
http://linux.kernel.org/mailman/listinfo/mon

Re: Defunct children after sending alert

Jim Trocki — 2011-07-19T11:58:21


let me know if the attached patch helps. watch the syslog "info"
output for "master alert pid", "child alert pid", and "reaped pid".
there should be one "reaped pid" for every "alert pid", assuming all
alert processes are exiting properly.

if that doesn't help, send a process tree output showing the zombies so
i can see whose zombies they are, actually.Index: mon
===================================================================
RCS file: /cvsroot/mon/mon/mon,v
retrieving revision 1.27
diff -u -r1.27 mon
--- mon20 Jun 2011 17:26:25 -00001.27
+++ mon19 Jul 2011 11:54:30 -0000
< at >< at > -3223,11 +3223,14 < at >< at >
     my ($summary, $tmnow, $buf);
 
     $tmnow = time;
-    return if (keys %running == 0);
 
     while ((my $p = waitpid (-1, &WNOHANG)) >0)
     {
-next if (!exists $runningpid{$p});
+if (!exists $runningpid{$p})
+{
+    syslog ("info", "reaped pid $p");
+    next;
+}
 my ($group, $service) = split (/\//, $runningpid{$p});
 my $sref = \%{$watch{$group}->{$service}};
 
< at >< at >

Defunct children after sending alert

Giampaolo Rodolà — 2011-07-19T10:03:08

Hi all,
I bumped into this problem:
http://www.mail-archive.com/mon< at >linux.kernel.org/msg00828.html

My configuration consists of a master mon server which receives traps from
different mon slaves.
Extract from my conf:

watch uci
    service cpu
        period wd {Sun-Sat}
            alert mail.alert {my email address}
            upalert mail.alert {my email address}
            alertevery 1h

Every time a failure trap is sent from one of my slaves the mon master
correctly sends an email alert and I can detect that a new defunct process
appeared with:

$ ps aux | grep mon
13637 ? Z 0:00 [mon] <defunct>
13659 ? Z 0:00 [mon] <defunct>
13697 ? Z 0:00 [mon] <defunct>

This is kind of annoying as I'm forced to restart the mon master server
periodically given that we can send hundreds of traps per-day.

By digging into commit history I found this:
http://www.mail-archive.com/mon< at >linux.kernel.org/msg00828.html
...so I picked up latest development version from
https://mon.wiki.kernel.org/index.php/Development and

Running a task once a day, at given time

Marco — 2011-07-15T08:24:29

Hello, this is my requirement: I want to run a monitor exactly once
per day, around 4am. If the monitor fails, I want to get exactly one
alert; if it succeeds, nothing should happen.

This is what I've tried so far:

watch myserver
        service testservice
                description Test for monitoring once per day
                interval 5m
                exclude_period hr {5-23} min {0-59}, hr {0-3} min
{0-59}, hr {4} min {5-59}
                monitor testservice.monitor
                period wd {Mon-Sun}
                        alert mail.alert alerts< at >example.com

Currently, "testservice.monitor" is a dummy script that always returns failure.

I figured that leaving a 5-minute window for the monitor to run, it
would run exactly once during that 5-minute window. However, it
doesn't seem to work that way as I get no email.

I also though of using "interval 1d", but there doesn't seem to be a
way to specify when, during the day, the monitor should run, so I
suppose that would just take the time the d

http.monitor IPv6 version

Shigeru Yanagibayashi — 2011-07-10T06:17:41

Does anyone use http.monitor IPv6 version? I tried to modify original one
to use "use Socket6;", but it is hard for me. Any help will be appreciated.

Infocon monitor

Nathan Gibbs — 2011-07-08T00:04:09

http://isc.sans.org/diary.html?date=2011-06-26

for nagios

Now we have one too.
:-)

http://www.cmpublishers.com/oss/#infocon.monitor

Re: mon monitor for arpwatch?

Nathan Gibbs — 2011-07-06T16:01:40

OK, other things are slowing down my development efforts right now, but
I will get it done.


If you can get arpwatch to dump into a log file and build a monitor to
process that, you may get what you want.
Just an idea.

Also check out arpalert, it seems to have more features than arpwatch.

Re: mon monitor for arpwatch?

Chris Hoogendyk — 2011-07-05T16:00:27


On 7/1/11 12:46 PM, Nathan Gibbs wrote:

Yes.

A bit more control over reporting frequency and what is reported would be very good. Arpwatch 
produces an overload and makes it hard to use on a busy network since it is constantly shouting 
about things. If you can recognize that some particular hardware address was already reported for a 
particular behavior and not continue hollering about it, that would make it more valuable -- i.e. 
increase the signal to noise ratio. Any other correlation or diagnostic stuff would be good as well.

Re: mon monitor for arpwatch?

Nathan Gibbs — 2011-07-01T16:46:35

I don't, but I have been working on a monitor to check the arp table of
hosts and report anomalies.

Anyone interested?

Re: Failure to find designatated monitor reported as "untested"

Jim Trocki — 2011-06-20T17:32:39



i just checked in changes to the trunk for module "mon" and "mon-client"
which added a "configerr" state. there are changes to clients/monshow
and clients/mon.cgi which should reflect this. i tested it a bit and
it seems to work, so it'd be nice if you could check out the code and
confirm for yourself that it works.

it may take some amount of time before the read-only public cvs repo is
synced with the devel repo at sf. these are the revisions:



  cvs ci -m "added configerr state"
cvs commit: Examining .
cvs commit: Examining alert.d
cvs commit: Examining cgi-bin
cvs commit: Examining clients
cvs commit: Examining clients/skymon
cvs commit: Examining doc
cvs commit: Examining etc
cvs commit: Examining mon.d
cvs commit: Examining muxpect
cvs commit: Examining state.d
cvs commit: Examining utils
Checking in mon;
/cvsroot/mon/mon/mon,v  <--  mon
new revision: 1.27; previous revision: 1.26
done
Mailing mon-commit< at >lists.sourceforge.net...
Generating notification message...
Generating notification message...

Re: Failure to find designatated monitor reported as "untested"

Nico Kadel-Garcia — 2011-06-15T12:20:44

I believe you, but wasn't seeing them in syslog, even with "-d" in the
command line. I see a check for the existence of the directory and its
report to syslog, but not for the absence of a particular monitor
tool, or even if I yank the /usr/local/lib/mon/mon.d directory.. I'm
not sure why. Looks like I'd like to review the settings for rsyslog,
used on Debian, but due to typical system security, it's often awkward
for a non-root user to parse through these logs.

If I can talk you, as the original author, to enhance your perl,  to
report a "missing" status rather than merely "untested", I'd
appreciate that quite a lot.

Re: Failure to find designatated monitor reported as "untested"

Jim Trocki — 2011-06-15T02:34:08


well, both are tested and if problems are found, reported to syslog.
other related troubles are reported as well.

Re: Failure to find designatated monitor reported as "untested"

Nico Kadel-Garcia — 2011-06-15T02:04:21

As it turns out, I got multiply confused. The "mondir" setting is in
the manual page. It *does* describe a list of target directories to
search through. The problem is that the stable Debian mon package
reads init script settings from /etc/default/mon, and hands them as
command line arguments ot the "/usr/sbin/mon" program. This overrides
the contents of mon.cf: So where mon.cf said something like "mondir =
/usr/lib/mon/mon.d:/usr/local/lib/mon/mon.d" to allow host specific or
local monitors in /usr/local/lib/mon/mon.d/, the init script  wound up
forcing the use of /usr/lib/mon/mon.d

Edit /etc/devailt/mon, and suddenly it worked. Drove me *NUTS* finding that one.


Not being executable, I think, should be the test, rather than merely
not being present.

Re: Failure to find designatated monitor reported as "untested"

Jim Trocki — 2011-06-14T22:55:47


so if you have mondir which is a colon-separated list of directories, and
a service definition specifies, say, "ping.monitor", it will search each
of those directories for a ping.monitor and use the first one it finds.
what was the behavior you were expecting? i don't understand.


it does syslog that there's a problem with the config, i.e. it cannot
find the monitor for a particular service, but nothing that would show
up on the web page output or indicated via the client protocol. making a
new state to indicate a config-related problem for a particular service
is a good idea. there are a few different errors which could be indicated
through that mechanism, beyond not finding the monitor in the mondir path.