We now have a YouTube Channel. Subscribe for the video content

HAProxy Logging Configuration Explained: How to Enable and View Log Files

HAProxy is generally the frontend layer of your application, which means it plays a critical role since all traffic first lands on this layer. Because of this, you need to make sure everything is working at this layer all the time, as any issue can directly impact your business. Therefore, having visibility on this layer is crucial.

Visibility can come from two aspects: the metrics HAProxy emits and the logs it generates while handling requests.

In this article, I’ll focus mainly on the logging aspect of HAProxy—how to enable different types of logs and how to work with them to make more informed decisions.

What Are HAProxy Logs?

Haproxy logs are the record of events that indicate what’s happening with HAProxy while starting up, serving a request, and during an error. HAProxy uses log files to record events including requests received by HAProxy, the response to those requests, and their status code. It also logs any errors that occur.

Configuration: How to Enable HAProxy Logging

HAProxy emits log messages for processing by a syslog server. These syslog messages are compatible with the basic tools for reading syslog messages like rsyslog. HAProxy syslog messages are also compatible with the systemd-journald service.

You can enable HAProxy log messages by specifying the syslog server, then configuring it for different proxies like frontend and backend. The first step is to enable logging in a global configuration:

        log local0

HAProxy natively supports syslog logging, which you can enable as shown in the above examples. Syslog facilities and severity levels are also at your disposal, as well as the ability to forward the logs to journald, rsyslog, or any supported syslog server:

log facility serverity_level

With the log directive, you can specify the syslog server where you want to send the HAProxy logs. Local0 is one facility used to send logs. Simply add the logging level in the log directive to control what information to log:

log local0 info

This will start logging the messages that have the log level of “info” or above. Then, add the log in the default directive, which will enable the same logging in all three frontend, backend, and listen parts.

        log global

The listen section actually combines the information in the backend section and the frontend section. So instead of defining the backend and frontend separately and mapping them, you can define them in one listen section, and the mapping will be done automatically.

HAProxy has four major sections: global, default, backend, and frontend.

In the global config level, you can define values that work process-wide for security and performance tuning. In the default configs, you have to keep the best configuration, which is used across all/multiple sections depending on your use case. After that, you can override these values in the frontend or backend as required if you want to add another option or override any existing one. You can also have multiple log directives to forward the logs to different files.

Default Logging

In the default section of the configuration, you can mention the default configs that you want to use. This will be used by default in all the sections if not otherwise specified. You can configure things like where to log and the log format, as seen below:

        log global
        option httplog
        Timeout client 30s

These values will be used automatically in the section’s frontend and backend unless you override these values.

Backend Logging

HAProxy backend servers are the set of servers among which a request is actually load-balanced. Create a logging line separately for these backends using the following configuration:

backend webservers
        balance roundrobin
        server server1
        log local0 info

With the above, you’ll be able to easily see the logs of different backends at different syslog servers.

Frontend Logging

Similar to the backend, frontend servers can also have their own logging configuration. The frontend in HAProxy is where traffic actually lands. Based on the frontend configuration, backend servers are chosen and the traffic is forwarded to these. As to logs, these are defined separately as seen in the configuration below:

frontend webui
        use_backend webservers
        log local0 error

Listen Section Logging

The listen section lets you define all the parts of the proxy together with the frontend and backend. This makes it easy to understand, as you only need to check the listen section for each proxy as described below:

listen fe_main
   log local0 error
   # frontend configuration settings
   mode http
   bind :80
   http-request redirect scheme https unless { ssl_fc }

   # backend configuration settings
   balance roundrobin
   option httpchk
   server s1 check
   server s2 check

Logging to a File

Most tools support logging to a file for better accessibility and easier setup. HAProxy, however, doesn’t natively support this. The reason for this design decision is that HAProxy is supposed to proxy requests, not write to the file. HAProxy instead offloads this responsibility to existing solutions like syslog.

If you want to write to a file, you need to configure the syslog server to do so. Below is the config for writing syslog messages to files using the rsyslog service in Linux:

local0.* /var/log/haproxy.log
local0.notice /var/log/hap_notifications.log

Logging in Containerized Environments

By default, containers tend to log to stdout and stderr. HAProxy can easily log to stdout with the configuration below, or you can send the log to syslog server:

    log stdout format raw local0

