February 2013 - Xymon - Xymon mailman web

Library Errors on Solaris 9
by everett.vernon＠gmail.com 21 Feb '13

21 Feb '13

Hi all Encountered an interesting problem installing my Xymon client on Solaris 9. I have solved it, but it's interesting enough that I felt it was worth sharing with the list. And maybe get some feedback on other approaches. The client was compiled on Solaris 10, so I was expecting the Solaris binary compatibility thing to make it all "just work" when I copied the client to Solaris 9. But that would be too easy. :-/ Most of the binaries gave this issue. ld.so.1: /usr/local/xymon/client/bin/msgcache: fatal: *libresolv.so.2*: version `SUNW_2.2.2' not found (required by file /usr/local/xymon/client/bin/msgcache) zsh: killed /usr/local/xymon/client/bin/msgcache Looks like *libresolve.so.2* is missing The library is there # grep libresolv.so.2 /var/sadm/install/contents /usr/lib/libresolv.so=./libresolv.so.2 s none SUNWcsl */usr/lib/libresolv.so.2* f none 0755 root bin 316552 9398 1268771224 SUNWcsl /usr/lib/sparcv9/libresolv.so=libresolv.so.2 s none SUNWcslx /usr/lib/sparcv9/libresolv.so.2 f none 0755 root bin 385952 24889 1268771224 SUNWcslx And we have the LD_LIBRARY_PATH set correctly. % echo $LD_LIBRARY_PATH /opt/svrexp/dvlpr/2.2/lib:/usr/openwin/lib:*/usr/lib* :/opt/cics/lib:/opt/dcelocal/lib:/opt/encina/lib:. So I checked to see if there was another issue, and it turns out it can see libresolv.so.2, but wants a specific version. # ldd /usr/local/xymon/client/bin/msgcache libresolv.so.2 => /usr/lib/libresolv.so.2 * libresolv.so.2 (SUNW_2.2.2) => (version not found)* libsocket.so.1 => /usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 librt.so.1 => /usr/lib/librt.so.1 libc.so.1 => /usr/lib/libc.so.1 libdl.so.1 => /usr/lib/libdl.so.1 libmp.so.2 => /usr/lib/libmp.so.2 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 /usr/platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1 /usr/platform/SUNW,Sun-Fire-V240/lib/libmd5_psr.so.1 Then I recalled hearing about the LD_NOVERSION parameter you can set, which causes the the runtime linker to ignore version requirements. A bit of reading here also helped. http://docs.oracle.com/cd/E19963-01/html/819-0690/docinfo.html I added the following 2 lines to the top of the ~/client/runclient.sh script *LD_NOVERSION=1 export LD_NOVERSION* Restarted, and it all worked fine. Maybe some of the programmer types can provide us with some feedback on the correctness of this approach, or even provide a better solution, but for now, it's working. Regards Vernon -- "Accept the challenges so that you can feel the exhilaration of victory" - General George Patton

3 3

Repeat HTTP-Test for HTTP Response Time ?
by jlaidman＠rebel-it.com.au 21 Feb '13

21 Feb '13

You could probably do this by adding an alternative HTTP check such as "cont" or "post" or "httpstatus" with the same URL as for the HTTP check. J On 21 February 2013 02:30, Werner Maier <werner at maiers.de> wrote: > Hi, > > I'm trying to set up a test for HTTP Response Time. > This works ok for most things out of the box. > > Now the problem: > I have a page that will be generated and then cached > into memcache by the application on the webserver. > > I now want to record both - cached and uncached - http response times. > > I can fetch an uncached result with a special get parameter like this: > http://server/?nocache > so that is not a problem. > But for the cached content, I need to ensure that the page is > fetched two times and only record the second request response time. > (the first one might be the one that generates the page and stores > it into the cache so it might have wrong timings). > > Is there a possibility to do this with the onboard xymonnet things > or do I have to write my own test for this? > > kind regards > > Werner Maier > -- > Dipl.-Ing. Univ. Werner Maier > http://www.maiers.de/ > ______________________________**_________________ > Xymon mailing list > Xymon at xymon.com > http://lists.xymon.com/**mailman/listinfo/xymon<http://lists.xymon.com/mailman/listinfo/xymon> >

1 0

Date issue with enable/disable page on 4.3.8
by tlewick＠apsaranetworks.com 20 Feb '13

20 Feb '13

I'm running xymon 4.3.8. Recently I disabled a couple of alerts via the web-page. Two issues, first it works for a while, but then some random and pretty short time later, the page shows red again. Also, the second or third time, I just set the alert out quite a ways, like disable until February 2014, and I noticed xymon reports funky dates like the one below. Disabled until Tue Oct 19 07:48:44 1926 Is this a known bug with xymon in this verison? Thanks, T

