Tag Archives: sample

7.3.2. Fetching sample from internal states



A first set of sample fetch methods applies to internal information which does not even relate to any client information. These ones are sometimes used with “monitor-fail” directives to report an internal status to external watchers.

The sample fetch methods described in this section are usable anywhere.

always_false : boolean
Always returns the boolean “false” value. It may be used with ACLs as a temporary replacement for another one when adjusting configurations.

always_true : boolean
Always returns the boolean “true” value. It may be used with ACLs as a temporary replacement for another one when adjusting configurations.

avg_queue([<backend>]) : integer
Returns the total number of queued connections of the designated backend divided by the number of active servers. The current backend is used if no backend is specified. This is very similar to “queue” except that the size of the farm is considered, in order to give a more accurate measurement of the time it may take for a new connection to be processed. The main usage is with ACL to return a sorry page to new users when it becomes certain they will get a degraded service, or to pass to the backend servers in a header so that they decide to work in degraded mode or to disable some functions to speed up the processing a bit. Note that in the event there would not be any active server anymore, twice the number of queued connections would be considered as the measured value. This is a fair estimate, as we expect one server to get back soon anyway, but we still prefer to send new traffic to another backend if in better shape. See also the “queue”, “be_conn”, and “be_sess_rate” sample fetches.

be_conn([<backend>]) : integer
Applies to the number of currently established connections on the backend, possibly including the connection being evaluated. If no backend name is specified, the current one is used. But it is also possible to check another backend. It can be used to use a specific farm when the nominal one is full. See also the “fe_conn”, “queue” and “be_sess_rate” criteria.

be_sess_rate([<backend>]) : integer
Returns an integer value corresponding to the sessions creation rate on the backend, in number of new sessions per second. This is used with ACLs to switch to an alternate backend when an expensive or fragile one reaches too high a session rate, or to limit abuse of service (eg. prevent sucking of an online dictionary). It can also be useful to add this element to logs using a log-format directive.

Example :

# Redirect to an error page if the dictionary is requested too often
        backend dynamic
            mode http
            acl being_scanned be_sess_rate gt 100
            redirect location /denied.html if being_scanned

connslots([<backend>]) : integer
Returns an integer value corresponding to the number of connection slots still available in the backend, by totaling the maximum amount of connections on all servers and the maximum queue size. This is probably only used with ACLs.

The basic idea here is to be able to measure the number of connection “slots” still available (connection + queue), so that anything beyond that (intended usage; see “use_backend” keyword) can be redirected to a different backend.

connslots‘ = number of available server connection slots, + number of available server queue slots.

Note that while “fe_conn” may be used, “connslots” comes in especially useful when you have a case of traffic going to one single ip, splitting into multiple backends (perhaps using ACLs to do name-based load balancing) and you want to be able to differentiate between different backends, and their available “connslots”. Also, whereas “nbsrv” only measures servers that are actually *down*, this fetch is more fine-grained and looks into the number of available connection slots as well. See also “queue” and “avg_queue”.

OTHER CAVEATS AND NOTES: at this point in time, the code does not take care of dynamic connections. Also, if any of the server maxconn, or maxqueue is 0, then this fetch clearly does not make sense, in which case the value returned will be -1.

date([<offset>]) : integer
Returns the current date as the epoch (number of seconds since 01/01/1970). If an offset value is specified, then it is a number of seconds that is added to the current date before returning the value. This is particularly useful to compute relative dates, as both positive and negative offsets are allowed.
It is useful combined with the http_date converter.

Example :

# set an expires header to now+1 hour in every response
     http-response set-header Expires %[date(3600),http_date]

env(<name>) : string
Returns a string containing the value of environment variable <name>. As a reminder, environment variables are per-process and are sampled when the process starts. This can be useful to pass some information to a next hop server, or with ACLs to take specific action when the process is started a certain way.

Examples :

# Pass the Via header to next hop with the local hostname in it
      http-request add-header Via 1.1\ %[env(HOSTNAME)]

      # reject cookie-less requests when the STOP environment variable is set
      http-request deny if !{ cook(SESSIONID) -m found } { env(STOP) -m found }

fe_conn([<frontend>]) : integer
Returns the number of currently established connections on the frontend, possibly including the connection being evaluated. If no frontend name is specified, the current one is used. But it is also possible to check another frontend. It can be used to return a sorry page before hard-blocking, or to use a specific backend to drain new requests when the farm is considered full. This is mostly used with ACLs but can also be used to pass some statistics to servers in HTTP headers. See also the “dst_conn”, “be_conn”, “fe_sess_rate” fetches.

