<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<font face="Calibri">Joel, I'm not sure I was clear about the legacy
use of 'mixed'. MIXED was actually an availability value, like
UP or DOWN, but used for a set of availability values that
contained a mix of UP, DOWN, etc. So, for a group of resources if
7 were UP, 2 were DOWN and 1 was UNKNOWN, that would have been
mixed.<br>
<br>
I'm OK with your proposed endpoints but I didn't want you to name
it that way because of history, because that's not how we used
'mixed'. If you preferred /aggregate, /set, /group or whatever,
go ahead and use that instead.</font><br>
<br>
<div class="moz-cite-prefix">On 9/2/2016 7:58 AM, Joel Takvorian
wrote:<br>
</div>
<blockquote
cite="mid:CAJo5TFnOspG=u7Owk1PxaEsWZSDxrKnFBFU90yiWGq9sWNh2RA@mail.gmail.com"
type="cite">
<div dir="ltr">Also if I go on, it probably means create new
endpoints for mixed availability. For instance:
<div><br>
</div>
<div><i>/availability/mixed</i></div>
</div>
</blockquote>
<br>
<i>Can you give an example of what you're thinking for params and
returned data?<br>
<br>
<br>
</i>
<blockquote
cite="mid:CAJo5TFnOspG=u7Owk1PxaEsWZSDxrKnFBFU90yiWGq9sWNh2RA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>and in case we're interested in getting stats of a mixed
availability, something like:</div>
<div><i>/availability/mixed/stats</i></div>
<div><br>
</div>
<div>Parallel changes would be done for string data type.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Sep 2, 2016 at 11:21 AM, Thomas
Heute <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:theute@redhat.com" target="_blank">theute@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">That sounds like a pretty useful feature to
me.
<div><br>
</div>
<div>Is there any blocker or can Joel move forward ?</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Aug 30, 2016 at 6:14
PM, Jay Shaughnessy <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jshaughn@redhat.com"
target="_blank">jshaughn@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> <br>
<font face="Calibri">Certainly you can't base
overall application health on some random
aggregate avail. It's an indicator, like so
many other things, of where problems could
lie. I don't think there is anything wrong
with a percentage as a quick indicator, from
there you'd drill down as needed. As Joel
says, it depends also on what you choose to
aggregate. When your URL response times are
degraded, likely firing alerts, you then want
to understand why. Aggregate avails could
help answer the questions. There's always
examples of how to misuse tools, a hammer can
easily break your thumb, doesn't mean hammers
are bad.<br>
<br>
</font>
<div>
<div><br>
<div>On 8/30/2016 11:45 AM, Joel Takvorian
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Just a precision because
I'm not sure if I was clear on that: the
idea is to mix series based on a list of
ids, or tags. Not *everything*</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Aug 30,
2016 at 5:39 PM, Joel Takvorian <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jtakvori@redhat.com"
target="_blank">jtakvori@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>I agree that you won't want
to mix everything, but you can
still adopt some groupings that
are meaningful, for instance
group all front-end servers into
a front-end availability series,
and all back-ends into another
series.</div>
<div><br>
</div>
<div>Moreover, once you get all
the availability as ratio, it's
easy to map to a binary
availability if it's what you're
looking for. The REST api will
provide the data, then it's up
to you to display what is the
most relevant. I think ratio
datapoints is an easy-to-use,
yet complete, information.</div>
<span><font color="#888888">
<div><br>
</div>
<div>Joel</div>
</font></span></div>
<div>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On
Tue, Aug 30, 2016 at 5:16
PM, Michael Burman <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:miburman@redhat.com"
target="_blank">miburman@redhat.com</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">Hi,<br>
<br>
So if I have 8 MySQLs, 4
primaries, 4 replicas. One
primary is down and the
replica of that set is
down as well. I request
Availability of my
datastore and I get 80%
UP. If I had two replicas
down instead, I would get
80% UP. There's a huge
difference in these
scenarios.<br>
<br>
I'm not a fan of percents
for that simple reason. Is
my service up? Yes, it's
99% up, only all the
front-end servers are
down.. ugh.<br>
<br>
- Micke<br>
<div>
<div><br>
----- Original Message
-----<br>
From: "John Sanda"
<<a
moz-do-not-send="true"
href="mailto:jsanda@redhat.com" target="_blank">jsanda@redhat.com</a>><br>
To: "Discussions
around Hawkular
development" <<a
moz-do-not-send="true"
href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a>><br>
Sent: Tuesday, August
30, 2016 4:11:07 PM<br>
Subject: Re:
[Hawkular-dev]
Availability metrics:
aggregate stats series<br>
<br>
I like the idea of
aggregated
availabilities, but I
don’t know that it can
easily be simplified
to up/down. Let’s say
we have 3 Cassandra
nodes deployed with
replication_factor =
1. If one node goes
down we are at 66%
availability.<br>
<br>
> On Aug 29, 2016,
at 3:24 AM, Joel
Takvorian <<a
moz-do-not-send="true"
href="mailto:jtakvori@redhat.com" target="_blank">jtakvori@redhat.com</a>>
wrote:<br>
><br>
> Hello all,<br>
><br>
> I'm still aiming
to add some features
to the grafana plugin.
I've started to
integrate
availabilities, but
now I'm facing a
problem when it comes
to show aggregated
availabilities ; for
example think about an
OpenShift pod that is
scaled up to several
instances.<br>
><br>
> Since
availability is
basically "up" or
"down" (or, to
simplify with the
other states such as
"unknown", say it's
either "up" or
"non-up"), I propose
to add this new
feature: availability
stats with
aggregation. The call
would be parameterized
with an aggregation
method, which would be
either "all of" or
"any of": with "all
of" we consider that
the aggregated series
is UP when all its
parts are UP.<br>
><br>
> It would require
a new endpoint since
the
AvailabilityHandler
currently only expose
stats queries with
metric id as query
parameter - not
suitable for multiple
metrics.<br>
><br>
> Any objection or
remark for this
feature?<br>
><br>
> Joel<br>
>
______________________________<wbr>_________________<br>
> hawkular-dev
mailing list<br>
> <a
moz-do-not-send="true"
href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
> <a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/hawkular-dev"
rel="noreferrer"
target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/hawkular-dev</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
hawkular-dev mailing
list<br>
<a
moz-do-not-send="true"
href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
<a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/hawkular-dev"
rel="noreferrer"
target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/hawkular-dev</a><br>
<br>
______________________________<wbr>_________________<br>
hawkular-dev mailing
list<br>
<a
moz-do-not-send="true"
href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
<a
moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/hawkular-dev"
rel="noreferrer"
target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/hawkular-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>______________________________<wbr>_________________
hawkular-dev mailing list
<a moz-do-not-send="true" href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/hawkular-dev</a>
</pre>
</blockquote>
</div></div></div>
______________________________<wbr>_________________
hawkular-dev mailing list
<a moz-do-not-send="true" href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/hawkular-dev</a>
</blockquote></div>
</div>
</div></div>
______________________________<wbr>_________________
hawkular-dev mailing list
<a moz-do-not-send="true" href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>
<a moz-do-not-send="true" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a>
</blockquote></div>
</div>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre wrap="">_______________________________________________
hawkular-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
</body></html>