Create or update a stick-table entry in the table. If the key is not present,
an entry is inserted. See stick-table in section 4.2 to find all possible
values for <data_type>. The most likely use consists in dynamically entering
entries for source IP addresses, with a flag in gpc0 to dynamically block an
IP address or affect its quality of service. It is possible to pass multiple
data_types in a single call.

set timeout cli

Change the CLI interface timeout for current connection. This can be useful
during long debugging sessions where the user needs to constantly inspect
some indicators without being disconnected. The delay is passed in seconds.

set weight / [%]

Change a server's weight to the value passed in argument. If the value ends
with the '%' sign, then the new weight will be relative to the initially
configured weight.  Absolute weights are permitted between 0 and 256.
Relative weights must be positive with the resulting absolute weight is
capped at 256.  Servers which are part of a farm running a static
load-balancing algorithm have stricter limitations because the weight
cannot change once set. Thus for these servers, the only accepted values
are 0 and 100% (or 0 and the initial weight). Changes take effect
immediately, though certain LB algorithms require a certain amount of
requests to consider changes. A typical usage of this command is to
disable a server during an update by setting its weight to zero, then to
enable it again after the update by setting it back to 100%. This command
is restricted and can only be issued on sockets configured for level
"admin". Both the backend and the server may be specified either by their
name or by their numeric ID, prefixed with a sharp ('#').

show acl []

Dump info about acl converters. Without argument, the list of all available
acls is returned. If a <acl> is specified, its contents are dumped. <acl> if
the #<id> or <file>. The dump format is the same than the map even for the
sample value. The data returned are not a list of available ACL, but are the
list of all patterns composing any ACL. Many of these patterns can be shared
with maps.

show backend

Dump the list of backends available in the running process

show cli level

Display the CLI level of the current CLI session. The result could be
'admin', 'operator' or 'user'. See also the 'operator' and 'user' commands.

Example :

$ socat /tmp/sock1 readline
prompt
> operator
> show cli level
operator
> user
> show cli level
user
> operator
Permission denied

operator

Decrease the CLI level of the current CLI session to operator. It can't be
increase. See also "show cli level"

user

Decrease the CLI level of the current CLI session to user. It can't be
increase. See also "show cli level"

show activity

Reports some counters about internal events that will help developers and
more generally people who know haproxy well enough to narrow down the causes
of reports of abnormal behaviours. A typical example would be a properly
running process never sleeping and eating 100% of the CPU. The output fields
will be made of one line per metric, and per-thread counters on the same
line. These counters are 32-bit and will wrap during the process' life, which
is not a problem since calls to this command will typically be performed
twice. The fields are purposely not documented so that their exact meaning is
verified in the code where the counters are fed. These values are also reset
by the "clear counters" command.

show cli sockets

List CLI sockets. The output format is composed of 3 fields separated by
spaces. The first field is the socket address, it can be a unix socket, a
ipv4 address:port couple or a ipv6 one. Socket of other types won't be dump.
The second field describe the level of the socket: 'admin', 'user' or
'operator'. The last field list the processes on which the socket is bound,
separated by commas, it can be numbers or 'all'.

Example :

$ echo 'show cli sockets' | socat stdio /tmp/sock1
# socket lvl processes
/tmp/sock1 admin all
127.0.0.1:9999 user 2,3,4
127.0.0.2:9969 user 2
[::1]:9999 operator 2

show cache

List the configured caches and the objects stored in each cache tree.
 
$ echo 'show cache' | socat stdio /tmp/sock1
0x7f6ac6c5b03a: foobar (shctx:0x7f6ac6c5b000, available blocks:3918)
       1          2             3                             4
 
1. pointer to the cache structure
2. cache name
3. pointer to the mmap area (shctx)
4. number of blocks available for reuse in the shctx
 
0x7f6ac6c5b4cc hash:286881868 size:39114 (39 blocks), refcount:9, expire:237
         1               2            3        4            5           6
 
1. pointer to the cache entry
2. first 32 bits of the hash
3. size of the object in bytes
4. number of blocks used for the object
5. number of transactions using the entry
6. expiration time, can be negative if already expired

