January 2014 - Xymon - Xymon mailman web

Roadmap of the future Xymon releases?
by henrik＠hswn.dk 28 Jan '14

28 Jan '14

Hi Naveen, Den 2014-01-24 15:34, Naveen Kumar Venkatesh skrev: > Hi Henrik, > It seems currently the database for storing client data supports only 5 minute sample. Is it possible to increase the granularity to 1 minute? I suppose you mean the RRD files used to store cpu-, disk-, memory-trends for the graphs? You can do that today in the rrddefinitions.cfg file - but note that these settings are defined when the RRD file is created, so for all of your existing RRD files you will probably lose the data. There are some scripts floating around to convert data from existing RRD files into new files with higher granularity, but I am don't know how well they work. Of course, you must also change how often your data-collection scripts run (i.e. the client scripts and the network test tools). The 5-minute interval is currently hard-coded into the xymonclient-*.sh scripts when it comes to how vmstat data is collected, but that can be changed. It will put more load on your Xymon server, and the client will also load your servers a bit more. And your disk usage on the Xymon server will grow, since you will need to store more datapoints for each of the measurements in the RRD file. But it doesn't really require any code changes, as far as I can tell. Regards, Henrik

1 0

Receiving Duplicate Alerts
by ken.shackelford＠siemens.com 28 Jan '14

28 Jan '14

3 2

Version 4.3.14 is out
by henrik＠hswn.dk 27 Jan '14

27 Jan '14

Hi, 4.3.14 is available on Sourceforge now, carrying the fixes and enhancements that have been discussed over the past couple of weeks. Regards, Henrik <<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>> * * * Release notes for Xymon 4.3.14 * * * <<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>> In previous Xymon versions, a client-only configuration (i.e. one configured with "./configure --client") would place the client files in a "client" subdirectory below the directory specified during configuration. This is the same directory layout as a server installation, where the server and client parts of Xymon are in separate subdirectories. In 4.3.14, the default has changed so a client-only installation now installs in the directory given during the configure-step. The "/client" has been eliminated, so if you are upgrading an existing client you must either move the old client installation one level up from the "client/" directory, or change the Makefile generated by "configure --client" and add "/client" to the XYMONTOPDIR setting. The SNI support added in 4.3.13 causes problems with some older webservers, whose SSL implementation cannot handshake correctly when SNI is used. The failed handshake causes Xymon to report the site as down. In 4.3.14, the default is changed so SNI is disabled. A new "--sni" option was added to xymonnet to control the default setting, and two new tags "sni" and "nosni" can be used in hosts.cfg to control SNI for each host that is tested. <<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>> * * * Changes in Xymon 4.3.14 * * * <<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>> * Fix critical ack not working for hosts where the display-name is set (via "NAME:" tag). From Any Smith. * SNI (Server Name Indication) causes some SSL connections to fail due to server-side buggy SSL implementations. Add "sni" and "nosni" flags to control SNI for specific hosts, and "--sni" option for xymonnet to control the default. Reported by Mark Felder. * Fix build process to fully obey any XYMONTOPDIR setting from the top-level Makefile. NOTE: Client-only builds no longer install the client in a "client/" subdirectory below XYMONHOME. * Fix showgraph so it silently ignores stale rrdctl files when trying to flush RRD data before showing a graph. * Fix xymond_alert crashing when trying to strip <cr> characters from the alert message. Bug introduced in 4.3.13. * Fix Solaris client to report memory even when no swap is configured. * Fix bug where alerts that were initially suppressed due to TIME restrictions are delayed until REPEAT interval expires. * Fix crash in xymonlaunch when trying to find tasks.cfg * Fix HTML generated by acknowledge.cgi (missing '>') * Fix Linux client reporting garbled client data if top output ends without a new-line (causes CPU load and other vmstat graphs to stop updating) * Fix Debian installation so it enables Apache mod_rewrite * Fix merge-lines utility crashing when first line was an include * Fix "make install" failing when server/www/help was a symlink * Document existing OPTIONAL setting in analysis.cfg for file-checks on files which may not exist. * Document existing CLASS setting in alerts.cfg * Add new INFOCOLUMNGIF and TRENDSCOLUMNGIF settings so the icons used for these pages are configurable. * Enhance Solaris client to correctly handle Solaris zones. * Add new search facilities to xymond to select hosts with the 'xymondboard' and 'hostinfo' commands. * New --ack-each-color option for xymondd changes ack behaviour so a yellow ack does not apply when status changed to red, but a red ack applies if status goes yellow * New "headermatch" tag for http tests so content checks can look at HTTP headers in addition to the HTML body. * Use system-wide c-ares library. The pre-built Debian packages now require the "libc-ares2" package.

