August 2013 - Xymon - Xymon mailman web

is depends broken?
by troy＠athabascau.ca 20 Aug '13

20 Aug '13

I have the following in my 'hosts.cfg': 209.85.225.105 google.com # http://www.google.com XXX.XXX.XXX.XXX www # trace http://www depends=(http:google.com/http) Yesterday, the web server (www) was down for 55 minutes. The Xymon record shows that: 1. google.com/http was green for that whole period 2. www/http bounced between red and clear for the whole period (with a bounce frequency of 5 minutes) 3. My other Xymon server (configured without "depends") shows a solid 55 minute outage (red for 55 minutes). This behavior is not what I expect from reading the man page. I tried to reproduce this problem with "depends" on my test Xymon server and was able to confirm the same behavior. Is there a workaround to this problem with my Xymon 4.3.10 server? cheers, Troy -- This communication is intended for the use of the recipient to whom it is addressed, and may contain confidential, personal, and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. ---

3 2

Xymon Cron Question
by john.kramer＠comodo.com 19 Aug '13

19 Aug '13

Hi, Very new to Xymon here, so I apologize if this is a newb question. We have a test script that runs as cron and inspects the state of the system (returns 0 for success, returns non 0 for failure). We would like to report the result of that test through Xymon. Any help as to how to do this would be appreciated. Thanks! John Kramer Product Manager - Enterprise Security Solutions <mailto:John.Kramer at comodo.com> John.Kramer at comodo.com Mobile: 314.435.2370 Skype: john.kramer_comodo <http://www.comodo.com/> http://www.comodo.com Description: Description: https://www.thesslstore.com/images/partner-comodo-logo.jpg

3 2

xymon polling periods
by JAlexander＠feeneywireless.com 19 Aug '13

19 Aug '13

A couple of questions about Xymon capabilities... - Can Xymon handle hosts that cannot be contacted by the server? I will have hosts reporting in, but won't know the IP and cannot connect to them. Status reports will actually come from a central agent rather than from the devices - Can Xymon handle multiple different polling periods - specifically with RRD? Some devices check in every minute. Some check in every 2 minutes. Some every 5 minutes. Thanks much all. John Alexander Network Administrator John.Alexander at feeneywireless.com<mailto:John.Alexander at feeneywireless.com> Feeney Wireless, LLC - PO Box 2549, Eugene, Oregon 97402 (Free) 800-683-4818 (P) 541-393-8518 (F) 541-284-0030 www.feeneywireless.com<http://www.feeneywireless.com/> [http://shopping.netsuite.com/c.491803/site/signature_image.gif] This email transmission is intended only for the addressee shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the addressee is strictly prohibited! If you have received this email transmission in error please notify us immediately.

2 2

xymonexi
by mark.rosedale＠gmail.com 19 Aug '13

19 Aug '13

Hello, I'm setting up xymon for my esxi servers. I'm using the xymon esxi project http://xymonesxi.sourceforge.net/. I've got everything setup and working properly, however, I'm noticing a huge cpu spike on my xymon server corresponding to the bb-esx.pl script. My vmware hosts are all esxi 4.x hosts. I'm running the following checks server.com # conn ssh vmware esxi If it is just one host not a big deal, but if I run these checks on 4 or more the cpu starts to get overloaded. Any suggestions for what is going on here? Thanks, mjr

1 0

Notification Log - status is missing
by A.Chervonets＠cominder.eu 19 Aug '13

19 Aug '13

Xymon 4.3.11 - Notification log report contains only: *Time *Host *Service *Recipient Would be nice to append service status too (colour or status name like DISABLED, RECOVERED etc.). We can then check service status at time listed using service history page, but it is quite uncomfortable. Best regards, Andrey Chervonets ---------------------- SIA CoMinder http://www.cominder.eu/

1 0

Xymon Digest, Vol 31, Issue 13
by s.watkins＠nhm.ac.uk 16 Aug '13

16 Aug '13

