July 2013 - Xymon - Xymon mailman web

xymon push notifications?
by feld＠feld.me 18 Jul '13

18 Jul '13

Does anyone happen to have a script that can take xymon alerts and push them to an android phone via Google's Cloud to Device push notifications? We're trying to find a more reliable way to notify technicians. Our on-call phone is an Android device and for a long time we used to use the email to SMS gateway, but those messages were getting throttled or just dropped/lost altogether. We then decided that maybe using Gmail would work well because Google tightly couples Gmail with the phone and the notifications are quite fast and reliable. Well, we're now discovering that Google is throttling emails to our GMail address preventing us from receiving notifications... Any suggestions or tips that you might have would be greatly appreciated. A Xymon push-notification app and a script to pipe the alerts through would probably be a quite reliable solution. I may consider investigating this myself. Thanks

4 3

How does Xymon update host config info?
by David.Mills＠ngc.com 18 Jul '13

18 Jul '13

All -- I'm trying to get a better grasp of how Xymon updates its internal structures with host configuration data from the hosts.cfg file. For example, I would have said that running "xymongen" reads the config data in hosts.cfg and immediately populates the Xymon structures, so that running "xymon ... "xymondboard"", for example, would immediately post results for a new host entered into hosts.cfg. However, I see this is not the case. I have to wait for a few minutes sometimes, before such new hosts become "visible". Can someone please explain how Xymon updates itself in this way? Thanks! david ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~ David Mills Systems Administrator Northrop Grumman (512) 873-6665

2 2

INFO Field -- Client S/W
by traxler＠lsu.edu 18 Jul '13

18 Jul '13

In the INFO web page for a host there is a field labeled Client S/W. Is this supposed to show the version of xymon client running on the host? In my case it is always blank. I went to xymon.com and saw the same thing. This started because I was interested in knowing what version of xymon each machine is running... -- Isaac Traxler AIX,Linux Admin Louisiana State University, LONI traxler at lsu.edu High Performance Computing 225-578-1923 Storage & Infrastructure

2 1

xymon MQ monitoring
by miker＠readq.com 17 Jul '13

17 Jul '13

