[Xymon] sepparated disk alerts

[Adam Goryachev]

On 20/02/13 15:00, Aiquen wrote:
> 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.

Perhaps the feature request could be along the following lines...

It is currently possible to add a &<color> to a status message,
generally this is done at the beginning of some of the lines to indicate
the status of that component, this can be seen in the procs column for
example.

It would be helpful to be able to disable the individual line instead of
the entire procs status, something like:
somehost.procs.crond

Where the value "crond" is the first "word" after the &red. This would
allow the column procs to have a overall status of green (or blue),
until the disabled expires, or another line of the procs changes to red.

In the meantime, you could implement this on the hobbit server by
listening to the client reports being sent in, and parsing/processing
the disk column as required, and then setting the color for that column
as needed.

This is probably a pretty involved job, especially to generalise it to
the point it can be useful for any column, and for more than one reason,
but it definitely could add a lot of value. procs, disk, ports are just
a few columns that are very overloaded (ie, one column but relate to
many services/meanings), it is not helpful to have 100 columns per host,
but it is helpful to be able to control enable/disable, alerts, and
similar based on these columns.

Just my thoughts on this, perhaps it will give someone inclined to write
some code some ideas... At the end of the day, I'd suggest the only way
to get this feature added (unless Henrik wants it himself) is to write
the code, and submit it. That way it is easy to add the code (as long as
it doesn't change things in an incompatible way).

Regards,
Adam

-- 
Adam Goryachev
Website Managers
www.websitemanagers.com.au