4 5

Repeat HTTP-Test for HTTP Response Time ?
by werner＠maiers.de 20 Feb '13

20 Feb '13

Hi, I'm trying to set up a test for HTTP Response Time. This works ok for most things out of the box. Now the problem: I have a page that will be generated and then cached into memcache by the application on the webserver. I now want to record both - cached and uncached - http response times. I can fetch an uncached result with a special get parameter like this: http://server/?nocache so that is not a problem. But for the cached content, I need to ensure that the page is fetched two times and only record the second request response time. (the first one might be the one that generates the page and stores it into the cache so it might have wrong timings). Is there a possibility to do this with the onboard xymonnet things or do I have to write my own test for this? kind regards Werner Maier -- Dipl.-Ing. Univ. Werner Maier http://www.maiers.de/

1 0

sepparated disk alerts
by aiqueneldar＠gmail.com 20 Feb '13

20 Feb '13

Greetings I don't know if this is the correct forum for this question or more like it, new feature request. How ever I'm gonna post here and hope someone will point me right if this is the wrong place. For the issue at hand. At my company we use Xymon to monitor thousands of servers. And sometimes disks gets filled and thus generates an alert. Sometimes this won't get looked into for a couple of days since our clients have specified that they want to remove data themselves (and not buy more storage). And as several servers have 3 - 8 disk and/or partitions we sometimes have trouble monitoring the other disks since one is already sending an alert. Example: Server1 has 3 monitored partitions of a disk: / /srv/important/data /srv/database with the same limits on all three: 80% -> yellow alert; 90% -> red alert Then if /srv/important/data reaches 82% the client wants us to notify them and they will free up space. This normaly takes around 3 - 5 working days. But they also wants us to monitor /srv/database. And say that 1 day after /srv/important/data gets filled, /srv/database reaches 84%. That will not trigger a new alert in the non-green status view which is what we monitor. The question/request is then as this: Is there a way to get the client to report each disk/partition as a separate alert, so we can disable the alert for one disk while receiving alerts for the other disks/partions. To use the example I want to be able to temporarily set /srv/important/data in disabled mode while still getting alerts from /srv/database I know this could be solved by writing my own script for the client, but that was disapproved of from management as they want as few custom scripts to maintain as possible (we already have dozens of custom scripts). All help and feedback is appreciated, thanks. Kind regards Calle Lejdbrandt

6 6

Questions regarding installation of Xymon
by dl1025＠att.com 19 Feb '13

19 Feb '13

I am looking to install xmon on our linux server, however, our SA's will not give me root to install it. Can I install xymon without root and get it up and running? If so, is there an installation manual that I can see. When I used BigBrother, I installed everything using root and could not do it otherwise, I wonder if it is possible to install Xymon without the use of root.

3 2

sepparated disk alerts
by aiqueneldar＠gmail.com 19 Feb '13

19 Feb '13

I include the list in this response as I think it was left out by mistake. That is a good answer, and will probably help people in similar situations out. This will however not work for us as we don't use the email-functionality at all in xymon. Also this is a decision from management. So I need a solution that will show up in the non-green systems view in xymon. And also I need to get alerts based on that a filesystem changes state, not based on one disk changes state on a host as it is natively. I do know this is very specefic. But I have tried several workarounds and have been shot down from management because they want changes to the client to come upstream since the disk alert technically is working. It is just annoying for us who have to work with it this way. Kind regards Calle Lejdbrandt On Fri, Feb 15, 2013 at 10:51 PM, Mike Burger <mburger at bubbanfriends.org> wrote: > While I don't have a Xymon specific, technical answer, I do have a > suggestion, which I've put to use in other places, with other monitoring > tools. > > Send the emails to an account on the Xymon server, maybe even xymon, itself. > > For the user in question, create a .procmailrc file and make use of > Procmail's ability to filter and forward. You can then filter the alarms > based on subject and/or body content, forward out the messages that need a > response, and send the rest to /dev/null. > -- > Mike Burger > http://www.bubbanfriends.org > > "It's always suicide-mission this, save-the-planet that. No one ever just > stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1 > > >> Greetings >> >> I don't know if this is the correct forum for this question or more >> like it, new feature request. How ever I'm gonna post here and hope >> someone will point me right if this is the wrong place. >> >> For the issue at hand. At my company we use Xymon to monitor thousands >> of servers. And sometimes disks gets filled and thus generates an >> alert. Sometimes this won't get looked into for a couple of days since >> our clients have specified that they want to remove data themselves >> (and not buy more storage). And as several servers have 3 - 8 disk >> and/or partitions we sometimes have trouble monitoring the other disks >> since one is already sending an alert. >> >> Example: >> Server1 has 3 monitored partitions of a disk: >> / >> /srv/important/data >> /srv/database >> >> with the same limits on all three: 80% -> yellow alert; 90% -> red alert >> Then if /srv/important/data reaches 82% the client wants us to notify >> them and they will free up space. This normaly takes around 3 - 5 >> working days. But they also wants us to monitor /srv/database. And say >> that 1 day after /srv/important/data gets filled, /srv/database >> reaches 84%. That will not trigger a new alert in the non-green status >> view which is what we monitor. >> >> The question/request is then as this: Is there a way to get the client >> to report each disk/partition as a separate alert, so we can disable >> the alert for one disk while receiving alerts for the other >> disks/partions. To use the example I want to be able to temporarily >> set /srv/important/data in disabled mode while still getting alerts >> from /srv/database >> >> I know this could be solved by writing my own script for the client, >> but that was disapproved of from management as they want as few custom >> scripts to maintain as possible (we already have dozens of custom >> scripts). >> >> All help and feedback is appreciated, thanks. >> >> Kind regards >> Calle Lejdbrandt >> _______________________________________________ >> Xymon mailing list >> Xymon at xymon.com >> http://lists.xymon.com/mailman/listinfo/xymon >> > -- Med vänliga hälsningar Aiquen Eldar ---Blessed be by the darkness---

