[Xymon] sepparated disk alerts (OPEN)

[oyvind.bjorge at telenor.com]

Hi
Sorry for late response to this.
A suggestion regarding your problem with max disable time. (In this case I consider the changing of threshold to be a disabling.)
For the use of a web-gui I would create a separate configfile where I keep track of these changes.
This would have one line for all active disabled volumes with info like nodename, volume, timestamp for the disabling, and maybe a timestamp for normalizing.
This configfile could be used by the webpage so it not only gives possibility to disable volumes, but always also show the actively disabled volumes (and with a button for normalizing).
In addition you should have a small job that runs periodically and check if timestamp for normalizing has been reached, or if timestamp of disabling is older than a defined max time (ex 28 days).
Also you could create a client-test on the server checking the config-file and generate alarms to xymon based on the time.

Something in the line of this should be possible to implement without too much work without having to change anything on the clients, keeping the requirement of not forgetting them.
Than you just have to get permission from management to do these kind of changes to the server.....

- Oyvind

-----Original Message-----
From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Aiquen
Sent: 20. februar 2013 05:00
To: Asif Iqbal
Cc: xymon at xymon.com
Subject: Re: [Xymon] sepparated disk alerts

Hi
Thanks for the suggestion. Oyvind suggestion seems close to what I need. I only need to find a way to make it keep track of which nodes have their limits raised. I am not allowed to make changes to the levels of the alerts without making sure that the levels get droped down again after a certain time. This is laid down as a rule from higher ups in my company.

What Asif and Ralph suggests is also good, but would breach the rule about "NO mails may be automatically sent from xymon anywhere" that is laid down on me.

Thank you for good suggestions and sorry about saying that they don't work for me. I want to point out that these will probably technically work to solve the problem. But I am not allowed to implement them because of the set of rules I have to follow that I mentioned in my first post. That is why I called this more of a new feature request than an actual issue. Pritty much the only acceptable solution for the higher ups is that a new client is released with the feature to sepparate disk alerts based on monitored disks. And then be able do disable or raise the limit within a time boundury, since we have to be able to garantee that the alert will come back and remind us if no one lookes in to it for a certain amount of time. Maby it is worth to mention that the feature "disable until ok" is disabled from our xymon. And you cannot disable an alert for more than 28 days to make sure that no alert ever gets neglected.

Again, thank you for your time. All suggestions is apprisiated. I will try to work on something along the lines of Oyvinds suggestion.

Kind Regards
Calle Lejdbrandt

On Tue, Feb 19, 2013 at 5:02 AM, Asif Iqbal <vadud3 at gmail.com> wrote:
> On Fri, Feb 15, 2013 at 3:14 PM, Aiquen <aiqueneldar at gmail.com> wrote:
>> 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
>
> analysis.cfg
>
> HOST=myhost
> DISK /srv/database GROUP=A
> DISK /srv/important/data GROUP=B
>
> alerts.cfg
>
> GROUP=A COLOR=red
>         MAIL groupA
>
> GROUP=B COLOR=red
>         MAIL groupB
>
>
>
> This might be start.
>
>
>>
>> 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
>
>
>
> --
> Asif Iqbal
> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
_______________________________________________
Xymon mailing list
Xymon at xymon.com
http://lists.xymon.com/mailman/listinfo/xymon