The above config will start logging to stdout. To send the log to the syslog server from the HAProxy container, you can use the following configurations:

    log rsyslog_location:514 local0

Read more about this in the documentation on Docker logging with HAProxy.

HAProxy Log Location

HAProxy logs location depends on the operating system you are using:

  • On Ubuntu or Debian-based distributions in Linux, the log location is /var/log/haproxy.log. This is automatically configured by the scripts provided in the installation package.
  • In CentOS or other Red Hat distributions, HAProxy does not output logs to a file by default, meaning you’ll need to configure it separately. This documentation tells you how to configure logs to a file on CentOS.

HAProxy Log Levels

Similar to other logging agents and tools, HAProxy divides logs into different log levels to make sure they’re properly segregated based on severity and verbosity:

  • Emerg: Emergency alerts that can come from underlying operating systems, including errors such as OOM and file descriptor exhaustion
  • Alert: Cases that happen rarely and cause unexpected exceptions
  • Crit: Not used by HAProxy
  • Err: HAProxy configuration errors like unable to parse the configuration file, maps file, etc.
  • Warning: Important messages but not critical; errors like failed modification to a request or failed DNS nameserver connection
  • Notice: Changes to HAProxy states, e.g., HAProxy emitting a restart, stop, or start event; also for logging module loading and health-check logging
  • Info: TCP and HTTP request details and error details
  • Debug: Not used by default with HAProxy, but can be used with custom Lua scripts to log extra details

All these log levels are easily configured in the log directives discussed above. It’s important to segregate different HAProxy log levels to facilitate more visibility with less hassle.

HAProxy Log Format

HAProxy can work with TCP and HTTP. It comes with a default log format, or you can customize the log format and use it with whatever field you want.

Default Log Format

The default log format of HAProxy is TCP mode. You can access the information present in TCP mode by logging in as shown in the TCP section below. Default log formats have lots of information present, but there are missing elements like SSL encryption information, headers, and payload. Due to this, users end up creating custom log formats most of the time.

TCP Format

When it’s working with TCP, you can enable it by adding the following configuration:

mode tcp
option tcplog

TCP mode will form a full duplex connection, and you will not be able to look at the application-level details. With TCP, you have to configure the logging mode to TCP so that the log format will comply with the field present in the logging options like byte count, timers, etc.

Fields present in the TCP mode are as below:

The above details are from the HAProxy official documentation. You can also define the log format in HAProxy using the log-format directive:

log-format "%ci:%cp [%t] %ft %b/%s %Tw/%Tc/%Tt %B %ts
%ac/%fc/%bc/%sc/%rc %sq/%bq"

HTTP Format

When using the HTTP protocol, you have to use the HTTP mode and option as httplog:

mode http
option httplog

In HTTP mode, HAProxy can log more than the TCP details, including log details such as HTTP request URL, status code, bytes sent, request and response header, etc. A full list of details is mentioned in the following:

Similar to the TCP logging format, the log-format directive lets you log HTTP requests:

log-format "%ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B
%CC %CS %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r"

The log-format directive can go in the default, frontend, or listen sections. If you put it in the default section, it will consider default options for all the sections.

Custom Log Formatting

The HAProxy logging format has variables to define the logging format properly; below are the rules that all variables have to follow:

  • Every variable is preceded by a percentage character “%”.
  • Variables can take flags with the help of braces {}.
  • Multiple flags can be separated with commas.
  • A + or – sign adds or removes flags.
  • Spaces that are not between variables have to be escaped with a backslash.

There are three flags:

  • Q: To quote a string
  • X: For hexadecimal representation
  • E: For escapes characters

You can add configuration for headers, SS, etc with the following configurations:

  • Connection handshake time (%Th)
  • SSL ciphers and versions (%sslc / %sslv)
  • Request headers (%hr or %hrl for CLF formatting)
  • Response headers (%hs or %hsl for CLF formatting)
  • The full HTTP request (%r)

You can look more into these variables and how to use them in HAProxy’s custom logging format documentation.

HAProxy Log Rotation

Like any system, HAProxy can generate large volumes of log data. To limit the amount of disk used by logs, you need to rotate them. Log rotation means keeping the older log data in another format, compressing it, and archiving it at another location.

