Re: HAProxy 1.7.5: conn_cur value problem with peer stick-table
Le 27/10/2017 à 18:06, Arnall a écrit : Le 27/05/2017 à 08:49, Willy Tarreau a écrit : Hi Maxime, On Fri, May 19, 2017 at 02:28:40PM +0200, Maxime Guillet wrote: 2/ If I launch the same test on both haproxy servers and peers configuration activated, I can see the conn_cur counter always increasing $ ab -n 2000 -c 20 http://10.0.0.2/ $ ab -n 2000 -c 20 http://10.0.0.3/ haproxy1# echo "show table http" | socat stdio /var/run/haproxy/haproxy.stats # table: http, type: ip, size:512000, used:1 0x7f59d568b9a0: key=10.10.10.10 use=20 exp=7285 conn_rate(1)=225 conn_cur=47 0x7f59d568b9a0: key=10.10.10.10 use=20 exp=5337 conn_rate(1)=213 conn_cur=52 0x7f59d568b9a0: key=10.10.10.10 use=20 exp=7952 conn_rate(1)=178 conn_cur=133 0x7f59d568b9a0: key=10.10.10.10 use=20 exp=9589 conn_rate(1)=218 conn_cur=259 0x7f59d568b9a0: key=10.10.10.10 use=20 exp=6144 conn_rate(1)=143 conn_cur=321 0x7f59d568b9a0: key=10.10.10.10 use=20 exp=8115 conn_rate(1)=190 conn_cur=553 0x7f59d568b9a0: key=10.10.10.10 use=20 exp=7815 conn_rate(1)=180 conn_cur=676 0x7f59d568b9a0: key=10.10.10.10 use=20 exp=7285 conn_rate(1)=162 conn_cur=738 => the conn_cur information becomes more and more higher, while it should be at maximum 40 (2 x 20 concurrent connection with ab) I don't believe this behavior is intended, it seems more to be a bug. Well, yes and no. The principle of stick table synchronization is primarily for stickiness and secondarily for active-backup table replication, so the last which pushes a value should overwrite the previous one. In that sense, it's expected that the values you find are around 20. What you're seeing still makes me think it's a bug (since it sounds like we're adding up some values here), but I don't know if it's a side effect of the update or not. Specifically it's possible that this replication would prevent a session from decrementing its reference on close for example. It could also be a stupid copy-paste of the conn_cnt replication, which would then be wrong. At first glance what I'm seeing in the code looks like a simple replication so I can't explain how what you're seeing happens for now :-/ Willy Hi willy, i found this topic because we have exactly the same problem , conn_cur increasing endlessly when peers are activated. ( HA-Proxy version 1.7.9-1~bpo8+1 ) We use it for rate limiting purpose but from what i read it's a bad idea after all, i thought that stick table were synchronised like this : Server A [ conn_cur = 10 ], Server B [ conn_cur = 20 ], with peers => Server A [ conn_cur = 30 ], Server B [ conn_cur = 30 ] But from what you write ( in fact it's in the documentation too ) it seems that A overwrite B, or B overwrite A so it's impossible to use it for rate limiting purpose.( i certainly don't want a [ conn_cur = 10 ] overwriting a [ conn_cur = 20 ] ) Am i right ? Thanks Hi Willy, as you ask i bump this message about endlessly increasing conn_cur counter when used with peers. At the time of the test it was with HA-Proxy version 1.7.9-1~bpo8+1, i didn't test with newer version. Regards. Arnaud. --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus
Why is there a tilde ~ character behind the frontend name in the log file?
I have a http frontend “default-http” and “default-https”. In the access log is the ~ (tilde) character appended to the default-https frontend name, like “default-https~”. Why is that? Best regards, Pieter Vogelaar
Re: Why is there a tilde ~ character behind the frontend name in the log file?
Hi Pieter,
On 7 February 2018 at 11:15, Pieter Vogelaar wrote:
> I have a http frontend “default-http” and “default-https”. In the access log
> is the ~ (tilde) character appended to the default-https frontend name, like
> “default-https~”.
>
>
> Why is that?
As per:
http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#8.2.4
> | | %ft | frontend_name_transport ('~' suffix for SSL) | string |
The tilde means the the incoming connection was SSL encrypted.
cheers,
lukas
Re: Why is there a tilde ~ character behind the frontend name in the log file?
On Wed, Feb 07, 2018 at 10:15:56AM +, Pieter Vogelaar wrote:
> I have a http frontend “default-http” and “default-https”. In the
> access log is the ~ (tilde) character appended to the default-https
> frontend name, like “default-https~”.
Looks like it means SSL:
| | %ft | frontend_name_transport ('~' suffix for SSL) | string |
--
Valentin
next bugfix release for 1.8 branch
Hello, i was wondering what the 'next bug-fix' release policy was, for the 1.8 branch, the only documentation i could find is a mail discussion for the 1.5 branch. I'm hoping that the next release fixes the 'ms -edge takes a long while, when redirected after a post' discussed here in https://www.mail-archive.com/haproxy@formilux.org/msg28533.html Regards Robbert
Re: next bugfix release for 1.8 branch
Hello Robbert, On Wed, Feb 07, 2018 at 10:52:21AM +, Robbert Muller wrote: > Hello, > > i was wondering what the 'next bug-fix' release policy was, for the 1.8 > branch, > the only documentation i could find is a mail discussion for the 1.5 branch. It's the same for all stable branches. In general whenever there is something really critical or an accumulation of less important stuff over some time, we emit one. Often the few months following a major release cause all the team an intense work fixing various reported bugs, so we tend to miss some time to do releases often (or we don't see the time fly). I wanted to emit 1.8.4 this morning but got distracted by other much less interesting activities :-( I'll try again this afternoon. Cheers, Willy
Hello, I have a question about a post on feedjunkie.com
Hello there Your page http://feedjunkie.com/item/26333552/Where Athletes In The Worlds Top Sports Leagues Come F has some good references to some of the best athletes in the world so I wanted to get in touch with you. I've recently written an article about Roger Federer and was wondering if you thought my article could help out on your page. You can read all the information right here: https://tennisdrills.tv/5-skills-set-roger-federer-apart-rest/ It would be great to know your opinion on the article. And if you find it useful please consider linking to it from that page of yours. Also if you prefer you may republish the article. How does that sound to you?. Thank you very much, Anna.
Server-template and randomized DNS responses
Hi!
I have a Consul as service discovery tool and HAProxy as load balancer.
In Consul registered a service running on a number of servers, and this
service can be scaled by adding and removing nodes and by moving nodes from
one server to another.
Consul has DNS service which randomizes responses for services like that:
[bux] michep@bux:~$ dig +short mfm-monitor-opentsdb.service.mfmconsul
10.182.161.239
10.182.161.152
10.182.161.240
10.182.161.92
[bux] michep@bux:~$ dig +short mfm-monitor-opentsdb.service.mfmconsul
10.182.161.92
10.182.161.152
10.182.161.240
10.182.161.239
In HAProxy 1.8.3 im using server-template configuration, like that:
resolvers dns
nameserver dns1 ${HAPROXY_NAMESERVER}
hold valid 2s
backend tsdb_backend_query
server-template tsdb_query 5
mfm-monitor-opentsdb.service.mfmconsul:4242 check resolvers dns inter
1000
And in that case I get alot of warinings in haproxy log:
time="2018-02-02T15:44:32+03:00" level=info msg="[WARNING] 032/154432
(32983) : tsdb_backend_query/tsdb_query1 changed its IP from
10.182.161.240 to 10.182.161.239 by DNS cache."
job=mfm-monitor-haproxy pid=32983
time="2018-02-02T15:44:42+03:00" level=info msg="[WARNING] 032/154442
(32983) : tsdb_backend_query/tsdb_query1 changed its IP from
10.182.161.239 to 10.182.161.240 by DNS cache."
job=mfm-monitor-haproxy pid=32983
time="2018-02-02T15:44:46+03:00" level=info msg="[WARNING] 032/154446
(32983) : tsdb_backend_query/tsdb_query3 changed its IP from
10.182.161.152 to 10.182.161.239 by DNS cache."
job=mfm-monitor-haproxy pid=32983
time="2018-02-02T15:44:50+03:00" level=info msg="[WARNING] 032/154450
(32983) : tsdb_backend_query/tsdb_query2 changed its IP from
10.182.161.92 to 10.182.161.152 by DNS cache." job=mfm-monitor-haproxy
pid=32983
time="2018-02-02T15:44:52+03:00" level=info msg="[WARNING] 032/154452
(32983) : tsdb_backend_query/tsdb_query3 changed its IP from
10.182.161.239 to 10.182.161.92 by DNS cache." job=mfm-monitor-haproxy
pid=32983
time="2018-02-02T15:44:56+03:00" level=info msg="[WARNING] 032/154456
(32983) : tsdb_backend_query/tsdb_query1 changed its IP from
10.182.161.240 to 10.182.161.239 by DNS cache."
job=mfm-monitor-haproxy pid=32983
time="2018-02-02T15:45:00+03:00" level=info msg="[WARNING] 032/154500
(32983) : tsdb_backend_query/tsdb_query3 changed its IP from
10.182.161.92 to 10.182.161.240 by DNS cache." job=mfm-monitor-haproxy
pid=32983
time="2018-02-02T15:45:02+03:00" level=info msg="[WARNING] 032/154502
(32983) : tsdb_backend_query/tsdb_query3 changed its IP from
10.182.161.240 to 10.182.161.92 by DNS cache." job=mfm-monitor-haproxy
pid=32983
time="2018-02-02T15:45:04+03:00" level=info msg="[WARNING] 032/154504
(32983) : tsdb_backend_query/tsdb_query2 changed its IP from
10.182.161.152 to 10.182.161.240 by DNS cache."
job=mfm-monitor-haproxy pid=32983
time="2018-02-02T15:45:06+03:00" level=info msg="[WARNING] 032/154506
(32983) : tsdb_backend_query/tsdb_query1 changed its IP from
10.182.161.239 to 10.182.161.152 by DNS cache."
job=mfm-monitor-haproxy pid=32983
time="2018-02-02T15:45:10+03:00" level=info msg="[WARNING] 032/154510
(32983) : tsdb_backend_query/tsdb_query3 changed its IP from
10.182.161.92 to 10.182.161.239 by DNS cache." job=mfm-monitor-haproxy
pid=32983
time="2018-02-02T15:45:18+03:00" level=info msg="[WARNING] 032/154518
(32983) : tsdb_backend_query/tsdb_query3 changed its IP from
10.182.161.239 to 10.182.161.92 by DNS cache." job=mfm-monitor-haproxy
pid=32983
time="2018-02-02T15:45:20+03:00" level=info msg="[WARNING] 032/154520
(32983) : tsdb_backend_query/tsdb_query2 changed its IP from
10.182.161.240 to 10.182.161.239 by DNS cache."
job=mfm-monitor-haproxy pid=32983
This isn’t really break the service, but I think this is not quite normal.
Any advise on how to resolve this issue?
--
Mike Chepaykin
Re: -Ws argument isn't document?
On 03/02/2018 03:53 μμ, Lucas Rolff wrote: > haproxy --help: > -W master-worker mode. > -Ws master-worker mode with systemd notify support. Stupid me. But, I think it should be mentioned in the document as well. I prepared a patched for it. Cheers, Pavlos signature.asc Description: OpenPGP digital signature
[PATCH] DOC: Mention -Ws in the list of available options
Hi, Please consider applying the attached patch. It is a patch for the management.txt and adds the '-Ws' in the list of available options. haproxy --help reports that option, so I thought we need to have in the document as well. The patch mentions that haproxy must be build with `USE_SYSTEMD` build option enabled, otherwise this option is not available. Cheers, Pavlos From 426a4b37f7f1347a3e017db8f577b81f34f51f13 Mon Sep 17 00:00:00 2001 From: Pavlos Parissis Date: Wed, 7 Feb 2018 21:42:16 +0100 Subject: [PATCH] DOC: Mention -Ws in the list of available options --- doc/management.txt | 4 1 file changed, 4 insertions(+) diff --git a/doc/management.txt b/doc/management.txt index af216521a..1488862e7 100644 --- a/doc/management.txt +++ b/doc/management.txt @@ -176,6 +176,10 @@ list of options is : is compatible either with the foreground or daemon mode. It is recommended to use this mode with multiprocess and systemd. + -Ws : master-worker mode with support of `notify` type of systemd service. +This option is only available when HAProxy was built with `USE_SYSTEMD` +build option enabled. + -c : only performs a check of the configuration files and exits before trying to bind. The exit status is zero if everything is OK, or non-zero if an error is encountered. -- 2.11.0 signature.asc Description: OpenPGP digital signature
Re[2]: [PATCH] MINOR: introduce proxy-v2-options for send-proxy-v2
Hi Manu. -- Originalnachricht -- Von: "Emmanuel Hocdet" An: "Aleksandar Lazic" Cc: "haproxy" Gesendet: 05.02.2018 14:58:20 Betreff: Re: [PATCH] MINOR: introduce proxy-v2-options for send-proxy-v2 Hi Aleks, Le 2 févr. 2018 à 20:46, Aleksandar Lazic a écrit : Hi Manu. Am 02-02-2018 10:49, schrieb Emmanuel Hocdet: Hi Aleks Le 1 févr. 2018 à 23:34, Aleksandar Lazic a écrit : Hi. -- Originalnachricht -- Von: "Emmanuel Hocdet" An: "haproxy" Gesendet: 01.02.2018 17:54:46 Betreff: [PATCH] MINOR: introduce proxy-v2-options for send-proxy-v2 Hi, It’s patch introduce proxy-v2-options for send-proxy-v2. Goal is to add more options from doc/proxy-protocol.txt, especially all TLS informations related to security. Can then this function replace the current one `send-proxy-v2-ssl-cn` && `send-proxy-v2-ssl` yes and no, you must add send-proxy-v2 to activate proxy-v2 Let's say when the option is 'ssl-cn' then add all three flags as in the current `srv_parse_send_proxy_cn` function? http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/ssl_sock.c;hb=497959290789002b814b9021a737a3c5f14e7407#l7788 http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/ssl_sock.c;hb=497959290789002b814b9021a737a3c5f14e7407#l7796 We offer with this suggested solution a backward compatibility and the new function is in use. you must used "send-proxy-v2 proxy-v2-options ssl » for current send-proxy-v2-ssl you must used "send-proxy-v2 proxy-v2-options cert-cn » for current send-proxy-v2-ssl-cn next options should be authority,cert-key,cert-sig,ssl-cipher Maybe in the next step there could be a 'tlv' option which can decode custom tlv's ? http://git.haproxy.org/?p=haproxy.git;a=blob;f=src/connection.c;hb=497959290789002b814b9021a737a3c5f14e7407#l606 Just some brainstorming ;-) What do you mean? Haproxy is naturally a producer for ‘tlv’ options (for sure when related to ssl). I don’t know how ‘tlv’ options (other than netns) could be really useful to consume, passthru coud be more useful. How about this example. https://www.mail-archive.com/haproxy@formilux.org/msg28647.html How to parse custom PROXY protocol v2 header for custom routing in HAProxy configuration? This case describes a case for AWS own header in PP2 PP2_SUBTYPE_AWS_VPCE_ID I know it's not easy but maybe worth to discuss how to use the free fields in PP2 for some acls Consume and produce pp-v2 tlv are two different things. For tlv consume, i work with Varnish and the problem is the same: where to store them and how to use them. I do not know of a generic solution, specially in the case of custom tlv. Thanks for explanation. I also have no idea for now. ++ Manu Best regards aleks
Re: Server-template and randomized DNS responses
Hi
You're not using SRV records and that may be the root cause of your issue.
Please try something like this:
backend tsdb_backend_query
server-template tsdb_query 5
_mfm-monitor-opentsdb._tcp.service.mfmconsul:4242 check resolvers dns
inter 1000
if "mfm-monitor-opentsdb" is your service name in consul.
Baptiste
On Wed, Feb 7, 2018 at 2:52 PM, Чепайкин Михаил
wrote:
> Hi!
>
> I have a Consul as service discovery tool and HAProxy as load balancer.
>
> In Consul registered a service running on a number of servers, and this
> service can be scaled by adding and removing nodes and by moving nodes from
> one server to another.
>
> Consul has DNS service which randomizes responses for services like that:
>
> [bux] michep@bux:~$ dig +short mfm-monitor-opentsdb.service.mfmconsul
> 10.182.161.239
> 10.182.161.152
> 10.182.161.240
> 10.182.161.92
> [bux] michep@bux:~$ dig +short mfm-monitor-opentsdb.service.mfmconsul
> 10.182.161.92
> 10.182.161.152
> 10.182.161.240
> 10.182.161.239
>
> In HAProxy 1.8.3 im using server-template configuration, like that:
>
> resolvers dns
> nameserver dns1 ${HAPROXY_NAMESERVER}
> hold valid 2s
>
> backend tsdb_backend_query
> server-template tsdb_query 5 mfm-monitor-opentsdb.service.mfmconsul:4242
> check resolvers dns inter 1000
>
> And in that case I get alot of warinings in haproxy log:
>
> time="2018-02-02T15:44:32+03:00" level=info msg="[WARNING] 032/154432 (32983)
> : tsdb_backend_query/tsdb_query1 changed its IP from 10.182.161.240 to
> 10.182.161.239 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:44:42+03:00" level=info msg="[WARNING] 032/154442 (32983)
> : tsdb_backend_query/tsdb_query1 changed its IP from 10.182.161.239 to
> 10.182.161.240 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:44:46+03:00" level=info msg="[WARNING] 032/154446 (32983)
> : tsdb_backend_query/tsdb_query3 changed its IP from 10.182.161.152 to
> 10.182.161.239 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:44:50+03:00" level=info msg="[WARNING] 032/154450 (32983)
> : tsdb_backend_query/tsdb_query2 changed its IP from 10.182.161.92 to
> 10.182.161.152 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:44:52+03:00" level=info msg="[WARNING] 032/154452 (32983)
> : tsdb_backend_query/tsdb_query3 changed its IP from 10.182.161.239 to
> 10.182.161.92 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:44:56+03:00" level=info msg="[WARNING] 032/154456 (32983)
> : tsdb_backend_query/tsdb_query1 changed its IP from 10.182.161.240 to
> 10.182.161.239 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:45:00+03:00" level=info msg="[WARNING] 032/154500 (32983)
> : tsdb_backend_query/tsdb_query3 changed its IP from 10.182.161.92 to
> 10.182.161.240 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:45:02+03:00" level=info msg="[WARNING] 032/154502 (32983)
> : tsdb_backend_query/tsdb_query3 changed its IP from 10.182.161.240 to
> 10.182.161.92 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:45:04+03:00" level=info msg="[WARNING] 032/154504 (32983)
> : tsdb_backend_query/tsdb_query2 changed its IP from 10.182.161.152 to
> 10.182.161.240 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:45:06+03:00" level=info msg="[WARNING] 032/154506 (32983)
> : tsdb_backend_query/tsdb_query1 changed its IP from 10.182.161.239 to
> 10.182.161.152 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:45:10+03:00" level=info msg="[WARNING] 032/154510 (32983)
> : tsdb_backend_query/tsdb_query3 changed its IP from 10.182.161.92 to
> 10.182.161.239 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:45:18+03:00" level=info msg="[WARNING] 032/154518 (32983)
> : tsdb_backend_query/tsdb_query3 changed its IP from 10.182.161.239 to
> 10.182.161.92 by DNS cache." job=mfm-monitor-haproxy pid=32983
> time="2018-02-02T15:45:20+03:00" level=info msg="[WARNING] 032/154520 (32983)
> : tsdb_backend_query/tsdb_query2 changed its IP from 10.182.161.240 to
> 10.182.161.239 by DNS cache." job=mfm-monitor-haproxy pid=32983
>
> This isn’t really break the service, but I think this is not quite normal.
>
> Any advise on how to resolve this issue?
> --
> Mike Chepaykin
>
>
Re: Server-template and randomized DNS responses
Hi
I’ve changed configuration as you suggested:
backend tsdb_backend_query
server-template tsdb_query 5
_mfm-monitor-opentsdb._tcp.service.mfmconsul:4242 check resolvers dns
inter 1000
Logs are kinda different - backend servers now go UP and DOWN, but seems
the same - ip addresses changing in the same way:
time="2018-02-08T02:12:53+03:00" level=info msg="[WARNING] 038/021253
(18208) : Server tsdb_backend_query/tsdb_query1 is going DOWN for
maintenance (No IP for server ). 2 active and 0 backup servers left. 0
sessions active, 0 requeued, 0 remaining in queue."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:12:53+03:00" level=info msg="[WARNING] 038/021253
(18208) : tsdb_backend_query/tsdb_query1 changed its IP from
10.182.161.223 to 10.182.161.211 by DNS cache."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:12:53+03:00" level=info msg="[WARNING] 038/021253
(18208) : Server tsdb_backend_query/tsdb_query1 administratively READY
thanks to valid DNS answer." job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:12:53+03:00" level=info msg="[WARNING] 038/021253
(18208) : Server tsdb_backend_query/tsdb_query1
('0ab6a1d3.addr.dc1.mfmconsul') is UP/READY (resolves again)."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:12:55+03:00" level=info msg="[WARNING] 038/021255
(18208) : Server tsdb_backend_query/tsdb_query3 is going DOWN for
maintenance (No IP for server ). 2 active and 0 backup servers left. 0
sessions active, 0 requeued, 0 remaining in queue."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:12:55+03:00" level=info msg="[WARNING] 038/021255
(18208) : tsdb_backend_query/tsdb_query3 changed its IP from
10.182.161.98 to 10.182.161.223 by DNS cache." job=mfm-monitor-haproxy
pid=18208
time="2018-02-08T02:12:55+03:00" level=info msg="[WARNING] 038/021255
(18208) : Server tsdb_backend_query/tsdb_query3 administratively READY
thanks to valid DNS answer." job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:12:55+03:00" level=info msg="[WARNING] 038/021255
(18208) : Server tsdb_backend_query/tsdb_query3
('0ab6a1df.addr.dc1.mfmconsul') is UP/READY (resolves again)."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:12:57+03:00" level=info msg="[WARNING] 038/021257
(18208) : Server tsdb_backend_query/tsdb_query3 is going DOWN for
maintenance (No IP for server ). 2 active and 0 backup servers left. 0
sessions active, 0 requeued, 0 remaining in queue."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:12:57+03:00" level=info msg="[WARNING] 038/021257
(18208) : tsdb_backend_query/tsdb_query3 changed its IP from
10.182.161.223 to 10.182.161.98 by DNS cache." job=mfm-monitor-haproxy
pid=18208
time="2018-02-08T02:12:57+03:00" level=info msg="[WARNING] 038/021257
(18208) : Server tsdb_backend_query/tsdb_query3 administratively READY
thanks to valid DNS answer." job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:12:57+03:00" level=info msg="[WARNING] 038/021257
(18208) : Server tsdb_backend_query/tsdb_query3
('0ab6a162.addr.dc1.mfmconsul') is UP/READY (resolves again)."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:13:01+03:00" level=info msg="[WARNING] 038/021301
(18208) : Server tsdb_backend_query/tsdb_query1 is going DOWN for
maintenance (No IP for server ). 2 active and 0 backup servers left. 0
sessions active, 0 requeued, 0 remaining in queue."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:13:01+03:00" level=info msg="[WARNING] 038/021301
(18208) : tsdb_backend_query/tsdb_query1 changed its IP from
10.182.161.211 to 10.182.161.223 by DNS cache."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:13:01+03:00" level=info msg="[WARNING] 038/021301
(18208) : Server tsdb_backend_query/tsdb_query1 administratively READY
thanks to valid DNS answer." job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:13:01+03:00" level=info msg="[WARNING] 038/021301
(18208) : Server tsdb_backend_query/tsdb_query1
('0ab6a1df.addr.dc1.mfmconsul') is UP/READY (resolves again)."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:13:05+03:00" level=info msg="[WARNING] 038/021305
(18208) : Server tsdb_backend_query/tsdb_query2 is going DOWN for
maintenance (No IP for server ). 2 active and 0 backup servers left. 0
sessions active, 0 requeued, 0 remaining in queue."
job=mfm-monitor-haproxy pid=18208
time="2018-02-08T02:13:05+03:00" level=info msg="[WARNING] 038/021305
(18208) : tsdb_backend_query/tsdb_query2 changed its IP from
10.182.161.163 to 10.182.161.211 by DNS cache."
job=mfm-monitor-haproxy pid=18208
Any thoughts?
On 8 February 2018 at 01:25, Baptiste wrote:
Hi
>
> You're not using SRV records and that may be the root cause of your issue.
> Please try something like this:
>
> backend tsdb_backend_query
> server-template tsdb_query 5
> _mfm-monitor-opentsdb._tcp.service.mfmconsul:4242 check resolvers dns inter
> 1000
>
> if "mfm-monitor-opentsdb" is your service name in consul.
>
> Baptiste
>
>
>
> On Wed, Feb 7, 2018 at 2:52 PM, Чепайкин Михаил
> wrote:
>
>> Hi!
>
