Hi Joao, On Fri, Aug 01, 2025 at 01:46:21PM -0300, Joao Morais wrote: > > Hey there, two updates on this. > > * 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. > 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. 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. Hoping this helps, Willy
