Use config file defining mapping between prometheus names/labels and k8s metrics

[discordianfish]

Hi,

there is a lot of translations involved when exposing prometheus metrics to kubernetes. These are currently hardcoded. It would be great to have a configuration file which defines this mapping explicitly, helping both maintaining it as well as understanding what is going on.

Having a config file with mapping is common among prometheus projects, e.g:

• https://github.com/prometheus/statsd_exporter#metric-mapping-and-configuration
• https://github.com/prometheus/jmx_exporter#configuration

[dobesv]

Yes, I am finding it difficult to get value out the exporter as it is because most of the stats in prometheus are not in a useful format for use in prometheus. In order for a metric to be useful for the horizontal pod autoscaler it has to be one such that adding pods will reduce that metric.

For example:

• if I use the "Object" target to scale based on the "number of open connections" on an ingress, I'll just be getting the total number of connections. What I want is the number of open connections divided by the number of pods handling those connections. Increasing the number of pods can never reduce the total number of open connections on the ingress.
• if I use the "Pods" target on a metric like "95th percentile response time", adding pods will actually reduce the response time (in theory). So, I need to transform the metric to "response time seconds per second" or something like that.

Also:

Often I do not have control over the names of the metrics exported to prometheus, so the naming conventions like the _total suffix might not help me. For example in the epimetheus metrics exporter for node.js the suffix is _sum instead.

I imagine there might be some prometheus config-fu that I could use to rename or adjust these, but it feels like this would be a lot easier if I could just write a list of prometheus queries and how to map their results to metrics.

[DirectXMan12]

This is fixed by #46

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale