Hi list,
We've recently tried to switch to the native prometheus exporter, but went
quickly stopped in our initiative given the output on one of our preprod server:
$ wc -l metrics.out
1478543 metrics.out
$ ls -lh metrics.out
-rw-r--r-- 1 pierre pierre 130M nov. 15 15:33 metrics.out
This is not only due to a large setup, but essentially related to server lines,
since we extensively user server-templates for server addition/deletion at
runtime.
# backend & servers number
$ echo "show stat -1 2 -1" | sudo socat stdio /var/lib/haproxy/stats | wc -l
1309
$ echo "show stat -1 4 -1" | sudo socat stdio /var/lib/haproxy/stats | wc -l
36360
# But a lot of them are actually "waiting to be provisioned" (especially on
this preprod environment)
$ echo "show stat -1 4 -1" | sudo socat stdio /var/lib/haproxy/stats | grep
MAINT | wc -l
34113
We'll filter out the server metrics as a quick fix, and will hopefully submit
something to do it natively, but we would also like to get your feedbacks about
some use-cases we expected to solve with this native exporter.
Ultimately, one of them would be a great value-added for us: being able to
count check_status types (and their values in the L7STS case) per backend.
So, there are 3 associated points:
* it's great to have new metrics (such as
`haproxy_process_current_zlib_memory`), but we also noticed that some very
useful ones were not present due to their type, example:
[ST_F_CHECK_STATUS] = IST("untyped"),
What could be done to be able to retrieve them? (I thought about something
similar to `HRSP_[1-5]XX`, where the different check status could be defined
and counted).
* 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)?
* 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.
Thanks for your feedbacks,
Pierre