3 17

Breaking msgs in multiple columns for various log files monitoring
by pmalenfa＠malavix.com 26 Jan '14

26 Jan '14

Hello All, I searched the Xymon Archive without success about this. Found a few inquiries but no solutions. I would like to have multiple columns for log file monitoring. I need the exact same thing as msgs, but in many columns to alert differently. Ex: System logs -> Alert to sysadmins Application logs -> Alert to Analysts DB logs -> Alert to DBA. Having the columns named like msgs_sys / msgs_app / msgs_db would make sense to me. There may be good ext scripts for this. I tought it would be simpler to have a central setup with the msgs "style". For thoses of you that had the issue, what's your recommendation? Thanks in advance! Pierre Malenfant

4 4

c-ares
by feld＠feld.me 24 Jan '14

24 Jan '14

Is there any hope of getting xymon to compile against the system provided c-ares, or is xymon always going to bundle it? Just seems like it would be more efficient to use the system-provided c-ares if it's there...

5 9

No cpu utilization graph under openSUSE 13.1
by hj.beckers＠kreis-steinfurt.de 24 Jan '14

24 Jan '14

Running xymon 4.3.13 under openSUSE 13.1, sending data to the local server under 4.3.13 and a second xymon 4.3.12 server under openSUSE 12.3. Since the latest openSUSE 13.1 updates on monday the cpu utilization graph on both servers is no longer generated. Only difference I can see is that top 3.3.5 on openSUSE 13.1 sets a percent (%) sign in front of the "cpu(s)...." line, whereas top 3.2.8 on opensuse 12.3 doesn't. Could this confuse the rrd generation? Yours Hermann-Josef Beckers

3 6

alerting issue?
by g.stone-tolcher＠its.uq.edu.au 23 Jan '14

23 Jan '14

I have recently migrated from a large BigBrother/bbgen installation (hosts.cfg 5300 lines) to xymon 4.3.12. Surprisingly there have been very few issues. Performance is very good compared to BigBrother/bbgen. We have just experienced a potentially major issue wiith alerting. Our issue seems to be with alerts not being generated for a rule if the initial event transition to red is not within the "TIME" range for an alerting rule. An example follows of the behaviour experienced: The "http" service went down for a system "butterfly.soe.uq.edu.au" at 03:07am and recovered 3 days later: Mon Jan 20 10:14:31 2014 green 1 days 4:50:51 Fri Jan 17 03:07:44 2014 red 3 days 7:06:47 Alerting for this test is as follows: ============ alerts.cfg: $AISMAILSVCS=cifs,cont,cpu,disk,fping,http,inode,login,loginc,memory,ssh,sslcert,rtmpe,rtmps,rtmpt,svcs,xfer_proxy_c,xfer_proxy_e,xfer_proxy_k $AISSMSSVCS=cifs,cont,cpu,disk,fping,http,inode,login,loginc,memory,ssh,sslcert,rtmpe,rtmps,rtmpt,svcs $AISTFHSVCS=fping,http,login # # web/proxy/other/cert alerts # PAGE=%its-ais/ais-(web|proxy|other).* MAIL ais-web at domain SERVICE=$AISMAILSVCS DURATION>2m COLOR=red REPEAT=1w FORMAT=PLAIN RECOVERED MAIL ais-web-sms at domain SERVICE=$AISSMSSVCS DURATION>6m TIME=*:0701:2159 COLOR=red REPEAT=1w FORMAT=SMS RECOVERED ============ The "info" test output displays alerting rules as: Alerting: Service Recipient 1st Delay Stop after Repeat Time of Day Colors ais-web at domain (R) 2m 1s - 1w - red ais-web-sms at domain (R) 6m 1s - 1w *:0701:2159 red ============ The notification log displays only email alert/recovery for "ais-web at domain", nothing for "ais-web-sms at domain" recipient: Time Host Service Recipient Mon Jan 20 10:14:47 2014 butterfly.soe.uq.edu.au http ais-web at domain Fri Jan 17 03:10:29 2014 butterfly.soe.uq.edu.au http ais-web at domain No notification was sent to "ais-web-sms at domain" by the second "MAIL" rule above after it's start time of 07:01 the morning following the failure even though the "http" test was to remain red for 3 days. Manually testing the alerting rules with: ~/server/bin/xymoncmd xymond_alert --test butterfly.soe.uq.edu.au http --duration=362 indicates syntax is ok and will send both emails when tested during the 0701:2159 TIME window of the second rule: 00029580 2014-01-17 11:31:30 Matching host:service:dgroup:page 'butterfly.soe.uq.edu.au:http: Linux Servers:its-usg/usg-linux,its-ais/ais-other' against rule line 1002 00029580 2014-01-17 11:31:30 *** Match with 'PAGE=%its-ais/ais-(web|proxy|other).*' *** 00029580 2014-01-17 11:31:30 Matching host:service:dgroup:page 'butterfly.soe.uq.edu.au:http: Linux Servers:its-usg/usg-linux,its-ais/ais-other' against rule line 1003 00029580 2014-01-17 11:31:30 *** Match with 'MAIL ais-web at domain SERVICE=$AISMAILSVCS DURATION>2m COLOR=red REPEAT=1w FORMAT=PLAIN RECOVERED' *** 00029580 2014-01-17 11:31:30 Mail alert with command '/usr/bin/mutt -s "Xymon [12345] butterfly.soe.uq.edu.au:http CRITICAL (RED)" ais-web at domain' 00029580 2014-01-17 11:31:30 Matching host:service:dgroup:page 'butterfly.soe.uq.edu.au:http: Linux Servers:its-usg/usg-linux,its-ais/ais-other' against rule line 1004 00029580 2014-01-17 11:31:30 *** Match with 'MAIL ais-web-sms at domain SERVICE=$AISSMSSVCS DURATION>6m TIME=*:0701:2159 COLOR=red REPEAT=1w FORMAT=SMS RECOVERED' *** 00029580 2014-01-17 11:31:30 Mail alert with command '/usr/bin/mutt ais-web-sms at domain' Is there anything wrong with the alerting logic I have used in alerts.cfg or am I mis-understanding how it works? The BigBrother behaviour would have been to send the alert after the rule settle time at the start of the time window for the rule if an event happened prior to the start of the alerting time window. Contriving a dummy test in the hosts.cfg and alerts.cfg for an unpingable host "dummy.alerting.test" "fping". Event log for "dummy.alerting.test" "fping": Tue Jan 21 15:47:43 2014 red 0:16:12 alerts.cfg: HOST=dummy.alerting.test MAIL g.stone-tolcher at its.uq.edu.au DURATION>2m TIME=*:1600:1700 COLOR=red REPEAT=1w FORMAT=PLAIN RECOVERED Notification: Tue Jan 21 16:00:36 2014 dummy.alerting.test fping g.stone-tolcher at its.uq.edu.au<mailto:g.stone-tolcher at its.uq.edu.au> Seems to indicate that it is working similar to what is expected, i.e. send notification at start of TIME window if event is still current (ignore duration/settle time unlike bigbrother)? I do not understand why the other alert would not have occurred. Any help with this issue would be appreciated. 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

