[Hawkular-dev] Availability metrics: aggregate stats series
Jay Shaughnessy
jshaughn at redhat.com
Fri Sep 2 08:48:48 EDT 2016
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
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20160902/65900121/attachment-0001.html
More information about the hawkular-dev
mailing list