Le 19/11/2019 à 17:12, Pierre Cheynier a écrit :
* also for `check_status`, there is the case of L7STS and its associated values
that are present
in another field. Most probably it could benefit from a better representation
in a prometheus
output (thanks to labels)?
We can also export the metrics ST_F_CHECK_CODE. For the use of labels, I have no
idea. For now, the labels are static in the exporter. And I don't know if it is
pertinent to add dynamic info in labels. If so, what is your idea ? Add a "code"
label associated to the check_status metric ?
Here again, my maybe-not-so-good idea was to keep the ability to retrieve all
the
underlying details at backend level, such as:
* 100 servers are L7OK
* 1 server is L4TOUT
* 2 servers are L4CON
* 2 servers are L7STS
** 1 due to a HTTP 429
** 1 due to a HTTP 503
But this is maybe overkill in terms of complexity, we could maybe push more on
our ability to retrieve non-maint servers status.
Ok, so it is a new kind of metric. I mean, not exposed by HAProxy. It would
require an extra loop on all servers for each backend. It is probably doable for
the check_status. For the code, I don't know. Because it is not exclusive to
HTTP checks. it is also used for SMTP and LDAP checks. At the end, I think a
better idea would be to have a way to get specifics metrics in each scope and
let Prometheus handling the aggregation. This way, everyone is free to choose
how to proceed while limiting the number of metrics exported.
--
Christopher Faulet
