MAJOR: contrib/prometheus-exporter: move health check status to labels
authorWilliam Dauchy <wdauchy@gmail.com>
Mon, 1 Feb 2021 12:11:51 +0000 (13:11 +0100)
committerChristopher Faulet <cfaulet@haproxy.com>
Mon, 1 Feb 2021 14:16:33 +0000 (15:16 +0100)
commitde3c32638925c2071a5a84cbdafe2f112d2c4261
treee846586bb76e042f3787b12dc53e41157d6b1202
parent7aa327143968ff248792dbc2ceba18101fd7ab4a
MAJOR: contrib/prometheus-exporter: move health check status to labels

this patch is a breaking change between v2.3 and v2.4: we move from
using gauge value for health check states to labels values. The diff is
quite small thanks to the preparation work from Christopher to allow
more flexibility in labels, see commit
5a2f938732126f43bbf4cea5482c01552b0d0314 ("MEDIUM:
contrib/prometheus-exporter: Use dynamic labels instead of static ones")

this is a follow up of commit c6464591a365bfcf509b322bdaa4d608c9395d75
("MAJOR: contrib/prometheus-exporter: move ftd/bkd/srv states to
labels"). The main goal being to be better aligned with prometheus use
cases in terms of queries. More specifically to health checks, Pierre C.
mentioned the possible quirks he had to put in place in order to make
use of those metrics through prometheus:

  <aggregator_function> by(proxy, check_status) (count_values by(proxy,
  instance) ("check_status", haproxy_server_check_status))

I am perfectly aware this introduces a lot more metrics but I don't see
how we can improve the usability without it. The main issue remains in
the cardinality of the states which are > 20. Prometheus recommends to
stay below a cardinality of 10 for a given metric but I consider our
case very specific, because highly linked to the level of precision
haproxy exposes.

Even before this patch I saw several large production setup (a few
hundreds of MB in output) which are making use of the scope parameter to
simply ignore the server metrics, so that the scrapping can be faster,
and memory consumed on client side not too high. So I believe we should
eventually continue in that direction and offer more granularity of
filtering of the output. That being said it is already possible to
filter out the data on prometheus client side.

this is related to github issue #1029

Signed-off-by: William Dauchy <wdauchy@gmail.com>
contrib/prometheus-exporter/README
contrib/prometheus-exporter/service-prometheus.c