[Hawkular-dev] Availability metrics: aggregate stats series

Thu Sep 15 03:29:04 EDT 2016

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?)

See https://github.com/hawkular/hawkular-metrics/pull/597#r78810036

So Jay proposed "/set" or "/group" 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 :)
I would also propose "/merged" or "/merge" (not sure about the "d")

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.

On Mon, Sep 5, 2016 at 8:51 AM, Joel Takvorian <jtakvori at redhat.com> wrote:

> Yes, so there would be the (GET) *'/aggregate'* and the (POST)
> *'/aggregate/query'*
>
> On Fri, Sep 2, 2016 at 4:31 PM, Michael Burman <miburman at redhat.com>
> wrote:
>
>> Hi,
>>
>> 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.
>>
>>   - Micke
>>
>> ----- Original Message -----
>> From: "Joel Takvorian" <jtakvori at redhat.com>
>> To: "Discussions around Hawkular development" <
>> hawkular-dev at lists.jboss.org>
>> Sent: Friday, September 2, 2016 4:16:46 PM
>> Subject: Re: [Hawkular-dev] Availability metrics: aggregate stats series
>>
>> Ok so i can use '/aggregate' for the time being, but if someone has a
>> better idea please tell me.
>>
>> 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
>>
>> Output would be a list of DataPoint<RatioMap<AvailabilityType>>
>> RatioMap<T> being a map of <T, Double> giving the ratio. Same data
>> structure can be used for aggregated string metrics.
>>
>> Eventually the RatioMap object can contain an integer " samples " that
>> gives the number of aggregated series on that point.
>>
>> On Fri, Sep 2, 2016 at 2:48 PM, Jay Shaughnessy < jshaughn at redhat.com >
>> wrote:
>>
>>
>>
>>
>> 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.
>>
>> 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.
>>
>> On 9/2/2016 7:58 AM, Joel Takvorian wrote:
>>
>>
>>
>> Also if I go on, it probably means create new endpoints for mixed
>> availability. For instance:
>>
>> /availability/mixed
>>
>> Can you give an example of what you're thinking for params and returned
>> data?
>>
>>
>>
>>
>>
>>
>> and in case we're interested in getting stats of a mixed availability,
>> something like:
>> /availability/mixed/stats
>>
>> Parallel changes would be done for string data type.
>>
>> On Fri, Sep 2, 2016 at 11:21 AM, Thomas Heute < theute at redhat.com >
>> wrote:
>>
>>
>>
>> That sounds like a pretty useful feature to me.
>>
>> Is there any blocker or can Joel move forward ?
>>
>> On Tue, Aug 30, 2016 at 6:14 PM, Jay Shaughnessy < jshaughn at redhat.com >
>> wrote:
>>
>>
>>
>>
>> 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.
>>
>>
>> On 8/30/2016 11:45 AM, Joel Takvorian wrote:
>>
>>
>>
>> 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*
>>
>> On Tue, Aug 30, 2016 at 5:39 PM, Joel Takvorian < jtakvori at redhat.com >
>> wrote:
>>
>>
>>
>> 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.
>>
>> 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.
>>
>> Joel
>>
>> On Tue, Aug 30, 2016 at 5:16 PM, Michael Burman < miburman at redhat.com >
>> wrote:
>>
>>
>> Hi,
>>
>> 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.
>>
>> 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.
>>
>> - Micke
>>
>> ----- Original Message -----
>> From: "John Sanda" < jsanda at redhat.com >
>> To: "Discussions around Hawkular development" <
>> hawkular-dev at lists.jboss.org >
>> Sent: Tuesday, August 30, 2016 4:11:07 PM
>> Subject: Re: [Hawkular-dev] Availability metrics: aggregate stats series
>>
>> 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.
>>
>> > On Aug 29, 2016, at 3:24 AM, Joel Takvorian < jtakvori at redhat.com >
>> wrote:
>> >
>> > Hello all,
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > 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.
>> >
>> > Any objection or remark for this feature?
>> >
>> > Joel
>> > _______________________________________________
>> > hawkular-dev mailing list
>> > hawkular-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>> _______________________________________________ hawkular-dev mailing
>> list hawkular-dev at lists.jboss.org https://lists.jboss.org/mailma
>> n/listinfo/hawkular-dev
>> _______________________________________________ hawkular-dev mailing
>> list hawkular-dev at lists.jboss.org https://lists.jboss.org/mailma
>> n/listinfo/hawkular-dev
>> _______________________________________________
>> hawkular-dev mailing list hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160915/1e65731d/attachment-0001.html 