<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><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 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 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 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 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 href="mailto:jsanda@redhat.com" target="_blank">jsanda@redhat.com</a>><br>
To: "Discussions around Hawkular development"
<<a 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 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 href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
> <a 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 href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
<a 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 href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
<a 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 href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org" target="_blank">hawkular-dev@lists.jboss.org</a><br>
<a 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></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
hawkular-dev mailing list<br>
<a href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/hawkular-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/hawkular-dev</a><br>
<br></blockquote></div><br></div>