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