show env []

Dump one or all environment variables known by the process. Without any
argument, all variables are dumped. With an argument, only the specified
variable is dumped if it exists. Otherwise "Variable not found" is emitted.
Variables are dumped in the same format as they are stored or returned by the
"env" utility, that is, "<name>=<value>". This can be handy when debugging
certain configuration files making heavy use of environment variables to
ensure that they contain the expected values. This command is restricted and
can only be issued on sockets configured for levels "operator" or "admin".

show errors [|] [request|response]

Dump last known request and response errors collected by frontends and
backends. If <iid> is specified, the limit the dump to errors concerning
either frontend or backend whose ID is <iid>. Proxy ID "-1" will cause
all instances to be dumped. If a proxy name is specified instead, its ID
will be used as the filter. If "request" or "response" is added after the
proxy name or ID, only request or response errors will be dumped. This
command is restricted and can only be issued on sockets configured for
levels "operator" or "admin".
 
The errors which may be collected are the last request and response errors
caused by protocol violations, often due to invalid characters in header
names. The report precisely indicates what exact character violated the
protocol. Other important information such as the exact date the error was
detected, frontend and backend names, the server name (when known), the
internal session ID and the source address which has initiated the session
are reported too.
 
All characters are returned, and non-printable characters are encoded. The
most common ones (\t = 9, \n = 10, \r = 13 and \e = 27) are encoded as one
letter following a backslash. The backslash itself is encoded as '\\' to
avoid confusion. Other non-printable characters are encoded '\xNN' where
NN is the two-digits hexadecimal representation of the character's ASCII
code.
 
Lines are prefixed with the position of their first character, starting at 0
for the beginning of the buffer. At most one input line is printed per line,
and large lines will be broken into multiple consecutive output lines so that
the output never goes beyond 79 characters wide. It is easy to detect if a
line was broken, because it will not end with '\n' and the next line's offset
will be followed by a '+' sign, indicating it is a continuation of previous
line.

Example :

    $ echo "show errors -1 response" | socat stdio /tmp/sock1
>>> [04/Mar/2009:15:46:56.081] backend http-in (#2) : invalid response
      src 127.0.0.1, session #54, frontend fe-eth0 (#1), server s2 (#1)
      response length 213 bytes, error at position 23:
      00000  HTTP/1.0 200 OK\r\n
      00017  header/bizarre:blah\r\n
      00038  Location: blah\r\n
      00054  Long-line: this is a very long line which should b
      00104+ e broken into multiple lines on the output buffer,
      00154+  otherwise it would be too large to print in a ter
      00204+ minal\r\n
      00211  \r\n
In the example above, we see that the backend "http-in" which has internal
ID 2 has blocked an invalid response from its server s2 which has internal
ID 1. The request was on session 54 initiated by source 127.0.0.1 and
received by frontend fe-eth0 whose ID is 1. The total response length was
213 bytes when the error was detected, and the error was at byte 23. This
is the slash ('/') in header name "header/bizarre", which is not a valid
HTTP character for a header name.

show fd []

Dump the list of either all open file descriptors or just the one number <fd>
if specified. This is only aimed at developers who need to observe internal
states in order to debug complex issues such as abnormal CPU usages. One fd
is reported per lines, and for each of them, its state in the poller using
upper case letters for enabled flags and lower case for disabled flags, using
"P" for "polled", "R" for "ready", "A" for "active", the events status using
"H" for "hangup", "E" for "error", "O" for "output", "P" for "priority" and
"I" for "input", a few other flags like "N" for "new" (just added into the fd
cache), "U" for "updated" (received an update in the fd cache), "L" for
"linger_risk", "C" for "cloned", then the cached entry position, the pointer
to the internal owner, the pointer to the I/O callback and its name when
known. When the owner is a connection, the connection flags, and the target
are reported (frontend, proxy or server). When the owner is a listener, the
listener's state and its frontend are reported. There is no point in using
this command without a good knowledge of the internals. It's worth noting
that the output format may evolve over time so this output must not be parsed
by tools designed to be durable.

show info [typed|json]

Dump info about haproxy status on current process. If "typed" is passed as an
optional argument, field numbers, names and types are emitted as well so that
external monitoring products can easily retrieve, possibly aggregate, then
report information found in fields they don't know. Each field is dumped on
its own line. If "json" is passed as an optional argument then
information provided by "typed" output is provided in JSON format as a
list of JSON objects. By default, the format contains only two columns
delimited by a colon (':'). The left one is the field name and the right
one is the value.  It is very important to note that in typed output
format, the dump for a single object is contiguous so that there is no
need for a consumer to store everything at once.
 
When using the typed output format, each line is made of 4 columns delimited
by colons (':'). The first column is a dot-delimited series of 3 elements. The
first element is the numeric position of the field in the list (starting at
zero). This position shall not change over time, but holes are to be expected,
depending on build options or if some fields are deleted in the future. The
second element is the field name as it appears in the default "show info"
output. The third element is the relative process number starting at 1.
 
The rest of the line starting after the first colon follows the "typed output
format" described in the section above. In short, the second column (after the
first ':') indicates the origin, nature and scope of the variable. The third
column indicates the type of the field, among "s32", "s64", "u32", "u64" and
"str". Then the fourth column is the value itself, which the consumer knows
how to parse thanks to column 3 and how to process thanks to column 2.
 
