<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">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">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">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">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">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">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">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>