<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I'd agree that disable is intended more
as a human override about the alertability of a host+service
combo. The acknowledge functionality is more in line with what it
seems you're looking for: "It's still Yellow, still keep track of
things, but don't alert downstream unless something explicitly
wants to." <br>
<br>
If the issue is with the nongreen page, I believe there should be
a way to remove ack'd items from that page (but it might require
running a second instance of xymongen just to spit out that page,
potentially with a BOARDFILTER in there to limit it further).<br>
<br>
"Disable until Change" would be possible, but we'd need to store
the actual underlying color to compare the incoming report to,
since disabling works by overriding the color that was sent and
forcing it blue. "Unack on Change" works precisely because we
still have a meaningful current color to compare an incoming
message to.<br>
<br>
-jc<br>
<br>
<br>
On 11/2/2015 4:21 PM, Novosielski, Ryan wrote:<br>
</div>
<blockquote
cite="mid:7C64B923-0440-494E-8CEB-5136C99980DE@ca.rutgers.edu"
type="cite">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<div>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.<br>
<br>
<span style="background-color: rgba(255, 255, 255, 0);">____
*Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*<br>
|| \\UTGERS
|---------------------*O*---------------------<br>
||_// Biomedical | Ryan Novosielski - Senior Technologist<br>
|| \\ and Health | <a moz-do-not-send="true"
href="mailto:novosirj@rutgers.edu"
x-apple-data-detectors="true"
x-apple-data-detectors-type="link"
x-apple-data-detectors-result="3">novosirj@rutgers.edu</a>-
973/972.0922 (2x0922)<br>
|| \\ Sciences | OIRT/High Perf & Res Comp - MSB C630,
Newark<br>
`'</span></div>
<div><br>
On Nov 2, 2015, at 18:59, John Thurston <<a
moz-do-not-send="true" href="mailto:john.thurston@alaska.gov"><a class="moz-txt-link-abbreviated" href="mailto:john.thurston@alaska.gov">john.thurston@alaska.gov</a></a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><span>We often use "disable until ok", but it was brought
to my attention that </span><br>
<span>it has burned us from time to time. For example:</span><br>
<span></span><br>
<span>Host foo is yellow on disk. But that's ok. We're going
to allocate some </span><br>
<span>new storage for it in the next service window. The test
is marked </span><br>
<span>"disable until ok". But before the service window
arrives, something </span><br>
<span>chews up a whole bunch of disk and the now-red test
continues to be blue </span><br>
<span>because the test is not yet ok.</span><br>
<span></span><br>
<span>We sometimes use "acknowledge" for this function, but
the non-green </span><br>
<span>screen can get kind of cluttered this way.</span><br>
<span></span><br>
<span>Does anyone have a good way to fake "disable while
status remains </span><br>
<span>unchanged"?</span><span></span><br>
</div>
</blockquote>
</blockquote>
<br>
</body>
</html>