I tend to have really large rise, and small fall like 2 and 9 (or 99 or higher would be good if you want to ensure it stays down long enough to trigger). That way they stay dead for awhile, but can go down quickly.
Anyways, so that it shows in my monitoring system I have this in my zabbix cfg on all my load balancers and trigger an alert if it is ever >0: UserParameter=proxysrvrsdown,echo "show stat" | /usr/local/bin/socat /var/lib/haproxy-stat stdio | grep -c DOWN So, if a frontend is flapping (and it could be the web server and not the nic), I will get the flapping as alerts from my network monitoring. Personally, if you think a backend should stay down when down, I would recommend having the backend do it's own self checks and shoot itself in the head if it detects problems, so that it will stay down. That said if you have enough backends, having a high rise could be a good idea. However, be warned that if there is one machine really bad, and the problem is on the load balancer side or global network hiccup, all backends could incorrectly be marked as down. So you really don't want them to stay down for too long. From: [email protected] [mailto:[email protected]] On Behalf Of John Clegg Sent: Wednesday, February 01, 2012 10:29 PM To: [email protected] Subject: Understanding how to use rise and fall settings on a dead server Hi I'm trying to understand how ensure backserver which is failing and classified as dead stays dead. I've just had an instance on another server which is using another load-balancer where the NIC has intermittently failing and it caused the load-balancer to flap constantly. I would like to set a threshold where if the back-end service fails that it says dead, it stays dead and needs to be manually re-added to load-balancer. I'm trying to understand how the rise and fall settings (plus other config settings) can achieve this, or if there is another approach. Any ideas would be appreciated. Regards John -- John Clegg Dash Tickets http://www.dashtickets.co.nz
