9:36 a.m.
On Mar 20, 2015, at 9:37 AM, Heiko W.Rupp <hrupp(a)redhat.com>
wrote:
On 20 Mar 2015, at 13:55, Lukas Krejci wrote:
> tl;dr - your ideas match almost exactly what we discussed on the
> meeting ;)
Nice :-)
> completely 3rd party "reporter" or maybe such reporters would be
> hooked on the
> bus to receive "realtime" info about events and be able to compute the
> avail
> reactively.
Yes, which is in fact something I've started yesterday for pinger
status.code
to metrics
>
> Also, it was agreed that even the availability states are not
> something we can
> decide upfront. Maybe we'd provide a number of avail values with
> undefined
> meaning that only avail "reporter" would be able define or we could
> understand
> avail as "health" ranging from 0-100% and again let the avail reporter
> decide
> on a value.
We may need to distinguish here between external value and internal
computed state.
For external values, I think what you say is just a different version of
the mapping function(s) I proposed.
For internal processing, I think we need to have a set of read-made
values that we map the external ones to.
In the computed resource state email I got those:
UP: Resource is available and working normally
DEGRADED: Resource is available but not at full performance
DOWN: Resource is at fault and not working normally
MISSING: The resource was recorded in inventory, but does not exist in
reality (e.g. was deleted on file system)
ADMIN_DOWN/DISABLED: The resource exists, but was disabled by the admin
(e.g. a network interface on a 8 port card where only 1 cable is
connected)
UNKNOWN: Resource state can not be determined
MIXED: for groups / applications
And then, but which I now think should be orthogonal:
MAINTENANCE: There is a scheduled maintenance period, availability may
be UP or DOWN
>
> On metrics level, the agreement was to keep the "availability"
> endpoints to be
> able to distinguish it from "normal" metrics. But there also were
> suggestions
> to just be able to mark some metrics as run-length encoded and
> consider avail
> as an ordinary metric.
I am not convinced (yet) that availability should be recorded into
Hawkular-Metrics,
as the Metrics api is lacking the mapping functionality.
I rather think we need "Hawkular-Availability" which offers some
end-points + api
and which then defers the storage to the Hawkular-Inventory metrics
storage engine.
I suppose I am a bit biased since I work on metrics, but I do think availability should be
stored in metrics. I think that the mapping functionality belongs on the client/agent side
just as it was in RHQ. Those mapping functions should probably stored be stored in
inventory so that users can see precisely how availability is determined for a particular
type of resource and so that the user can also change how availability is calculated.