3 9

Acknowledge problem
by Jurgen.Claessens＠cegeka.be 23 Jan '14

23 Jan '14

Hello all, First of all I would like to say what a wonderful tool xymon is. I have been using it since hobbit and still am amazed at what you can do with it. Currently I'm running xymon 4.3.12 on opensuse 12.3 and I've run into a snag. I have had a yellow disk warning, but as most know, time enough to clear out disk space. However meanwhile the disk space had increased at such a rate, that it was completely full. What's the problem? Well, it never came out of acknowledgment. If it turns from yellow to red, I would expect the ack to be removed. Did anybody encounter this issue before? Is what I expect not possible? Kind regards Jurgen This e-mail and all files transmitted as attachment(s) thereto are confidential and solely intended for the individual to whom or the organization to which they are addressed. If you received this e-mail by mistake, please notify Cegeka's Service Desk at cegeka.support at cegeka.be or call +32 (0)11 240 363. We thank you in advance. Cegeka hereby confirms that this message has been swept by Sophos for the presence of viruses.

3 3

critical systems
by majones＠mnsi.net 22 Jan '14

22 Jan '14

I am trying to setup critical systems. I have one host in alarm right now and if I add it to the critical systems editor the display page is still blank. Any tips? Mark

1 0

Documentation mismatch between hosts.cfg.5.html and xymonnet.1.htm ?
by john.thurston＠alaska.gov 22 Jan '14

22 Jan '14

I spent a few minutes chasing my tail on this. It looks like the documentation has a minor discrepancy in option names for xymonnet. In hosts.cfg.5.html, ssldays=WARNDAYS:ALARMDAYS says it overrides the values taken from "--sslwarndays" and "--sslalarmdays" options for the xymonnet(1) tool. xymonnet.1.html, however, says the options for SSL certificate tests are named: --sslwarn and --sslalarm I think my testing indicates these are the correct names. If this is the case, can we have you strike the 'days' from the ends of those two options in hosts.cfg.5.html page? -- 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