Thus the overall line format in typed mode is :
 
    <field_pos>.<field_name>.<process_num>:<tags>:<type>:<value>

Example :

> show info
Name: HAProxy
Version: 1.7-dev1-de52ea-146
Release_date: 2016/03/11
Nbproc: 1
Process_num: 1
Pid: 28105
Uptime: 0d 0h00m04s
Uptime_sec: 4
Memmax_MB: 0
PoolAlloc_MB: 0
PoolUsed_MB: 0
PoolFailed: 0
(...)
> show info typed
0.Name.1:POS:str:HAProxy
1.Version.1:POS:str:1.7-dev1-de52ea-146
2.Release_date.1:POS:str:2016/03/11
3.Nbproc.1:CGS:u32:1
4.Process_num.1:KGP:u32:1
5.Pid.1:SGP:u32:28105
6.Uptime.1:MDP:str:0d 0h00m08s
7.Uptime_sec.1:MDP:u32:8
8.Memmax_MB.1:CLP:u32:0
9.PoolAlloc_MB.1:MGP:u32:0
10.PoolUsed_MB.1:MGP:u32:0
11.PoolFailed.1:MCP:u32:0
(...)

In the typed format, the presence of the process ID at the end of the
first column makes it very easy to visually aggregate outputs from
multiple processes.

Example :

$ ( echo show info typed | socat /var/run/haproxy.sock1 ;    \
    echo show info typed | socat /var/run/haproxy.sock2 ) |  \
  sort -t . -k 1,1n -k 2,2 -k 3,3n
0.Name.1:POS:str:HAProxy
0.Name.2:POS:str:HAProxy
1.Version.1:POS:str:1.7-dev1-868ab3-148
1.Version.2:POS:str:1.7-dev1-868ab3-148
2.Release_date.1:POS:str:2016/03/11
2.Release_date.2:POS:str:2016/03/11
3.Nbproc.1:CGS:u32:2
3.Nbproc.2:CGS:u32:2
4.Process_num.1:KGP:u32:1
4.Process_num.2:KGP:u32:2
5.Pid.1:SGP:u32:30120
5.Pid.2:SGP:u32:30121
6.Uptime.1:MDP:str:0d 0h01m28s
6.Uptime.2:MDP:str:0d 0h01m28s
(...)

The format of JSON output is described in a schema which may be output
using "show schema json".
 
The JSON output contains no extra whitespace in order to reduce the
volume of output. For human consumption passing the output through a
pretty printer may be helpful. Example :
 
$ echo "show info json" | socat /var/run/haproxy.sock stdio | \
  python -m json.tool
 
The JSON output contains no extra whitespace in order to reduce the
volume of output. For human consumption passing the output through a
pretty printer may be helpful. Example :
 
