On Wed, Jun 7, 2017 at 2:55 PM, Georg Henzler wrote:
> ...I'm happy to implement this later this evening if you have not started
> yet...
I haven't started so feel free to go for it!
I think that should cover Clint's SLING-6855 use case as well.
-Bertrand
Hi Bertrand,
sounds great, I like your suggestions.
Do we need logic to make sure only the worst sticky result is kept? It
might not be convenient to keep all sticky results, that would make
the above log very long.
I would keep one last result for WARN/CRITICAL/HEALTH_CHECK_ERROR per HC
ins
Hi Georg,
On Wed, Jun 7, 2017 at 1:01 AM, Georg Henzler wrote:
> ...We could introduce a HC property "hc.keepWarnStickyForMin" (and
> "hc.keepCriticalStickyForMin") - this can be entirely implemented in the
> impl package and would not require a new API
Ok, so you'd have to implement an HC (
Hi,
The goal is to declare health check results that remain valid for a
specified time or forever.
So I agree metrics as proposed in comment [1] cannot achieve this
(limited to 1, 5 and 15 minutes time windows). However I still think a
purely declarative approach is cleaner and will lead to
Hi,
I 've had a look at SLING-6855 that Clint contributed, and I have a
slightly different proposal.
The goal is to declare health check results that remain valid for a
specified time or forever.
For example, a quota has been tripped - warn for 30 minutes.
Or an events queue overflowed and the
