Re: native prometheus exporter: retrieving check_status

2019-11-28 Thread Christopher Faulet
Le 15/11/2019 à 15:55, Pierre Cheynier a écrit : * 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"), Hi Pierre, Here is a patch

RE: native prometheus exporter: retrieving check_status

2019-11-20 Thread Pierre Cheynier
>> 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

RE: native prometheus exporter: retrieving check_status

2019-11-20 Thread Pierre Cheynier
> 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

Re: native prometheus exporter: retrieving check_status

2019-11-20 Thread Christopher Faulet
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

Re: native prometheus exporter: retrieving check_status

2019-11-20 Thread Christopher Faulet
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

RE: native prometheus exporter: retrieving check_status

2019-11-19 Thread Pierre Cheynier
> Hi Pierre, Hi!, > I addressed this issue based on a William's idea. I also proposed to add a > filter to exclude all servers in maintenance from the export. Let me know if > you > see a better way to do so. For the moment, from the exporter point of view, > it > is not really hard to do

Re: native prometheus exporter: retrieving check_status

2019-11-19 Thread William Dauchy
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)?

Re: native prometheus exporter: retrieving check_status

2019-11-19 Thread Christopher Faulet
Hi Pierre, Sorry I missed you email. Thanks to William for the reminder. Le 15/11/2019 à 15:55, Pierre Cheynier a écrit : 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

native prometheus exporter: retrieving check_status

2019-11-15 Thread Pierre Cheynier
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