Xymon Mailing List Archive search

bbtest yellow-mystery

list Josh Luthman
Mon, 12 Jul 2010 15:24:44 -0400
Message-Id: <user-76c205956709@xymon.invalid>

I didn't mean to be rude...I'm entirely serious.

I don't know where to find the RTFM book (that's not my name for
it...) but I'm on IRC all the time.  Just mention my nick in the
channel and I'd be happy to help as much as I can.  I feel it is
everyone's duty to at least spend a moment looking through the
documentation pages before involving someone else.

Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX


On Mon, Jul 12, 2010 at 3:17 PM, Smith, Jim <user-dc30f243a817@xymon.invalid> wrote:
LOL!  Funny, but kinda rude.


-----Original Message-----
From: Josh Luthman [mailto:user-4c45a83f15cb@xymon.invalid]
Sent: Monday, July 12, 2010 1:50 PM
To: xymon at xymon.com
Subject: Re: [xymon] bbtest yellow-mystery

To my knowledge the best thing that relates to this is T.J.'s RTFM
guide.  I browsed through it when the IRC channel was first
created...long ago.

You can always ask logical questions after searching the docs in IRC.

Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX


On Mon, Jul 12, 2010 at 2:45 PM, Carl Melgaard <user-cdea55422fa4@xymon.invalid> wrote:
Hi,
Yes, that is only for disabling alerting to create a maintenance window.
It doesn't stop the checks from occurring. Thanks.
Great, I feel like a beginner now. Is there any day-to-day operations-manual
in the Xymon-documentation/wiki somewhere? I think I've missed the basic
Xymon operation-guidelines somehow.


/melgaard

On Mon, Jul 12, 2010 at 1:50 PM, Carl Melgaard <user-cdea55422fa4@xymon.invalid>
wrote:
Hi,

Have you disabled alerting for that host or commented it out in your
bb-hosts? The way to disable a "check" for a host is to remove the check or
comment out the host in the bb-hosts. If you have just disabled the
"alerting", then it will continue to do the "check", just not alert you.

I've used the Enable/Disable-options in he Administration-part of Xymon,
to disable the tests (the hobbit-enadis.sh-script) - is that just
alert-disabling?


/melgaard


On Mon, Jul 12, 2010 at 1:13 PM, Carl Melgaard <user-cdea55422fa4@xymon.invalid>
wrote:
Hi,

One of our AD-servers went down for maintenance for 1 week, and I
disabled
 the conn+dns tests in Xymon for that period. Now the "bbtest" column
 suddenly goes yellow, and indicates that DNS lookups takes 450+
seconds
 now (indicating that the DNS-check for the maintenanced server is
still
 active).
No, it indicates that the Xymon server is taking a long time to resolve
host
names to IP addresses. You may need to configure the DNS client
settings on the
Xymon server (e.g. adjust the 'server' parameters in /etc/resolv.conf).

If you have most IP addresses hardcoded correctly in bb-hosts, you may
want to
add the 'testip' flag to the relevant lines of bb-hosts.
But why is the check still running against the AD-host I've disabled? It
looks like its that exact dns-check that takes 450 seconds to run (timeout).
Looking at the DNS-statistics:

DNS tests executed                          4602546.200466
 450.096498

which is the normal checks + the 450 second timeout. All other dns-checks
run fine.

Shouldnt I except something like this (from the conn checks):

"System unreachable for 764 poll periods (363317 seconds)"

instead of:

"Service dns on xxx07 is OK
Dialup host/service, or test depends on another failed test
Host appears to be down
Timeout
Seconds: 450.003"

when I've disabled all the checks on the host, and the server is powered
down? Or am I missing something here?

/melgaard

The information contained in this message is privileged
and confidential information intended for the review and
use of the individual and entity named above. If the
reader of this message is not the intended recipient, you
are hereby notified that any disclosure, dissemination,
distribution or copying of this communication or the
information contained herein is strictly prohibited. If
you have received this communication in error, please
immediately notify us.