Hi all, while working on some dataplaneapi fixes, I noticed that the docs for the log-balance keyword are missing in configuration.txt so sending a patch.
Regards, Marko Juraga
From 270225cec77b28195ec6bb2b19db32deeabb6840 Mon Sep 17 00:00:00 2001 From: Marko Juraga <mjur...@haproxy.com> Date: Wed, 22 Nov 2023 14:57:08 +0100 Subject: [PATCH] DOC: configuration.txt: add log-balance documentation Adding missing documentation for the newly added log-balance configuration keyword. --- doc/configuration.txt | 75 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) diff --git a/doc/configuration.txt b/doc/configuration.txt index 898fe97c8..6c6aad8c1 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -8973,6 +8973,81 @@ no log # level and send in tcp log "${LOCAL_SYSLOG}:514" local0 notice # send to local server +log-balance <algorithm> [ <arguments> ] + Define the load balancing algorithm to be used in a log backend. + ("mode log" enabled) + + May be used in sections : defaults | frontend | listen | backend + yes | no | yes | yes + Arguments : + <algorithm> is the algorithm used to select a server when doing load + balancing. This only applies when no persistence information + is available, or when a connection is redispatched to another + server. <algorithm> may be one of the following : + + roundrobin Each server is used in turns. This is the smoothest and + fairest algorithm when the server's processing time remains + equally distributed. + + sticky The first server in the list of available servers receives all + the log messages. When the server goes DOWN, the next server + in the list takes its place. When a previously DOWN server + goes back UP it is added at the end of the list so that the + sticky server doesn't change until it becomes DOWN. + + random A random number will be used as the key for the server + lookup. Random log balancing can be useful with large farms + or when servers are frequently added or removed from the + pool of available servers as it may avoid the hammering + effect that could result from roundrobin in this situation. + + hash <arguments> should be found in the form: <cnv_list> + e.g.: log-balance hash <cnv_list> + + Each log message will be passed to the converter list + specified in <cnv_list> (ie: "cnv1,cnv2..."), and it will + then be passed to haproxy hashing function according to + "hash-type" settings. The resulting hash will be used to + select the destination server among the ones declared in the + log backend. The goal of this algorithm is to be able to + extract a key within the final log message using string + converters and then be able to stick to the same server thanks + to the hash. Only "map-based" hashes are supported for now. + + <arguments> is an optional list of arguments which may be needed by some + algorithms. + + The load balancing algorithm of a log backend is set to roundrobin when + no other algorithm has been set. The algorithm may only be set once for each + log backend. The above algorithms support the "backup" server option and the + "allbackups" proxy option. However server "weight" is not supported and will + be ignored. + + Example : + + global + log backend@mylog-rrb local0 # send all logs to mylog-rrb backend + log backend@mylog-hash local0 # send all logs to mylog-hash backend + + backend mylog-rrb + mode log + log-balance roundrobin + + server s1 udp@127.0.0.1:514 # will receive 50% of log messages + server s2 udp@127.0.0.1:514 + + backend mylog-hash + mode log + + # extract "METHOD URL PROTO" at the end of the log message, + # and let haproxy hash it so that log messages generated from + # similar requests get sent to the same syslog server: + log-balance hash 'field(-2,\")' + + # server list here + server s1 127.0.0.1:514 + #... + log-format <string> Specifies the log format string to use for traffic logs May be used in sections: defaults | frontend | listen | backend -- 2.34.1