<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
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)?<br>
<br>
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.<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/27/2017 5:30 AM, Lucas Ponce
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGUuq3X7kSO6EOF4Mh0+T2Z1TFZ3XB-SexrLJBdO_9uB030eKg@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Oct 27, 2017 at 10:50 AM,
John Mazzitelli <span dir="ltr"><<a
href="mailto:mazz@redhat.com" target="_blank"
moz-do-not-send="true">mazz@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><span class="gmail-">>
I mean, what if we consider a metricId also opaque, and
we know that in P8S<br>
> is a combination of
<metric_name><labels>, at the end of the
day, is a<br>
> string and it is unique.<br>
><br>
> I ask this, because if we expose the details, it
will be tempted to start<br>
> manipulating IDs in other layers, and perhaps that
will create technical<br>
> debt.<br>
<br>
</span>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.<br>
<br>
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.<br>
<br>
For example, if there is:<br>
<br>
http_requests_time{method="<wbr>POST", app="my.war"} = 1.0<br>
http_requests_time{method="<wbr>POST", app="another.war"}
= 1.2<br>
http_requests_time{method="<wbr>GET", app="my.war"} = 0.5<br>
http_requests_time{method="<wbr>GET", app="another.war"} =
0.6<br>
<br>
A client (MiQ UI?) can aggregate the GET request times
across all apps by<br>
knowing it only queries with the method label, like
"average( http_requests_time{method="<wbr>GET"} )"<br>
<br>
So therefore P metric IDs (family+labels) are not opaque -
clients need to understand them a bit.<br>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">Like this:</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><a
href="https://github.com/ManageIQ/manageiq/blob/master/product/live_metrics/middleware_server.yaml"
moz-do-not-send="true">https://github.com/ManageIQ/manageiq/blob/master/product/live_metrics/middleware_server.yaml</a><br>
</div>
<div class="gmail_extra"><a
href="https://github.com/ManageIQ/manageiq/blob/master/product/live_metrics/middleware_datasource.yaml"
moz-do-not-send="true">https://github.com/ManageIQ/manageiq/blob/master/product/live_metrics/middleware_datasource.yaml</a><br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">So, a report in MiQ is defined with
this miq identifiers</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><a
href="https://github.com/ManageIQ/manageiq/blob/master/product/charts/miq_reports/vim_perf_realtime_middleware_server.yaml"
moz-do-not-send="true">https://github.com/ManageIQ/manageiq/blob/master/product/charts/miq_reports/vim_perf_realtime_middleware_server.yaml</a><br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><a
href="https://github.com/ManageIQ/manageiq-providers-hawkular/blob/master/app/models/manageiq/providers/hawkular/middleware_manager/live_metrics_capture.rb"
moz-do-not-send="true">https://github.com/ManageIQ/manageiq-providers-hawkular/blob/master/app/models/manageiq/providers/hawkular/middleware_manager/live_metrics_capture.rb</a><br>
</div>
<div class="gmail_extra"><a
href="https://github.com/ManageIQ/manageiq-providers-hawkular/blob/master/app/models/manageiq/providers/hawkular/middleware_manager/alert_profile_manager.rb"
moz-do-not-send="true">https://github.com/ManageIQ/manageiq-providers-hawkular/blob/master/app/models/manageiq/providers/hawkular/middleware_manager/alert_profile_manager.rb</a><br>
</div>
<div class="gmail_extra"><a
href="https://github.com/ManageIQ/manageiq/blob/master/app/models/middleware_performance.rb"
moz-do-not-send="true">https://github.com/ManageIQ/manageiq/blob/master/app/models/middleware_performance.rb</a><br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">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.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">In summary, I think we will need a
metric_id (but perhaps the identifier of the inventory could
be enough).</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra"><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
hawkular-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hawkular-dev@lists.jboss.org">hawkular-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/hawkular-dev">https://lists.jboss.org/mailman/listinfo/hawkular-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>