2 1

sepparated disk alerts (OPEN)
by oyvind.bjorge＠telenor.com 18 Feb '13

18 Feb '13

Hi, I assume that the reason for not wanting a custom-made disk-check (which would be a quick and easy fix), is based on not wanting a lot of different modification on the clients. Have you considered to make an small overbuild on the hobbit-clients.cfg? Ex. A web-gui where you can easy change from default threshold values to a specific thresholds for this node/volume? So that when you have one known problem on one volume, in steed of disabling the node/test you only increase the threshold temporary. Then the test would go green again, and you are able to react on issues on other volume and also if this volume should reach new threshold. When state is normalized you return to default values by deleting the customized rules. This could be implemented on server without the need of any changes on clients. - Oyvind -----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Aiquen Sent: 15. februar 2013 23:12 To: Mike Burger Cc: xymon at xymon.com Subject: Re: [Xymon] sepparated disk alerts I include the list in this response as I think it was left out by mistake. That is a good answer, and will probably help people in similar situations out. This will however not work for us as we don't use the email-functionality at all in xymon. Also this is a decision from management. So I need a solution that will show up in the non-green systems view in xymon. And also I need to get alerts based on that a filesystem changes state, not based on one disk changes state on a host as it is natively. I do know this is very specefic. But I have tried several workarounds and have been shot down from management because they want changes to the client to come upstream since the disk alert technically is working. It is just annoying for us who have to work with it this way. Kind regards Calle Lejdbrandt On Fri, Feb 15, 2013 at 10:51 PM, Mike Burger <mburger at bubbanfriends.org> wrote: > While I don't have a Xymon specific, technical answer, I do have a > suggestion, which I've put to use in other places, with other > monitoring tools. > > Send the emails to an account on the Xymon server, maybe even xymon, itself. > > For the user in question, create a .procmailrc file and make use of > Procmail's ability to filter and forward. You can then filter the > alarms based on subject and/or body content, forward out the messages > that need a response, and send the rest to /dev/null. > -- > Mike Burger > http://www.bubbanfriends.org > > "It's always suicide-mission this, save-the-planet that. No one ever > just stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1 > > >> Greetings >> >> I don't know if this is the correct forum for this question or more >> like it, new feature request. How ever I'm gonna post here and hope >> someone will point me right if this is the wrong place. >> >> For the issue at hand. At my company we use Xymon to monitor >> thousands of servers. And sometimes disks gets filled and thus >> generates an alert. Sometimes this won't get looked into for a couple >> of days since our clients have specified that they want to remove >> data themselves (and not buy more storage). And as several servers >> have 3 - 8 disk and/or partitions we sometimes have trouble >> monitoring the other disks since one is already sending an alert. >> >> Example: >> Server1 has 3 monitored partitions of a disk: >> / >> /srv/important/data >> /srv/database >> >> with the same limits on all three: 80% -> yellow alert; 90% -> red >> alert Then if /srv/important/data reaches 82% the client wants us to >> notify them and they will free up space. This normaly takes around 3 >> - 5 working days. But they also wants us to monitor /srv/database. >> And say that 1 day after /srv/important/data gets filled, >> /srv/database reaches 84%. That will not trigger a new alert in the >> non-green status view which is what we monitor. >> >> The question/request is then as this: Is there a way to get the >> client to report each disk/partition as a separate alert, so we can >> disable the alert for one disk while receiving alerts for the other >> disks/partions. To use the example I want to be able to temporarily >> set /srv/important/data in disabled mode while still getting alerts >> from /srv/database >> >> I know this could be solved by writing my own script for the client, >> but that was disapproved of from management as they want as few >> custom scripts to maintain as possible (we already have dozens of >> custom scripts). >> >> All help and feedback is appreciated, thanks. >> >> Kind regards >> Calle Lejdbrandt >> _______________________________________________ >> Xymon mailing list >> Xymon at xymon.com >> http://lists.xymon.com/mailman/listinfo/xymon >> > -- Med vänliga hälsningar Aiquen Eldar ---Blessed be by the darkness--- _______________________________________________ Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

