[Hawkular-dev] change to inventory metric model to store Prometheus info
Lucas Ponce
lponce at redhat.com
Fri Oct 27 05:30:02 EDT 2017
On Fri, Oct 27, 2017 at 10:50 AM, John Mazzitelli <mazz at 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/middleware_server.yaml
https://github.com/ManageIQ/manageiq/blob/master/product/live_metrics/middleware_datasource.yaml
So, a report in MiQ is defined with this miq identifiers
https://github.com/ManageIQ/manageiq/blob/master/product/charts/miq_reports/vim_perf_realtime_middleware_server.yaml
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/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/alert_profile_manager.rb
https://github.com/ManageIQ/manageiq/blob/master/app/models/middleware_performance.rb
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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20171027/7d49db60/attachment.html
More information about the hawkular-dev
mailing list