4:50 a.m.
Hey,
what internal stats of the Hawkular metrics do we currently collect?
I think Joel did some work for the C* part.
What I think we need is
- number of data points stored on a per tenant basis.
Resolution could be something like "last minute" or
"last 5 minutes" I.e. not realtime updates in the table.
- Total number of data points (i.e. sum over all tenants)
- Query stats. This is probably more complicated, as
querying on metrics that are still in some buffer is
cheaper than over 3 years of raw data.
To get started I'd go with # of queries per tenant and global
Those could perhaps be differentiated on
- raw endpoint
- stats endpoint
- What about alerting? More alert definitions certainly
need more cpu, so number of alert definitions per tenant
and total would be another pair.
- does number of fired alerts also make sense?
The idea behind those is to get some usage figures of the
shared resource "Hawkular metrics" and then to be able to
charge them back onto individual tenants e.g. inside of
OpenShift.
5:05 a.m.
What about alerting? More alert definitions certainly need more cpu, so
number of alert definitions per tenant and total would be another pair.
* does number of fired alerts also make sense?
Certainly, it could have some sense to have these figures.
These kind of data is "low hanging fruit" in the sense that adding an endpoint
to query them is straightforward.
We can add a "/count" suffix to some endpoint to get the # instead the list or a
similar.
Is there a preferred way to name the endpoint for this ?
The idea behind those is to get some usage figures of the
shared resource "Hawkular metrics" and then to be able to
charge them back onto individual tenants e.g. inside of
OpenShift.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
7:10 a.m.
Hi,
Wouldn't it make sense in Metrics deployment to just send them to
metrics? Then there's no need to create new endpoints, just fetch them
as you would any other metric (from the internal admin tenant).
- Micke
On 01/30/2017 01:05 PM, Lucas Ponce wrote:
> What about alerting? More alert definitions certainly need more
cpu, so
> number of alert definitions per tenant and total would be another pair.
> * does number of fired alerts also make sense?
>
Certainly, it could have some sense to have these figures.
These kind of data is "low hanging fruit" in the sense that adding an endpoint
to query them is straightforward.
We can add a "/count" suffix to some endpoint to get the # instead the list or
a similar.
Is there a preferred way to name the endpoint for this ?
> The idea behind those is to get some usage figures of the
> shared resource "Hawkular metrics" and then to be able to
> charge them back onto individual tenants e.g. inside of
> OpenShift.
>
> _______________________________________________
> 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:15 a.m.
C* metrics are pushed to hawkular-metrics through a dropwizard reporter,
there's no new endpoint as far as I can tell (it was mostly John's work,
actually, not mine).
Of course (and except if I'm missing something) metrics wouldn't be on a
per tenant basis here.
On Mon, Jan 30, 2017 at 2:10 PM, Michael Burman <miburman(a)redhat.com> wrote:
Hi,
Wouldn't it make sense in Metrics deployment to just send them to
metrics? Then there's no need to create new endpoints, just fetch them
as you would any other metric (from the internal admin tenant).
- Micke
On 01/30/2017 01:05 PM, Lucas Ponce wrote:
>> What about alerting? More alert definitions certainly need more cpu, so
>> number of alert definitions per tenant and total would be another pair.
>> * does number of fired alerts also make sense?
>>
> Certainly, it could have some sense to have these figures.
>
> These kind of data is "low hanging fruit" in the sense that adding an
endpoint to query them is straightforward.
>
> We can add a "/count" suffix to some endpoint to get the # instead the
list or a similar.
>
> Is there a preferred way to name the endpoint for this ?
>
>
>> The idea behind those is to get some usage figures of the
>> shared resource "Hawkular metrics" and then to be able to
>> charge them back onto individual tenants e.g. inside of
>> OpenShift.
>>
>> _______________________________________________
>> 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:37 a.m.
On 30 Jan 2017, at 15:15, Joel Takvorian wrote:
Of course (and except if I'm missing something) metrics
wouldn't be on a
per tenant basis here.
The C* stats are probably more something for the "global"
admin tenant and not for the "user tenants".
For the per-tenant datapoint and query stats, I can imagine that
they are made available on two places
- per tenant in some "reserved" space ( e.g. /_hawkular-stats )
- on the agent tenant /stats/<tenant>/
With the global ones also at the agent tenant below /stats/<tenant>/_global
or similar.
The above locations are only meant for illustration purposes. ;-)
9:12 a.m.
Not that I think this is a bad idea, but it is the first I have heard about the per tenant
metrics. Where is this feature request/requirement coming from? I’d just like some
context.
On Jan 30, 2017, at 5:50 AM, Heiko W.Rupp <hrupp(a)redhat.com>
wrote:
Hey,
what internal stats of the Hawkular metrics do we currently collect?
I think Joel did some work for the C* part.
What I think we need is
- number of data points stored on a per tenant basis.
Resolution could be something like "last minute" or
"last 5 minutes" I.e. not realtime updates in the table.
- Total number of data points (i.e. sum over all tenants)
Query stats. This is probably more complicated, as
querying on metrics that are still in some buffer is
cheaper than over 3 years of raw data.
To get started I'd go with # of queries per tenant and global
Those could perhaps be differentiated on
raw endpoint
stats endpoint
What about alerting? More alert definitions certainly
need more cpu, so number of alert definitions per tenant
and total would be another pair.
does number of fired alerts also make sense?
The idea behind those is to get some usage figures of the
shared resource "Hawkular metrics" and then to be able to
charge them back onto individual tenants e.g. inside of
OpenShift.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
9:16 a.m.
Not that I think this is a bad idea, but it is the first I have heard
about
the per tenant metrics. Where is this feature request/requirement coming
from? I’d just like some context.
Probably from OpenShift. The Hawkular OpenShift Agent (and the heapster stuff, too) stores
data per tenant where tenant is the name of the OpenShift project (aka k8s namespace).
so I'm assuming this feature would be required for some kind of "charge
back" - it can track how much metric data are stored for each OpenShift project.
9:34 a.m.
On 30 Jan 2017, at 16:16, John Mazzitelli wrote:
so I'm assuming this feature would be required for some kind of
"charge back" - it can track how much metric data are stored for each
OpenShift project.
Exactly. As I wrote:
---snip---
The idea behind those is to get some usage figures of the
shared resource "Hawkular metrics" and then to be able to
charge them back onto individual tenants e.g. inside of
OpenShift.
10:05 a.m.
I have (finally) opened https://issues.jboss.org/browse/HWKMETRICS-619
for this.
On 30 Jan 2017, at 16:12, John Sanda wrote:
Not that I think this is a bad idea, but it is the first I have heard
about the per tenant metrics. Where is this feature
request/requirement coming from? I’d just like some context.
> On Jan 30, 2017, at 5:50 AM, Heiko W.Rupp <hrupp(a)redhat.com> wrote:
>
> Hey,
>
> what internal stats of the Hawkular metrics do we currently collect?
> I think Joel did some work for the C* part.
>
> What I think we need is
> - number of data points stored on a per tenant basis.
> Resolution could be something like "last minute" or
> "last 5 minutes" I.e. not realtime updates in the table.
> - Total number of data points (i.e. sum over all tenants)
>
> Query stats. This is probably more complicated, as
> querying on metrics that are still in some buffer is
> cheaper than over 3 years of raw data.
> To get started I'd go with # of queries per tenant and global
> Those could perhaps be differentiated on
>
> raw endpoint
> stats endpoint
> What about alerting? More alert definitions certainly
> need more cpu, so number of alert definitions per tenant
> and total would be another pair.
>
> does number of fired alerts also make sense?
> The idea behind those is to get some usage figures of the
> shared resource "Hawkular metrics" and then to be able to
> charge them back onto individual tenants e.g. inside of
> OpenShift.
>
> _______________________________________________
> 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
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschäftsführer: Charles Cachera, Michael Cunningham, Michael O'Neill,
Eric Shander
2832
days inactive
2864
days old
8 comments
6 participants
participants (6)
-
Heiko W.Rupp -
Joel Takvorian -
John Mazzitelli -
John Sanda -
Lucas Ponce -
Michael Burman