[Hawkular-dev] Availability metrics: aggregate stats series

Mon Sep 5 02:51:19 EDT 2016

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/
> 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/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/20160905/abdfb51a/attachment-0001.html 