> Date: Thu, 15 Aug 2013 14:47:09 +0200 > From: Thomas Eckert <thomas.eckert at it-eckert.de> > Subject: Re: [Xymon] ssh Unexpected service response > Message-ID: <782C18D3-D4FC-4844-95FE-BA17D7FAABE0 at it-eckert.de> > > We see this regularily with (over-) loaded hosts. > Any chance that your Solaris host is under heavy load (both network and/or system) when this happens? > >> Am 14.08.2013 um 00:58 schrieb Vernon Everett <everett.vernon at gmail.com>: >> >> Hi all >> >> From time to time I get the "Unexpected service response" on the ssh tests of a Solaris host. >> The test goes yellow, and recovers again within seconds. 10 seconds on the last example. >> >> Because of the short duration, it's really dificult to replicate. >> Can anybody give me some pointers as to what's causing this? When I first started using the [ssh|ssh1|ssh2] test on system I was also getting the issue where various systems, all solaris hosts exhibited this problem of flapping around between green and yellow status. The "Unexpected service response" is both correct in its description of the problem and absolute buttons at being of any help to diagnose the issue. The issue is caused by xymon "expecting" a certain response from the ssh daemon when it first connects and handshakes. From what I was seeing it looked like it was an issue only with systems that where running the native solaris ssh server daemon as provided by the SUNWssh range of software packages. I tracked it a little further and found that it looked like the solaris ssh servers were not (consistently?) returning an initial SSH ident. So the way I banished the bouncing yellow alerts was to comment out the 'expect' line in my [ssh|ssh1|ssh2] definition. For clarity, here is the entry I'm currently using in protocols.cfg: ---- [ssh|ssh1|ssh2] send "SSH-2.0-OpenSSH_4.1\r\n" # expect "SSH" options banner port 22 ----- Note: the '#'/commented out "expect" line. After doing this the bouncing yellow alerts for ssh stopped. It is still a valid test as it will fail to red if the xymon server cannot make a connection via ssh to the target system. Pro: stops the bouncing yellow warnings on ssh Con: means that you cannot definitively check the handshake/response that the ssh daemon first sends. Another possible way of getting around this issue could be to check and possibly install the same release/version of the ssh daemon on all your monitored systems. As I said earlier the issue "seems" to only happen on systems running the native solaris ssh daemon. I did not notice this being reported by systems running OpenSSH daemons. Of course, there may be a huge set of considerations about what ssh daemon you use in your own particular IT landscape. Hope that helps, Steff Watkins ----- Steff Watkins Natural History Museum, Cromwell Road, London,SW75BD Systems programmer Email: s.watkins at nhm.ac.uk Systems Team Phone: +44 (0)20 7942 6000 opt 2 ======== "Many were increasingly of the opinion that they'd all made a big mistake in coming down from the trees in the first place. And some said that even the trees had been a bad move, and that no one should ever have left the oceans." - HHGTTG

1 0

Warning: Flapping Status
by cure4all＠gmail.com 15 Aug '13

15 Aug '13

How do I completely disable "Flapping Status" on my Xymon 4.3.11? I have the following settings on my tasks.cfg, but I'm still seeing "Flapping Status". Please help. Thank you. [xymond] ENVFILE /home/xymon/server/etc/xymonserver.cfg CMD xymond --pidfile=$XYMONSERVERLOGS/xymond.pid \ --restart=$XYMONTMP/xymond.chk --checkpoint-file=$XYMONTMP/xymond.chk --checkpoint-interval=600 \ --log=$XYMONSERVERLOGS/xymond.log \ --admin-senders=127.0.0.1,$XYMONSERVERIP \ --store-clientlogs=!msgs --flap-count=0 John

2 1

ssh Unexpected service response
by everett.vernon＠gmail.com 15 Aug '13

15 Aug '13

Hi all >From time to time I get the "Unexpected service response" on the ssh tests of a Solaris host. The test goes yellow, and recovers again within seconds. 10 seconds on the last example. Because of the short duration, it's really dificult to replicate. Can anybody give me some pointers as to what's causing this? Does xymon log the exact response somewhere? The old Hobbit archive has a few threads with this error message, but none give me usable diagnostic information. The error isn''t associated with any service disruption, and nobody has reported difficulty with their connections, but I would still like to get to the bottom of this, and hopefully eliminate the "problem". Any assistance appreciated. Regards Vernon -- "Accept the challenges so that you can feel the exhilaration of victory" - General George Patton

3 2

SMS to long
by dirk.kastens＠uni-osnabrueck.de 15 Aug '13

15 Aug '13

Hi, > Don't know if you had a reaction but you can use the cut command to > maximize the message. OK, but this would only work with an external script. We use MAIL with FORMAT=sms. Meanwhile we have shortened the URL that is tested by xymon. Now we are below the 160 character limit. Dirk

2 2

monitoring UPS
by JAlexander＠feeneywireless.com 14 Aug '13

14 Aug '13

I installed NUT and the set of scripts from revpol.com. They work as advertised, but I'm looking to have the data displayed on the page for the respective UPS - rather than the Xymon server. Any thoughts or hints? Thanks. John Alexander Network Administrator John.Alexander at feeneywireless.com<mailto:John.Alexander at feeneywireless.com> Feeney Wireless, LLC - PO Box 2549, Eugene, Oregon 97402 (Free) 800-683-4818 (P) 541-393-8518 (F) 541-284-0030 www.feeneywireless.com<http://www.feeneywireless.com/> [http://shopping.netsuite.com/c.491803/site/signature_image.gif] This email transmission is intended only for the addressee shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the addressee is strictly prohibited! If you have received this email transmission in error please notify us immediately.

6 7