$ echo "show info json" | socat /var/run/haproxy.sock stdio | \
  python -m json.tool

show map [

Dump info about map converters. Without argument, the list of all available
maps is returned. If a <map> is specified, its contents are dumped. <map> is
the #<id> or <file>. The first column is a unique identifier. It can be used
as reference for the operation "del map" and "set map". The second column is
the pattern and the third column is the sample if available. The data returned
are not directly a list of available maps, but are the list of all patterns
composing any map. Many of these patterns can be shared with ACL.

show peers []

Dump info about the peers configured in "peers" sections. Without argument,
the list of the peers belonging to all the "peers" sections are listed. If
<peers section> is specified, only the information about the peers belonging
to this "peers" section are dumped.
 
Here are two examples of outputs where hostA, hostB and hostC peers belong to
"sharedlb" peers sections. Only hostA and hostB are connected. Only hostA has
sent data to hostB.
 
$ echo "show peers" | socat - /tmp/hostA
0x55deb0224320: [15/Apr/2019:11:28:01] id=sharedlb state=0 flags=0x3 \
  resync_timeout=<PAST> task_calls=45122
    0x55deb022b540: id=hostC(remote) addr=127.0.0.12:10002 status=CONN \
      reconnect=4s confirm=0
      flags=0x0
    0x55deb022a440: id=hostA(local) addr=127.0.0.10:10000 status=NONE \
      reconnect=<NEVER> confirm=0
      flags=0x0
    0x55deb0227d70: id=hostB(remote) addr=127.0.0.11:10001 status=ESTA
      reconnect=2s confirm=0
      flags=0x20000200 appctx:0x55deb028fba0 st0=7 st1=0 task_calls=14456 \
        state=EST
      xprt=RAW src=127.0.0.1:37257 addr=127.0.0.10:10000
      remote_table:0x55deb0224a10 id=stkt local_id=1 remote_id=1
      last_local_table:0x55deb0224a10 id=stkt local_id=1 remote_id=1
      shared tables:
        0x55deb0224a10 local_id=1 remote_id=1 flags=0x0 remote_data=0x65
          last_acked=0 last_pushed=3 last_get=0 teaching_origin=0 update=3
          table:0x55deb022d6a0 id=stkt update=3 localupdate=3 \
            commitupdate=3 syncing=0
 
$ echo "show peers" | socat - /tmp/hostB
0x55871b5ab320: [15/Apr/2019:11:28:03] id=sharedlb state=0 flags=0x3 \
  resync_timeout=<PAST> task_calls=3
    0x55871b5b2540: id=hostC(remote) addr=127.0.0.12:10002 status=CONN \
      reconnect=3s confirm=0
      flags=0x0
    0x55871b5b1440: id=hostB(local) addr=127.0.0.11:10001 status=NONE \
      reconnect=<NEVER> confirm=0
      flags=0x0
    0x55871b5aed70: id=hostA(remote) addr=127.0.0.10:10000 status=ESTA \
      reconnect=2s confirm=0
      flags=0x20000200 appctx:0x7fa46800ee00 st0=7 st1=0 task_calls=62356 \
        state=EST
      remote_table:0x55871b5ab960 id=stkt local_id=1 remote_id=1
      last_local_table:0x55871b5ab960 id=stkt local_id=1 remote_id=1
      shared tables:
        0x55871b5ab960 local_id=1 remote_id=1 flags=0x0 remote_data=0x65
          last_acked=3 last_pushed=0 last_get=3 teaching_origin=0 update=0
          table:0x55871b5b46a0 id=stkt update=1 localupdate=0 \
            commitupdate=0 syncing=0

show pools

Dump the status of internal memory pools. This is useful to track memory
usage when suspecting a memory leak for example. It does exactly the same
as the SIGQUIT when running in foreground except that it does not flush
the pools.

show profiling

Dumps the current profiling settings, one per line, as well as the command
needed to change them.

show servers state []

Dump the state of the servers found in the running configuration. A backend
name or identifier may be provided to limit the output to this backend only.
 
The dump has the following format:
 - first line contains the format version (1 in this specification);
 - second line contains the column headers, prefixed by a sharp ('#');
 - third line and next ones contain data;
 - each line starting by a sharp ('#') is considered as a comment.
 
Since multiple versions of the output may co-exist, below is the list of
fields and their order per file format version :
 1:
   be_id:                       Backend unique id.
   be_name:                     Backend label.
   srv_id:                      Server unique id (in the backend).
   srv_name:                    Server label.
   srv_addr:                    Server IP address.
   srv_op_state:                Server operational state (UP/DOWN/...).
                                  0 = SRV_ST_STOPPED
                                    The server is down.
                                  1 = SRV_ST_STARTING
                                    The server is warming up (up but
                                    throttled).
                                  2 = SRV_ST_RUNNING
                                    The server is fully up.
                                  3 = SRV_ST_STOPPING
                                    The server is up but soft-stopping
                                    (eg: 404).
   srv_admin_state:             Server administrative state (MAINT/DRAIN/...).
                                The state is actually a mask of values :
                                  0x01 = SRV_ADMF_FMAINT
                                    The server was explicitly forced into
                                    maintenance.
                                  0x02 = SRV_ADMF_IMAINT
                                    The server has inherited the maintenance
                                    status from a tracked server.
                                  0x04 = SRV_ADMF_CMAINT
                                    The server is in maintenance because of
                                    the configuration.
                                  0x08 = SRV_ADMF_FDRAIN
                                    The server was explicitly forced into
                                    drain state.
                                  0x10 = SRV_ADMF_IDRAIN
                                    The server has inherited the drain status
                                    from a tracked server.
                                  0x20 = SRV_ADMF_RMAINT
                                    The server is in maintenance because of an
                                    IP address resolution failure.
                                  0x40 = SRV_ADMF_HMAINT
                                    The server FQDN was set from stats socket.
 
   srv_uweight:                 User visible server's weight.
   srv_iweight:                 Server's initial weight.
   srv_time_since_last_change:  Time since last operational change.
   srv_check_status:            Last health check status.
   srv_check_result:            Last check result (FAILED/PASSED/...).
                                  0 = CHK_RES_UNKNOWN
                                    Initialized to this by default.
                                  1 = CHK_RES_NEUTRAL
                                    Valid check but no status information.
                                  2 = CHK_RES_FAILED
                                    Check failed.
                                  3 = CHK_RES_PASSED
                                    Check succeeded and server is fully up
                                    again.
                                  4 = CHK_RES_CONDPASS
                                    Check reports the server doesn't want new
                                    sessions.
   srv_check_health:            Checks rise / fall current counter.
   srv_check_state:             State of the check (ENABLED/PAUSED/...).
                                The state is actually a mask of values :
                                  0x01 = CHK_ST_INPROGRESS
                                    A check is currently running.
                                  0x02 = CHK_ST_CONFIGURED
                                    This check is configured and may be
                                    enabled.
                                  0x04 = CHK_ST_ENABLED
                                    This check is currently administratively
                                    enabled.
                                  0x08 = CHK_ST_PAUSED
                                    Checks are paused because of maintenance
                                    (health only).
   srv_agent_state:             State of the agent check (ENABLED/PAUSED/...).
                                This state uses the same mask values as
                                "srv_check_state", adding this specific one :
                                  0x10 = CHK_ST_AGENT
                                    Check is an agent check (otherwise it's a
                                    health check).
   bk_f_forced_id:              Flag to know if the backend ID is forced by
                                configuration.
   srv_f_forced_id:             Flag to know if the server's ID is forced by
                                configuration.
   srv_fqdn:                    Server FQDN.
   srv_port:                    Server port.
   srvrecord:                   DNS SRV record associated to this SRV.

show sess

Dump all known sessions. Avoid doing this on slow connections as this can
be huge. This command is restricted and can only be issued on sockets
configured for levels "operator" or "admin".

show sess

Display a lot of internal information about the specified session identifier.
This identifier is the first field at the beginning of the lines in the dumps
of "show sess" (it corresponds to the session pointer). Those information are
useless to most users but may be used by haproxy developers to troubleshoot a
complex bug. The output format is intentionally not documented so that it can
freely evolve depending on demands. You may find a description of all fields
returned in src/dumpstats.c
 
The special id "all" dumps the states of all sessions, which must be avoided
as much as possible as it is highly CPU intensive and can take a lot of time.

show stat [{|} ] [typed|json]

Dump statistics using the CSV format; using the extended typed output
format described in the section above if "typed" is passed after the
other arguments; or in JSON if "json" is passed after the other arguments
. By passing <id>, <type> and <sid>, it is possible to dump only selected
items :
  - <iid> is a proxy ID, -1 to dump everything. Alternatively, a proxy name
    <proxy> may be specified. In this case, this proxy's ID will be used as
    the ID selector.
  - <type> selects the type of dumpable objects : 1 for frontends, 2 for
     backends, 4 for servers, -1 for everything. These values can be ORed,
     for example:
        1 + 2     = 3   -> frontend + backend.
        1 + 2 + 4 = 7   -> frontend + backend + server.
  - <sid> is a server ID, -1 to dump everything from the selected proxy.

Example :

    $ echo "show info;show stat" | socat stdio unix-connect:/tmp/sock1
>>> Name: HAProxy
    Version: 1.4-dev2-49
    Release_date: 2009/09/23
    Nbproc: 1
    Process_num: 1
    (...)
    # pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,  (...)
    stats,FRONTEND,,,0,0,1000,0,0,0,0,0,0,,,,,OPEN,,,,,,,,,1,1,0, (...)
    stats,BACKEND,0,0,0,0,1000,0,0,0,0,0,,0,0,0,0,UP,0,0,0,,0,250,(...)
    (...)
    www1,BACKEND,0,0,0,0,1000,0,0,0,0,0,,0,0,0,0,UP,1,1,0,,0,250, (...)
    $

In this example, two commands have been issued at once. That way it's easy to
find which process the stats apply to in multi-process mode. This is not
needed in the typed output format as the process number is reported on each
line.  Notice the empty line after the information output which marks the end
of the first block.  A similar empty line appears at the end of the second
block (stats) so that the reader knows the output has not been truncated.
 
When "typed" is specified, the output format is more suitable to monitoring
tools because it provides numeric positions and indicates the type of each
output field. Each value stands on its own line with process number, element
number, nature, origin and scope. This same format is available via the HTTP
stats by passing ";typed" after the URI. It is very important to note that in
typed output format, the dump for a single object is contiguous so that there
is no need for a consumer to store everything at once.
 
When using the typed output format, each line is made of 4 columns delimited
by colons (':'). The first column is a dot-delimited series of 5 elements. The
first element is a letter indicating the type of the object being described.
At the moment the following object types are known : 'F' for a frontend, 'B'
for a backend, 'L' for a listener, and 'S' for a server. The second element
The second element is a positive integer representing the unique identifier of
the proxy the object belongs to. It is equivalent to the "iid" column of the
CSV output and matches the value in front of the optional "id" directive found
in the frontend or backend section. The third element is a positive integer
containing the unique object identifier inside the proxy, and corresponds to
the "sid" column of the CSV output. ID 0 is reported when dumping a frontend
or a backend. For a listener or a server, this corresponds to their respective
ID inside the proxy. The fourth element is the numeric position of the field
in the list (starting at zero). This position shall not change over time, but
holes are to be expected, depending on build options or if some fields are
deleted in the future. The fifth element is the field name as it appears in
the CSV output. The sixth element is a positive integer and is the relative
process number starting at 1.
 
The rest of the line starting after the first colon follows the "typed output
format" described in the section above. In short, the second column (after the
first ':') indicates the origin, nature and scope of the variable. The third
column indicates the type of the field, among "s32", "s64", "u32", "u64" and
"str". Then the fourth column is the value itself, which the consumer knows
how to parse thanks to column 3 and how to process thanks to column 2.
 
