- Xymon - Xymon mailman web

Improving memory monitoring
by steve＠opendium.com 14 Apr '15

14 Apr '15

I'm working on improving my Xymon configuration to reduce the number of false alerts that we get. In particular, memory monitoring is a bit of a problem so I'm hoping someone will be able to offer some advice. At the moment, Xymon is set up with something like: MEMPHYS 100 101 MEMSWAP 20 40 MEMACT 95 97 I pretty much don't care about MEMPHYS. The problem with MEMSWAP and MEMACT is that they work independently or each other - i.e. the above will give me an alert if > 97% of the RAM is used OR > 40% of swap is used. However, this results in warnings for systems that have a lot of idle data in memory. The Linux kernel will page out idle data (increasing swap usage and reducing RAM usage) and use that space for buffers/caches, and this is a very sensible strategy. Unfortunately, then Xymon comes along and notices that there's lots of swap in use and throws an alert, even though there's plenty of RAM free. Basically, I don't care that a machine is 4GB into swap if it has 5GB of free ram - that isn't a problem, it just means there's quite a lot of idle data that the kernel has decided can be paged out. I do care if it's 4GB into swap and only has 0.5GB of free RAM since this would indicate that it's actually short of memory. What I really need is to warn if > x% of the RAM is used AND > y% of swap is used - is there a way to do that? Thanks. -- - Steve Hill Technical Director Opendium Limited http://www.opendium.com Direct contacts: Instant messager: xmpp:steve at opendium.com Email: steve at opendium.com Phone: sip:steve at opendium.com Sales / enquiries contacts: Email: sales at opendium.com Phone: +44-1792-824568 / sip:sales at opendium.com Support contacts: Email: support at opendium.com Phone: +44-1792-825748 / sip:support at opendium.com

2 1

alerts.cfg “TIME=” broken in v4.3.19?
by g.stone-tolcher＠its.uq.edu.au 13 Apr '15

13 Apr '15

Hi, I am seeing something unusual in the “info” display for alerting on v4.3.19: alerts.cfg entry: HOST=mixtec.cc.uq.edu.au SERVICE=fping,bbd MAIL irt-work-sms at xyz.cc.uq.edu.au DURATION>3m TIME=W:0945:1800 COLOR=red REPEAT=1w FORMAT=SMS RECOVERED “info” for mixtec.cc.uq.edu.au (v4.3.19) Alerting: Service Recipient 1st Delay Stop after Repeat Time of Day Colors bbd irt-work-sms at xyz.cc.uq.edu.au (R) 3m 1s - 1w - red fping irt-work-sms at xyz.cc.uq.edu.au (R) 3m 1s - 1w - red Notice “-“ for “Time of Day”! “info” for mixtec.cc.uq.edu.au (reverted to v4.3.18) Alerting: Service Recipient 1st Delay Stop after Repeat Time of Day Colors bbd irt-work-sms at xyz.cc.uq.edu.au (R) 3m 1s - 1w W:0945:1800 red fping irt-work-sms at xyz.cc.uq.edu.au (R) 3m 1s - 1w W:0945:1800 red “Time of Day” seems correct. Is anyone else seeing similar? Cheers, Gavin Stone-Tolcher, IT Support Officer, Network Operations and Incident Response Information Technology Services The University of Queensland Level 4, Prentice Building, St Lucia 4072 T: +61 7 334 66645, M: +61 401 140 838 E: g.stone-tolcher at its.uq.edu.au<mailto:g.stone-tolcher at its.uq.edu.au> W: www.its.uq.edu.au<http://www.its.uq.edu.au> ITS: Service. Team. Accountability. Results. IMPORTANT: This email and any attachments are intended solely for the addressee(s), contain copyright material and are confidential. We do not waive any legal privilege or rights in respect of copyright or confidentiality. Except as intended addressees are otherwise permitted, you do not have permission to use, disclose, reproduce or communicate any part of this email or its attachments. Statements, opinions and information not related to the official business of The University of Queensland are neither given nor endorsed by us. By using this email (including accessing any attachments or links) you agree we are not liable for any loss or damage of any kind arising in connection with any electronic defect, virus or other malicious code we did not intentionally include. Please consider the environment before printing this email. CRICOS Code 00025B

5 5

Planned downtime - purple
by bb4＠richter-it.net 13 Apr '15

13 Apr '15

