Hi Willy,
> On 2 Aug 2025, at 02:30, Willy Tarreau <[email protected]> wrote: > > On Fri, Aug 01, 2025 at 01:46:21PM -0300, Joao Morais wrote: >> >> * 2.6.22 works better when I add some jitter on the requests, it seems data >> was colliding; >> * Just re-read the doc and found that "The pushed values overwrite remote >> ones without aggregation.", which means that 2.6 is misbehaving, and 3.2 is >> working as expected. :( > > Absolutely, the initial purpose of the peers is to have an exact copy of > a stick-table on other peers (initially it was used only for stickiness, but > is now also used to share info such as "be careful, this IP is an attacker" > etc. Let me share a few other findings after another round of tests I did yesterday. Two haproxy instances, single table shared between them, there’s a sc0_inc_gpc0 in place against that table that +1 a gpc on every request: * from 2.x to 3.1.8: peers request is always overwriting the remote table, as stated in the doc, despite the state of the local table. * 3.2: peers request is also overwriting the remote table, until that table is updated locally - the first call to gc0_inc_gpc0, after that it seems that remote peers don’t have the ability to update the local table anymore. Maybe you know the details behind this change in the behavior, if it’s either a better align with some internal implementation or this can be considered a regression. In the case of the former, wondering if this change can be (or already is) behind a customizable flag. >> Wondering how do you folks use to aggregate values. I could maintain one >> table per instance on every instance and sum all of its metrics, but >> wondering if there is an easier and more straightforward way out there. > > That's indeed the usual way to do it when you don't use an external > aggregator. For example if you have 4 nodes, you have 4 tables named > with a suffix of 1 to 4, This way all nodes know each other's values, > and when you read metrics, you can just assign them to local variables > and apply the operations you want (sum/max/etc). In such cases I advise > you to declare the tables in the peers section. It's more convenient and > easier to see that they're per-peer. Such setups are fine till a few > nodes where configs remain manageable by hand. I remember once seeing a > conf where entries were agggregated in Lua functions exposed as sample > fetch functions in order to hide a bit of the complexity from the conf, > I don't remember where it was. Thanks for confirming the approach and sharing the idea about a Lua script. On my use case the complexity isn’t exactly an issue since my cfg file is created and maintained via automation. I have however two doubts about how to implement it. Taking the snippet below: listen l1 ... http-request track-sc0 str(z) table p/t1 http-request set-var(req.gpc0) sc0_inc_gpc0 http-request set-var(req.gpc0) sc0_get_gpc0(p/t2),add(req.gpc0) http-request set-var(req.gpc0) sc0_get_gpc0(p/t3),add(req.gpc0) http-request return hdr x-out %[var(req.gpc0)] peers p ... table t1 type string size 10 store gpc0 table t2 type string size 10 store gpc0 table t3 type string size 10 store gpc0 * is this the way to aggregate values from several tables, I mean, one set-var() action and add() converter per remote table? Wondering if I’m missing some addall(fetch1,fetch2,...) out there; * is it known that a Lua script could be more or less optimized than a chain of, say, 3 or 4 http-requests directly in the conf, or both approaches worth to be properly tested. > Alternately, if it's for a professional / high-performance use case, > there's at least one aggregator developed and maintained by HaproxyTech > (there might be other ones but I'm not aware of them). Then the principle > is that your nodes do not directly communicate between each other and > instead communicate with the aggregator. Each of your nodes will have > only their local table and a global one. The aggregator learns from > all nodes' local tables, computes new global values and broadcasts them > to the global table on each node. This is generally what you want for > large deployments where it's no longer practical to sum some fields. Sure, already found the aggregator as part of the enterprise module. I’m using haproxy community however, since it is so good and perfectly fits all my (other) needs, so it seems this approach is not available to me. :( > Hoping this helps, Sure it does! Thanks Willy. --jm