I noticed this old message from June 2011 (http://lists.xymon.com/archive/2011-June/031906.html) and unfortunately I'm running into the same problem with MQ monitoring. I get the "client data" from the collector, but the server doesn't seem to want to do anything with it. Is this the correct syntax? And do I have to put anything else in bb-hosts to get it to work? Here's the line from analysis.cfg for my host: HOST=testmq1.readq.local MQ_QUEUE Q1 depth-warning=10 depth-critical=20 MQ_QUEUE Q2 depth-warning=10 depth-critical=20 MQ_QUEUE Q3 depth-warning=10 depth-critical=20 -- Michael Russo, ReadQ Systems Inc. 1 Whitehall Street, 16th Floor, NY NY 10004

2 1

Definitive guide for BBWin central mode?
by hobbit＠elyograg.org 16 Jul '13

16 Jul '13

Is there a definitive guide for how to configure BBWin central mode, in particular the msgs part? I'd like to know what can be specified, how to configure multiple ignore entries, how to configure host-specific sections and the win32 section, and what limitations currently exist with the 0.13 version. The documentation link on the BBWin page is invalid as it refers to a man page that predates the full name change. The man pages currently found in Xymon and the various things that I can find with Google seem to all contradict each other as far as how to actually configure analysis.cfg and other server-side config files. Help? Thanks, Shawn

1 1

Graphing issues gotcha - RESOLVED
by everett.vernon＠gmail.com 16 Jul '13

16 Jul '13

Hi all I just hit an interesting graphing issue, which I resolved, and I believe the list could benefit from. I have a custom test, http://www.xymonton.org/monitors:bb-zfs running on two hosts. Sticking to tradition, let's call them foo and bar. The test status appears fine for both hosts, with graphs for foo, but no graph for bar. The rrd file is correctly populated for both, and the graphs appeared correctly on the trends column. I eventually traced it back to the graphs.cfg definition. I had FNPATTERN zfs,(.*).rrd However, on bar, I also had a zpool called testzfs, with file systems, among them, testzfs/test1 This meant that disk (file system) monitoring was creating rrd files disk,test*zfs,*test1.rrd The defined FNPATTERN would match this file too, and was trying to graph the zfs rrd files with some of the disk rrd files. And wasn't too happy about it. To fix it, I changed the FNPATTERN definition to FNPATTERN *^*zfs,(.*).rrd And all was good. Anybody using the zfs test might want to make this change. I have updated Xymonton already, but I am guessing the same "bug" might exist in other tests too. Regards Vernon -- "Accept the challenges so that you can feel the exhilaration of victory" - General George Patton

1 0

how integrate xymonpdf into new xymon-menue
by martin.flemming＠desy.de 14 Jul '13

14 Jul '13

Hi ! I need an hint how to integrate the xymonpdf http://www.trantor.org/xymonton/doku.php/reports:xymonpdf or other entries into the new xymon-menue .. ... > * Edit '$BBHOME/server/www/menu/menu_items.js' and add two lines in > 'Reports' section like those ones (I put my scripts into $BBHOME/server/www/pdf) : > > ['Analysis PDF', '/xymon/pdf/analysis.php'], > ['Reports PDF', '/xymon/pdf/pdf.php'] didn't work ... because the menue_items.js is missing :-) i've added an entry in xymonmenu.cfg <a class="inner" href="$BBSERVERWWWURL/pdf/pdf.php">PDF Report</a> but without success :-( thanks & cheers Martin

5 9

problem with receiving bbwin data
by martin.blomdahl＠jonkopingenergi.se 13 Jul '13

13 Jul '13

Phil You are absolutely right, the maxdata does not work, but everything else do. I got at first 10MB from my DC, but after putting a lot of ignore clauses, I got It down to 1MB. So that part works. (hadent come so far previous) I have an consultant who is good on C++, I will let him have a look at it, with low priority, in August. Cheers, Martin -----Ursprungligt meddelande----- Från: Phil Crooker [mailto:Phil.Crooker at orix.com.au] Skickat: den 12 juli 2013 01:45 Till: Blomdahl, Martin; David Baldwin Kopia: xymon at xymon.com Ämne: RE: [Xymon] problem with receiving bbwin data Hi Martin, Yes, I've seen that post and used those settings and they don't work - eg I tried setting the maxdata to say 1024 bytes and the client definitely sends more than that. It is sending 80-odd MB when I've limited it to under 20K (we are generating a lot of logs at the moment). If it isn't too much trouble, could you pls try setting maxdata to a small number and see whether it is truncated on the respective msgs page? You'll have to check the local copy of clientlocal.cfg (under \tmp) to make sure it has updated. I've had to shut down the client, delete that file and then restart it to force it. cheers, Phil ________________________________________ From: Martin Blomdahl Sent: Thursday, 11 July 2013 6:43 PM To: David Baldwin; Phil Crooker Cc: xymon at xymon.com Subject: Re: [Xymon] problem with receiving bbwin data Hi Have a look at the last post in this thread http://sourceforge.net/p/bbwin/discussion/460874/thread/04a00deb/?limit=50 I have tested it, IT WORKS , and it explains HOW ! Martin ( who have been struggling with this a lot, whithout success) Phil, > Thanks, David.... Yes, I don't have clientversion.cfg either - I tried > putting in "0.13" in a file of that name in \etc, the client says it > reads it and no more error, but who knows what this does or doesn't do... > > Anyway, on to the rest. As I described in the previous email, I did > let the clientlocal.cfg update successfully. But as soon as I add the > msgs.dll agent bbwin still ignores the maxdata parameter, tries to > send everything and xymond drops the connection before completion > (this latest time at 31MB). > > Do you have this working? Does it actually reduce the size of the msgs > sent? > I have it working, but I don't actually use BBWin for event log reporting - I forward all my event logs using Snare to a central syslog server and have my own checking against that server-side - see http://xymonton.org/monitors:winevtmsgs.pl My client-local.cfg for Windows clients includes the following to filter out everything client-side. You may be able to play with the ignore rules to tune it a bit more to your needs while still reducing the size of the report. By checking the BBWin\tmp\msg.<clientname>.txt file you should see what is taking up all the space. log:eventlog_security:10240 ignore .* ignore . eventlog:security:10240 ignore handle ignore .* ignore . eventlog:System:10240 ignore .* ignore . eventlog:application:10240 ignore .* ignore . eventlog:directory service:10240 ignore .* ignore . David. > thanks, Phil > > > ---------------------------------------------------------------------- > -- > *From:* David Baldwin > *Sent:* Thursday, 11 July 2013 11:28 AM > *To:* Phil Crooker > *Cc:* xymon at xymon.com > *Subject:* Re: [Xymon] problem with receiving bbwin data > > Phil, >> Thanks for the reply. >> >> Before continuing, what is supposed to be in logfetch.status? and in >> clientversion.cfg? >> > logfetch.status will possibly only exist if you are checking any > regular logfiles - e.g. if client-local.cfg contains something like: > > [win32] > log:c:\WINDOWS\WindowsUpdate.log:20480 > > clientlocal.cfg will contain the relevant section similar to your 4 > line example below. clientversion.cfg doesn't exist on my systems > > As BBWin runs, check the size of clientlocal.cfg - if it gets wiped, > try saving the contents back again. Also, updating BBWin.cfg should > cause BBWin to run immediately without restarting the service. I > haven't played around with commenting out msgs.dll > > David. > >> So, I have one server with the msgs.dll out of the config. It has >> been running for many days with the client updating fine. I redid the >> xymon client-local.cfg, stopped bbwin, deleted \tmp\clientlocal.cfg >> and restarted it (as it wouldn't update), the \tmp\clientlocal.cfg >> now reads what the client-local has: >> >> eventlog:application:1024 >> ignore BigBrotherXymonClient >> eventlog:system:1025 >> eventlog:security:10240 >> >> I let that run a cycle, it still updates OK. I then put in the >> msgs.dll statement in BBWin.cfg; that registers and BBWin.log shows: >> >> 2013/07/11 10:42:55 [DEBUG]: [bbwinupdate]: can't open C:\Program >> Files (x86)\BBWin\etc\clientversion.cfg : The system cannot find the >> file specified. >> 2013/07/11 10:42:55 [DEBUG]: [cpu]: cpu review started >> 2013/07/11 10:42:55 [DEBUG]: [cpu]: cpu review ended >> 2013/07/11 10:42:55 [DEBUG]: [disk]: drive string A:\ >> 2013/07/11 10:42:55 [DEBUG]: [disk]: drive string C:\ >> 2013/07/11 10:42:55 [DEBUG]: [disk]: drive string D:\ >> 2013/07/11 10:42:55 [DEBUG]: [disk]: drive string E:\ >> 2013/07/11 10:42:55 [DEBUG]: [filesystem]: start >> AgentFileSystem::InitCentralMode >> 2013/07/11 10:42:55 [DEBUG]: [filesystem]: checking file C:\Program >> Files (x86)\BBWin\tmp\clientlocal.cfg >> 2013/07/11 10:42:55 [DEBUG]: [filesystem]: reading file C:\Program >> Files (x86)\BBWin\tmp\clientlocal.cfg >> 2013/07/11 10:42:55 [DEBUG]: [msgs]: start AgentMsgs::InitCentralMode >> 2013/07/11 10:42:55 [DEBUG]: [msgs]: checking file C:\Program Files >> (x86)\BBWin\tmp\clientlocal.cfg >> 2013/07/11 10:42:55 [DEBUG]: [msgs]: reading file C:\Program Files >> (x86)\BBWin\tmp\clientlocal.cfg >> 2013/07/11 10:42:55 [DEBUG]: [msgs]: will use maxdata size : 1024 >> 2013/07/11 10:42:55 [DEBUG]: [msgs]: will ignore : >> BigBrotherXymonClient >> 2013/07/11 10:42:55 [DEBUG]: [msgs]: will use maxdata size : 1025 >> 2013/07/11 10:42:55 [DEBUG]: [msgs]: will use maxdata size : 10240 >> >> and no more updates. The .\tmp\msgs.hostname.txt file is 88MB. >> >> thanks, Phil >> >> --------------------------------------------------------------------- >> --- >> *From:* Scot Kreienkamp >> *Sent:* Wednesday, 10 July 2013 10:19 PM >> *To:* David Baldwin; Phil Crooker >> *Cc:* xymon at xymon.com >> *Subject:* RE: [Xymon] problem with receiving bbwin data >> >> >> If the eventlog data being transmitted is too large to transmit until >> the clientlocal.cfg is sent back and populated in BBWin, then why not >> disable the eventlog client in BBWin until it successfully sends 2-3 >> status messages? By that time the clientlocal.cfg will be populated >> on the client and you can enable the eventlog reader again and >> everything should work fine. >> >> >> >> *Scot Kreienkamp * >> >> >> >> *From:*Xymon [mailto:xymon-bounces at xymon.com] *On Behalf Of *David >> Baldwin >> *Sent:* Wednesday, July 10, 2013 4:19 AM >> *To:* Phil Crooker >> *Cc:* xymon at xymon.com >> *Subject:* Re: [Xymon] problem with receiving bbwin data >> >> >> >> Phil, >> >> Just found a fix that works for me :) >> >> I've been having difficulties setting up the bbwin client (ver >> 0.13 going to xymon 4.3.10 server) running on win7 sp1, 2008r2 >> and win2012 boxes in central mode. I've had zero response from >> the bbwin-help forum for this, so please bear with me. >> >> >> >> For background: I can't get the bbwin client to stop sending all >> the logs, it ignores any maxdata parameters I use. Eg: >> >> >> >> eventlog:system:1024 >> >> >> >> It sends everything anyway. If I use log:system:1024, the bbwin >> client throws an error that it can't find the system log file. It >> does find the file without the maxdata parameter. >> >> >> >> >> One problem with the settings in client-local.cfg on the xymon server >> is that they only propagate to the client after a successful sending >> of a client message. The mechanics is that after the client message >> has been sent, BBWin does a shutdown on the write socket and then >> reads from the read socket until EOF. If the write socket is never >> shutdown because the server breaks the connection due to flooding, >> then the client-local.cfg section will never be sent to the client. >> >> I've previously attempted to manually create C:\Program >> Files(x86)\BBWin\tmp\clientlocal.cfg to trick it, but with limited >> success. Just played around with it again - with client reporting to >> my primary server I just got it going - previously I was reporting to >> 2 servers. The trick seems to be in having logfetch.status also >> created. I then modified my BBWin.cfg back to 2 servers and it broke >> again. Maybe the 2nd server is responding differently. It is >> undefined which server's clientlocal.cfg to believe anyway :) Swapped >> the order of the servers around and it seems stable. >> >> If the server just discarded all the flooding data beyond MAXMSG_* >> and then returned the client config section anyway maybe it could be >> made to work, but there may be good reasons why that would not be >> sensible. >> >> This aside, I do need to get this working as I have to start >> monitoring 10 new windows servers and have to monitor the event logs, >> so I can't just stop sending them as has been suggested. Yes I could >> do some powershell scripts and send them via bbwincmd but the bbwin >> client is made for this task..... >> >> >> >> So, looking at this from the other side, the xymon server appears to >> be resetting the session after about 22MB of data has been sent (I >> know, this is ludicrous, but it is windows). Nothing in the xymond >> logs (except for the occasional data flooding error ("1st line >> client", always)); on the client side it reports it can't send the >> data to the xymon server. >> >> >> >> Depending on what auditting you have enabled, 22MB is very easy to >> achieve! Turn on Security event logging including success and failure >> and it's almost guaranteed :) >> >> David. >> >> I've set the MAXMSG_* to quite silly levels: >> >> >> >> # ipcs >> >> ------ Shared Memory Segments -------- >> >> key shmid owner perms bytes >> nattch status >> >> 0x01034be7 16908288 xymon 600 102400000 2 >> >> >> 0x02034be7 16941057 xymon 600 102400000 2 >> >> >> 0x03034be7 16973826 xymon 600 102400000 2 >> >> >> 0x04034be7 17006595 xymon 600 102400000 2 >> >> >> 0x05034be7 17039364 xymon 600 262144 1 >> >> >> 0x06034be7 17072133 xymon 600 32768 1 >> >> >> 0x07034be7 17104902 xymon 600 102400000 2 >> >> >> 0x08034be7 17137671 xymon 600 102400000 2 >> >> >> 0x09034be7 17170440 xymon 600 131072 1 >> >> >> >> >> Anything up to and including this size has no effect on the problem. >> >> >> >> Looking at the tcpdump stream, the bbwin client sends data normally >> with regular ACKs from xymond till around that 22MB mark then xymond >> responds with a FIN packet, then with RST packets and the session >> shuts down. Nothing in the packets themselves indicate what the >> problem is. >> >> >> >> If anyone can help with this, please, it would be great. >> >> >> >> thanks, Phil >> >> >> -- David Baldwin - Senior Systems Administrator (Datacentres + Networks) Information and Communication Technology Services Australian Sports Commission http://ausport.gov.au Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616 david.baldwin at ausport.gov.au Leverrier Street Bruce ACT 2617 ------------------------------------------------------------------------------------- Keep up to date with what's happening in Australian sport visit http://www.ausport.gov.au This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender. ------------------------------------------------------------------------------------- _______________________________________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon ________________________________ Please consider the environment before printing this e-mail This message from ORIX Australia may contain confidential and/or privileged information. If you are not the intended recipient, any use, disclosure or copying of this message (or of any attachments to it) is not authorised. If you have received this message in error, please notify the sender immediately and delete the message and any attachments from your system. Please inform the sender if you do not wish to receive further communications by email. ORIX handles personal information according to a Privacy Policy that is consistent with the National Privacy Principles. Please let us know if you would like a copy. It is also available at www.orix.com.au<http://www.orix.com.au>

2 1

Missing etc/tasks.d directory in XyMon 4.3.11
by A.Chervonets＠cominder.eu 12 Jul '13

12 Jul '13

I had found in log-file message just after xymon server start: Cannot open directory /u01/app/xymon/product/xymon4.3.11/server/etc/tasks.d It is mentioned in etc/tasks.cfg, but was not created during install: # Include add-on modules. directory /u01/app/xymon/product/xymon4.3.11/server/etc/tasks.d Not a big deal while we do not use add-ons now, but anyway - may it it can be fixed in future versions. Best regards, Andrey Chervonets ---------------------- SIA CoMinder http://www.cominder.eu/ mobile: +371 26517848 fax: +371 66066346

1 0

alerts issue
by massimiliano.angei＠akhela.com 12 Jul '13

12 Jul '13

Hi, I'm experiencing a weird problem with mail notifications of http tests. I've got an host entry with 4 http url tested. When the check goes red (for example 1 url http get fails with timeout error) xymon sends a mail notification but the alert reports ALL GREEN! below the mail of critical event occurred (after 30 minutes the check went green and the recovered mail arrived correct) -----Original message----- From: Xymon Sent: 29 june 2013 00:35 A: Admin Subject: Xymon [17210] host:http CRITICAL (RED) green Sat Jun 29 00:34:32 2013: OK ; OK ; OK ; OK &green http://url1 <http://url1/> - OK HTTP/1.1 200 OK Content-Length: 1347 Content-Type: application/x-x509-ca-cert Last-Modified: Tue, 29 Jan 2013 08:59:31 GMT X-Powered-By: ASP.NET Date: Fri, 28 Jun 2013 22:34:33 GMT Connection: close Seconds: 0.28 &green http://url2 <http://url2/> - OK HTTP/1.1 200 OK Content-Length: 1351 Content-Type: application/x-x509-ca-cert Last-Modified: Wed, 04 Apr 2012 14:40:58 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Date: Fri, 28 Jun 2013 22:34:33 GMT Connection: close Seconds: 0.28 &green http://url3 <http://url3/> - OK HTTP/1.1 200 OK Content-Length: 1351 Content-Type: application/x-x509-ca-cert Last-Modified: Wed, 04 Apr 2012 11:28:14 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Date: Fri, 28 Jun 2013 22:34:33 GMT Connection: close Seconds: 0.59 &green http://url4 <http://url4/> - OK HTTP/1.1 200 OK Content-Length: 1421 Content-Type: application/x-x509-ca-cert Last-Modified: Wed, 04 Apr 2012 08:43:14 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Date: Fri, 28 Jun 2013 22:34:33 GMT Connection: close Seconds: 0.28 greetings, max a. Before printing, think about the environment Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

1 0