[Xymon] "Disable until change"
novosirj at ca.rutgers.edu
Tue Nov 3 01:21:32 CET 2015
I personally do not think using disable is a good idea for unplanned problems. For one, if you use the reporting features, you will be mixing planned and unplanned downtime together. Disable is really for times when you know exactly what is going on with the system, and alerting is not needed/someone is watching the system manually. That's my take on it anyway, and what I tell the people that work with me.
____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
|| \\UTGERS |---------------------*O*---------------------
||_// Biomedical | Ryan Novosielski - Senior Technologist
|| \\ and Health | novosirj at rutgers.edu<mailto:novosirj at rutgers.edu>- 973/972.0922 (2x0922)
|| \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
On Nov 2, 2015, at 18:59, John Thurston <john.thurston at alaska.gov<mailto:john.thurston at alaska.gov>> wrote:
We often use "disable until ok", but it was brought to my attention that
it has burned us from time to time. For example:
Host foo is yellow on disk. But that's ok. We're going to allocate some
new storage for it in the next service window. The test is marked
"disable until ok". But before the service window arrives, something
chews up a whole bunch of disk and the now-red test continues to be blue
because the test is not yet ok.
We sometimes use "acknowledge" for this function, but the non-green
screen can get kind of cluttered this way.
Does anyone have a good way to fake "disable while status remains
Do things because you should, not just because you can.
John Thurston 907-465-8591
John.Thurston at alaska.gov<mailto:John.Thurston at alaska.gov>
Enterprise Technology Services
Department of Administration
State of Alaska
Xymon mailing list
Xymon at xymon.com<mailto:Xymon at xymon.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Xymon