<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<font face="Calibri">Instead of approaching it from the perspective
of reporting on avail from a set or group of several entities, you
could also approach it from the resulting data, which is
basically like a /summary of the avail type /percentages. Or a
/rollup to generate a /pie /chart. I don't know, just some ideas,
I'm OK with whatever you choose.<br>
<br>
<br>
</font>
<div class="moz-cite-prefix">On 9/15/2016 3:29 AM, Joel Takvorian
wrote:<br>
</div>
<blockquote
cite="mid:CAJo5TFktaO=JN0__HwiP60rn00yStj_2NWEd1AadMxm7ym9gHQ@mail.gmail.com"
type="cite">
<div dir="ltr">According the Stephen we need to find another word
than "aggregate" for the REST path, as it will be used for
something else (and BTW, what is it for? Is there really no
connection with multiple series aggregation?)
<div><br>
</div>
<div>See <a moz-do-not-send="true"
href="https://github.com/hawkular/hawkular-metrics/pull/597#r78810036">https://github.com/hawkular/hawkular-metrics/pull/597#r78810036</a><br>
<div><br>
</div>
<div>So Jay proposed "<span
style="color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,"segoe
ui",roboto,helvetica,arial,sans-serif,"apple
color emoji","segoe ui emoji","segoe
ui symbol";font-size:14px;line-height:21px">/set" or
"/group"</span> earlier. I'm not very good at finding
words but it's important especially for a REST API. If
someone has a good idea please tell :)</div>
</div>
<div>I would also propose "/merged" or "/merge" (not sure about
the "d")</div>
<div><br>
</div>
<div>To sum up the idea here, is to take several availability
series and merge them into a single one ; but the resulting
series' data model is not exactly the same as an availability
series since it contains a ratio map like {up: 0.9, down: 0.1}
for each data point.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Sep 5, 2016 at 8:51 AM, 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">Yes, so there would be the (GET) <i>'/aggregate'</i> and
the (POST) <i>'/aggregate/query'</i></div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Sep 2, 2016 at 4:31
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>
If you create some new endpoints, you must have
them in pure-REST-form in the first place. The
/query format should follow afterwards, if it's
necessary at all.<br>
<span><br>
- Micke<br>
<br>
----- Original Message -----<br>
</span><span>From: "Joel Takvorian" <<a
moz-do-not-send="true"
href="mailto:jtakvori@redhat.com"
target="_blank">jtakvori@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>
</span>
<div>
<div>Sent: Friday, September 2, 2016 4:16:46 PM<br>
Subject: Re: [Hawkular-dev] Availability
metrics: aggregate stats series<br>
<br>
Ok so i can use '/aggregate' for the time
being, but if someone has a better idea please
tell me.<br>
<br>
The input query would be basically same as the
existing query request on (POST) /raw/query :
list of ids, start, end, limit, order ; and
eventually 'tags' also<br>
<br>
Output would be a list of
DataPoint<RatioMap<Availabilit<wbr>yType>><br>
RatioMap<T> being a map of <T,
Double> giving the ratio. Same data
structure can be used for aggregated string
metrics.<br>
<br>
Eventually the RatioMap object can contain an
integer " samples " that gives the number of
aggregated series on that point.<br>
<br>
On Fri, Sep 2, 2016 at 2:48 PM, Jay
Shaughnessy < <a moz-do-not-send="true"
href="mailto:jshaughn@redhat.com"
target="_blank">jshaughn@redhat.com</a> >
wrote:<br>
<br>
<br>
<br>
<br>
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.<br>
<br>
On 9/2/2016 7:58 AM, Joel Takvorian wrote:<br>
<br>
<br>
<br>
Also if I go on, it probably means create new
endpoints for mixed availability. For
instance:<br>
<br>
/availability/mixed<br>
<br>
Can you give an example of what you're
thinking for params and returned data?<br>
<br>
<br>
<br>
<br>
<br>
<br>
and in case we're interested in getting stats
of a mixed availability, something like:<br>
/availability/mixed/stats<br>
<br>
Parallel changes would be done for string data
type.<br>
<br>
On Fri, Sep 2, 2016 at 11:21 AM, Thomas Heute
< <a moz-do-not-send="true"
href="mailto:theute@redhat.com"
target="_blank">theute@redhat.com</a> >
wrote:<br>
<br>
<br>
<br>
That sounds like a pretty useful feature to
me.<br>
<br>
Is there any blocker or can Joel move forward
?<br>
<br>
On Tue, Aug 30, 2016 at 6:14 PM, Jay
Shaughnessy < <a moz-do-not-send="true"
href="mailto:jshaughn@redhat.com"
target="_blank">jshaughn@redhat.com</a> >
wrote:<br>
<br>
<br>
<br>
<br>
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>
<br>
On 8/30/2016 11:45 AM, Joel Takvorian wrote:<br>
<br>
<br>
<br>
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*<br>
<br>
On Tue, Aug 30, 2016 at 5:39 PM, Joel
Takvorian < <a moz-do-not-send="true"
href="mailto:jtakvori@redhat.com"
target="_blank">jtakvori@redhat.com</a> >
wrote:<br>
<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
Joel<br>
<br>
On Tue, Aug 30, 2016 at 5:16 PM, Michael
Burman < <a moz-do-not-send="true"
href="mailto:miburman@redhat.com"
target="_blank">miburman@redhat.com</a> >
wrote:<br>
<br>
<br>
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>
<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>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
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><br>
______________________________<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><br>
______________________________<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><br>
______________________________<wbr>_________________<br>
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><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>
<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 class="mimeAttachmentHeader"></fieldset>
<br>
<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>
<br>
</body>
</html>