Thus the overall line format in typed mode is :
 
    <obj>.<px_id>.<id>.<fpos>.<fname>.<process_num>:<tags>:<type>:<value>
 
Here's an example of typed output format :
 
      $ echo "show stat typed" | socat stdio unix-connect:/tmp/sock1
      F.2.0.0.pxname.1:MGP:str:private-frontend
      F.2.0.1.svname.1:MGP:str:FRONTEND
      F.2.0.8.bin.1:MGP:u64:0
      F.2.0.9.bout.1:MGP:u64:0
      F.2.0.40.hrsp_2xx.1:MGP:u64:0
      L.2.1.0.pxname.1:MGP:str:private-frontend
      L.2.1.1.svname.1:MGP:str:sock-1
      L.2.1.17.status.1:MGP:str:OPEN
      L.2.1.73.addr.1:MGP:str:0.0.0.0:8001
      S.3.13.60.rtime.1:MCP:u32:0
      S.3.13.61.ttime.1:MCP:u32:0
      S.3.13.62.agent_status.1:MGP:str:L4TOUT
      S.3.13.64.agent_duration.1:MGP:u64:2001
      S.3.13.65.check_desc.1:MCP:str:Layer4 timeout
      S.3.13.66.agent_desc.1:MCP:str:Layer4 timeout
      S.3.13.67.check_rise.1:MCP:u32:2
      S.3.13.68.check_fall.1:MCP:u32:3
      S.3.13.69.check_health.1:SGP:u32:0
      S.3.13.70.agent_rise.1:MaP:u32:1
      S.3.13.71.agent_fall.1:SGP:u32:1
      S.3.13.72.agent_health.1:SGP:u32:1
      S.3.13.73.addr.1:MCP:str:1.255.255.255:8888
      S.3.13.75.mode.1:MAP:str:http
      B.3.0.0.pxname.1:MGP:str:private-backend
      B.3.0.1.svname.1:MGP:str:BACKEND
      B.3.0.2.qcur.1:MGP:u32:0
      B.3.0.3.qmax.1:MGP:u32:0
      B.3.0.4.scur.1:MGP:u32:0
      B.3.0.5.smax.1:MGP:u32:0
      B.3.0.6.slim.1:MGP:u32:1000
      B.3.0.55.lastsess.1:MMP:s32:-1
      (...)
 
