[Hawkular-dev] Availability metrics: aggregate stats series
Jay Shaughnessy
jshaughn at redhat.com
Thu Sep 15 08:26:16 EDT 2016
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.
On 9/15/2016 3:29 AM, Joel Takvorian wrote:
> 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
> <mailto: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 <mailto: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
> <mailto:jtakvori at redhat.com>>
> To: "Discussions around Hawkular development"
> <hawkular-dev at lists.jboss.org
> <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
> <mailto:jsanda at redhat.com> >
> To: "Discussions around Hawkular development" <
> hawkular-dev at lists.jboss.org
> <mailto: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 <mailto: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
> <mailto:hawkular-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
> <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
>
>
>
> _______________________________________________
> hawkular-dev mailing list hawkular-dev at lists.jboss.org
> <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> _______________________________________________ hawkular-dev
> mailing list hawkular-dev at lists.jboss.org
> <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> _______________________________________________ hawkular-dev
> mailing list hawkular-dev at lists.jboss.org
> <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
> _______________________________________________
> hawkular-dev mailing list hawkular-dev at lists.jboss.org
> <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> <https://lists.jboss.org/mailman/listinfo/hawkular-dev>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org <mailto:hawkular-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> <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/7c6642b3/attachment-0001.html
More information about the hawkular-dev
mailing list