January 2014 - Xymon - Xymon mailman web

Disk usage issue
by ffolse＠thezenith.com 11 Jan '14

11 Jan '14

Hi, We are having a fairly unusual issue with disk usage monitoring. The client is reporting 2 disk usage as seen in the example below. &red 249832 802352 24% / (1052184% used) has reached the PANIC level (99%) &red 41980 166776 21% /boot (208756% used) has reached the PANIC level (99%) &red 33008 5212008 1% /home (5245016% used) has reached the PANIC level (99%) &red 32840 1019344 4% /local (1052184% used) has reached the PANIC level (99%) &red 1179544 4065472 23% /opt (5245016% used) has reached the PANIC level (99%) &red 611832 440352 59% /tmp (1052184% used) has reached the PANIC level (99%) &red 4013520 1231496 77% /usr (5245016% used) has reached the PANIC level (99%) &red 2555380 2689636 49% /var (5245016% used) has reached the PANIC level (99%) &red 9832944 11137932 47% /local/apps/oracle (20970876% used) has reached the PANIC level (99%) The 3rd column is the correct usage, however an additional column with 99% usage is added at the end. Have you guys experienced anything like this? Environment: Hobbit Monitor 4.3.0-0.beta2<http://www.xymon.com/> SUSE linux 11 sp1 Thanks and let me know, Liz *********************************************************** NOTICE: This e-mail, including attachments, contains information that may be confidential, protected by the attorney/client or other privileges, or exempt from disclosure under applicable law. Further, this e-mail may contain information that is proprietary and/or constitutes a trade secret. This e-mail, including attachments, constitutes non-public information intended to be conveyed only to the designated recipient of this communication, please be advised that any disclosure, dissemination, distribution, copying, or other use of this communication or any attached document is strictly prohibited. If you have received this communication in error, please notify the sender immediately by reply e-mail and promptly destroy all electronic and printed copies of this communication and attached documents. ***********************************************************

2 1

xymon-4.3.13 on CentOS-6.5 testing
by tjyang2001＠gmail.com 10 Jan '14

10 Jan '14

Hi All I am testing new xymon-4.3.13 on CentOS 6.5 platform, so far I have only encountered one tiny bug. 1. tasks.cfg WHAT: can't open tasks.d directory, HOW: 1. comment out last line in tasks.cfg 2. or change the makefile to create etc/tasks.d directory [xymon]$ tail -3 /data/xymon/server/etc/tasks.cfg # Include add-on modules. directory /data/xymon/server/etc/tasks.d [xymon ]$ grep task xymonlaunch.log 2014-01-09 14:12:37 Loading tasklist configuration from /data/xymon/server/etc/tasks.cfg 2014-01-09 14:12:37 Cannot open directory /data/xymon/server/etc/tasks.d 2014-01-09 16:09:44 Loading tasklist configuration from /data/xymon/server/etc/tasks.cfg 2014-01-09 16:09:44 Cannot open directory /data/xymon/server/etc/tasks.d 2014-01-09 16:10:16 Loading tasklist configuration from /data/xymon/server/etc/tasks.cfg 2014-01-09 16:10:16 Cannot open directory /data/xymon/server/etc/tasks.d [xymon]$ Thanks tj -- T.J. Yang

1 1

Ntpdate deprecated
by dan.mcdonald＠austinenergy.com 10 Jan '14

10 Jan '14

Running xymon 4.3.13 on SuSe ES 11 SP 3, the ntp test isn¹t working: Fri Jan 10 08:21:02 2014 ntp ok Service ntp on ns6.aelabad.net is OK (up) Command: ntpdate -u -q -p 2 10.1.9.51 2>&1 !!!!!!!!!!!!!! WARNING !!!!!!!!!!!!!!!!!! The ntpdate program is deprecated and should not be used any more. To quote the upstream ntp developers: "The functionality ntpdate offered is now provided by the ntpd daemon itself. If you call ntpd with the command line option -q it will retrieve the current time and set it accordingly." Please check the Network Time Protocol (NTP) daemon man page and http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate for further information. You can replace the ntpdate call with "rcntp ntptimeset" to achieve an inital poll of the servers specified in /etc/ntp.conf. The program /usr/sbin/sntp offers comparable functionality to ntpdate. Specifically sntp -P no -r pool.ntp.org is equivalent to ntpdate pool.ntp.org For further details please refer to the man page of sntp. sntp: unable to write PID to /etc/sntp.pid sntp: Permission denied -- Daniel J McDonald, CISSP # 78281

4 5

Reference tag in hosts.cfg
by abs＠shadymint.com 10 Jan '14

10 Jan '14

