I *think* I'm almost at the point where our inventory is able to store Prometheus metric data (metric family name and labels) in our inventory. Once done, you need only query inventory to get a resource's metric data and from there you will get the Prometheus metric family+labels so you know what you need to ask Prometheus for. Currently, there is no place in our Metric domain object in inventory for this information. Right now I am putting it in that generic properties: // don't copy properties - we are using the inventory properties for P labels right now //m.getProperties().forEach((k, v) -> mb.property(k, v.toString())); // map to the Prometheus metric timeseries mb.property("hawkular.metric.family", m.getMetricFamily()); mb.properties(m.getMetricLabels()); The object "m" is the agent's own Metric object that has a generic properties map. Right now I don't think we store anything in there so that commented portion of the code is no big deal at the moment. But notice the metric family name and the metric labels are all in the same generic properties for the inventory Metric object (that's what mb is). I don't like this. It means who ever queries inventory has to strip out the "hawkular.metric.family" key from the metric generic properties - the rest of the map are the real labels. I think we should make these first-class attributes in the inventory model: mb.metricFamily(m.getMetricFamily()) mb.metricLabels(m.getMetricLabels()) Thoughts? (looking at you Joel :-) [ps. this email was sent at 5:48pm on October 26, 2017] _______________________________________________ hawkular-dev mailing list hawkular-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hawkular-dev

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.

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