Hi, about 2 years ago I asked Henrik about the planned downtime behaviour that doesn't work for purple alerts and he told me that he wanted to change the behaviour in 4.3.12. But since the nothing happened. So I am posting the patch for 4.3.19 and hope this time it gets added. --- xymond.c.orig 2015-02-20 01:38:25.000000000 +0100 +++ xymond.c 2015-04-13 11:29:25.563999251 +0200 @@ -1244,7 +1244,7 @@ done: if (colstr) { - if ((*color == COL_RED) || (*color == COL_YELLOW)) { + if ((*color == COL_RED) || (*color == COL_YELLOW) || (*color == COL_PURPLE)) { char *cause; cause = check_downtime(hostname, testname); Thanks Torsten

2 2

xymon client message STATUSLIFETIME?
by werner＠maiers.de 13 Apr '15

13 Apr '15

Hi, I have the following problem: I want to monitor the client data of a machine that is only up once a day. the machine gets waked up w/ wakeonlan, takes an rsnapshost of other servers, and shuts down again. (no need to be up 24/7 with 8 2 TB HDDs, raidcontroller)... I know about the normal xymon status+LIFETIME protocol. but I don't see where or how to configure that client to send a LIFETIME with the "xymonclient.sh" - it uses the "client" protocol. how do I set the validity for these tests to 24h+ ? (1600 minutes should be ok). thanks in advance. Werner -- Dipl.-Ing. Univ. Werner Maier http://www.maiers.de/

1 0

showgraph.cgi behaviour
by bb4＠richter-it.net 13 Apr '15

13 Apr '15

Hi, last week a colleague turned my attention to the graphs that are shown below the single tests, like cpu, disk etc. First I have to say that the problem seems only to occur if you have more than 10 file systems mounted. He told me that if he clicks on a graph beneath the test because he wants to check the utilisation of a file system everything seems to be fine at first but when he zooms into the graph suddenly other file systems are shown but not the one he wanted to take a look. If he tries the same on the trends page it seems to work. I was able to verify this behaviour with XYmon 4.3.12 and XYmon 4.3.18 (Unfortunately I only have these 2 versions running at the moment). See attached screenshots. Can someone else verify this? If this is a bug (seems that there are different sort algorithms used on the test page and the trends page) how can I disable the graphs on the test pages and only rely on the ones that are displayed on the trends page. Thanks Torsten

1 1

Bug report in xymonfetch
by john.thurston＠alaska.gov 10 Apr '15

10 Apr '15

Back in December, I reported what I thought was a defect in xymonfetch http://lists.xymon.com/archive/2014-December/040850.html Can anyone else confirm this behavior so we can get it narrowed down, logged, and squashed? -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska

2 1

Xymon for Ubuntu 11.04
by Paul.Root＠CenturyLink.com 10 Apr '15

10 Apr '15

Is there a newer package for the xymon-client for Ubuntu 11.04 than 4.3.0~beta2. I'm inheriting monitoring for a computer and am having a hard time making heads or tails of it. I think most of my problem is a firewall between my server and this machine, but I would like to get newer stuff here. Paul Root Lead Engineer CenturyLink Network Reliability Operations Center 600 Stinson Blvd, N.E. Flr 2N Minneapolis, MN 55413 Direct: (651)312-5207 Paul.Root at centurylink.com This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

3 3

Summary for remotes in 4.3.19 not working
by john.r.rothlisberger＠accenture.com 10 Apr '15

10 Apr '15