Hi, Could I request that this trivial change be added at some stage please. It introduces the ability to include a tag in hosts.cfg which has no purpose other than provide an arbitary reference. eg configdbid=12345 In my case '12345' would be the ID of a record in an asset database and I can use this to construct a query that delivers useful support information. It could also be used the other way round and provide a way to maintain hosts.cfg in a mysql db or some such. Let me know what you think. *** xymon-code/lib/loadhosts.h.FCS 2014-01-10 11:29:26.000000000 +0000 --- xymon-code/lib/loadhosts.h 2014-01-10 14:00:51.000000000 +0000 *************** *** 55,60 **** --- 55,61 ---- XMH_FLAG_PULLDATA, XMH_FLAG_MULTIHOMED, XMH_LDAPLOGIN, + XMH_CONFIGDBID, XMH_IP, XMH_HOSTNAME, XMH_DOCURL, *** xymon-code/lib/loadhosts.c.FCS 2014-01-10 11:29:26.000000000 +0000 --- xymon-code/lib/loadhosts.c 2014-01-10 14:00:42.000000000 +0000 *************** *** 170,175 **** --- 170,177 ---- xmh_item_name[XMH_FLAG_MULTIHOMED] = "XMH_MULTIHOMED"; xmh_item_key[XMH_LDAPLOGIN] = "ldaplogin="; xmh_item_name[XMH_LDAPLOGIN] = "XMH_LDAPLOGIN"; + xmh_item_key[XMH_CONFIGDBID] = "configdbid="; + xmh_item_name[XMH_CONFIGDBID] = "XMH_CONFIGDBID"; xmh_item_key[XMH_CLASS] = "CLASS:"; xmh_item_name[XMH_CLASS] = "XMH_CLASS"; xmh_item_key[XMH_OS] = "OS:"; *** xymon-code/web/svcstatus-info.c.FCS 2014-01-10 11:30:24.000000000 +0000 --- xymon-code/web/svcstatus-info.c 2014-01-10 14:01:27.000000000 +0000 *************** *** 1206,1211 **** --- 1206,1212 ---- (strncmp(val, "type=", 5) == 0) || (strncmp(val, "post=", 5) == 0) || (strncmp(val, "nopost=", 7) == 0) || + (strncmp(val, "configdbid=", 11) != 0) && (strncmp(val, "soap=", 5) == 0) || (strncmp(val, "nosoap=", 7) == 0) ) { Thanks -- Andy

4 5

MQ monitoring on Windows
by henrik＠hswn.dk 10 Jan '14

10 Jan '14

Den 10.01.2014 08:38, Neil Simmonds skrev: > Could you tell me which version of Xymon the ability to send a status with "client" instead of colour was introduced? > > Essentially, was it after 4.3.4? It's been there since (before) 4.3.0. I don't know if the "drop a text file in the tmp directory" way of sending such a status works with BBWin, I have only used it with a commandline utility so sending the data was done as on a Unix box. For it to work, your data must mimic that which is generated by the "client/mq.sh" script on Unix. And in order to get "mqcollect" as the collector ID, the test name that you use in the status message must be "mqcollect". So a status message with status myhost.mqcollect client ... output from the runmqsc commands ... should work. If you want to try the "drop file in tmp directory", then the file must be called "mqcollect" and have "client" as the first word on line 1. Regards, Henrik

3 3

inode test fails after change in showgraph
by Wim.Nelis＠nlr.nl 10 Jan '14

10 Jan '14

Hello, Yesterday Xymon server, version 4.3.12, stopped performing the test inode, after a change in program showgraph.cgi. In all Xymon pages, we show the date in an ISO8601 format. File showgraph.c is modified to generate an ISO8601 date too, by changing the format in the invocations of strftime. After a `make`, a `make install` and a restart of xymon server, the dates in the graphs were changed to the desired format. However, after half an hour, all inode tests became purple. It was found that: - in subdir ~xymon/server/bin only programs showgraph.cgi and xymond_rrd are rebuild, all the other programs have modification time multiple months back; - there are no inode-related (error)messages in any of the logfiles in /var/log/xymon - `make install` has changed some of the *.cfg files in ~xymon/server/etc. Those changes are reverted, by reloading the previous version of those files from an svn repository. This had no effect on the colour of the inode tests; - defining the INODE tag in ~xymon/server/etc/analysis.cfg for one of the affected hosts does not change the colour of the inode-test of that host. The colour of the test stays purple; - reloading programs showgraph.cgi and xymon_rrd from a back-up does not change the colour of the inode-tests either. Of course the dates in the graphs are now again shown using the original format. Xymon server has been stopped and started at each change. The configuration of the xymon clients has not been changed while looking for a solution for this problem. Does any one knows how to solve this problem? Are there more things I can do (check,restore) to get the inode test operational again? Regards, Wim Nelis. ****************************************************************************************************************** The NLR disclaimer is valid for NLR e-mail messages. This message is only meant for providing information. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of the sender. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. Sender accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. ******************************************************************************************************************

2 5

4.3.13 DIG test issues
by dan.mcdonald＠austinenergy.com 09 Jan '14

09 Jan '14

I¹ve just stood up a 4.3.13 instance in my lab and am setting up some basic tests. I¹ve got 4 hosts being monitored for active DNS servers, of which, one is failing, but I¹m not seeing the test actually being performed. I¹m running tcpdump on the server, and no packets are being sent. Using dig at the command line works fine. The other 3 servers all work fine. Here¹s a sanitized config file: #Name Servers page DNS Name servers group lab 0.0.0.0 ns1.example.net # noconn dig=soa:other.net,soa:example.net,soa:example.org,soa:example.com 0.0.0.0 ns3.example.net # noconn ssh dig=soa:anotherexample.com group virtual 0.0.0.0 ns5.example.net # noconn ssh ntp dig=soa:other.net,soa:example.net,soa:example.org,soa:example.com 0.0.0.0 ns6.example.net # noconn ssh ntp dig=soa:other.net,soa:example.net,soa:example.org,soa:example.com ns1 fails and does not poll. ns3, ns5, and ns6 work fine. ns1 isn¹t a real server it¹s a load-balancer in front of ns5 and ns6. So it doesn¹t have any other services that could be polled. All of the ns names resolve properly in DNS. Any ideas? Helpful debug flags to turn on so that it spits out logfiles about why it is not sending any probes? -- Daniel J McDonald, CCISSP # 78281

1 0

MQ monitoring on Windows
by Neil.Simmonds＠express-gifts.co.uk 09 Jan '14

09 Jan '14

I've been working on getting MQ monitoring on Windows working. I've got a bat file that is running and creating a file for the MQ Queue data however I'm not seeing the data in Xymon. I have got a MQ column on the server in question but all it shows is the word "data". I'm pretty sure this is something to do with the data format but I can't see what. If I look at the file on a Linux box before it is sent to Xymon it looks like this, client ukclapimprb01.mqcollect mqcollect 5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED. Starting MQSC for queue manager PBKR01. My file on the Windows box before it is dropped into the tmp directory looks like this, client ukaccmtx001.mqcollect mqcollect 5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED. Starting MQSC for queue manager PMTX01. However, when I display client data from the two servers on Xymon the Linux one looks like this, [collector:] client ukclapimprb01.mqcollect mqcollect 5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED. Starting MQSC for queue manager PBKR01. While the Windows one looks like this, [collector:mq] status UKACCMTX001.mq client ukaccmtx001.mqcollect mqcollect 5724-H72 (C) Copyright IBM Corp. 1994, 2009. ALL RIGHTS RESERVED. Starting MQSC for queue manager PMTX01. Has anyone any idea where I'm going wrong? Regards, Neil Simmonds Senior Operations Analyst (Operations Support Group) Express Gifts Limited Express House Clayton Business Park Accrington Lancashire BB5 5JY T: 01254 303092 | E: neil.simmonds at Express-Gifts.co.uk<mailto:neil.simmonds at Express-Gifts.co.uk> Name & Registered Office: EXPRESS GIFTS LIMITED, 2 GREGORY ST, HYDE, CHESHIRE, ENGLAND, SK14 4TH, Company No. 00718151. Express Gifts Limited is authorised and regulated by the Financial Services Authority -------------- NOTE: This email and any information contained within or attached in a separate file is confidential and intended solely for the Individual to whom it is addressed. The information or data included is solely for the purpose indicated or previously agreed. Any information or data included with this e-mail remains the property of Findel PLC and the recipient will refrain from utilising the information for any purpose other than that indicated and upon request will destroy the information and remove it from their records. Any views or opinions presented are solely those of the author and do not necessarily represent those of Findel PLC. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. No warranties or assurances are made in relation to the safety and content of this e-mail and any attachments. No liability is accepted for any consequences arising from it. Findel Plc reserves the right to monitor all e-mail communications through its internal and external networks. If you have received this email in error please notify our IT helpdesk on +44(0) 1254 303030

1 0

Custom graph and TRENDS in hosts.cfg
by john.thurston＠alaska.gov 09 Jan '14

09 Jan '14

I have a couple of .rrd files for a host: dio.1.rrd dio.2.rrd I am confident they have valid data and that Xymon is able to graph their contents. If I add "dio" to the the "GRAPHS" line in xymonserver.cfg, the chart is available on the "trends" page along with the "tcp" chart. If I then add "TRENDS:*,!tcp" to the host's line in hosts.cfg, the "tcp" chart disappears and the "dio" chart is still available. If I change it to "TRENDS:*,!dio" the "tcp" chart returns and the "dio" chart disappears. What I'd really like is to not have this chart included on every host's "trends" page, but to have it only on a few. I thought I could do this by putting it only in the hosts.cfg for those specific hosts. But.... If I remove "dio" from the "GRAPHS" line and add "TRENDS:*,dio" to the host's line in the hosts.cfg, the "tcp" chart is shown but the the "dio" chart is not. I can suppress the chart but not display it. What am I dong wrong? -- 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

1 0

Xymon 4.3.13 is out
by henrik＠hswn.dk 08 Jan '14

08 Jan '14

Version 4.3.13 landed on Sourceforge a few minutes ago, marking the beginning of the new year. You can grab it at http://sourceforge.net/projects/xymon/files/latest/download Preparations for a release of version 5 is underway, the current code is now running at http://beta.xymon.com/ Regards, Henrik

8 10