9:24 a.m.
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
3:11 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:49 p.m.
Hi Joel,
Historically we have called this "Mixed" availability, when you have
various avail states for a group of resources. Personally, I like a
percentage representation of avail, on a scale of 0..100 it's fairly
easy to understand if you are all DOWN, all UP or somewhere in between.
It can also map to a color scale pretty well. Also, historically,
we've used "not up" as opposed to "non up". Not up can be
applied to
UNKNOWN and ADMIN, which are the other two states outside of UP/DOWN.
On 8/30/2016 9:11 AM, John Sanda wrote:
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:51 p.m.
On Tue, Aug 30, 2016 at 3:11 PM, John Sanda <jsanda(a)redhat.com> wrote:
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.
You're right, it would be even better to keep a "up ratio" information for
each point. And it will still be easily reduced to a binary "all UP" or
"any UP" by the client if desired.
4:32 p.m.
After discussion with Jay:
- About the naming, we can stick to the term of "mixed" availability
(rather than "aggregated" or whatever) to keep continuity with previous
products
- The endpoint would accept query by ids or tags
- Resulting series would provide datapoints with a key/value map of ratio
per state. So states such as "unknown" and "admin" are not discarded.
More
interestingly it would also be usable with string types
On Tue, Aug 30, 2016 at 3:51 PM, Joel Takvorian <jtakvori(a)redhat.com> wrote:
On Tue, Aug 30, 2016 at 3:11 PM, John Sanda <jsanda(a)redhat.com>
wrote:
> 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.
>
You're right, it would be even better to keep a "up ratio" information for
each point. And it will still be easily reduced to a binary "all UP" or
"any UP" by the client if desired.
5:16 p.m.
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(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:39 p.m.
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(a)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(a)redhat.com>
To: "Discussions around Hawkular development" <
hawkular-dev(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:45 p.m.
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(a)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(a)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(a)redhat.com>
> To: "Discussions around Hawkular development" <
> hawkular-dev(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
6:14 p.m.
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(a)redhat.com
<mailto:jtakvori@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(a)redhat.com <mailto:miburman@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(a)redhat.com
<mailto:jsanda@redhat.com>>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org
<mailto:hawkular-dev@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(a)redhat.com <mailto:jtakvori@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(a)lists.jboss.org
<mailto:hawkular-dev@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(a)lists.jboss.org <mailto:hawkular-dev@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(a)lists.jboss.org <mailto:hawkular-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
11:21 a.m.
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(a)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(a)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(a)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(a)redhat.com>
>> To: "Discussions around Hawkular development" <
>> hawkular-dev(a)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(a)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(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>
>
_______________________________________________
hawkular-dev mailing
listhawkular-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
1:58 p.m.
Also if I go on, it probably means create new endpoints for mixed
availability. For instance:
*/availability/mixed*
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(a)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(a)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(a)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(a)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(a)redhat.com>
>>> To: "Discussions around Hawkular development" <
>>> hawkular-dev(a)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(a)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(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>
>>
>
>
> _______________________________________________
> hawkular-dev mailing
listhawkular-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2:48 p.m.
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(a)redhat.com
<mailto:theute@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(a)redhat.com <mailto:jshaughn@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(a)redhat.com <mailto:jtakvori@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(a)redhat.com <mailto:miburman@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(a)redhat.com
> <mailto:jsanda@redhat.com>>
> To: "Discussions around Hawkular development"
> <hawkular-dev(a)lists.jboss.org
> <mailto:hawkular-dev@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(a)redhat.com <mailto:jtakvori@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(a)lists.jboss.org
> <mailto:hawkular-dev@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(a)lists.jboss.org
> <mailto:hawkular-dev@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(a)lists.jboss.org
> <mailto:hawkular-dev@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(a)lists.jboss.org
> <mailto:hawkular-dev@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(a)lists.jboss.org
<mailto:hawkular-dev@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(a)lists.jboss.org
<mailto:hawkular-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:16 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)redhat.com>
>>>> To: "Discussions around Hawkular development" <
>>>> hawkular-dev(a)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(a)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(a)lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> hawkular-dev mailing
listhawkular-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>> _______________________________________________ hawkular-dev mailing
>> list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailma
>> n/listinfo/hawkular-dev
>
> _______________________________________________ hawkular-dev mailing
> list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailma
> n/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing
listhawkular-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:27 p.m.
On the client side, if I need to know have a UP/DOWN/Mixed as in legacy
use, it's as easy as that:
List<DataPoint<(Up/Down/Mixed enum)>> l =
ratioMapSeries.stream().map(ratioMap -> ratioMap.get(UP) == 1d ? UP :
(ratioMap.get(DOWN) == 1d ? DOWN : MIXED)).collect...
4:31 p.m.
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(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)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(a)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(a)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(a)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(a)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(a)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(a)redhat.com >
To: "Discussions around Hawkular development" < hawkular-dev(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________ hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________ hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
8:51 a.m.
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(a)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(a)redhat.com>
To: "Discussions around Hawkular development" <
hawkular-dev(a)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(a)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(a)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(a)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(a)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(a)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(a)redhat.com >
To: "Discussions around Hawkular development" <
hawkular-dev(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________ hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org https://lists.jboss.org/
mailman/listinfo/hawkular-dev
_______________________________________________ hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org https://lists.jboss.org/
mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:29 a.m.
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(a)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(a)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(a)redhat.com>
> To: "Discussions around Hawkular development" <
> hawkular-dev(a)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(a)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(a)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(a)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(a)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(a)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(a)redhat.com >
> To: "Discussions around Hawkular development" <
> hawkular-dev(a)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(a)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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
>
> _______________________________________________
> hawkular-dev mailing list hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
> _______________________________________________ hawkular-dev mailing
> list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailma
> n/listinfo/hawkular-dev
> _______________________________________________ hawkular-dev mailing
> list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailma
> n/listinfo/hawkular-dev
> _______________________________________________
> hawkular-dev mailing list hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
2:26 p.m.
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(a)redhat.com
<mailto:jtakvori@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(a)redhat.com <mailto:miburman@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(a)redhat.com
<mailto:jtakvori@redhat.com>>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org
<mailto:hawkular-dev@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(a)redhat.com <mailto:jshaughn@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(a)redhat.com <mailto:theute@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(a)redhat.com <mailto:jshaughn@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(a)redhat.com <mailto:jtakvori@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(a)redhat.com <mailto:miburman@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(a)redhat.com
<mailto:jsanda@redhat.com> >
To: "Discussions around Hawkular development" <
hawkular-dev(a)lists.jboss.org
<mailto:hawkular-dev@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(a)redhat.com <mailto:jtakvori@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(a)lists.jboss.org
<mailto:hawkular-dev@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(a)lists.jboss.org <mailto:hawkular-dev@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(a)lists.jboss.org <mailto:hawkular-dev@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(a)lists.jboss.org
<mailto:hawkular-dev@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(a)lists.jboss.org
<mailto:hawkular-dev@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(a)lists.jboss.org
<mailto:hawkular-dev@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(a)lists.jboss.org
<mailto:hawkular-dev@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(a)lists.jboss.org <mailto:hawkular-dev@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(a)lists.jboss.org <mailto:hawkular-dev@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(a)lists.jboss.org <mailto:hawkular-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
2:47 p.m.
On 15 Sep 2016, at 14:26, Jay Shaughnessy wrote:
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.
If it is only a different representation that is requested,
content-types
could be the solution.
Like requesting text/plain or application/json
one could request application/json+summary
or image/png
2:29 p.m.
----- Original Message -----
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")
Plenty of words we can choose from that would make sense here:
/combine
/merge
/fuse
/conjoin
/collate
/synthesize
/collapse
/coalesce
/blend
/meld
/composite
...
Just look up the words "merge" or "combine" (or other words in the
list above) in a thesaurus :)
But I think one of the ones in the list above could work, some better than others.
2:48 p.m.
On 15 Sep 2016, at 14:29, John Mazzitelli wrote:
Plenty of words we can choose from that would make sense here:
/combine
/merge
/fuse
/conjoin
/collate
/synthesize
/collapse
/coalesce
/blend
/meld
/composite
...
Rest is about *State* transfer. Verbs in the uri
are no good choices to name a state.
2:58 p.m.
Rest is about *State* transfer. Verbs in the uri
are no good choices to name a state.
Then change them to a noun :)
/combine
/combination
/merge
/amalgamation
/collate
/collation
/coalesce
/coalescence
/blend
/blend (can be a noun, too :)
/composite
/composition
Do we really follow ALL the stipulations in our REST APIs anyway?
3031
days inactive
3048
days old
21 comments
7 participants
participants (7)
-
Heiko W.Rupp -
Jay Shaughnessy -
Joel Takvorian -
John Mazzitelli -
John Sanda -
Michael Burman -
Thomas Heute