Sunday, October 9, 2011

Tomcat: Clustering and Load Balancing with HAProxy under Ubuntu 10.04 - Part 3


In the previous section, we've implemented load balancing using HAProxy and session sharing among our Tomcat instances. In this section, we will examine in-depth the HAProxy configuration file and setup its logging facilities.

Table of Contents

  1. Setting-up the Environment
    • Download Tomcat
    • Configure Tomcat
    • Run Tomcat
    • Download HAProxy
    • Configure HAProxy
  2. Load Balancing
    • Default Setup
    • Sharing Sessions
    • Configure Tomcat to Share Sessions
    • Retest Session Sharing
    • Session Sharing Caveat
    • Sharing Sessions
  3. HAProxy Configuration
    • Configuration File
    • Logging

HAProxy Configuration

When it comes to HAProxy configuration, the best source of information is its online documentation at It's one massive text file of technical information though.

Configuration File

Not all information in that document applies to our configuration. Therefore, I have copied the relevant information only and pasted them as comments per line:

Take note of the following parts:
  • frontend http-in: We're telling HAProxy to listen to HTTP requests
  • default_backend servers: We declare a set of backend servers
  • stats uri /admin?stats: This is the URL to the stats page, relative to your hostname
  • stats realm Haproxy\ Statistics: This is the server name you see when you login to the stats page.
  • server tomcat1 cookie JSESSIONID check inter 5000: Defines a server. In this case, a Tomcat server. Here we assigned the IP and port number.

HAProxy Logging

Logging is crucial in any serious application, and HAProxy has facilities to log its activities.
However, to setup one requires extra effort because to enable logging in HAProxy we need to know
Linux's logging facilities via the Syslog server and take into account the Syslog implementation in Ubuntu Lucid (10.04).

What is Syslog?
syslog is a utility for tracking and logging all manner of system messages from the merely informational to the extremely critical. Each system message sent to the syslog server has two descriptive labels associated with it that makes the message easier to handle. - Source: Quick HOWTO : Ch05 : Troubleshooting Linux with syslog

To enable logging, we need to:
  • Add a logging facility in haproxy.cfg
  • Add the logging facility to Syslog server

Add a logging facility in haproxy.cfg
Edit the haproxy.cfg file:
sudo gedit /etc/haproxy/haproxy.cfg

And declare the following:

We declared two logging facilities under the global section. Both facilities will send their log output to the Syslog server which is located at The default port is 514. Each logger has its own unique name: local0 and local1.

Why are they named such? These are local facilities defined by the user to log specific deamons (see What is LOCAL0 through LOCAL7 ?).

Remember an optional level can be specified to a filter. Hence, local1 has an extra argument: notice. This means local1 will only capture logs with notice level as opposed to all, i.e. errors, debugs.