fe_sess_rate([<frontend>]) : integer
Returns an integer value corresponding to the sessions creation rate on the frontend, in number of new sessions per second. This is used with ACLs to limit the incoming session rate to an acceptable range in order to prevent abuse of service at the earliest moment, for example when combined with other layer 4 ACLs in order to force the clients to wait a bit for the rate to go down below the limit. It can also be useful to add this element to logs using a log-format directive. See also the “rate-limit sessions” directive for use in frontends.

Example :

# This frontend limits incoming mails to 10/s with a max of 100
        # concurrent connections. We accept any connection below 10/s, and
        # force excess clients to wait for 100 ms. Since clients are limited to
        # 100 max, there cannot be more than 10 incoming mails per second.
        frontend mail
            bind :25
            mode tcp
            maxconn 100
            acl too_fast fe_sess_rate ge 10
            tcp-request inspect-delay 100ms
            tcp-request content accept if ! too_fast
            tcp-request content accept if WAIT_END

nbsrv([<backend>]) : integer
Returns an integer value corresponding to the number of usable servers of either the current backend or the named backend. This is mostly used with ACLs but can also be useful when added to logs. This is normally used to switch to an alternate backend when the number of servers is too low to to handle some load. It is useful to report a failure when combined with “monitor fail”.

queue([<backend>]) : integer
Returns the total number of queued connections of the designated backend, including all the connections in server queues. If no backend name is specified, the current one is used, but it is also possible to check another one. This is useful with ACLs or to pass statistics to backend servers. This can be used to take actions when queuing goes above a known level, generally indicating a surge of traffic or a massive slowdown on the servers. One possible action could be to reject new users but still accept old ones. See also the “avg_queue”, “be_conn”, and “be_sess_rate” fetches.

rand([<range>]) : integer
Returns a random integer value within a range of <range> possible values, starting at zero. If the range is not specified, it defaults to 2^32, which gives numbers between 0 and 4294967295. It can be useful to pass some values needed to take some routing decisions for example, or just for debugging purposes. This random must not be used for security purposes.

srv_conn([<backend>/]<server>) : integer
Returns an integer value corresponding to the number of currently established connections on the designated server, possibly including the connection being evaluated. If <backend> is omitted, then the server is looked up in the current backend. It can be used to use a specific farm when one server is full, or to inform the server about our view of the number of active connections with it. See also the “fe_conn”, “be_conn” and “queue” fetch methods.

srv_is_up([<backend>/]<server>) : boolean
Returns true when the designated server is UP, and false when it is either DOWN or in maintenance mode. If <backend> is omitted, then the server is looked up in the current backend. It is mainly used to take action based on an external status reported via a health check (eg: a geographical site’s availability). Another possible use which is more of a hack consists in using dummy servers as boolean variables that can be enabled or disabled from the CLI, so that rules depending on those ACLs can be tweaked in realtime.

srv_sess_rate([<backend>/]<server>) : integer
Returns an integer corresponding to the sessions creation rate on the designated server, in number of new sessions per second. If <backend> is omitted, then the server is looked up in the current backend. This is mostly used with ACLs but can make sense with logs too. This is used to switch to an alternate backend when an expensive or fragile one reaches too high a session rate, or to limit abuse of service (eg. prevent latent requests from overloading servers).

Example :

# Redirect to a separate back
        acl srv1_full srv_sess_rate(be1/srv1) gt 50
        acl srv2_full srv_sess_rate(be1/srv2) gt 50
        use_backend be2 if srv1_full or srv2_full

table_avl([<table>]) : integer
Returns the total number of available entries in the current proxy’s stick-table or in the designated stick-table. See also table_cnt.

table_cnt([<table>]) : integer
Returns the total number of entries currently in use in the current proxy’s stick-table or in the designated stick-table. See also src_conn_cnt and table_avl for other entry counting methods.

Share Button

7. Using ACLs and fetching samples



Haproxy is capable of extracting data from request or response streams, from client or server information, from tables, environmental information etc…

The action of extracting such data is called fetching a sample. Once retrieved, these samples may be used for various purposes such as a key to a stick-table, but most common usages consist in matching them against predefined constant data called patterns.

Share Button