In the typed format, the presence of the process ID at the end of the
first column makes it very easy to visually aggregate outputs from
multiple processes, as show in the example below where each line appears
for each process :
 
      $ ( echo show stat typed | socat /var/run/haproxy.sock1 - ; \
          echo show stat typed | socat /var/run/haproxy.sock2 - ) | \
        sort -t . -k 1,1 -k 2,2n -k 3,3n -k 4,4n -k 5,5 -k 6,6n
      B.3.0.0.pxname.1:MGP:str:private-backend
      B.3.0.0.pxname.2:MGP:str:private-backend
      B.3.0.1.svname.1:MGP:str:BACKEND
      B.3.0.1.svname.2:MGP:str:BACKEND
      B.3.0.2.qcur.1:MGP:u32:0
      B.3.0.2.qcur.2:MGP:u32:0
      B.3.0.3.qmax.1:MGP:u32:0
      B.3.0.3.qmax.2:MGP:u32:0
      B.3.0.4.scur.1:MGP:u32:0
      B.3.0.4.scur.2:MGP:u32:0
      B.3.0.5.smax.1:MGP:u32:0
      B.3.0.5.smax.2:MGP:u32:0
      B.3.0.6.slim.1:MGP:u32:1000
      B.3.0.6.slim.2:MGP:u32:1000
      (...)
 
The format of JSON output is described in a schema which may be output
using "show schema json".
 
The JSON output contains no extra whitespace in order to reduce the
volume of output. For human consumption passing the output through a
pretty printer may be helpful. Example :
 
$ echo "show stat json" | socat /var/run/haproxy.sock stdio | \
  python -m json.tool
 
The JSON output contains no extra whitespace in order to reduce the
volume of output. For human consumption passing the output through a
pretty printer may be helpful. Example :
 
$ echo "show stat json" | socat /var/run/haproxy.sock stdio | \
  python -m json.tool