- Xymon - Xymon mailman web

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

upcoming release / trunk / ipv6
by s.seitz＠secretresearchfacility.com 14 Feb '13

14 Feb '13

Hi! I'm currently going to setup some "cloud" infrastructure as a training platform to get a deeper insight into very recent developments, like nested virtualization, storage failover and a lot of IPv6. Since my fellow hobbit did very well over the last couple of years, I'ld really like to stay with xymon. My question targets the proposed IPv6 capabilities in the upcoming release. Is it worth to give a try to the code in trunk? Or is it too early for resiliant statements? Also, should I expect big configuration differences between 4.3.10 and the cutting edge? Thanks for your suggestions! Cheers, - Stephan

3 2

histlog file permissions
by jtkbishop＠gmail.com 14 Feb '13

14 Feb '13

Hi. I recently noticed I'm not able to view the history log file via the web interface. I can see that when it was working the histlog files had permissions of 644. For some reason they are now written with 640 permissions and xymon is unable to display them. If I manually chmod to 644 xymon can read them. Where can we configure the permissions with which these files are written? I'm talking about the files at xymon/data/hislogs by the way. I should also mention that xymon:xymon has ownership of these files. Thanks, Jon.

5 4

Xymon Digest, Vol 25, Issue 11
by s.watkins＠nhm.ac.uk 14 Feb '13

14 Feb '13

> Message: 1 > Date: Wed, 13 Feb 2013 08:11:14 -0500 (EST) > From: "Mike Burger" <mburger at bubbanfriends.org> > To: "Jonathan Bishop" <jtkbishop at gmail.com> > Cc: xymon at xymon.com > Subject: Re: [Xymon] histlog file permissions > Message-ID: > <9606.209.43.25.133.1360761074.squirrel at www.bubbanfriends.org> > Content-Type: text/plain;charset=iso-8859-1 > > > Hi. > > > > I recently noticed I'm not able to view the history log file via the > > web interface. I can see that when it was working the histlog files > > had permissions of 644. For some reason they are now written with 640 > > permissions and xymon is unable to display them. If I manually chmod > > to 644 xymon can read them. >> >> I should also mention that xymon:xymon has ownership of these files. To me this sounds more like a user-ID problem than a file permissions problem. If the file is 644, then owner, group and world/other can read it. If file is 640, then owner and group but NOT world/other can read it. When the histlog file is 640 then your copy of xymon can't read the file. This seems to indicate that the user identity that xymon is running under is NOT the same user identity as wrote the history logfile (not even in the same group!). Check the user id for the xymond process (ps -ef | grep xymond) . I'm guessing what's happened is something like the xymon server was shutdown possibly for a reconfig or an upgrade and then it was restarted under the wrong user identity. Good luck with sorting it out, Steff ----- Steff Watkins Natural History Museum, Cromwell Road, London,SW75BD Systems programmer Email: s.watkins at nhm.ac.uk Systems Team Phone: +44 (0)20 7942 6000 opt 2 ======== "Many were increasingly of the opinion that they'd all made a big mistake in coming down from the trees in the first place. And some said that even the trees had been a bad move, and that no one should ever have left the oceans." - HHGTTG

2 1

MAPE: tweak for display of servers
by Mark.Deiss＠xerox.com 14 Feb '13

14 Feb '13

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.

2 2

QNAP
by denicoloj＠gmail.com 13 Feb '13

13 Feb '13

Xymon Users & Admins, Are there any xymon custom scripts / monitors for monitoring QNAP systems? My QNAP system is behind a private switch so I have two options: 1. Install an xymon client + any custom services scripts on the QNAP itself. (I'm not sure if this is possible as I am fairly new to QNAP systems) or 2. Install a QNAP custom xymon script / monitor on an existing xymon client(which has 1 NIC connected to the private network for qnap services and 1 NIC on the regular subnet which can communicate with the xymon server) that will run the script to probe the QNAP and then relay the results to the xymon server. If there is no such monitor for QNAP systems, I can settle for a NFS monitor since this is probably the most important service I run on the QNAP. Thanks for any help or input. * * *Joseph De Nicolo* *Secure Database Administrator * *Center for Complex Network Research <http://www.barabasilab.com>* *Northeastern University*

2 1