For log rotation, make use of the logrotate utility in Linux by creating a haproxy.logrotate file with a basic configuration in Linux:

/var/log/haproxy {
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
        /bin/kill -HUP `cat /var/run/rsyslogd.pid 2> /dev/null` 2> /dev/null || true
        /bin/kill -HUP `cat /var/run/syslog-ng.pid 2> /dev/null` 2> /dev/null || true

How to Read HAProxy Logs

HAProxy has lots of fields and provides great in-depth details about logs, but it can be hard to understand these variables and fields. Fortunately, HAProxy ships with HALog, a very powerful, production-ready log analysis tool. Unfortunately, HALog doesn’t support custom-log format parsing at the moment. But you can use tools like Sematext Logs to solve this problem.

This means it can be deployed in production and is really fast, parsing both TCP and HTTP logs, up to 1-2 GB of logs per second. You can even pass different flags with HALog to make it filter out the information you need.

HALog presents you with metrics that give you critical insight into your servers. It can parse logs to show how many requests failed per server, the total number of requests, the number of occurrences of different status codes, and much more.

These commands will retrieve information including status codes, total requests, and response times:

halog -srv -H < hap.log | column -t
195000 lines in, 10 lines out, 0 parsing errors
#srv_name       1xx  2xx    3xx  4xx  5xx  other  tot_req  req_ok  pct_ok  avg_ct  avg_rt
api/users       0    17969  163  851  0    1      13984    13983   100.0   0       60
api/profile     0    12976  149  854  5    0      13984    13979   100.0   1       150
httpd/<NOSRV>   0    0      8    0    0    0      8        0       0.0     0       0
httpd/users     84   534    0    6    2    0      626      626     100.0   0       342
httpd/profile   72   3096   0    9    10   0      3187     3183    99.9    1       1509

HAProxy Stats Page

HAProxy has a stats page to see all the above details in your web browser; to enable, use the following configuration:

frontend stats
   bind *:8404
   stats enable
   stats uri /stats
   stats refresh 10s
   stats admin if LOCALHOST

This will display the stats page on port 8404:

Stats page for HAProxy server. (Source: HAProxy)

Log Monitoring and Analysis with Sematext

Generally, companies run a huge fleet of HAProxy servers to handle traffic; I myself have run some 200 HAProxy servers. These servers generate a huge amount of logs, and looking at them can be a challenge. HALog can help, but it’s still difficult to log into such a huge number of servers, run HALog on each of them, and then accumulate the results.

What you really need is a centralized logging solution such as Sematext Logs, where you can ship all the logs and build analytics on top of it.

Sematext is a log management and monitoring tool with great support for HAProxy logs. It is easy to install and configure. In no time, you’ll be able to see logs in your dashboard and leverage pre-built dashboards to filter out key information.

Sematext comes with many other features that give you confidence in running your HAProxy clusters in production. You can add alerting on the dashboard and forward alerts to different channels such as email, Slack, PagerDuty, and many more.

Sematext Logs is part of the Sematext Cloud, a full-stack observability platform with support for monitoring HAProxy clusters as well as the majority of tools present in your infrastructure. This means that it also gathers HAProxy metrics. Correlating metrics and logs from your HAProxy servers is greatly valuable, reducing the time needed to fix issues in production. Plus, anomaly detection lets you identify issues before they happen based on past metrics.

Watch the video below to learn more about what Sematext Logs can do for you.


HAProxy is a critical component of your infrastructure, and you need visibility on these servers to monitor for errors and performance. You need a centralized location to see logs and receive alerts if you’re running a huge fleet of HAProxy servers.

Sematext provides an effective dashboard to catch issues and alert you in advance via its integration with logging and monitoring solutions around HAProxy.

Sign up for a free trial today.

Author Bio

Gaurav Yadav
Gaurav has been involved with systems and infrastructure for almost 6 years now. He has expertise in designing underlying infrastructure and observability for large-scale software. He has worked on Docker, Kubernetes, Prometheus, Mesos, Marathon, Redis, Chef, and many more infrastructure tools. He is currently working on Kubernetes operators for running and monitoring stateful services on Kubernetes. He also likes to write about and guide people in DevOps and SRE space through his initiatives Learnsteps and Letusdevops.