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 unchanged"?
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> http://lists.xymon.com/mailman/listinfo/xymon