Closed chrisboulton closed 1 year ago
This is a great idea.
It may need some reworking of how addresses are loaded, but possibility to improve across the board. At the moment address lookups are performed "as needed", such as during initial connection and during reconnect, with one exception: if a lookup returns multiples addresses, it pulls from those secondary addresses on reconnect rather than doing a new lookup. This means connecting to "localhost" on most server would mean an attempt to connect to "::1" on IPv6, before then connecting to "127.0.0.1" on next attempt. SRV fits into this same thing. It will resolve multiple hosts and then queue them.
I guess the target here is for SRV to be expanded first to produce the full server list. Then to use that list as if it were configured. Do you think the lookup would need repeating though to keep the server list up to date? Or would an initial lookup on startup be sufficient (and another lookup on each configuration reload I would guess!)
I'm 50/50 on if I consider this a bug, or a feature enhancement - it was just somewhat unexpected because it wasn't super spelled out in the documentation.
For a while now, we've been using log-courier configured to connect to a Consul service
@logstash.service.consul
, and hadmethod: loadbalance
configured in our configuration file.We'd assumed that with this in place, we'd have log-courier doing client side load balancing for us, but that didn't seem to be the case - log-courier would only ever pick one record at a time and connect to it, vs all.
When I switched out the single hostname for a list of the servers, the load balancing functionality worked as expected and we had connections established to each server.
Maybe if there aren't plans to fix this, it could be spelled out in the docs? I'm happy to submit a PR if we think that's the right direction for now.