[PR] MINOR: connection: add TCP keep-alive parameters
Dear list! Author: Sven Ulland Number of patches: 1 This is an automated relay of the Github pull request: MINOR: connection: add TCP keep-alive parameters Patch title(s): MINOR: connection: add TCP keep-alive parameters Link: https://github.com/haproxy/haproxy/pull/252 Edit locally: wget https://github.com/haproxy/haproxy/pull/252.patch && vi 252.patch Apply locally: curl https://github.com/haproxy/haproxy/pull/252.patch | git am - Description: Add configuration parameters to control TCP keep-alives: * tcp- keepalive-time: Idle time before keep-alive probes are sent * tcp- keepalive-interval: Interval between keep-alive probes * tcp- keepalive-count: Number of keep-alive probes to send before giving up Tested with TCP and HTTP, and with different settings in the default, listen, frontend and backend sections. Potential issues: * Only tested on Linux. * Darwin `#ifdef TCP_KEEPALIVE` implemented but untested. * No Windows support. Rationale: * HAProxy only allows enabling/disabling TCP keep- alives; not controlling parameters. * System default parameters controllable using sysctl. * System defaults apply to all connections. Default idle time: 7200 seconds, as required by RFC 1122. * The `sysctl` command does not work on Docker containers due to read- only procfs. * The Docker `privileged` flag could have worked, but is unsupported on AWS Fargate. * The Docker `sysctl` flag could have worked, but is unsupported on AWS Fargate. * The Docker Linux capability flags could have worked, but are unsupported on AWS Fargate. * I'm behind a Cisco Meraki NAT gateway that has a fixed TCP NAT timeout of 300 seconds, meaning connections are dropped before the TCP keep-alive idle time kicks in (default 7200 seconds on Linux). Meraki support confirms the fixed 300 second timeout. * Instead of requiring all clients to increase the TCP keep-alive probe frequency, fix it centrally by enabling parameters in HAProxy. Instructions: This github pull request will be closed automatically; patch should be reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is invited to comment, even the patch's author. Please keep the author and list CCed in replies. Please note that in absence of any response this pull request will be lost.
Re: RFC uuid for log-format
Hello Luca, On Tue, 3 Sep 2019 at 09:18, Schimweg, Luca wrote: > > Hey, > > > > for one use case I have, I would need a variable like %uuid in log-formats, > which just generates a random UUID. The use-case would be, to be able > to set the unique-id-format to this uuid, so that we can have a random uuid > set as request-id for any incoming request. Right now, it’s quite difficult to > get a random and unique request-id, the random uuid approach would > definitely help with that. I assume the rand [1] does not suffice. In this case, I'd suggest to use LUA for this, maybe by using some library like lua-resty-jit-uuid [2]. Lukas [1] https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#7.3.2-rand [2] https://github.com/thibaultcha/lua-resty-jit-uuid
RFC uuid for log-format
Hey, for one use case I have, I would need a variable like %uuid in log-formats, which just generates a random UUID. The use-case would be, to be able to set the unique-id-format to this uuid, so that we can have a random uuid set as request-id for any incoming request. Right now, it’s quite difficult to get a random and unique request-id, the random uuid approach would definitely help with that. Best regards Luca
Re: RFC uuid for log-format
I would be open to implement this feature, as it is currently not possible to implement this behavior (at least afaik). Would there be interest in such a feature from the community? From: "Schimweg, Luca" Date: Tuesday, 3. September 2019 at 09:19 To: "haproxy@formilux.org" Subject: [CAUTION] RFC uuid for log-format Hey, for one use case I have, I would need a variable like %uuid in log-formats, which just generates a random UUID. The use-case would be, to be able to set the unique-id-format to this uuid, so that we can have a random uuid set as request-id for any incoming request. Right now, it’s quite difficult to get a random and unique request-id, the random uuid approach would definitely help with that. Best regards Luca
Re: RFC uuid for log-format
Hey, thanks for mentioning rand, I didn't know about it... With some rand()s I was able to generate a UUID, I'll have to do some performance checks, but I think it will be fair enough. Then we don't need a %uuid or similar from my point of view. Thanks, Luca On 03.09.19, 10:34, "li...@ltri.eu on behalf of Lukas Tribus" wrote: Hello Luca, On Tue, 3 Sep 2019 at 09:18, Schimweg, Luca wrote: > > Hey, > > > > for one use case I have, I would need a variable like %uuid in log-formats, > which just generates a random UUID. The use-case would be, to be able > to set the unique-id-format to this uuid, so that we can have a random uuid > set as request-id for any incoming request. Right now, it’s quite difficult to > get a random and unique request-id, the random uuid approach would > definitely help with that. I assume the rand [1] does not suffice. In this case, I'd suggest to use LUA for this, maybe by using some library like lua-resty-jit-uuid [2]. Lukas [1] https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#7.3.2-rand [2] https://github.com/thibaultcha/lua-resty-jit-uuid
Re: RFC uuid for log-format
Hi, On Tue, 2019-09-03 at 14:07 +, Schimweg, Luca wrote: > thanks for mentioning rand, I didn't know about it... With some > rand()s I was able to generate a UUID, I'll have to do some > performance checks, but I think it will be fair enough. Then we don't > need a %uuid or similar from my point of view. FWIW, we use (among others) %Ts (timestamp), %pid (PID b/c multi- process setup), %rc (retry count), and %rt (session request counter), which produces some reasonably unique id, though our constraint is only for it to be (mostly) unique across one server. You can also throw in the server IP or name of course. Cheers, Conrad > > Thanks, > Luca > > On 03.09.19, 10:34, "li...@ltri.eu on behalf of Lukas Tribus" < > li...@ltri.eu> wrote: > > Hello Luca, > > On Tue, 3 Sep 2019 at 09:18, Schimweg, Luca < > luca.schim...@sap.com> wrote: > > > > Hey, > > > > > > > > for one use case I have, I would need a variable like %uuid in > log-formats, > > which just generates a random UUID. The use-case would be, to > be able > > to set the unique-id-format to this uuid, so that we can have a > random uuid > > set as request-id for any incoming request. Right now, it’s > quite difficult to > > get a random and unique request-id, the random uuid approach > would > > definitely help with that. > > I assume the rand [1] does not suffice. In this case, I'd suggest > to > use LUA for this, maybe by using some library like lua-resty-jit- > uuid > [2]. > > > Lukas > > [1] > https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#7.3.2-rand > [2] https://github.com/thibaultcha/lua-resty-jit-uuid > > -- Conrad Hoffmann Systems and Traffic Engineering SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany Managing Director: Artem Fishman | Incorporated in England & Wales with Company No. 6343600 | Local Branch Office | AG Charlottenburg | HRB 110657B
Re: RFC uuid for log-format
Hey, we are using a similar procedure right now, but we got the requirement to use the format of, or similar to, a uuid. Best regards, Luca From: Conrad Hoffmann Sent: Tuesday, September 3, 2019 4:45:57 PM To: Schimweg, Luca ; Lukas Tribus Cc: haproxy@formilux.org Subject: Re: RFC uuid for log-format Hi, On Tue, 2019-09-03 at 14:07 +, Schimweg, Luca wrote: > thanks for mentioning rand, I didn't know about it... With some > rand()s I was able to generate a UUID, I'll have to do some > performance checks, but I think it will be fair enough. Then we don't > need a %uuid or similar from my point of view. FWIW, we use (among others) %Ts (timestamp), %pid (PID b/c multi- process setup), %rc (retry count), and %rt (session request counter), which produces some reasonably unique id, though our constraint is only for it to be (mostly) unique across one server. You can also throw in the server IP or name of course. Cheers, Conrad > > Thanks, > Luca > > On 03.09.19, 10:34, "li...@ltri.eu on behalf of Lukas Tribus" < > li...@ltri.eu> wrote: > > Hello Luca, > > On Tue, 3 Sep 2019 at 09:18, Schimweg, Luca < > luca.schim...@sap.com> wrote: > > > > Hey, > > > > > > > > for one use case I have, I would need a variable like %uuid in > log-formats, > > which just generates a random UUID. The use-case would be, to > be able > > to set the unique-id-format to this uuid, so that we can have a > random uuid > > set as request-id for any incoming request. Right now, it’s > quite difficult to > > get a random and unique request-id, the random uuid approach > would > > definitely help with that. > > I assume the rand [1] does not suffice. In this case, I'd suggest > to > use LUA for this, maybe by using some library like lua-resty-jit- > uuid > [2]. > > > Lukas > > [1] > https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#7.3.2-rand > [2] https://github.com/thibaultcha/lua-resty-jit-uuid > > -- Conrad Hoffmann Systems and Traffic Engineering SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany Managing Director: Artem Fishman | Incorporated in England & Wales with Company No. 6343600 | Local Branch Office | AG Charlottenburg | HRB 110657B