Reload haproxy by running the following command:
sudo haproxy -f /etc/haproxy/haproxy.cfg -p /var/run/ -sf $(cat /var/run/

This command will not restart HAProxy. It will just reload the configuration file. This is good because you won't be killing active connections. If you get a missing file i.e /var/run/ or other errors, just kill the haproxy process and restart it:
kill -9 #####
where ##### is the process id

Add the logging facility to Syslog server
There are two solutions to achieve this.

Solution #1
a. Run
sudo gedit /etc/rsyslog.conf

And declare the following lines at the end:

b. Restart syslog server by running:
restart rsyslog

Solution #2
Instead of editing directly the rsyslog.conf, we can declare a separate configuration under /etc/rsyslog.d/ directory. If you inspect carefully the rsyslog.conf, you will see the following comments:

This setting will load all *.conf files under /etc/rsyslog.d/ directory.

a. Run
sudo gedit /etc/rsyslog.d/haproxy.conf

And declare the following lines at the end:

b. Restart syslog server by running:
restart rsyslog

Overflowing Logs

We've setup HAProxy logging. We can see the logs in /var/log/haproxy0a.log and /var/log/haproxy1a.log files. However, we also see them in /var/log/syslog.

This is bad because now we have redundant logs that just eats up space. You don't want that syslog to be polluted with HAProxy logs. That's the reason why we've setup a separate logging facility in the first place.

There are two ways to prevent this unwanted overflow:

Solution #1
1. Run
sudo gedit /etc/rsyslog.d/50-default.conf

And search for the following lines (right after the introductory comments):

And change them as follows:

This means local0 and local1 should not overflow to syslog.

b. Restart syslog server by running:
restart rsyslog

Solution #2
1. Run
sudo gedit /etc/rsyslog.conf

And find the following lines:

And change them as follows:

The addition of & ~ will prevent the logs designated to local0 from overflowing to other logging facilities.

Note: If you can't find those lines, maybe you've declared your configuration under /etc/rsyslog.d/haproxy.conf. If yes, follow the same steps.

b. Restart syslog server by running:
restart rsyslog

Rotate Logs

We've setup HAProxy logging. We've isolated the logs from overflowing to syslog. However, there's another problem. The HAProxy logs will soon pile-up and consume precious disk space. Gladly, Linux has a way to schedule and reuse the same lgo file and perform compression.

For more info of log rotation in Linux, please see Quick HOWTO : Ch05 : Troubleshooting Linux with syslog: Logrotate.

Again, there are two ways of handling this requirement:

Solution #1
a. Run
sudo gedit /etc/logrotate.d/haproxy

And add the following lines:

b. Restart syslog server by running:
restart rsyslog

Solution #2
Log rotation with rsyslog from the official rsyslog documentation. This is something I haven't tried yet but if you're willing to experiment, here's the link: This technique utilizes the output channels.

However, read the following notes:
Output Channels are a new concept first introduced in rsyslog 0.9.0. As of this writing, it is most likely that they will be replaced by something different in the future. So if you use them, be prepared to change you configuration file syntax when you upgrade to a later release.


The following is a compendium of references that I found interesting to read further:

R: What is LOCAL0 through LOCAL7 ?

R: Quick HOWTO : Ch05 : Troubleshooting Linux with syslog

R: rsyslog official site

R: rsyslog.conf configuration file

R: UDP Syslog Input Module

R: How to keep haproxy log messages out of /var/log/syslog

R: HAProxy Logging in Ubuntu Lucid

Q: Install and configure haproxy, the software based loadbalancer in Ubuntu


That's it. We've completed our study of HAProxy and Tomcat clustering. We've learned how to setup, configure load balancing, and handle failover. We've also learned the important points when enabling session sharing. We've also studied HAProxy's configuration and logging facilities.

If you want to learn more about web development and integration with other technologies, feel free to read my other tutorials in the Tutorials section.
StumpleUpon DiggIt! Blinklist Yahoo Furl Technorati Simpy Spurl Reddit Google I'm reading: Tomcat: Clustering and Load Balancing with HAProxy under Ubuntu 10.04 - Part 3 ~ Twitter FaceBook

Subscribe by reader Subscribe by email Share


  1. Thank you very much for such a good tutorial :)

  2. Thanks so much for this tutorial!! it is amazing the way you explain!!
    It is a pity that you no longer continue with this tutorials since time ago.

  3. I would like to say thanks a lot .. This tutorial it is great for me ... Obrigado !!!

  4. If you want your ex-girlfriend or ex-boyfriend to come crawling back to you on their knees (even if they're dating somebody else now) you need to watch this video
    right away...

    (VIDEO) Have your ex CRAWLING back to you...?

  5. BlueHost is definitely the best website hosting provider with plans for all of your hosting requirements.

  6. Excellent write up! I was stuck in session sharing, followed the steps as mentioned in the article, now working fine!

  7. Good Post! Thank you so much for sharing this pretty post, it was so good to read and useful to improve my knowledge as updated one, keep blogging.

    core java training in Electronic City

    Hibernate Training in electronic city

    spring training in electronic city

    java j2ee training in electronic city

  8. Great Article… I love to read your articles because your writing style is too good,
    its is very very helpful for all of us and I never get bored while reading your article because,
    they are becomes a more and more interesting from the starting lines until the end.

    Java training in Chennai

    Java training in Bangalore

    Java online training

    Java training in Pune