1 0

MAPE: tweak for display of servers, fix for uninitialized values from hash. Timestamp errors
by Mark.Deiss＠xerox.com 18 Feb '13

18 Feb '13

On an intermittent/sporadic basis with perl v 5.14, getting an undefined key out of the map hash which causes perl uninitialized value warnings. To handle this, looks like need the following amendments (for the case of order by hosts.cfg content): foreach my $element (sort { ($map{$a}{"entryid"} || 0) <=> ($map{$b}{"entryid"} || 0) } keys %map) { next unless defined $map${element}("entryid"); .... Another suggestion is to add timestamps to the warns and die messages (and in the d_printf subroutine if someone is running that enabled....) At top of routine add: $| = 1; $SIG{__WARN__} = sub {warn sprint{"[%s] ", scalar localtime), @_}; $SIG{__DIE__} = sub {die sprint{"[%s] ", scalar localtime), @_}; From: Deiss, Mark Sent: Wednesday, February 13, 2013 12:06 PM To: 'xymon at xymon.com' Subject: MAPE: tweak for display of servers This is for MAPE 1.4 - may not be correct for 1.4+. The MAPE web page displays the server entries in a branch in a random order. The www/MAPE/bin/parse-config.pl can be adjusted so that MAPE displays the upper branches, and the servers under a branch, follow the ordering in the Xymon hosts.cfg file. Alternatively, the file can be adjusted so the MAPE displays branches and servers under a branch in alphabetical sequence. For the case of MAPE web page displaying per order of Xymon hosts.cfg entries. Need to save the entryid values into the map hash table for each entry (this change is sprinkled through parse-config.pl and not shown here), and sort on the entryid value in the drawMap subroutine via: # 2/13/13 mcd - disable original loop control #foreach my $element (keys %map) # 2/13/13 mcd - add sort on entryid in loop control - this will follow server ordering in hosts.cfg foreach my $element (sort { $map{$a}{"entryid"} <=> $map{$b}{"entryid"} } keys %map) For the second case of MAPE web page displaying levels and servers in a branch in alphabetical order. Need to sort on the name value in the drawMap subroutine via: # 2/13/13 mcd - disable original loop control #foreach my $element (keys %map) # 2/13/13 mcd - add sort on name in loop control - this will alphabetize order groups and servers # override ordering in hosts.cfg foreach my $element (sort { $map{$a}{"name"} cmp $map{$b}{"name"} } keys %map) For this latter sort, a minor tweak is also required to populate the top leaf with a "name" value. Popular root note $map{0}{"title"} = $config{"company-name"}; # Read company name from config file .... $map{0}{"entryid"} = 0; # 2/13/13 mcd - add in something for name entry $map{0}{"name"} = $config{"company-name"}; I can post the modified www/MAPE/bin/parse-config.pl that covers all of the changes if there is any interest, it's a 332 line file at the moment. Some sites may want to take this sorting another step and promote red alerts (then yellow alerts) so they are grouped at the top of the MAPE web page. Right now they are scattered around in the MAPE web display. Of course the other green servers in a branch with a red/yellow server entry would also be displayed at the top of the display but the idea is to move all red/yellow tree paths and red/yellow server leafs to the top of the display.

1 0

xymon monitoring of redis?
by betsy.schwartz＠gmail.com 15 Feb '13

15 Feb '13

Before I go reinventing the wheel or dissecting Nagios plugins, anyone got any handy scripts for redis cluster monitoring? (many other systems here:http://stackoverflow.com/questions/8614737/what-are-some-recommended-t… ) thanks Betsy

1 0