To be perfectly honest, I just upgraded to 4.3.18 on March 27th from 4.3.13 on the server side, and cannot be positive that it was working in 4.3.18. I certainly didn't notice that it wasn't working. I can say that it was working in 4.3.13. There is no hosts.cfg entry on the server side. Thanks, John Upcoming PTO: _____________________________________________________________________ John Rothlisberger IT Strategy, Infrastructure & Security - Technology Growth Platform TGP for Business Process Outsourcing Accenture 312.693.3136 office _____________________________________________________________________ > -----Original Message----- > From: J.C. Cleaver [mailto:cleaver at terabithia.org] > Sent: Tuesday, April 07, 2015 12:29 PM > To: Andy Smith; Rothlisberger, John R. > Subject: Re: [Xymon] Summary for remotes in 4.3.19 not working > > > > On Tue, April 7, 2015 7:47 am, Andy Smith wrote: > > On 7 April 2015 at 04:43, J.C. Cleaver <cleaver at terabithia.org> > wrote: > > > >> > >> > >> On Mon, April 6, 2015 6:53 am, john.r.rothlisberger at accenture.com > wrote: > >> > Is there anyone else having trouble with the summary function in > >> 4.3.19? > >> > > >> > From my remote server I am getting the following errors in > >> display.log: > >> > 2015-04-06 14:40:15.860975 Whoops ! Failed to send message > >> > (Connection > >> > failed) > >> > 2015-04-06 14:40:15.861020 -> Could not connect to Xymon > >> > daemon at N.N.N.N:1984 (Connection refused) > >> > 2015-04-06 14:40:15.861026 -> Recipient 'N.N.N.N', timeout 15 > >> > 2015-04-06 14:40:15.861032 -> 1st line: 'summary > >> > summary.Remotes.MyRemoteSite red https://my.url.com/MyRemoteSite/ > >> > Mon > >> Apr > >> > 6 14:40:15 2015' > >> > > >> > My hosts.cfg file looks like: > >> > summary Remotes.MyRemoteSite 63.240.185.103 > >> > https://my.url.com/MyRemoteSite/ > >> > > >> > I have 4 servers that I just upgraded to 4.3.19 and all were a mix > >> from > >> > 4.3.18 to 4.3.0 and all worked fine prior to the upgrade. > >> > > >> > I am able to telnet to N.N.N.N:1984 from my remote sites. I do > not > >> have > >> > any firewalls running on my main server. > >> > > >> > Ideas? > >> > >> > >> Hmm. I'm not aware of anything that would have changed in this > >> regard, especially in a way that would have looked like a > communications issue. > >> > >> Can you verify with a 'ping' and 'dummy' message that normal > >> connectivity from those boxes work normally? > >> > >> If so, can you run xymongen with --debug enabled? There should be an > >> init_sum section and a segment near the end showing it being sent > off. > >> > >> > >> Regards, > >> > >> -jc > >> > >> _______________________________________________ > >> Xymon mailing list > >> Xymon at xymon.com > >> http://lists.xymon.com/mailman/listinfo/xymon > >> > > > > > > > > > > > > I can repeat this, it is something on the server side. It was last > > seen working here on 4.3.13. > > > > In a lab I have 3 servers, 2 on Solaris (4.3.4 & 4.3.19) and 4.3.19 > on > > CentOS 5. I am sending the summary from the CentOS server to both of > > the Solaris servers. The hosts.cfg on the CentOS server contains > > :- > > > > > > summary builds.centos63_i686 192.168.2.124 http://192.168.2.61/xymon/ > > > > summary builds.centos63_i686 192.168.2.122 http://192.168.2.61/xymon/ > > > > This is appearing correctly on 4.3.4 (192.168.2.122), but missing > > completely on 4.3.19 (192.168.2.124) > > > > Here is a clue, checking xymondboard on each Solaris server from the > > CentOS server :- > > > > $ xymon 192.168.2.122 "xymondboard test=centos63_i686" > > > summary|builds.centos63_i686|green||0|1428398444|1428400244|0|0|192.16 > > summary|8.2.61||green > > http://192.168.2.61/xymon/ Tue Apr 7 10:20:05 2015 > > > > $ xymon 192.168.2.124 "xymondboard > > test=centos63_i686" > > > |builds.centos63_i686|green||1428387271|1428398444|1428400244|0|0|192. > > |168.2.61||green > > http://192.168.2.61/xymon/ Tue Apr 7 10:20:05 2015 > > > > > > (note the missing "summary" psuedo hostname field stored on 4.3.19). > > -- > > Andy > > > > > Gotcha. > > Can you give your server-side hosts.cfg line for this? > > John: Was your previous direct server version 4.3.18, or were you > running an older version than that? > > > -jc > ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com

3 4

Accessing availabitlity or snapshot reports
by dirk.kastens＠uni-osnabrueck.de 10 Apr '15

10 Apr '15

Hi JC, > Would you mind testing > http://terabithia.org/rpms/xymon/testing/el6/x86_64/xymon-4.3.19-9.el6.x86_… > (et al.) and see if this fixes the problem for you? > > If possible, please first change the context back to: > > /usr/sbin/semanage fcontext -a -t httpd_cache_t '/var/cache/xymon(/.*)?' > and then run restorecon -Rv /var/cache/xymon I deleted my added file contexts, restored the original ones, and updated the RPM. Now the reports are working. Thanks for your support. Dirk

1 0

Is there a reason why the httpstatus test is case sensitive?
by john.thurston＠alaska.gov 10 Apr '15

10 Apr '15

Yesterday, I crashed xymonnet by doing a copy/paste into an httpstatus test. I eventually figured out what was wrong. This syntax is good: 0.0.0.0 foo.com # httpstatus;http://foo.com/index.html;401 This syntax is bad: 0.0.0.0 foo.com # httpstatus;HTTP://foo.com/index.html;401 The man page for hosts.cfg doesn't say anything about required or supported casing. Is there some reason why xymonnet shouldn't be able to handle mixed-case protocol names in the URLs provided? -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston at alaska.gov Enterprise Technology Services Department of Administration State of Alaska

3 4