Le 19/11/2019 à 16:48, William Dauchy a écrit :
On Tue, Nov 19, 2019 at 03:31:28PM +0100, Christopher Faulet wrote:
* 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 ?
we need to be very careful here indeed. It's not very clear in my mind
how much values we are talking about, but labels trigger the creation of
a new metric of each key/value pair. So it can quickly explode your
memory on scrapping side.
If there is different metric for each label, it is probably not the right way to
do. However, I may have wrong, I'm not a Prometheus expert, far from it :) I
will probably start by exporting metrics as present in HAProxy using a mapping
to represent the check_status.
* what about getting some backend-level aggregation of server metrics, such as
the one that was previously mentioned, to avoid retrieving all the server
metrics but still be able to get some insights?
I'm thinking about an aggregation of some fields at backend level, which was
not previously done with the CSV output.
It is feasible. But only counters may be aggregated. It may be enabled using
a parameter in the query-string. However, it is probably pertinent only when
the server metrics are filtered out. Because otherwise, Prometheus can
handle the aggregation itself.
My only fear for this point would be to make the code too complicated
and harder to maintain.
And slow down the exporter execution. Moreover, everyone will have a different
opinion on how to aggregate the stats. My first idea was to sum all servers
counters. But Pierre's reply shown me that it's not what he expects.
--
Christopher Faulet
