Hi Christopher,
On Thu, Feb 07, 2019 at 10:09:52PM +0100, Christopher Faulet wrote:
> Hi,
>
> This patch adds a new component in contrib. It is a Prometheus exporter for
> HAProxy.
(...)
Thanks for doing this. After reading the whole patch, I measure how
uninteresting an experience this must have been! After all, using C
to produce yet-another-format is akin to using python to write
yet-another-http-proxy :-)
I totally agree with your approach of placing it under contrib/. After
all we've already done the same with other extensions explicitly
targetting products (mod_security, mod_defender, systemd, ...).
We support standards, not products. And products which respect standards
are naturally supported via the standards, so there is indeed no reason
for opening a new can of worms by inviting $PRODUCT_OF_THE_MONTH into
src/ especially when these products change faster than our maintenance
cycle.
In my opinion the right place for a stats exporter is : outside. However
I'm well aware that our export formats are not necessarily friendly to
such exporters. For example, the fact that prometheus uses this funny
ordering forces a gateway to keep all metrics in memory before being
able to dump them. It's not cool either. We could have a long-term
approach consisting in trying to implement multiple tree walk methods
combined with a few formats so that implementing external exporters in
various languages becomes trivial. In this case such tools could provide
high quality agents to collect our metrics by default without having to
work around some limitations or constraints.
This is probably a design discussion to have for the long term here on
the list : what are the main stats export mechanisms desired in field.
I can imagine that most agents will want to poll haproxy and dump the
whole stats once in a while, some will rely on it to send a full dump
once in a while (this may already become an issue during reloads), some
might possibly want to subscribe to change notification of certain
metrics, or receive a diff from the previous dump once in a while. And
for all these variations I guess we may have to implement 2 or 3 dump
styles :
- Front -> Back -> Server -> metric
- { Front, Back, Server } -> metric
- metric: { front, back, server }
I don't know if I'm completely off or not, but I do think that those who
have experience with such tools should definitely join the discussion to
share their observations and deployment difficulties met in field.
In the mean time I think your patch should be merged, you'll get more
feedback on it this way, and it's not a critical part like HTX that
you want to be certain to be perfect before merging :-)
Thanks,
Willy
