8:30 a.m.
I agree with Lucas that a unique ID will help the existing model we have
for the provider. P doesn't care about this because it is designed
around the slice-and-dice grouping of querying against the metric name
and a subset of labels. We do care because we need to identify the
singleton time series (TS) for a metric name on a resource. That
equates to the set of key-value pairs that uniquely identify the TS. I
don't have a problem with merging the two suggestions. We could have
explicit, immutable fields for [family] name (String) and labels (Map).
We could also have an id (perhaps a hash of these two fields)?
By keeping the name and label (keyset) available, we would have more
flexibility for potentially using the metrics easily is some other sort
of aggregation.
On 10/27/2017 5:30 AM, Lucas Ponce wrote:
On Fri, Oct 27, 2017 at 10:50 AM, John Mazzitelli <mazz(a)redhat.com
<mailto:mazz@redhat.com>> wrote:
> I mean, what if we consider a metricId also opaque, and we know
that in P8S
> is a combination of <metric_name><labels>, at the end of the
day, is a
> string and it is unique.
>
> I ask this, because if we expose the details, it will be tempted
to start
> manipulating IDs in other layers, and perhaps that will create
technical
> debt.
Just thinking off the top of my head, Prometheus's
"family{labels}" ID is not to be considered opaque. It is
important, I think, that clients understand these because it is
how you query in Prometheus.
For example, to get a group (aggregate) metric value, you could
query on just a subset of labels thus aggregating over the labels
you did not specify.
For example, if there is:
http_requests_time{method="POST", app="my.war"} = 1.0
http_requests_time{method="POST", app="another.war"} = 1.2
http_requests_time{method="GET", app="my.war"} = 0.5
http_requests_time{method="GET", app="another.war"} = 0.6
A client (MiQ UI?) can aggregate the GET request times across all
apps by
knowing it only queries with the method label, like "average(
http_requests_time{method="GET"} )"
So therefore P metric IDs (family+labels) are not opaque - clients
need to understand them a bit.
MiQ today provides an abstraction layer (which is not perfect, but it
helps) to map miq identifiers used in MiQ reports and charts and
native metrics identifiers.
Like this:
https://github.com/ManageIQ/manageiq/blob/master/product/live_metrics/mid...
https://github.com/ManageIQ/manageiq/blob/master/product/live_metrics/mid...
So, a report in MiQ is defined with this miq identifiers
https://github.com/ManageIQ/manageiq/blob/master/product/charts/miq_repor...
The way we define the mapping between inventory and prometheus will
have an important impact in MiQ code as it will be needed to change
most of today's logic
https://github.com/ManageIQ/manageiq-providers-hawkular/blob/master/app/m...
https://github.com/ManageIQ/manageiq-providers-hawkular/blob/master/app/m...
https://github.com/ManageIQ/manageiq/blob/master/app/models/middleware_pe...
So, I'm just thinking loud with the new inventory how this will be
translated, as I guess we will still need a metric_id at least to
define the mapping, even we get benefits of the metricNames/Labels to
perform specific calculations.
In summary, I think we will need a metric_id (but perhaps the
identifier of the inventory could be enough).
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev