文档贡献者须知：本文档每行格式化为 80 列，缩进使用偶数个空格，不使用制表符。请严格遵守这些规则，以便文档能够轻松地在任何地方打印。如果您添加章节，请更新下面的摘要以便于搜索。

本文档假设读者在类 UNIX 操作系统上拥有足够多的管理技能，日常使用 shell，并且熟悉 strace 和 tcpdump 等故障排除工具。

HAProxy 是一个单线程、事件驱动、非阻塞的守护进程。这意味着它使用事件多路复用技术来调度其所有活动，而不是依赖系统在多个活动之间进行调度。大多数时候它作为单个进程运行，因此在系统上执行 "ps aux" 的输出将只报告一个 "haproxy" 进程，除非正在进行软重载，并且旧进程正在与新进程并行完成其工作。因此，使用 strace 工具总是很容易追踪其活动。HAProxy 被设计为在启动期间将自己隔离在一个 chroot jail 中，在那里它根本无法执行任何文件系统访问。这也适用于它所依赖的库（例如：libc、libssl 等）。直接的影响是，正在运行的进程将无法重新加载配置文件以应用更改，而是会使用更新后的配置文件启动一个新进程。其他一些不太明显的影响是，libc 可能会在运行时尝试访问的某些时区文件或解析器文件将找不到，尽管这通常不应发生，因为它们在启动后是不需要的。这个原则的一个好处是 HAProxy 进程是完全无状态的，在它被杀死后不需要任何清理工作，所以任何有效的杀死方法都可以正常工作。HAProxy 不写入日志文件，但它依赖标准的 syslog 协议将日志发送到远程服务器（通常位于同一系统上）。HAProxy 使用其内部时钟来强制执行超时，该时钟源自系统时间，但会校正意外的漂移。这是通过限制在 poll() 中等待事件的时间，并测量实际花费的时间来实现的。实际上，它从不等待超过一秒。这就解释了为什么当在一个完全空闲的进程上运行 strace 时，会注意到周期性的 poll() 调用（或其任何变体）被两个 gettimeofday() 调用包围。这些是正常的，完全无害的，并且开销很小，以至于它们所带来的负载在系统级别上是完全无法检测到的，所以那里没有任何异常。示例： 16:35:40.002320 gettimeofday({1442759740, 2605}, NULL) = 0 16:35:40.002942 epoll_wait(0, {}, 200, 1000) = 0 16:35:41.007542 gettimeofday({1442759741, 7641}, NULL) = 0 16:35:41.007998 gettimeofday({1442759741, 8114}, NULL) = 0 16:35:41.008391 epoll_wait(0, {}, 200, 1000) = 0 16:35:42.011313 gettimeofday({1442759742, 11411}, NULL) = 0 HAProxy 是一个 TCP 代理，而不是路由器。它处理已由内核验证的已建立连接，而不处理任何形式的数据包或处于其他状态的套接字（例如：没有 SYN_RECV 或 TIME_WAIT），尽管它们的存在可能会阻止它绑定端口。它依赖系统来接受传入连接和发起传出连接。这一个直接影响是，在转发连接的两侧观察到的数据包之间没有关系，它们的大小、数量甚至协议族都可能不同。由于连接只能从处于 LISTEN 状态的套接字接受，因此它正在监听的所有套接字都必须通过使用 "netstat" 工具来显示监听套接字。示例： # netstat -ltnp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1629/sshd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 2847/haproxy tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 2847/haproxy

HAProxy 通过在命令行调用 "haproxy" 程序并带有一些参数来启动。实际语法是：$ haproxy [<options>]*

后跟一个或多个字母，并可能后跟一个或多个额外参数。不带任何选项时，HAProxy 会显示帮助页面，并提示支持的选项。可用选项可能因操作系统而略有不同。这些选项中有相当一部分与 "global" 部分中的等效选项重叠。在这种情况下，命令行总是优先于配置文件，这样命令行就可以用来快速强制执行某些设置，而无需修改配置文件。当前的选项列表是： -- <cfgfile>* : "--" 之后的所有参数都是要按声明顺序加载和处理的配置文件/目录的路径。当依赖 shell 加载许多按数字排序的文件时，这非常有用。另请参见 "-f"。"--" 和 "-f" 的区别在于，每个文件名之前必须放置一个 "-f"，而所有文件名之前只需要一个 "--"。这两个选项可以一起使用，命令行顺序仍然适用。当指定多个文件时，每个文件必须从一个节（section）边界开始，因此每个文件的第一个关键字必须是 "global"、"defaults"、"peers"、"listen"、"frontend"、"backend" 等之一。例如，一个文件不能只包含一个服务器列表。 -f <cfgfile|cfgdir> : 将 <cfgfile> 添加到要加载的配置文件列表中。如果 <cfgdir> 是一个目录，那么它包含的所有文件（且仅限文件）将按字典顺序（使用 LC_COLLATE=C）添加到要加载的配置文件列表中；只添加扩展名为 ".cfg" 的文件，只添加非隐藏文件（不以 "." 开头）。配置文件按其声明顺序加载和处理。此选项可以多次指定以加载多个文件。另请参见 "--"。" --" 和 "-f" 的区别在于，每个文件名之前必须放置一个 "-f"，而所有文件名之前只需要一个 "--"。这两个选项可以一起使用，命令行顺序仍然适用。当指定多个文件时，每个文件必须从一个节（section）边界开始，因此每个文件的第一个关键字必须是 "global"、"defaults"、"peers"、"listen"、"frontend"、"backend" 等之一。例如，一个文件不能只包含一个服务器列表。 -C <dir> : 在加载配置文件之前切换到目录 <dir>。在使用相对路径时这很有用。注意，当在 "--" 之后使用通配符时，通配符实际上在启动 haproxy 之前由 shell 替换。 -D : 作为守护进程启动。进程在派生（forking）后与当前终端分离，并且错误不再在终端中报告。它等同于配置中 "global" 部分的 "daemon" 关键字。建议在任何 init 脚本中始终强制使用它，以防止错误的配置阻止系统启动。 -L <name> : 将本地对等节点名称更改为 <name>，默认为本地主机名。这仅用于对等节点复制。 -N <limit> : 将每个代理的默认 maxconn 设置为 <limit>，而不是内置的默认值（通常是 2000）。仅用于调试。 -V : 启用详细模式（禁用安静模式）。撤销 "-q" 或 "quiet" 的效果。 -W : master-worker 模式。它等同于配置中 "global" 部分的 "master-worker" 关键字。此模式将启动一个 "master" 进程来监控 "worker" 进程。使用此模式，您可以通过向 master 发送 SIGUSR2 信号来直接重载 HAProxy。master-worker 模式与前台或守护进程模式兼容。建议在多进程和 systemd 环境下使用此模式。 -Ws : 支持 systemd 服务的 `notify` 类型的 master-worker 模式。此选项仅在 HAProxy 构建时启用了 `USE_SYSTEMD` 构建选项时可用。 -c : 仅对配置文件进行检查，并在尝试绑定之前退出。如果一切正常，退出状态为零；如果遇到错误，则为非零。 -d : 启用调试模式。这将禁用守护进程模式，强制进程保持在前台并显示传入和传出的事件。它等同于 "global" 部分的 "debug" 关键字。绝不能在 init 脚本中使用。 -dG : 禁用 getaddrinfo() 来将主机名解析为地址。当怀疑 getaddrinfo() 工作不正常时可以使用。提供此选项是因为许多系统上存在 getaddrinfo() 的错误实现，导致难以排查的异常。 -dM[<byte>] : 强制内存投毒，这意味着每个通过 malloc() 或 pool_alloc() 分配的内存区域在传递给调用者之前都会被填充为 <byte>。当未指定 <byte> 时，默认为 0x50 ('P')。虽然这会稍微减慢操作速度，但它有助于可靠地触发因代码中缺少初始化而导致随机崩溃的问题。请注意，-dM0 的效果是将任何 malloc() 转换为 calloc()。在任何情况下，如果使用此选项时某个错误出现或消失，这意味着 haproxy 中存在一个错误，请报告它。 -dS : 禁用 splice() 系统调用。它等同于 "global" 部分的 "nosplice" 关键字。当怀疑 splice() 行为不当或导致性能问题，或者使用 strace 查看转发的数据（使用 splice() 时不会出现）时，可以使用此选项。 -dV : 禁用服务器端的 SSL 验证。它等同于在 "global" 部分设置 "ssl-server-verify none"。当试图在生产环境之外重现生产问题时，这很有用。切勿在 init 脚本中使用此选项，因为它会降低到服务器的 SSL 安全性。 -db : 禁用后台模式和多进程模式。进程保持在前台。它主要用于开发或小型测试期间，因为 Ctrl-C 就足以停止进程。切勿在 init 脚本中使用。 -de : 禁用 "epoll" 轮询器。它等同于 "global" 部分的关键字 "noepoll"。当怀疑与此轮询器相关的错误时，这非常有用。在支持 epoll 的系统上，通常会回退到 "poll" 轮询器。 -dk : 禁用 "kqueue" 轮询器。它等同于 "global" 部分的关键字 "nokqueue"。当怀疑与此轮询器相关的错误时，这非常有用。在支持 kqueue 的系统上，通常会回退到 "poll" 轮询器。 -dp : 禁用 "poll" 轮询器。它等同于 "global" 部分的关键字 "nopoll"。当怀疑与此轮询器相关的错误时，这非常有用。在支持 poll 的系统上，通常会回退到 "select" 轮询器，该轮询器无法禁用且限制为 1024 个文件描述符。 -dr : 忽略服务器地址解析失败。在生产环境之外验证配置时，通常无法访问相同的解析器，导致服务器地址解析失败，从而难以测试配置。此选项只是将 "none" 方法附加到所有服务器的地址解析方法列表中，确保即使 libc 解析地址失败，启动序列也不会中断。 -m <limit> : 将所有进程的总可分配内存限制为 <limit> 兆字节。这可能会导致一些连接拒绝或一些减速，具体取决于正常操作所需的内存量。这主要用于强制进程在受限的资源使用场景下工作。需要注意的是，内存不在进程之间共享，因此在多进程场景中，此值在派生（forking）前首先除以 global.nbproc。 -n <limit> : 将每个进程的连接限制为 <limit>。这等同于 global 部分的关键字 "maxconn"。它优先于该关键字。这可用于快速强制降低限制，以避免在资源限制过低的系统上发生服务中断。 -p <file> : 在启动期间将所有进程的 pid 写入 <file>。这等同于 "global" 部分的关键字 "pidfile"。该文件在进入 chroot jail 之前，以及在执行 "-C" 暗示的 chdir() 之后打开。每个 pid 各占一行。 -q : 设置 "quiet" 模式。这会在配置解析和启动期间禁用一些消息。它可以与 "-c" 结合使用，仅检查配置文件是否有效。 -sf <pid>* : 在启动完成后向旧进程发送 "finish" 信号（SIGUSR1），要求它们完成正在做的事情并退出。<pid> 是要发送信号的 pid 列表（每个参数一个）。列表在任何以 "-" 开头的选项处结束。如果 pid 列表为空也没问题，因此可以根据 "pidof" 或 "pgrep" 等命令的结果动态构建。 -st <pid>* : 在启动完成后向旧进程发送 "terminate" 信号（SIGTERM），立即终止它们，而不完成它们正在做的事情。<pid> 是要发送信号的 pid 列表（每个参数一个）。列表在任何以 "-" 开头的选项处结束。如果 pid 列表为空也没问题，因此可以根据 "pidof" 或 "pgrep" 等命令的结果动态构建。 -v : 报告版本和构建日期。 -vv : 显示版本、构建选项、库版本和可用的轮询器。提交错误报告时系统地会要求提供此输出。 -x <unix_socket> : 连接到指定的套接字，并尝试从旧进程中检索任何监听套接字，并使用它们而不是尝试绑定新的套接字。这在 Linux 上重载配置时避免丢失任何新连接很有用。必须在您的配置中使用 "expose-fd listeners" 在 stats 套接字上启用此功能。 从 init 文件安全启动 HAProxy 的一种方法是强制守护进程模式，将现有 pid 存储到 pid 文件中，并使用此 pid 文件通知旧进程在退出前完成任务： haproxy -f /etc/haproxy.cfg \ -D -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) 当配置被分割成几个特定文件（例如：tcp vs http）时，建议使用 "-f" 选项： haproxy -f /etc/haproxy/global.cfg -f /etc/haproxy/stats.cfg \ -f /etc/haproxy/default-tcp.cfg -f /etc/haproxy/tcp.cfg \ -f /etc/haproxy/default-http.cfg -f /etc/haproxy/http.cfg \ -D -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) 当预期有未知数量的文件时，例如客户特定文件，建议为它们分配一个以固定长度序列号开头的名称，并使用 "--" 来加载它们，可能在加载一些默认配置之后： haproxy -f /etc/haproxy/global.cfg -f /etc/haproxy/stats.cfg \ -f /etc/haproxy/default-tcp.cfg -f /etc/haproxy/tcp.cfg \ -f /etc/haproxy/default-http.cfg -f /etc/haproxy/http.cfg \ -D -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid) \ -f /etc/haproxy/default-customers.cfg -- /etc/haproxy/customers/* 有时由于某种原因可能会启动失败。这时，验证您调用的 HAProxy 版本是否是预期版本，以及它是否支持您期望的功能（例如：SSL、PCRE、压缩、Lua 等）非常重要。这可以通过使用 "haproxy -vv" 来验证。一些重要信息，如某些构建选项、目标系统和所用库的版本都在那里报告。这也是您在提交错误报告时系统地会被要求提供的信息： $ haproxy -vv HA-Proxy version 1.6-dev7-a088d3-4 2015/10/08 Copyright 2000-2015 Willy Tarreau <willy@haproxy.org> Build options : TARGET = linux2628 CPU = generic CC = gcc CFLAGS = -pg -O0 -g -fno-strict-aliasing -Wdeclaration-after-statement \ -DBUFSIZE=8030 -DMAXREWRITE=1030 -DSO_MARK=36 -DTCP_REPAIR=19 OPTIONS = USE_ZLIB=1 USE_DLMALLOC=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 8030, maxrewrite = 1030, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.6 Compression algorithms supported : identity("identity"), deflate("deflate"), \ raw-deflate("deflate"), gzip("gzip") Built with OpenSSL version : OpenSSL 1.0.1o 12 Jun 2015 Running on OpenSSL version : OpenSSL 1.0.1o 12 Jun 2015 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 8.12 2011-01-15 PCRE library supports JIT : no (USE_PCRE_JIT not set) Built with Lua version : Lua 5.3.1 Built with transparent proxy support using: IP_TRANSPARENT IP_FREEBIND Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll. 许多非开发人员用户可以在这里验证的相关信息是： - 版本：上面的 1.6-dev7-a088d3-4 意味着代码当前位于提交 ID "a088d3"，这是官方版本 "1.6-dev7" 之后的第 4 个提交。版本 1.6-dev7 将显示为 "1.6-dev7-8c1ad7"。这里重要的是 "1.6-dev7"。这是未来将成为 1.6 版本的第 7 个开发版本。开发版本不适合在生产中使用（除非您确切知道自己在做什么）。稳定版本将显示为三段式版本号，例如 "1.5.14-16f863"，表示在 1.5 版本之上的第 14 个修复级别。这是一个生产就绪的版本。 - 发布日期：2015/10/08。它以通用的年/月/日格式表示。这里表示 2015 年 10 月 8 日。鉴于稳定版本每隔几个月发布一次（开始时 1-2 个月，一旦产品变得非常稳定，有时是 6 个月），如果您在这里看到一个旧日期，这意味着您可能受到一些自那时以来已修复的错误或安全问题的影响，可能值得在官方网站上查看。 - 构建选项：这些与自己构建软件包的人有关，它们可以解释为什么事情没有按预期进行。例如，上面的开发版本是为 Linux 2.6.28 或更高版本构建的，目标是通用 CPU（没有特定于 CPU 的优化），并且缺少任何代码优化（-O0），因此在性能方面会表现不佳。 - 库版本：zlib 版本是根据库本身报告的。通常，zlib 被认为是一个非常稳定的产品，几乎不需要升级。OpenSSL 报告两个版本，构建时使用的版本和正在使用的版本，如在系统上找到的那样。这些版本的最后一个字母可能不同，但数字永远不会不同。构建日期也被报告，因为大多数 OpenSSL 的错误都是安全问题，需要认真对待，所以这个库绝对需要保持最新。在这里看到一个 4 个月前的版本是高度可疑的，并且确实错过了更新。PCRE 提供非常快的正则表达式，强烈推荐。它的某些扩展，如 JIT，并非在所有版本中都存在，而且还很新，所以有些人不喜欢用它们来构建，这就是为什么构建状态也被报告的原因。关于 Lua 脚本语言，HAProxy 期望版本 5.3，这个版本非常新，因为它是在 HAProxy 1.6 之前不久发布的。在 Lua 网站上检查该分支是否有修复建议是很重要的。 - 可用轮询系统将影响进程在处理超过约一千个并发连接时的可扩展性。这些只有在构建期间在 TARGET 变量中指定了正确的系统时才可用。在 Linux 上强烈推荐 "epoll" 机制，在 BSD 上强烈推荐 kqueue 机制。缺少它们将导致使用 poll() 甚至 select()，在处理大量连接时会导致高 CPU 使用率。

HAProxy 支持平滑停止和硬停止。硬停止很简单，当向 haproxy 进程发送 SIGTERM 信号时，它会立即退出，所有已建立的连接都会被关闭。平滑停止是在向 haproxy 进程发送 SIGUSR1 信号时触发的。它只包括从监听端口解绑，但继续处理现有连接直到它们关闭。一旦最后一个连接关闭，进程就会退出。硬停止方法用于服务管理脚本的 "stop" 或 "restart" 操作。平滑停止用于 "reload" 操作，该操作试图在新进程中无缝地重新加载新配置。这两个信号都可以在重载或重启期间由新的 haproxy 进程自己发送，以便它们在尽可能晚的时刻发送，并且仅在绝对需要时才发送。这就是分别由 "-st" (硬) 和 "-sf" (平滑) 选项执行的操作。在 master-worker 模式下，不需要启动新的 haproxy 进程来重新加载配置。master 进程对 SIGUSR2 信号的反应是，使用 -sf 参数后跟 worker 的 PID 来重新执行自己。然后 master 将解析配置文件并派生新的 worker。为了更好地理解这些信号是如何使用的，了解整个重启机制非常重要。首先，一个现有的 haproxy 进程正在运行。管理员使用系统特定的命令，如 "/etc/init.d/haproxy reload"，来表示他想让新的配置文件生效。接下来会发生以下情况。首先，服务脚本（/etc/init.d/haproxy 或等效脚本）将使用 "haproxy -c" 验证配置文件是否能正确解析。之后，它将尝试使用此配置文件启动 haproxy，使用 "-st" 或 "-sf"。然后 HAProxy 尝试绑定到所有监听端口。如果发生一些致命错误（例如：系统上不存在地址，权限被拒绝），进程将以错误退出。如果套接字绑定失败是因为端口已被使用，那么该进程将首先向 "-st" 或 "-sf" pid 列表中指定的所有 pid 发送一个 SIGTTOU 信号。这就是所谓的“暂停”信号。它指示所有现有的 haproxy 进程暂时停止监听它们的端口，以便新进程可以再次尝试绑定。在此期间，旧进程继续处理现有连接。如果绑定仍然失败（例如因为端口与另一个守护进程共享），那么新进程会向旧进程发送一个 SIGTTIN 信号，指示它们像什么都没发生一样恢复操作。然后旧进程将重新开始监听端口并继续接受连接。请注意，此机制是系统相关的，某些操作系统可能在多进程模式下不支持它。如果新进程成功绑定到所有端口，那么它会向所有进程发送 SIGTERM（在 "-st" 的情况下为硬停止）或 SIGUSR1（在 "-sf" 的情况下为平滑停止），通知它们现在由它负责操作，旧进程必须离开，要么立即离开，要么在完成工作后离开。需要注意的是，在此时间范围内，有两个几毫秒的小窗口，在高负载期间可能会注意到一些连接失败。通常观察到的失败率大约是在每秒 10000 个新连接的重载操作中出现 1 次失败，这意味着一个负载很重的站点，以每秒 30000 个新连接的速度运行，每次重载可能会看到大约 3 个失败的连接。发生这种情况的两种情况是： - 如果新进程由于旧进程的存在而绑定失败，它将首先必须经历 SIGTTOU+SIGTTIN 序列，对于几十个前端来说，这通常持续约一毫秒，在此期间，一些端口将不会绑定到旧进程，也尚未绑定到新进程。HAProxy 在支持 SO_REUSEPORT 套接字选项的系统上解决了这个问题，因为它允许新进程绑定而无需先请求旧进程解绑。大多数 BSD 系统几乎一直都支持这个功能。Linux 在 2.0 版本中支持过它，但在 2.2 版本左右放弃了，但当时有一些补丁在流传。它在内核 3.9 中被重新引入，所以如果您观察到的连接失败率高于上述提到的，请确保您的内核是 3.9 或更新版本，或者相关的补丁已经反向移植到您的内核中（可能性较小）。 - 当旧进程关闭监听端口时，内核可能不总是重新分配套接字积压队列（backlog）中剩余的任何待处理连接。在高负载下，SYN 数据包可能在套接字关闭前一刻到达，并将导致向客户端发送 RST 数据包。在一些即使一次丢包都不可接受的关键环境中，有时会通过使用防火墙规则在重载期间阻止 SYN 数据包来处理这些问题，从而强制客户端重传。这完全是系统相关的，因为一些系统可能能够访问其他监听队列并避免此 RST。第二种情况涉及客户端在本地套接字处于 SYN_RECV 状态时发送的 ACK，恰好在关闭之前。此 ACK 将导致一个 RST 数据包，而 haproxy 进程仍然不知道它。这个问题更难解决，尽管上面提到的防火墙过滤规则如果在重启进程前一秒左右应用，会工作得很好。对于绝大多数用户来说，这样的丢包永远不会发生，因为他们的负载不足以触发竞争条件。而对于大多数高流量用户，只要他们的系统上至少正确支持 SO_REUSEPORT，失败率仍然完全在噪声范围内。

为了确保所有传入的连接都能成功得到服务，HAProxy 在加载时计算进程生命周期中所需的总文件描述符数量。一个普通的 Unix 进程通常默认被授予 1024 个文件描述符，而一个特权进程可以自己提高这个限制。这就是以 root 身份启动 HAProxy 并让它调整限制的原因之一。默认的 1024 个文件描述符限制大致允许处理约 500 个并发连接。计算基于全局 maxconn 参数，该参数限制了每个进程的总连接数、监听器的数量、启用了健康检查的服务器数量、代理检查、对等节点、日志记录器以及可能的一些其他技术要求。这个数字的一个简单粗略估计是简单地将 maxconn 值加倍，再加上几十个，就能得到所需的文件描述符的大概数量。最初 HAProxy 不知道如何计算这个值，因此有必要在全局部分使用 "ulimit-n" 设置来传递该值。这就解释了为什么即使在今天，很多配置中仍然存在这个设置。不幸的是，它常常被错误计算，导致在接近 maxconn 时出现连接失败，而不是在等待所需资源时节流传入连接。因此，删除任何可能从非常旧版本遗留下来的 "ulimit-n" 设置非常重要。为了接受中等负载，提高文件描述符的数量是强制性的，但这需要一些特定于操作系统的调整。首先，select() 轮询系统限制为 1024 个文件描述符。实际上，在 Linux 上它曾经能够处理更多，但由于某些操作系统附带了过度限制性的 SELinux 策略，禁止使用超过 1024 个文件描述符的 select()，HAProxy 现在在这种情况下拒绝启动，以避免在运行时出现任何问题。在所有支持的操作系统上，poll() 都是可用的，并且不会受到这个限制。它会被自动选择，所以不需要做任何事情来获得一个可用的配置。但是当文件描述符的数量增加时，poll() 会变得非常慢。虽然 HAProxy 尽力限制这种性能影响（例如：通过使用内部文件描述符缓存和批处理），一个好的经验法则是，使用 poll() 处理超过一千个并发连接会消耗大量 CPU。对于基于内核 2.6 及以上的 Linux 系统，将使用 epoll() 系统调用。这是一个更具可扩展性的机制，依赖于内核中的回调，保证了无论注册的被监控文件描述符数量多少，都能有恒定的唤醒时间。在检测到它的地方，只要 HAProxy 是为某个 Linux 版本构建的，它就会被自动使用。它的存在和支持可以通过 "haproxy -vv" 来验证。对于支持它的 BSD 系统，kqueue() 可作为替代方案。它比 poll() 快得多，甚至由于其对变化的批处理，比 epoll() 还要快一些。至少 FreeBSD 和 OpenBSD 支持它。就像 Linux 的 epoll() 一样，它的支持和可用性在 "haproxy -vv" 的输出中报告。拥有一个好的轮询器是一回事，但进程必须能够达到限制。当 HAProxy 启动时，它会立即设置新进程的文件描述符限制，并验证是否成功。如果失败，它会在派生（forking）前报告，以便管理员可以看到问题。只要进程以 root 身份启动，这个设置就没有理由会失败。但是，如果进程由非特权用户启动，它可能会失败。如果有充分的理由*不*以 root 身份启动 haproxy（例如：由最终用户启动，或由每个应用程序的账户启动），那么系统管理员可以为这个特定用户提高文件描述符限制。可以通过从该用户的命令行发出 "ulimit -n" 来验证设置的有效性。它应该反映新的限制。警告：当非特权用户的限制在该用户的账户中更改时，通常这些值仅在用户登录时被考虑，而在系统启动时运行的某些脚本或 crontabs 中根本不被考虑。这完全取决于操作系统，请记住在以这种方式运行时，在启动 haproxy 之前检查 "ulimit -n"。一般的建议是，为了生产目的，永远不要以非特权用户身份启动 haproxy。另一个好理由是，这样做会阻止 haproxy 启用某些安全保护。一旦确定系统将允许 haproxy 进程使用所请求数量的文件描述符，可能会遇到两个新的系统特定限制。第一个是系统范围的文件描述符限制，即系统上打开的文件描述符总数，涵盖所有进程。当达到此限制时，accept() 或 socket() 通常会返回 ENFILE。第二个是每个进程的文件描述符硬限制，它阻止 setrlimit() 设置得更高。两者都非常依赖于操作系统。在 Linux 上，系统限制在启动时根据内存量设置。可以使用 "fs.file-max" sysctl 来更改它。而每个进程的硬限制默认为 1048576，但可以使用 "fs.nr_open" sysctl 来更改它。当文件描述符限制设置得太低时，可以在正在运行的进程上观察到。strace 工具会报告当进程的限制达到时，accept() 和 socket() 返回 "-1 EMFILE"。在这种情况下，简单地提高 "ulimit-n" 值（或删除它）将解决问题。如果这些系统调用返回 "-1 ENFILE"，则意味着内核的限制已达到，必须对系统范围的参数进行操作。这些问题必须绝对解决，因为它们会导致高 CPU 使用率（当 accept() 失败时）和通常用户可见的连接失败。一种解决方案还包括降低全局 maxconn 值以强制序列化，并可能禁用 HTTP keep-alive 以强制连接更快地释放和重用。

HAProxy 使用一种简单快速的基于池的内存管理。由于它依赖于少量不同类型的对象，从已经包含适当大小对象的池中挑选新对象，比为每个不同大小调用 malloc() 要高效得多。池被组织成一个栈或 LIFO（后进先出），这样新分配的对象就取自最近释放的、仍在 CPU 缓存中“热”的对象。大小相似的池被合并在一起，以限制内存碎片。默认情况下，由于重点是性能，每个释放的对象都会被放回它来自的池中，并且已分配的对象永远不会被释放，因为它们预计很快就会被重用。在 CLI 上，可以通过 "show pools" 命令检查内存如何在池中使用： > show pools Dumping pools usage. Use SIGQUIT to flush them. - Pool pipe (32 bytes) : 5 allocated (160 bytes), 5 used, 3 users [SHARED] - Pool hlua_com (48 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] - Pool vars (64 bytes) : 0 allocated (0 bytes), 0 used, 2 users [SHARED] - Pool task (112 bytes) : 5 allocated (560 bytes), 5 used, 1 users [SHARED] - Pool session (128 bytes) : 1 allocated (128 bytes), 1 used, 2 users [SHARED] - Pool http_txn (272 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] - Pool connection (352 bytes) : 2 allocated (704 bytes), 2 used, 1 users [SHARED] - Pool hdr_idx (416 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] - Pool stream (864 bytes) : 1 allocated (864 bytes), 1 used, 1 users [SHARED] - Pool requri (1024 bytes) : 0 allocated (0 bytes), 0 used, 1 users [SHARED] - Pool buffer (8064 bytes) : 3 allocated (24192 bytes), 2 used, 1 users [SHARED] Total: 11 pools, 26608 bytes allocated, 18544 used. 池名称仅是指示性的，它是使用该池的第一个对象类型的名称。括号中的大小是该池中对象的对象大小。对象大小总是向上舍入到最接近的 16 字节的倍数。报告了当前分配的对象数量和等效的字节数，以便轻松了解哪个池是最高内存使用的原因。当前正在使用的对象数量也在 "used" 字段中报告。"allocated" 和 "used" 之间的差异对应于已释放并可立即使用的对象。可以使用 "-m" 命令行选项后跟兆字节数来限制每个进程分配的内存量。它涵盖了进程的所有可寻址空间，因此包括一些库使用的内存以及栈，但在构建资源受限的系统时，这是一个可靠的限制。它的工作方式与有 "ulimit -v" 的系统上的该命令相同，或者与其他系统上的 "ulimit -d" 相同。如果由于达到内存限制或系统没有足够内存而导致内存分配失败，那么 haproxy 将首先开始从所有池中释放所有可用对象，然后再尝试再次分配内存。可以通过向 haproxy 进程发送 SIGQUIT 信号来触发这种释放未使用内存的机制。这样做时，当进程在前台运行时，刷新前的池状态也将报告给 stderr。在重载操作期间，切换到平滑停止状态的进程也会在释放任何连接后自动执行一些刷新，以便释放所有可能的内存，为新进程节省内存。

HAProxy 通常大部分时间花费在系统（内核态），一小部分时间花费在用户态。一个精细调优的 3.5 GHz CPU 在单个核心上，在 100% CPU 使用率下，可以维持每秒约 80000 次端到端的连接建立和关闭速率。当一个核心饱和时，典型的数据是： - 对于长 TCP 连接或大型 HTTP 对象，95% 系统时间，5% 用户时间 - 对于短 TCP 连接或关闭模式下的小型 HTTP 对象，85% 系统时间，15% 用户时间 - 对于保持连接（keep-alive）模式下的小型 HTTP 对象，70% 系统时间，30% 用户时间 规则处理和正则表达式的数量会增加用户态部分。系统中存在防火墙规则、连接跟踪、复杂的路由表则会增加系统态部分。在大多数系统上，网络传输期间观察到的 CPU 时间可以分为 4 个部分： - 中断部分，涉及在 I/O 接收时执行的所有处理，甚至在目标进程被知晓之前。通常，接收（Rx）数据包被计入中断。在某些系统上，如 Linux，中断处理可能会被推迟到一个专用线程，这时它可以显示为 softirq，该线程称为 ksoftirqd/0（对于 CPU 0）。负责此负载的 CPU 通常由硬件设置定义，尽管在 softirq 的情况下，通常可以将处理重新映射到另一个 CPU。这个中断部分通常被认为是寄生的，因为它与任何进程无关，但实际上它是为进程准备工作而进行的一些处理。 - 系统部分，涉及从用户态调用的所有使用内核代码完成的处理。例如，系统调用被计为系统时间。所有同步发送的传输（Tx）数据包都将被计为系统时间。如果由于队列填满而必须推迟某些数据包，它们可能会在稍后的中断上下文中处理（例如：在收到打开 TCP 窗口的 ACK 时）。 - 用户部分，专门在用户态运行应用程序代码。HAProxy 完全在这一部分运行，尽管它大量使用系统调用。规则处理、正则表达式、压缩、加密都增加了 CPU 消耗的用户部分。 - 空闲部分，是 CPU 在无事可做时所做的事情。例如，HAProxy 等待传入连接，或等待一些数据离开，这意味着系统正在等待客户端的 ACK 来推送这些数据。实际上，关于 HAProxy 的活动，通常可以合理准确地（但完全不精确地）认为，中断/softirq 是由内核驱动程序中的 Rx 处理引起的，用户态是由 HAProxy 中的第 7 层处理引起的，而系统时间是由 Tx 路径上的网络处理引起的。由于 HAProxy 围绕事件循环运行，它使用 poll() (或任何替代方案) 等待新事件，并尽快处理所有这些事件，然后返回 poll() 等待新事件。它测量在 poll() 中等待所花费的时间与处理事件所花费的时间。轮询时间与总时间的比率称为“空闲”时间，它是等待某事发生所花费的时间量。这个比率在统计页面的 "idle" 行上报告，或者在 CLI 上是 "Idle_pct"。当它接近 100% 时，意味着负载极低。当它接近 0% 时，意味着持续有活动。虽然在一个过载的系统上，由于其他进程可能会抢占 haproxy 进程的 CPU，它可能不是很准确，但它仍然提供了一个关于 HAProxy 如何看待其工作情况的良好估计：如果负载低而空闲率也很低，这可能表明 HAProxy 有很多工作要做，可能是由于必须处理非常昂贵的规则。相反，如果 HAProxy 表示空闲率接近 100% 而事情很慢，这意味着它无法做任何事情来加速，因为它已经在等待传入数据进行处理。在下面的例子中，haproxy 完全空闲： $ echo "show info" | socat - /var/run/haproxy.sock | grep ^Idle Idle_pct: 100 当空闲率开始变得非常低时，调整系统并正确放置进程和中断以尽可能为所有任务节省 CPU 资源非常重要。如果存在防火墙，可能值得尝试禁用它或调整它，以确保它不是性能限制的很大一部分原因。值得注意的是，卸载有状态防火墙通常会减少中断/softirq 和系统使用的量，因为这样的防火墙同时作用于 Rx 和 Tx 路径。在 Linux 上，卸载 nf_conntrack 和 ip_conntrack 模块将显示是否可以获得任何好处。如果可以，那么模块正在以默认设置运行，您将需要弄清楚如何调整它以获得更好的性能。通常这包括大幅增加哈希表的大小。在 FreeBSD 上，“pfctl -d” 将禁用 “pf” 防火墙及其有状态引擎。如果观察到大量时间花费在中断/softirq 上，确保它们不在同一个 CPU 上运行是很重要的。大多数系统倾向于将任务固定在接收网络流量的 CPU 上，因为对于某些工作负载，这会改善情况。但对于重度网络绑定的工作负载，情况恰恰相反，因为 haproxy 进程将不得不与其内核对应部分竞争。将 haproxy 固定到一个 CPU 核心，并将中断固定到另一个共享相同 L3 缓存的核心，往往会显著提高网络性能，因为实际上 haproxy 和网络栈的工作量非常接近，所以它们几乎可以各自填满一个完整的 CPU。在 Linux 上，这是通过 taskset (对于 haproxy) 或使用 cpu-map (从 haproxy 配置) 完成的，中断则在 /proc/irq 下分配。许多网络接口支持多个队列和多个中断。通常，将它们分散在少量共享相同 L3 缓存的 CPU 核心上会有所帮助。请务必停止 irq_balance，它在这种工作负载下总是做出最差的决定。对于由大量 SSL 流量或大量压缩组成的 CPU 密集型工作负载，可能值得使用多个专门用于某些任务的进程，尽管这里没有通用规则，必须进行实验。为了增加 CPU 容量，可以使用全局部分的 "nbproc" 指令使 HAProxy 作为多个进程运行。但存在一些限制： - 健康检查是按进程运行的，因此目标服务器将收到与运行进程数量一样多的检查； - maxconn 值和队列是按进程的，因此必须设置正确的值以避免服务器过载； - 出站连接应避免使用端口范围以避免冲突； - 粘性表（stick-tables）是按进程的，并且在进程之间不共享； - 每个 peers 部分一次只能在一个进程上运行； - CLI 操作一次只会作用于一个进程。考虑到这些，最简单的设置通常是有一个运行在多个进程上的第一层，负责繁重的处理，将流量传递给一个运行在单个进程中的第二层。这种机制适用于 SSL 和压缩这两个 CPU 密集型功能。实例可以很容易地通过 UNIX 套接字（比 TCP 套接字开销更小，且不浪费端口）链接，并且代理协议（proxy protocol）对于将客户端信息传递到下一阶段很有用。这样做时，通常最好将所有单进程任务绑定到进程号 1，并将额外任务绑定到后续进程，因为这将使为不同机器生成相似配置变得更容易。在 Linux 3.9 及以上版本中，当每个进程在同一个 IP:端口上使用不同的监听套接字时，以多进程模式运行 HAProxy 的效率要高得多；这将使内核在所有进程之间均匀分配负载，而不是唤醒所有进程。请查阅配置手册中 "bind" 关键字行的 "process" 选项以获取更多信息。

对于日志记录，HAProxy 总是依赖于 syslog 服务器，因为它不执行任何文件系统访问。使用它的标准方法是通过 UDP 将日志发送到日志服务器（默认在端口 514）。通常，这被配置为 127.0.0.1，本地 syslog 守护进程正在那里运行，但它也用于通过网络记录到中央服务器。中央服务器提供了额外的好处，特别是在主-主（active-active）场景中，希望将日志按到达顺序合并。HAProxy 也可以使用 UNIX 套接字将其日志发送到本地 syslog 守护进程，但完全不推荐，因为如果在 haproxy 运行时重启 syslog 服务器，套接字将被替换，新的日志将丢失。由于 HAProxy 将被隔离在一个 chroot jail 中，它将无法重新连接到新的套接字。在实践中还观察到，UNIX 套接字上使用的日志缓冲区非常小，即使在非常轻的负载下也会导致消息丢失。但对于测试来说这可能没问题。建议在 "global" 部分添加以下指令，使 HAProxy 使用 facility "local0" 记录到本地守护进程： log 127.0.0.1:514 local0 然后在每个 "defaults" 部分或每个前端和后端部分添加以下指令： log global 这样，所有日志将通过日志服务器所在的全局定义进行集中。一些 syslog 守护进程默认不监听 UDP 流量，因此根据所使用的守护进程，启用此功能的语法会有所不同： - 在 sysklogd 上，您需要在守护进程的命令行上传递参数 "-r"，以便它监听一个 UDP 套接字用于“远程”日志；请注意，无法将其限制为地址 127.0.0.1，因此它也会接收来自远程系统的日志； - 在 rsyslogd 上，必须将以下行添加到配置文件中： $ModLoad imudp $UDPServerAddress * $UDPServerRun 514 - 在 syslog-ng 上，可以按以下方式创建一个新的源，然后需要将其作为有效源添加到一个 "log" 指令中： source s_udp { udp(ip(127.0.0.1) port(514)); }; 请查阅您的 syslog 守护进程手册以获取更多信息。如果在系统的日志文件中没有看到日志，请考虑以下测试： - 重启 haproxy。每个前端和后端都会记录一行，表明它正在启动。如果收到这些日志，说明日志工作正常。 - 运行 "strace -tt -s100 -etrace=sendmsg -p <haproxy's pid>" 并执行一些您期望被记录的活动。您应该看到日志消息通过 sendmsg() 发送出去。如果它们没有出现，请在 haproxy 之上使用 strace 重新启动。如果您仍然看不到日志，那绝对意味着您的配置中有问题。 - 运行 tcpdump 来监视端口 514，例如在环回接口上（如果流量是本地发送的）：“tcpdump -As0 -ni lo port 514”。如果在那里看到数据包，就证明它们已发送，那么需要对 syslogd 守护进程进行故障排除。虽然流量日志是从前端（接受传入连接的地方）发送的，但后端也需要能够发送日志，以报告由于健康检查而导致的服务器状态变化。请查阅 HAProxy 的配置手册以获取有关所有可能的日志设置的更多信息。选择一个其他守护进程不使用的 facility 是很方便的。HAProxy 示例通常建议对流量日志使用 "local0"，对管理日志使用 "local1"，因为它们在实践中很少见到。单个 facility 也足够了。拥有单独的日志对于日志分析很方便，但同样重要的是要记住，日志有时可能包含机密信息，因此它们不应与其他可能意外泄露给未经授权人员的日志混合。为了在不影响服务器容量的情况下进行现场故障排除，建议使用 HAProxy 附带的 "halog" 工具。这是一种类似 grep 的工具，旨在以非常快的数据速率处理 HAProxy 日志文件。典型的数据范围在每秒 1 到 2 GB 的日志之间。它能够仅提取某些日志（例如：搜索某些类别的 HTTP 状态码、连接终止状态、按响应时间范围搜索、仅查找错误），计算行数，将输出限制为一定行数，并执行一些更高级的统计，例如按响应时间或错误计数对服务器进行排序，按时间或计数对 URL 进行排序，按访问计数对客户端地址进行排序等等。它非常方便地可以快速发现异常情况，例如网站上的机器人循环访问，并阻止它们。

可以查询 HAProxy 的状态。最常用的机制是 HTTP 统计页面。该页面还为监控工具提供了一种替代的 CSV 输出格式。在 Unix 套接字上也提供了相同的格式。

统计信息可以从 unix 套接字或 HTTP 页面查询。两种方式都提供 CSV 格式，其字段如下。第一行以井号（'#'）开头，每个逗号分隔的字段有一个单词，代表该列的标题。从第二行开始的所有其他行都使用经典的 CSV 格式，以逗号为分隔符，双引号（'"'）作为可选的文本定界符，但仅当被括起来的文本有歧义时（如果它包含引号或逗号）才使用。文本中的双引号字符（'"'）会加倍（'""'），这是大多数工具能够识别的格式。请不要在这些列之前插入任何列，以免破坏使用硬编码列位置的工具。每个字段名后面的括号里是可能对该字段有值的类型。这些类型是 L (Listeners 侦听器)、F (Frontends 前端)、B (Backends 后端) 和 S (Servers 服务器)。 0. pxname [LFBS]: 代理名称 1. svname [LFBS]: 服务名称 (前端为 FRONTEND，后端为 BACKEND，服务器/侦听器为任意名称) 2. qcur [..BS]: 当前排队请求数。对于后端，这报告了没有分配服务器的排队请求数。 3. qmax [..BS]: qcur 的最大值 4. scur [LFBS]: 当前会话数 5. smax [LFBS]: 最大会话数 6. slim [LFBS]: 配置的会话限制 7. stot [LFBS]: 累计会话数 8. bin [LFBS]: 输入字节数 9. bout [LFBS]: 输出字节数 10. dreq [LFB.]: 因安全问题被拒绝的请求。 - 对于 tcp，这是因为匹配了 tcp-request content 规则。 - 对于 http，这是因为匹配了 http-request 或 tarpit 规则。 11. dresp [LFBS]: 因安全问题被拒绝的响应。 - 对于 http，这是因为匹配了 http-request 规则，或 "option checkcache"。 12. ereq [LF..]: 请求错误。一些可能的原因是： - 客户端在请求发送前提前终止。 - 从客户端读取错误 - 客户端超时 - 客户端关闭连接 - 客户端发出的各种错误请求。 - 请求被 tarpit 策略处理。 13. econ [..BS]: 尝试连接到后端服务器时遇到错误的请求数。后端的统计数据是该后端所有服务器的统计数据之和，加上任何未与特定服务器关联的连接错误（例如后端没有活动服务器）。 14. eresp [..BS]: 响应错误。srv_abrt 也将在此计数。其他一些错误是： - 客户端套接字上的写入错误（不会计入服务器统计） - 对响应应用过滤器失败。 15. wretr [..BS]: 重试连接到服务器的次数。 16. wredis [..BS]: 请求被重新分派到另一台服务器的次数。服务器的值计算的是该服务器被切换出去的次数。 17. status [LFBS]: 状态 (UP/DOWN/NOLB/MAINT/MAINT(via)/MAINT(resolution)...) 18. weight [..BS]: 总权重（后端），服务器权重（服务器） 19. act [..BS]: 活动服务器数量（后端），服务器是否活动（服务器） 20. bck [..BS]: 备份服务器数量（后端），服务器是否为备份（服务器） 21. chkfail [...S]: 失败的检查次数。（仅计算服务器启动时检查失败的次数。） 22. chkdown [..BS]: UP->DOWN 转换的次数。后端计数器计算的是整个后端变为 down 的转换次数，而不是每个服务器计数器的总和。 23. lastchg [..BS]: 自上次 UP<->DOWN 转换以来的秒数 24. downtime [..BS]: 总停机时间（秒）。后端的值是整个后端的停机时间，而不是服务器停机时间的总和。 25. qlimit [...S]: 为服务器配置的 maxqueue，如果值为 0（默认，表示无限制）则为空 26. pid [LFBS]: 进程 ID (第一个实例为 0，第二个为 1，...) 27. iid [LFBS]: 唯一的代理 ID 28. sid [L..S]: 服务器 ID (在代理内部唯一) 29. throttle [...S]: 服务器当前的节流百分比，当 slowstart 激活时，如果不在 slowstart 中则无值。 30. lbtot [..BS]: 服务器被选中的总次数，无论是新会话还是重新分派时。服务器计数器是该服务器被选中的次数。 31. tracked [...S]: 如果启用了跟踪，则为代理/服务器的 ID。 32. type [LFBS]: (0=前端, 1=后端, 2=服务器, 3=套接字/侦听器) 33. rate [.FBS]: 过去一秒内每秒的会话数 34. rate_lim [.F..]: 配置的每秒新会话限制 35. rate_max [.FBS]: 每秒最大新会话数 36. check_status [...S]: 上次健康检查的状态，其中之一： UNK -> 未知 INI -> 初始化中 SOCKERR -> 套接字错误 L4OK -> 第 4 层检查通过，未启用上层测试 L4TOUT -> 第 1-4 层超时 L4CON -> 第 1-4 层连接问题，例如“连接被拒绝”(tcp rst)或“无路由到主机”(icmp) L6OK -> 第 6 层检查通过 L6TOUT -> 第 6 层 (SSL) 超时 L6RSP -> 第 6 层无效响应 - 协议错误 L7OK -> 第 7 层检查通过 L7OKC -> 第 7 层检查有条件通过，例如 404 with disable-on-404 L7TOUT -> 第 7 层 (HTTP/SMTP) 超时 L7RSP -> 第 7 层无效响应 - 协议错误 L7STS -> 第 7 层响应错误，例如 HTTP 5xx 注意：如果检查当前正在运行，将报告最后已知的状态，并以“* ”为前缀。例如：“* L7OK”。 37. check_code [...S]: 第 5-7 层代码，如果可用 38. check_duration [...S]: 完成上次健康检查所用的时间（毫秒） 39. hrsp_1xx [.FBS]: http 响应代码为 1xx 的数量 40. hrsp_2xx [.FBS]: http 响应代码为 2xx 的数量 41. hrsp_3xx [.FBS]: http 响应代码为 3xx 的数量 42. hrsp_4xx [.FBS]: http 响应代码为 4xx 的数量 43. hrsp_5xx [.FBS]: http 响应代码为 5xx 的数量 44. hrsp_other [.FBS]: 其他代码的 http 响应数量（协议错误） 45. hanafail [...S]: 失败的健康检查详情 46. req_rate [.F..]: 过去一秒内每秒的 HTTP 请求数 47. req_rate_max [.F..]: 观察到的每秒最大 HTTP 请求数 48. req_tot [.FB.]: 收到的 HTTP 请求总数 49. cli_abrt [..BS]: 客户端中止的数据传输次数 50. srv_abrt [..BS]: 服务器中止的数据传输次数（包含在 eresp 中） 51. comp_in [.FB.]: 送入压缩器的 HTTP 响应字节数 52. comp_out [.FB.]: 压缩器输出的 HTTP 响应字节数 53. comp_byp [.FB.]: 绕过 HTTP 压缩器的字节数（CPU/带宽限制） 54. comp_rsp [.FB.]: 被压缩的 HTTP 响应数 55. lastsess [..BS]: 自上次会话分配给服务器/后端以来的秒数 56. last_chk [...S]: 上次健康检查的内容或文本错误 57. last_agt [...S]: 上次代理检查的内容或文本错误 58. qtime [..BS]: 过去 1024 个请求的平均队列时间（毫秒） 59. ctime [..BS]: 过去 1024 个请求的平均连接时间（毫秒） 60. rtime [..BS]: 过去 1024 个请求的平均响应时间（毫秒）（TCP 为 0） 61. ttime [..BS]: 过去 1024 个请求的平均总会话时间（毫秒） 62. agent_status [...S]: 上次代理检查的状态，其中之一： UNK -> 未知 INI -> 初始化中 SOCKERR -> 套接字错误 L4OK -> 第 4 层检查通过，未启用上层测试 L4TOUT -> 第 1-4 层超时 L4CON -> 第 1-4 层连接问题，例如“连接被拒绝”(tcp rst)或“无路由到主机”(icmp) L7OK -> 代理报告 "up" L7STS -> 代理报告 "fail", "stop", 或 "down" 63. agent_code [...S]: 代理报告的数字代码（如果有的话）（目前未使用） 64. agent_duration [...S]: 完成上次检查所用的时间（毫秒） 65. check_desc [...S]: check_status 的简短人类可读描述 66. agent_desc [...S]: agent_status 的简短人类可读描述 67. check_rise [...S]: 服务器检查使用的 "rise" 参数 68. check_fall [...S]: 服务器检查使用的 "fall" 参数 69. check_health [...S]: 服务器的健康检查值，介于 0 和 rise+fall-1 之间 70. agent_rise [...S]: 代理的 "rise" 参数，通常为 1 71. agent_fall [...S]: 代理的 "fall" 参数，通常为 1 72. agent_health [...S]: 代理的健康参数，介于 0 和 rise+fall-1 之间 73. addr [L..S]: 地址:端口 或 "unix"。IPv6 地址用方括号括起来。 74: cookie [..BS]: 服务器的 cookie 值或后端的 cookie 名称 75: mode [LFBS]: 代理模式 (tcp, http, health, unknown) 76: algo [..B.]: 负载均衡算法 77: conn_rate [.F..]: 过去一秒内的连接数 78: conn_rate_max [.F..]: 已知的最高 conn_rate 79: conn_tot [.F..]: 累计连接数 80: intercepted [.FB.]: 累计拦截的请求数 (monitor, stats) 81: dcon [LF..]: 被 "tcp-request connection" 规则拒绝的请求 82: dses [LF..]: 被 "tcp-request session" 规则拒绝的请求

"show info" 和 "show stat" 都支持一种模式，其中每个输出值都附带其类型和足够的信息，以便了解该值应如何在进程之间聚合以及它如何演变。在所有情况下，输出都由每行一个值组成，所有信息被分成由冒号（':'）分隔的字段。第一列指定了正在转储的对象或指标。其格式特定于产生此输出的命令，本节将不作描述。通常，它将由一系列标识符和字段名组成。第二列包含 3 个字符，分别表示所报告值的来源、性质和范围。第一个字符（来源）指示值的提取位置。可能的字符有： M 该值是一个指标。它在某一时刻有效，并可能根据其性质而改变。 S 该值是一个状态。它代表一个离散值，根据定义不能被聚合。它可能是服务器的状态（“UP”或“DOWN”），进程的PID等。 K 该值是一个排序键。它代表一个标识符，可用于将一些值分组在一起，因为它在其类别中是唯一的。所有内部标识符都是键。如果某些名称是唯一的（例如：前端名称是唯一的），它们可以被列为键。通常，键来自配置，尽管其中一些可能是自动分配的。对于大多数目的，键可以被视为等同于配置。 C 该值来自配置。某些配置值在输出中是有意义的，例如并发连接限制或 cookie 名称。根据定义，这些值在从同一配置文件启动的所有进程中都是相同的。 P 该值来自产品本身。这样的值非常少，最常见的用途是报告产品名称、版本和发布日期。这些元素在所有进程之间也是相同的。第二个字符（性质）指示字段所携带信息的性质，以便聚合器决定使用什么操作来聚合多个值。可能的字符有： A 该值表示自上次事件以来的时间。这与持续时间有点不同，因为时间是根据当前日期自动计算的。一个典型的例子是服务器上最后一次会话发生在多久以前。时间通常通过取最小值来聚合，并且不需要存储。 a 该值表示一个已经平均过的值。平均响应时间和服务器权重属于此性质。平均值通常可以在进程之间进行平均。 C 该值表示一个累积计数器。这种度量会持续增加，直到回绕。一些监控协议需要区分计数器和计量器以报告不同的类型。通常，计数器可以直接相加，因为它们代表事件或数量。这种性质的指标的例子是连接计数或字节计数。 D 该值表示一个状态的持续时间。这个有几种用法，大多数包括上次健康检查所花费的时间和一个服务器宕机的时间。持续时间通常不相加，大多数时候会保留最大值来计算SLA。 G 该值表示一个计量器（gauge）。它是在某一瞬间的测量值。内存使用量或当前活动连接数属于此性质。这种类型的指标在聚合时通常会相加。 L 该值表示一个限制（通常是配置的）。本质上，限制更难聚合，因为它们特定于它们被检索的点。在某些情况下，它们可能会被相加或保持独立。 M 该值表示一个最大值。通常，它将应用于一个计量器并保留已知的最高值。这种指标的一个例子可能是在产品生命周期中遇到的最大并发连接数。为了正确地聚合最大值，你应该输出一个范围，从所有最大值的最大值到它们的总和。确实无法知道它们是否是同时遇到的。 m 该值表示一个最小值。通常，它将应用于一个计量-器并保留已知的最低值。这种指标的一个例子可能是在产品生命周期中遇到的最小空闲内存池数量。为了正确地聚合最小值，你应该输出一个范围，从所有最小值的最小值到它们的总和。确实无法知道它们是否是同时遇到的。 N 该值表示一个名称，所以它是一个字符串。它用于报告代理名称、服务器名称和 cookie 名称。名称的来源是配置或键，并且在所有进程中应该是相同的。 O 该值表示一个自由文本输出。各种命令的输出、健康检查的返回、节点描述都属于此性质。 R 该值表示一个事件率。它是在某一瞬间的测量值。它与计量器非常相似，只是接收者知道这个测量值变化缓慢，可能会决定不保留所有值。这种指标的一个例子是测量的每秒连接数。这种类型的指标在聚合时通常会相加。 T 该值表示一个日期或时间。一个发出当前日期的字段将属于此类型。聚合此类信息的方法留作实现选择。目前没有字段使用此类型。第三个字符（范围）指示值反映的范围。一些元素可能是每个进程的，而另一些可能是每个配置或每个系统的。区分这一点很重要，以便知道在聚合过程中是应该保留单个值还是必须聚合值。目前支持以下字符： C 该值对整个节点集群有效，即通过对等协议通信的节点集合。一个例子可能是在与其他对等节点复制的粘性表（stick table）中存在的条目数量。目前没有指标使用此范围。 P 该值仅对报告它的进程有效。大多数指标使用此范围。 S 该值对整个服务有效，即从同一配置文件一起启动的进程集合。所有源自配置的指标都使用此范围。一些其他指标也可能用于某些共享资源（例如：共享的SSL缓存统计信息）。 s 该值对整个系统有效，例如系统的主机名、当前日期或资源使用情况。目前没有任何指标使用此范围。这些信息的消费者通常有足够的这 3 个字符来确定如何准确地报告跨多个进程的聚合信息。在此列之后，第三列指示字段的类型，包括 "s32" (有符号32位整数), "s64" (有符号64位整数), "u32" (无符号32位整数), "u64" (无符号64位整数), "str" (字符串)。在解析值之前了解其类型很重要，以便正确读取它。例如，一个只包含数字的字符串仍然是一个字符串，而不是一个整数（例如：由检查提取的错误代码）。然后第四列是值本身，根据其类型进行编码。字符串在冒号后立即按原样转储，没有任何前导空格。如果字符串包含冒号，它将正常出现。这意味着输出不应该完全围绕冒号进行分割，否则一些检查输出或服务器地址可能会被截断。

默认情况下，统计套接字未启用。为了启用它，必须在 haproxy 配置的 global 部分添加一行。建议添加第二行以设置更长的超时时间，这在手动发出命令时总是很有用的： global stats socket /var/run/haproxy.sock mode 600 level admin stats timeout 2m 也可以通过重复该行来添加多个统计套接字实例，并使它们监听 TCP 端口而不是 UNIX 套接字。默认情况下从不这样做，因为这很危险，但在某些情况下可能很方便： global stats socket /var/run/haproxy.sock mode 600 level admin stats socket ipv4@192.168.0.1:9999 level admin stats timeout 2m 要访问套接字，需要一个外部实用程序，如 "socat"。Socat 是一把瑞士军刀，可以连接任何东西到任何东西。我们用它来将终端连接到套接字，或者将一对 stdin/stdout 管道连接到它以供脚本使用。我们将使用的两个主要语法如下： # socat /var/run/haproxy.sock stdio # socat /var/run/haproxy.sock readline 第一个用于脚本。可以将脚本的输出发送到 haproxy，并将 haproxy 的输出传递给另一个脚本。这对于检索计数器或攻击痕迹等很有用。第二个只适用于手动发出命令。它的好处是终端由 readline 库处理，该库支持行编辑和历史记录，这在发出重复命令时非常方便（例如：观察计数器）。套接字支持两种操作模式： - 交互式 - 非交互式 当 socat 连接到套接字时，非交互式模式是默认模式。在此模式下，可以发送单行。它被作为一个整体处理，响应被发回，连接在响应结束后关闭。这是脚本和监控工具使用的模式。可以在此模式下发送多个命令，它们需要用分号（';'）分隔。例如： # echo "show info;show stat;show table" | socat /var/run/haproxy stdio 如果命令需要使用分号或反斜杠（例如：在值中），它必须以反斜杠（'\'）为前缀。交互式模式显示一个提示符（'>'）并等待在行上输入命令，然后处理它们，并再次显示提示符以等待新命令。此模式通过 "prompt" 命令进入，该命令必须在非交互模式下的第一行发送。该模式是一个切换开关，如果在交互模式下发送 "prompt" ，它将被禁用，连接在处理同一行的最后一个命令后关闭。因此，在手动调试时，通常以 "prompt" 命令开始： # socat /var/run/haproxy readline prompt > show info ... > 由于可以一次发出多个命令，haproxy 使用空行作为分隔符来标记每个命令的输出结束，并确保没有命令可以在输出上发出空行。因此，即使在单行上通过管道传输了多个命令，脚本也可以轻松地解析输出。重要的是要理解，当在同一个套接字上启动多个 haproxy 进程时，任何进程都可能接收请求并输出其自己的统计信息。下面提供了统计套接字当前支持的命令列表。如果发送了未知命令，haproxy 会显示用法消息，提醒所有支持的命令。一些命令支持更复杂的语法，通常当发生这种情况时，它会解释命令的哪个部分无效。一些命令需要更高的权限级别才能工作。如果您没有足够的权限，您将收到错误“Permission denied”。有关更多信息，请查看配置手册中 "bind" 关键字行的 "level" 选项。

向 ACL <acl> 中添加一个条目。<acl> 是由 "show acl" 返回的 #<id> 或 <file>。此命令不验证条目是否已存在。如果引用的 <acl> 是一个也与 map 一起使用的文件，则不能使用此命令。在这种情况下，您必须使用 "add map" 命令来代替 "add acl"。

在映射表 <map> 中添加一个条目，将值 <value> 与键 <key> 关联起来。此命令不验证条目是否已存在。它主要用于在清除操作后填充映射表。请注意，如果引用 <map> 是一个文件并且与一个映射表共享，则该映射表也将包含一个新的模式条目。

清除每个代理（前端和后端）和每个服务器中统计计数器的最大值。累积的计数器不受影响。由 "show activity" 报告的内部活动计数器也会被重置。这可用于在发生事件后获取干净的计数器，而无需重新启动或清除流量计数器。此命令受限制，只能在配置为 "operator" 或 "admin" 级别的套接字上发出。

清除每个代理（前端和后端）和每个服务器中的所有统计计数器。这与重新启动具有相同的效果。此命令受限制，只能在配置为“admin”级别的套接字上发出。

从 ACL <acl> 中删除所有条目。<acl> 是由 "show acl" 返回的 #<id> 或 <file>。请注意，如果引用的 <acl> 是一个文件并且与一个 map 共享，那么该 map 也将被清除。

从 map <map> 中删除所有条目。<map> 是由 "show map" 返回的 #<id> 或 <file>。请注意，如果引用的 <map> 是一个文件并且与一个 acl 共享，那么该 acl 也将被清除。

从粘性表 <table> 中移除条目。这通常用于解锁一些抱怨被不公正地拒绝访问服务的用户，但也可用于清除匹配即将被替换的服务器的某些粘性条目（详见下文 "show table"）。请注意，有时，移除条目会被拒绝，因为它当前正被会话跟踪。几秒钟后，在会话结束后重试通常就足够了。如果没有给出选项参数，所有条目都将被移除。当使用 "data." 格式时，会移除匹配使用存储数据应用的过滤器的条目（参见4.2节中的 "stick-table"）。必须在 <type> 中指定一个存储的数据类型，并且此数据类型必须存储在表中，否则会报告错误。数据会根据 <operator> 与64位整数 <value> 进行比较。操作符与 ACLs 中的相同：- eq：匹配数据等于此值的条目 - ne：匹配数据不等于此值的条目 - le：匹配数据小于或等于此值的条目 - ge：匹配数据大于或等于此值的条目 - lt：匹配数据小于此值的条目 - gt：匹配数据大于此值的条目 当使用 key 格式时，条目 <key> 会被移除。键必须与表的类型相同，目前仅限于 IPv4、IPv6、整数和字符串。

$ echo "show table http_proxy" | socat stdio /tmp/sock1 >>> # table: http_proxy, type: ip, size:204800, used:2 >>> 0x80e6a4c: key=127.0.0.1 use=0 exp=3594729 gpc0=0 conn_rate(30000)=1 \ bytes_out_rate(60000)=187 >>> 0x80e6a80: key=127.0.0.2 use=0 exp=3594740 gpc0=1 conn_rate(30000)=10 \ bytes_out_rate(60000)=191 $ echo "clear table http_proxy key 127.0.0.1" | socat stdio /tmp/sock1 $ echo "show table http_proxy" | socat stdio /tmp/sock1 >>> # table: http_proxy, type: ip, size:204800, used:1 >>> 0x80e6a80: key=127.0.0.2 use=0 exp=3594740 gpc0=1 conn_rate(30000)=10 \ bytes_out_rate(60000)=191 $ echo "clear table http_proxy data.gpc0 eq 1" | socat stdio /tmp/sock1 $ echo "show table http_proxy" | socat stdio /tmp/sock1 >>> # table: http_proxy, type: ip, size:204800, used:1

从 acl <acl> 中删除所有与键 <key> 对应的 acl 条目。<acl> 是由“show acl”返回的 #<id> 或 <file>。如果使用了 <ref>，此命令仅删除列出的引用。引用可以通过列出 acl 的内容找到。请注意，如果引用的 <acl> 是一个文件并且与 map 共享，该条目也将在 map 中被删除。

从 map <map> 中删除所有与键 <key> 对应的 map 条目。<map> 是由“show map”返回的 #<id> 或 <file>。如果使用了 <ref>，此命令仅删除列出的引用。引用可以通过列出 map 的内容找到。请注意，如果引用的 <map> 是一个文件并且与 acl 共享，该条目也将在 acl 中被删除。

将辅助代理检查标记为临时停止。在代理检查作为辅助检查运行的情况下（由于服务器指令的 agent-check 参数），只有当代理处于启用状态时才会初始化新的检查。因此，disable agent 将阻止任何新的代理检查被启动，直到使用 enable agent 重新启用代理。当代理被禁用时，对在代理启用时启动的辅助代理检查的处理如下：所有会改变权重的结果，特别是 "drain" 或代理返回的权重，都将被忽略。代理检查的其他处理方式保持不变。此功能的动机是允许暂停代理检查的权重更改效果，以便可以使用 set weight 配置服务器的权重，而不会被代理覆盖。此命令受限，并且只能在配置为 "admin" 级别的套接字上发出。

为后端 <backend> 禁用动态 cookie 的生成

将前端标记为临时停止。这对应于软重启期间使用的模式：前端释放端口，但如果需要可以再次启用。应谨慎使用此命令，因为一些非 Linux 操作系统无法重新启用它。这旨在用于那些甚至无法想象停止代理但必须修复配置错误的代理的环境中。这样就有可能释放端口并将其绑定到另一个进程以恢复操作。前端将在统计页面上显示为 "STOP" 状态。前端可以通过其名称或其数字 ID（前缀为井号 '#'）指定。此命令受限，并且只能在配置为 "admin" 级别的套接字上发出。

将主健康检查标记为临时停止。这将禁用发送健康检查，并且最后的健康检查结果将被忽略。服务器将处于未检查状态并被认为是 UP，除非辅助代理检查强制其 down。此命令受限，并且只能在配置为 "admin" 级别的套接字上发出。

将服务器标记为 DOWN 进行维护。在此模式下，直到服务器离开维护模式，否则不会再对其进行检查。如果该服务器被其他服务器跟踪，那些服务器在维护期间也将被设置为 DOWN。在统计页面上，处于维护状态的服务器将显示 "MAINT" 状态，其跟踪服务器将显示 "MAINT(via)" 状态。后端和服务器都可以通过其名称或其数字 ID（前缀为井号 '#'）指定。此命令受限，并且只能在配置为 "admin" 级别的套接字上发出。

恢复临时停止的辅助代理检查。有关临时启动和停止辅助代理的效果的详细信息，请参见 "disable agent"。此命令受限，并且只能在配置为 "admin" 级别的套接字上发出。

为后端 <backend> 启用动态 cookie 的生成。还必须提供一个密钥。

恢复一个临时停止的前端。某些监听端口可能无法再次绑定（例如：自'disable frontend'操作以来，另一个进程占用了它们）。如果发生这种情况，将显示错误。某些操作系统可能无法恢复被禁用的前端。前端可以通过其名称或其数字 ID（前缀为井号 '#'）指定。此命令受限，并且只能在配置为 "admin" 级别的套接字上发出。

恢复一个临时停止的主健康检查。这将再次启用发送健康检查。详情请参见 "disable health"。此命令受限，并且只能在配置为 "admin" 级别的套接字上发出。

如果服务器之前被标记为 DOWN 进行维护，此命令将服务器标记为 UP 并重新启用检查。后端和服务器都可以通过其名称或其数字 ID（前缀为井号 '#'）指定。此命令受限，并且只能在配置为 "admin" 级别的套接字上发出。

在映射表 <map> 或 ACL <acl> 中查找值 <value>。<map> 或 <acl> 是由 "show map" 或 "show acl" 返回的 #<id> 或 <file>。此命令返回与此映射关联的所有匹配模式。这对于调试映射表和 ACLs 很有用。输出格式由每个匹配类型一行组成。每行由空格分隔的一系列单词组成。前两个单词是：<match method>: 应用的匹配方法。可以是 "found", "bool", "int", "ip", "bin", "len", "str", "beg", "sub", "dir", "dom", "end" 或 "reg" 。<match result>: 结果。可以是 "match" 或 "no-match" 。只有当模式匹配一个条目时，才会返回以下单词。<index type>: "tree" 或 "list" 。内部查找算法。<case>: "case-insensitive" 或 "case-sensitive" 。大小写的解释。<entry matched>: match="<entry>" 。返回匹配的模式。这对于正则表达式很有用。最后两个单词用于显示返回的值及其类型。在 "acl" 情况下，模式不存在。return=nothing: 没有返回，因为没有 "map" 。return="<value>": 以字符串格式返回的值。return=cannot-display: 该值无法转换为字符串。type="<type>": 返回样本的类型。

报告后端 <backend> 中服务器 <server> 的当前权重和初始权重，如果任一不存在则报告错误。初始权重是配置文件中出现的权重。除非当前权重已被更改，否则两者通常相等。后端和服务器都可以通过其名称或其数字 ID（前缀为井号 '#'）指定。

打印已知关键字及其基本用法的列表。对于未知命令，也会显示相同的帮助屏幕。

切换行首的提示符，并进入或离开交互模式。在交互模式下，命令完成后连接不会关闭。相反，提示符会再次出现，表示解释器正在等待新命令。提示符由一个右尖括号后跟一个空格“> ”组成。当希望定期检查信息（如统计数据或错误）时，此模式特别方便。在发出“help”命令之前进入交互模式也是一个好主意。

在交互模式下关闭连接。

修改用于生成动态持久性 cookie 的密钥。这将破坏现有会话。

修改 map <map> 中每个键 <key> 对应的值。<map> 是由“show map”返回的 #<id> 或 <file>。如果使用 <ref> 代替 <key>，则只更改 <ref> 指向的条目。新值为 <value>。

动态更改指定前端的 maxconn 设置。允许任何正值，包括零，但设置大于全局 maxconn 的值没有太大意义。如果限制增加并且有待处理的连接，它们将立即被接受。如果限制降低到低于当前连接数的水平，新连接的接受将被延迟，直到达到阈值。前端可以通过其名称或其前缀为井号（'#'）的数字 ID 来指定。

动态更改指定服务器的 maxconn 设置。允许任何正值，包括零，但设置大于全局 maxconn 的值没有太大意义。

在初始全局 maxconn 设置定义的范围内动态更改全局 maxconn 设置。如果它被增加并且有待处理的连接，它们将立即被接受。如果它被降低到低于当前连接数的水平，新连接的接受将被延迟，直到达到阈值。值为零将恢复初始设置。

更改进程范围的连接速率限制，该限制由全局 'maxconnrate' 设置。值为零表示禁用限制。此限制适用于所有前端，并且更改会立即生效。值以每秒连接数的形式传递。

更改最大输入压缩速率，该速率由全局 'maxcomprate' 设置。值为零表示禁用限制。值以每秒千字节数的形式传递。该值可在 "show info" 的 "CompressBpsRateLim" 行中以字节为单位查看。

更改进程范围的会话速率限制，该限制由全局 'maxsessrate' 设置。值为零表示禁用限制。此限制适用于所有前端，并且更改会立即生效。值以每秒会话数的形式传递。

更改进程范围的 SSL 会话速率限制，该限制由全局 'maxsslrate' 设置。值为零表示禁用限制。此限制适用于所有前端，并且更改会立即生效。值以每秒发送到 SSL 堆栈的会话数的形式传递。它在握手之前应用，以保护堆栈免受握手滥用。

用提供的 IP 地址替换服务器的当前 IP 地址。可选地，可以使用 'port' 参数更改端口。请注意，更改端口也支持从端口映射（表示为 +X 或 -Y）切换或切换到端口映射，前提是为健康检查配置了端口。

强制服务器的代理进入新状态。例如，这对于不考虑某些缓慢的代理检查而立即切换服务器状态非常有用。请注意，如果有跟踪服务器，此更改将传播到它们。

更改服务器代理检查的地址。允许在运行时将代理检查迁移到另一个地址。您可以指定 IP 和主机名，它将被解析。

更改发送到代理检查目标的代理字符串。允许在更改服务器地址时更新字符串以保持两者匹配。

强制服务器的健康状态进入新状态。例如，这对于不考虑某些缓慢的健康检查而立即切换服务器状态非常有用。请注意，如果有跟踪服务器，此更改将传播到它们。

将用于健康检查的端口更改为 <port>

强制服务器的管理状态进入新状态。这对于禁用负载均衡和/或到服务器的任何流量非常有用。将状态设置为 "ready" 会使服务器进入正常模式，该命令等同于 "enable server" 命令。将状态设置为 "maint" 会禁用任何到服务器的流量以及任何健康检查。这等同于 "disable server" 命令。将模式设置为 "drain" 只会从负载均衡中移除服务器，但仍允许其被检查并接受新的持久连接。如果有跟踪服务器，更改将传播到它们。

将服务器的权重更改为参数中传递的值。这与下面的 "set weight" 命令完全等效。

将服务器的 FQDN 更改为参数中传递的值。这要求为该服务器配置并启用了内部运行时 DNS 解析器。

更改当前会话期间连接的 stats socket 的严重性输出格式。

此命令用于更新证书的 OCSP 响应（参见 "bind" 行上的 "crt"）。执行的控制与初始加载响应时相同。<response> 必须作为来自 OCSP 服务器的 DER 编码响应的 base64 编码字符串传递。BoringSSL 不支持此命令。

openssl ocsp -issuer issuer.pem -cert server.pem \ -host ocsp.issuer.com:80 -respout resp.der echo "set ssl ocsp-response $(base64 -w 10000 resp.der)" | \ socat stdio /var/run/haproxy.stat

为 <id> 侦听器设置下一个 TLS 密钥为 <tlskey>。此密钥成为最终密钥，而倒数第二个密钥用于加密（其他的只用于解密）。最旧的 TLS 密钥将被覆盖。<id> 是由 "show tls-keys" 返回的数字 #<id> 或 <file>。<tlskey> 是一个 base64 编码的 48 位 TLS 票证密钥（例如 openssl rand -base64 48）。

在 stick-table 中创建或更新一个条目。如果键不存在，则插入一个条目。请参阅 4.2 节 中的 stick-table 以查找 <data_type> 的所有可能值。最常见的用途是动态输入源 IP 地址的条目，并在 gpc0 中设置一个标志来动态阻止 IP 地址或影响其服务质量。可以在单次调用中传递多个 data_type。

更改当前连接的 CLI 接口超时。这在长时间的调试会话中非常有用，用户需要不断检查一些指标而不会被断开连接。延迟以秒为单位传递。

将服务器的权重更改为参数中传递的值。如果值以“%”符号结尾，则新权重将相对于初始配置的权重。绝对权重允许在 0 到 256 之间。相对权重必须为正，且最终的绝对权重上限为 256。属于运行静态负载均衡算法的服务器组的服务器有更严格的限制，因为权重一旦设置就不能更改。因此，对于这些服务器，唯一接受的值是 0 和 100%（或 0 和初始权重）。更改立即生效，尽管某些 LB 算法需要一定数量的请求才能考虑更改。此命令的典型用法是在更新期间通过将其权重设置为零来禁用服务器，然后在更新后通过将其设置回 100% 来重新启用它。此命令受限制，只能在为 "admin" 级别配置的套接字上发出。后端和服务器都可以通过它们的名称或数字 ID 指定，数字 ID 前缀为井号（'#'）。

转储有关 acl 转换器的信息。不带参数时，返回所有可用 acl 的列表。如果指定了 <acl>，则转储其内容。<acl> 是 #<id> 或 <file>。转储格式与 map 相同，甚至对于样本值也是如此。返回的数据不是可用 ACL 的列表，而是构成任何 ACL 的所有模式的列表。这些模式中的许多可以与 map 共享。

转储正在运行的进程中可用的后端列表。

列出 CLI 套接字。输出格式由 3 个以空格分隔的字段组成。第一个字段是套接字地址，可以是 unix 套接字、ipv4 地址:端口对或 ipv6 地址:端口对。其他类型的套接字不会被转储。第二个字段描述套接字的级别：'admin'、'user' 或 'operator'。最后一个字段列出套接字绑定的进程，用逗号分隔，可以是数字或 'all'。

$ 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

列出配置的缓存以及存储在每个缓存树中的对象。 $ echo 'show cache' | socat stdio /tmp/sock1 0x7f6ac6c5b03a: foobar (shctx:0x7f6ac6c5b000, available blocks:3918) 1 2 3 4 1. 指向缓存结构的指针 2. 缓存名称 3. 指向 mmap 区域 (shctx) 的指针 4. shctx 中可供重用的块数 0x7f6ac6c5b4cc hash:286881868 size:39114 (39 blocks), refcount:9, expire:237 1 2 3 4 5 6 1. 指向缓存条目的指针 2. 哈希的前 32 位 3. 对象的字节大小 4. 对象使用的块数 5. 使用该条目的事务数 6. 过期时间，如果已过期则可以为负数

转储进程已知的一个或所有环境变量。不带任何参数时，转储所有变量。带有一个参数时，如果指定的变量存在，则只转储该变量。否则会输出 "Variable not found"。变量以它们存储或由 "env" 实用程序返回的相同格式转储，即 "<name>=<value>"。这在调试大量使用环境变量的配置文件时非常方便，可以确保它们包含预期的值。此命令受限制，只能在为 "operator" 或 "admin" 级别配置的套接字上发出。

转储由前端和后端收集的最新已知请求和响应错误。如果指定了 <iid>，则将转储限制为与 ID 为 <iid> 的前端或后端相关的错误。代理 ID "-1" 将导致转储所有实例。如果指定了代理名称，则其 ID 将用作过滤器。如果在代理名称或 ID 后添加 "request" 或 "response"，则仅转储请求或响应错误。此命令受限制，只能在为 "operator" 或 "admin" 级别配置的套接字上发出。可能收集的错误是由于协议违规（通常是由于头名称中的无效字符）导致的最新请求和响应错误。报告会精确指出哪个确切的字符违反了协议。还会报告其他重要信息，例如检测到错误的确切日期、前端和后端名称、服务器名称（如果已知）、内部会话 ID 以及发起会话的源地址。所有字符都会返回，不可打印的字符会被编码。最常见的字符（\t = 9, \n = 10, \r = 13 和 \e = 27）被编码为反斜杠后的一个字母。反斜杠本身被编码为 '\\' 以避免混淆。其他不可打印的字符被编码为 '\xNN'，其中 NN 是字符 ASCII 码的两位十六进制表示。行以其第一个字符的位置为前缀，从缓冲区的开头 0 开始。每行最多打印一个输入行，长行将被分成多个连续的输出行，以便输出永远不会超过 79 个字符宽。很容易检测一行是否被拆分，因为它不会以 '\n' 结尾，并且下一行的偏移量后面会跟一个 '+' 号，表示它是前一行的延续。

$ 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 在上面的例子中，我们看到内部 ID 为 2 的后端 "http-in" 阻止了来自其内部 ID 为 1 的服务器 s2 的一个无效响应。该请求是在会话 54 上，由源 127.0.0.1 发起，并由 ID 为 1 的前端 fe-eth0 接收。检测到错误时，总响应长度为 213 字节，错误位于第 23 字节。这是头名称 "header/bizarre" 中的斜杠（'/'），它不是一个有效的 HTTP 头名称字符。

转储所有打开的文件描述符列表，或者如果指定了，只转储文件描述符编号 <fd>。这仅适用于需要观察内部状态以调试复杂问题（如异常 CPU 使用率）的开发人员。每个 fd 报告一行，对于每个 fd，报告其在轮询器中的状态，使用大写字母表示启用的标志，小写字母表示禁用的标志，使用 "P" 表示 "polled"（已轮询），"R" 表示 "ready"（就绪），"A" 表示 "active"（活动），事件状态使用 "H" 表示 "hangup"（挂起），"E" 表示 "error"（错误），"O" 表示 "output"（输出），"P" 表示 "priority"（优先），"I" 表示 "input"（输入），以及其他一些标志，如 "N" 表示 "new"（刚添加到 fd 缓存中），"U" 表示 "updated"（在 fd 缓存中收到更新），"L" 表示 "linger_risk"，"C" 表示 "cloned"（已克隆），然后是缓存的条目位置、指向内部所有者的指针、指向 I/O 回调的指针及其名称（如果已知）。当所有者是连接时，报告连接标志和目标（前端、代理或服务器）。当所有者是侦听器时，报告侦听器的状态及其前端。在不熟悉内部机制的情况下使用此命令没有意义。值得注意的是，输出格式可能会随时间演变，因此此输出不应被设计为持久性的工具解析。

报告一些关于内部事件的计数器，这将帮助开发人员以及通常对 haproxy 足够了解的人员缩小异常行为报告的原因。一个典型的例子是一个正常运行的进程从不休眠并占用 100% 的 CPU。输出字段将由每个指标一行组成，同一行上是每个线程的计数器。这些计数器是 32 位的，会在进程的生命周期内回绕，这不是问题，因为通常会对该命令进行两次调用。这些字段的目的性地没有文档化，以便在提供计数器的代码中验证其确切含义。这些值也会被 "clear counters" 命令重置。

转储当前进程上有关 haproxy 状态的信息。如果将 "typed" 作为可选参数传递，则字段编号、名称和类型也会被发出，以便外部监控产品可以轻松检索、可能聚合，然后报告在它们不知道的字段中找到的信息。每个字段都在其自己的行上转储。如果将 "json" 作为可选参数传递，则 "typed" 输出提供的信息将以 JSON 格式作为 JSON 对象列表提供。默认情况下，格式只包含由冒号（':'）分隔的两列。左边是字段名，右边是值。非常重要的一点是，在类型化输出格式中，单个对象的转储是连续的，因此消费者无需一次存储所有内容。当使用类型化输出格式时，每行由冒号（':'）分隔的 4 列组成。第一列是由点分隔的 3 个元素的系列。第一个元素是字段在列表中的数字位置（从零开始）。这个位置不应随时间改变，但根据构建选项或将来删除某些字段，可能会出现空缺。第二个元素是字段名，与默认的 "show info" 输出中显示的一样。第三个元素是相对进程号，从 1 开始。从第一个冒号开始的行剩余部分遵循上面描述的“类型化输出格式”。简而言之，第二列（在第一个':'之后）表示变量的来源、性质和范围。第三列表示字段的类型，包括 "s32", "s64", "u32", "u64" 和 "str"。然后第四列是值本身，消费者知道如何根据第 3 列进行解析，并根据第 2 列进行处理。因此，类型化模式下的整体行格式是： <field_pos>.<field_name>.<process_num>:<tags>:<type>:<value>

> 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 (...)

在类型化格式中，第一列末尾的进程ID使得从多个进程的输出中进行视觉聚合变得非常容易。

$ ( 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 (...)

JSON 输出的格式在一个 schema 中描述，可以使用“show schema json”输出该 schema。JSON 输出不包含额外的空白字符，以减少输出量。为了方便人类阅读，可以通过一个美化打印器来处理输出。示例：$ echo "show info json" | socat /var/run/haproxy.sock stdio | \ python -m json.tool JSON 输出不包含额外的空白字符，以减少输出量。为了方便人类阅读，可以通过一个美化打印器来处理输出。示例：$ echo "show info json" | socat /var/run/haproxy.sock stdio | \ python -m json.tool

转储关于 map 转换器的信息。不带参数时，返回所有可用 map 的列表。如果指定了 <map>，则转储其内容。<map> 是 #<id> 或 <file>。第一列是唯一标识符。它可以作为 "del map" 和 "set map" 操作的参考。第二列是模式，第三列是样本（如果可用）。返回的数据不是直接的可用 map 列表，而是构成任何 map 的所有模式的列表。这些模式中的许多可以与 ACL 共享。

转储内部内存池的状态。这对于在怀疑有内存泄漏时跟踪内存使用情况很有用。它与在前台运行时发送 SIGQUIT 信号的作用完全相同，只是它不会刷新池。

转储给定解析器部分或所有解析器部分（如果未提供部分）的统计信息。对于每个名称服务器，报告以下计数器： sent: 发送到此服务器的 DNS 请求数 valid: 从此服务器收到的有效 DNS 响应数 update: 用于更新服务器 IP 地址的 DNS 响应数 cname: CNAME 响应数 cname_error: 此服务器遇到的 CNAME 错误数 any_err: 空响应数 (即：服务器不支持 ANY 类型) nx: 从此服务器收到的不存在的域响应 timeout: 此服务器未及时应答的次数 refused: 此服务器拒绝的请求数 other: 任何其他 DNS 错误 invalid: 无效的 DNS 响应（从协议角度看） too_big: 响应过大 outdated: 响应到达过晚的次数（在另一个名称服务器之后）

转储在运行配置中找到的服务器的状态。可以提供后端名称或标识符以将输出仅限于该后端。转储格式如下：- 第一行包含格式版本（在本规范中为1）；- 第二行包含列标题，前缀为井号（'#'）；- 第三行及以后包含数据；- 每个以井号（'#'）开头的行都被视作注释。由于可能共存多个版本的输出，下面是每个文件格式版本的字段及其顺序列表：1: be_id: 后端唯一ID。 be_name: 后端标签。 srv_id: 服务器唯一ID（在后端内）。 srv_name: 服务器标签。 srv_addr: 服务器IP地址。 srv_op_state: 服务器操作状态 (UP/DOWN/...)。 0 = SRV_ST_STOPPED 服务器已关闭。 1 = SRV_ST_STARTING 服务器正在预热（已启动但受限）。 2 = SRV_ST_RUNNING 服务器完全正常运行。 3 = SRV_ST_STOPPING 服务器已启动但正在软停止（例如：404）。 srv_admin_state: 服务器管理状态 (MAINT/DRAIN/...)。 该状态实际上是一个值的掩码： 0x01 = SRV_ADMF_FMAINT 服务器被明确强制进入维护状态。 0x02 = SRV_ADMF_IMAINT 服务器从被跟踪的服务器继承了维护状态。 0x04 = SRV_ADMF_CMAINT 由于配置，服务器处于维护状态。 0x08 = SRV_ADMF_FDRAIN 服务器被明确强制进入排空状态。 0x10 = SRV_ADMF_IDRAIN 服务器从被跟踪的服务器继承了排空状态。 0x20 = SRV_ADMF_RMAINT 由于IP地址解析失败，服务器处于维护状态。 0x40 = SRV_ADMF_HMAINT 服务器FQDN通过统计套接字设置。 srv_uweight: 用户可见的服务器权重。 srv_iweight: 服务器的初始权重。 srv_time_since_last_change: 自上次操作状态变更以来的时间。 srv_check_status: 上次健康检查状态。 srv_check_result: 上次检查结果 (FAILED/PASSED/...)。 0 = CHK_RES_UNKNOWN 默认初始化为此值。 1 = CHK_RES_NEUTRAL 检查有效但无状态信息。 2 = CHK_RES_FAILED 检查失败。 3 = CHK_RES_PASSED 检查成功且服务器再次完全正常运行。 4 = CHK_RES_CONDPASS 检查报告服务器不希望接收新会话。 srv_check_health: 检查的 rise / fall 当前计数器。 srv_check_state: 检查的状态 (ENABLED/PAUSED/...)。 该状态实际上是一个值的掩码： 0x01 = CHK_ST_INPROGRESS 检查当前正在运行。 0x02 = CHK_ST_CONFIGURED 此检查已配置并可能被启用。 0x04 = CHK_ST_ENABLED 此检查当前在管理上已启用。 0x08 = CHK_ST_PAUSED 由于维护，检查已暂停（仅健康检查）。 srv_agent_state: 代理检查的状态 (ENABLED/PAUSED/...)。 此状态使用与 "srv_check_state" 相同的掩码值，并添加此特定值： 0x10 = CHK_ST_AGENT 检查是代理检查（否则是健康检查）。 bk_f_forced_id: 标志，用于判断后端ID是否由配置强制指定。 srv_f_forced_id: 标志，用于判断服务器ID是否由配置强制指定。 srv_fqdn: 服务器 FQDN。 srv_port: 服务器端口。 srvrecord: 与此 SRV 关联的 DNS SRV 记录。

转储所有已知会话。避免在慢速连接上执行此操作，因为这可能会非常庞大。此命令受限制，只能在为 "operator" 或 "admin" 级别配置的套接字上发出。请注意，在连接快速回收的机器上，此输出报告的条目可能比实际存在的少，因为它将转储在输入命令之前创建的所有现有会话直到最后一个；在此期间终止的会话将不会出现。

显示有关指定会话标识符的大量内部信息。此标识符是“show sess”转储中行开头的第一个字段（它对应于会话指针）。这些信息对大多数用户无用，但可能被 haproxy 开发人员用于排查复杂的错误。输出格式有意不作文档说明，以便可以根据需求自由演变。您可以在 src/dumpstats.c 中找到所有返回字段的描述。特殊 id "all" 会转储所有会话的状态，必须尽可能避免使用，因为它非常消耗 CPU 并且可能需要很长时间。

使用 CSV 格式转储统计信息；如果 "typed" 在其他参数后传递，则使用上面章节描述的扩展类型化输出格式；或者如果 "json" 在其他参数后传递，则以 JSON 格式转储。通过传递 <id>、<type> 和 <sid>，可以只转储选定的项目：- <iid> 是代理 ID，-1 表示转储所有内容。或者，可以指定代理名称 <proxy>。在这种情况下，此代理的 ID 将用作 ID 选择器。- <type> 选择可转储对象的类型：1 表示前端，2 表示后端，4 表示服务器，-1 表示所有内容。这些值可以进行或运算，例如：1 + 2 = 3 -> 前端 + 后端。1 + 2 + 4 = 7 -> 前端 + 后端 + 服务器。- <sid> 是服务器 ID，-1 表示转储所选代理的所有内容。

$ 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, (...) $

在此示例中，一次发出了两个命令。这样，在多进程模式下很容易找出统计信息适用于哪个进程。在类型化输出格式中不需要这样做，因为进程号在每行上都有报告。请注意信息输出后的空行，它标记了第一个块的结束。第二个块（统计信息）的末尾也会出现类似的空行，以便读者知道输出未被截断。当指定 "typed" 时，输出格式更适合监控工具，因为它提供了数字位置并指示每个输出字段的类型。每个值都独立成行，包含进程号、元素号、性质、来源和范围。通过在 URI 后传递 ";typed"，可以通过 HTTP 统计信息获得相同的格式。非常重要的一点是，在类型化输出格式中，单个对象的转储是连续的，因此消费者无需一次存储所有内容。当使用类型化输出格式时，每行由冒号（':'）分隔的 4 列组成。第一列是由点分隔的 5 个元素的系列。第一个元素是表示所描述对象类型的字母。目前已知的对象类型如下：'F' 代表前端，'B' 代表后端，'L' 代表侦听器，'S' 代表服务器。第二个元素是表示对象所属代理的唯一标识符的正整数。它等同于 CSV 输出的 "iid" 列，并与前端或后端部分中可选的 "id" 指令前面的值匹配。第三个元素是包含代理内部唯一对象标识符的正整数，并对应于 CSV 输出的 "sid" 列。转储前端或后端时报告 ID 0。对于侦听器或服务器，这对应于它们在代理内部的各自 ID。第四个元素是字段在列表中的数字位置（从零开始）。这个位置不应随时间改变，但根据构建选项或将来删除某些字段，可能会出现空缺。第五个元素是字段名，与 CSV 输出中显示的一样。第六个元素是一个正整数，是相对进程号，从 1 开始。从第一个冒号开始的行剩余部分遵循上面章节描述的“类型化输出格式”。简而言之，第二列（在第一个':'之后）表示变量的来源、性质和范围。第三列表示字段的类型，包括 "s32", "s64", "u32", "u64" 和 "str"。然后第四列是值本身，消费者知道如何根据第 3 列进行解析，并根据第 2 列进行处理。因此，类型化模式下的整体行格式是： <obj>.<px_id>.<id>.<fpos>.<fname>.<process_num>:<tags>:<type>:<value> 以下是类型化输出格式的示例：$ 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 (...) 在类型化格式中，第一列末尾的进程 ID 使得从视觉上聚合多个进程的输出变得非常容易，如下例所示，其中每行都为每个进程出现：$ ( 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 (...) JSON 输出的格式在一个模式中描述，可以使用 "show schema json" 输出该模式。JSON 输出不包含额外的空白，以减少输出量。为了便于人类阅读，将输出通过一个美化打印器可能会有所帮助。示例：$ echo "show stat json" | socat /var/run/haproxy.sock stdio | \ python -m json.tool JSON 输出不包含额外的空白，以减少输出量。为了便于人类阅读，将输出通过一个美化打印器可能会有所帮助。示例：$ echo "show stat json" | socat /var/run/haproxy.sock stdio | \ python -m json.tool

转储所有已知粘性表的一般信息。返回它们的名称（持有它们的代理的名称）、它们的类型（目前为零，总是 IP）、它们的最大可能条目数大小，以及当前使用的条目数。

$ echo "show table" | socat stdio /tmp/sock1 >>> # table: front_pub, type: ip, size:204800, used:171454 >>> # table: back_rdp, type: ip, size:204800, used:0

转储粘性表 <name> 的内容。在此模式下，首先会报告一行关于该表的通用信息，与 "show table" 类似，然后转储所有条目。由于这可能非常耗时，可以指定一个过滤器以指定要显示的条目。当使用 "data." 形式时，过滤器应用于存储的数据（参见第4.2节中的 "stick-table"）。必须在 <type> 中指定一个存储的数据类型，并且该数据类型必须存储在表中，否则会报告错误。数据会根据 <operator> 与 64 位整数 <value> 进行比较。操作符与 ACL 相同：- eq: 匹配数据等于此值的条目 - ne: 匹配数据不等于此值的条目 - le: 匹配数据小于或等于此值的条目 - ge: 匹配数据大于或等于此值的条目 - lt: 匹配数据小于此值的条目 - gt: 匹配数据大于此值的条目 当使用 key 形式时，会显示条目 <key>。键的类型必须与表的类型相同，目前仅限于 IPv4、IPv6、整数和字符串。

$ echo "show table http_proxy" | socat stdio /tmp/sock1 >>> # table: http_proxy, type: ip, size:204800, used:2 >>> 0x80e6a4c: key=127.0.0.1 use=0 exp=3594729 gpc0=0 conn_rate(30000)=1 \ bytes_out_rate(60000)=187 >>> 0x80e6a80: key=127.0.0.2 use=0 exp=3594740 gpc0=1 conn_rate(30000)=10 \ bytes_out_rate(60000)=191 $ echo "show table http_proxy data.gpc0 gt 0" | socat stdio /tmp/sock1 >>> # table: http_proxy, type: ip, size:204800, used:2 >>> 0x80e6a80: key=127.0.0.2 use=0 exp=3594740 gpc0=1 conn_rate(30000)=10 \ bytes_out_rate(60000)=191 $ echo "show table http_proxy data.conn_rate gt 5" | \ socat stdio /tmp/sock1 >>> # table: http_proxy, type: ip, size:204800, used:2 >>> 0x80e6a80: key=127.0.0.2 use=0 exp=3594740 gpc0=1 conn_rate(30000)=10 \ bytes_out_rate(60000)=191 $ echo "show table http_proxy key 127.0.0.2" | \ socat stdio /tmp/sock1 >>> # table: http_proxy, type: ip, size:204800, used:2 >>> 0x80e6a80: key=127.0.0.2 use=0 exp=3594740 gpc0=1 conn_rate(30000)=10 \ bytes_out_rate(60000)=191

当数据标准应用于依赖于时间的动态值（例如字节速率）时，该值在评估条目期间动态计算，以决定是否必须转储它。这意味着这样的过滤器可能会在一段时间内匹配，然后由于时间的推移，平均事件速率下降而不再匹配。可以利用这一点来提取滥用服务的 IP 地址列表，以便监视它们甚至在防火墙中将它们列入黑名单。

$ echo "show table http_proxy data.gpc0 gt 0" \ | socat stdio /tmp/sock1 \ | fgrep 'key=' | cut -d' ' -f2 | cut -d= -f2 > abusers-ip.txt ( 或 | awk '/key/{ print a[split($2,a,"=")]; }' )

转储所有已加载的 TLS ticket 密钥引用。将显示 TLS ticket 密钥引用 ID 和加载密钥的文件。这两个都可用于使用“set ssl tls-key”更新 TLS 密钥。如果指定了一个 ID 作为参数，它将转储 tickets，使用 * 将转储每个引用的所有密钥。

转储用于“show info json”和“show stat json”输出的模式。为了减少输出量，其中不包含额外的空格。为了方便人类阅读，可以通过一个美化打印器来处理输出。示例：$ echo "show schema json" | socat /var/run/haproxy.sock stdio | \ python -m json.tool 该模式遵循“JSON Schema”(json-schema.org)，因此可以使用验证器来验证“show info json”和“show stat json”的输出是否符合该模式。

完全删除指定的前端。它所绑定的所有端口都将被释放。此操作后将无法再启用该前端。这旨在用于那些甚至无法想象停止代理但必须修复配置错误的代理的环境中。这样就可以释放端口并将其绑定到另一个进程以恢复操作。一旦终止，该前端将完全不会出现在统计页面上。前端可以通过其名称或以井号（'#'）为前缀的数字 ID 来指定。此命令受限制，只能在配置为 "admin" 级别的套接字上发出。

立即终止与指定会话标识符匹配的会话。此标识符是“show sess”转储中行开头的第一个字段（它对应于会话指针）。这可用于终止一个长时间运行的会话，而无需等待超时或当正在进行无休止的传输时。此类被终止的会话在日志中以“K”标志报告。

立即终止附加到指定服务器的所有会话。例如，这可用于在服务器进入维护模式后终止长时间运行的会话。此类被终止的会话在日志中以“K”标志报告。

很常见的情况是，构成集群的两个 HAProxy 节点共享完全相同的配置，只是一些地址不同。与其为每个节点维护一个重复的配置（这不可避免地会产生差异），不如在配置中包含环境变量。这样，多个配置可以共享完全相同的文件，只有少数几个系统范围的环境变量不同。这始于 1.5 版本，当时只允许地址包含环境变量，而 1.6 版本则更进一步，支持在任何地方使用环境变量。语法与 UNIX shell 中的相同，变量以美元符号（'$'）开头，后跟一个左花括号（'{'），然后是变量名，最后是右花括号（'}'）。除了地址之外，环境变量只在用双引号括起来的参数中解释（这是为了不破坏现有使用涉及美元符号的正则表达式的设置）。环境变量也使得编写期望在不同站点上工作的配置变得方便，这些站点只有地址不同。它还可以允许从某些配置中删除密码。下面的示例中，文件 "site1.env" 在启动时由 init 脚本加载：$ cat site1.env LISTEN=192.168.1.1 CACHE_PFX=192.168.11 SERVER_PFX=192.168.22 LOGGER=192.168.33.1 STATSLP=admin:pa$$w0rd ABUSERS=/etc/haproxy/abuse.lst TIMEOUT=10s $ cat haproxy.cfg global log "${LOGGER}:514" local0 defaults mode http timeout client "${TIMEOUT}" timeout server "${TIMEOUT}" timeout connect 5s frontend public bind "${LISTEN}:80" http-request reject if { src -f "${ABUSERS}" } stats uri /stats stats auth "${STATSLP}" use_backend cache if { path_end .jpg .css .ico } default_backend server backend cache server cache1 "${CACHE_PFX}.1:18080" check server cache2 "${CACHE_PFX}.2:18080" check backend server server cache1 "${SERVER_PFX}.1:8080" check server cache2 "${SERVER_PFX}.2:8080" check

偶尔有人报告说，系统重启后，haproxy 服务没有启动，而一旦他们手动启动它，它就能正常工作。大多数情况下，这些人正在运行一个集群 IP 地址机制，如 keepalived，只将服务 IP 地址分配给主节点，虽然当他们将 haproxy 绑定到地址 0.0.0.0 时它曾经工作正常，但在他们将其绑定到虚拟 IP 地址后就停止工作了。这里发生的情况是，当服务启动时，虚拟 IP 地址尚未被本地节点拥有，所以当 HAProxy 想要绑定到它时，系统会拒绝，因为它不是一个本地 IP 地址。修复方法不是延迟 haproxy 服务的启动（因为它无法承受重启），而是正确配置系统以允许绑定到非本地地址。这在 Linux 上很容易做到，只需将 net.ipv4.ip_nonlocal_bind sysctl 设置为 1。为了透明地拦截通过 HAProxy 的特定目标地址的 IP 流量，这也是必需的。涉及源端口范围的多进程配置可能看起来可以工作，但它们在高负载下会导致一些随机故障，因为多个进程可能试图使用相同的源端口连接到同一个服务器，这是不可能的。系统会报告一个错误，然后会进行重试，选择另一个端口。“retries”参数中的高值可以在一定程度上掩盖这种影响，但这也会增加 CPU 使用率和处理时间。日志也会报告一定数量的重试。因此，在多进程配置中应避免使用端口范围。由于 HAProxy 使用 SO_REUSEPORT 并支持将多个独立进程绑定到同一个 IP:port，在故障排除期间，可能会发生旧进程在启动新进程之前没有停止的情况。这会提供荒谬的测试结果，倾向于表明对配置的任何更改都被忽略了。原因在于，事实上，即使新进程以新配置重新启动，旧进程也会接收到一些传入连接并处理它们，返回意外的结果。如有疑问，只需停止新进程再试一次。如果它仍然工作，很可能意味着一个旧进程仍然存活并且必须被停止。Linux 的 "netstat -lntp" 在这里很有帮助。当从命令行向 ACL 添加条目时（例如：当将源地址列入黑名单时），重要的是要记住这些条目不会同步到文件，如果有人重新加载配置，这些更新将会丢失。虽然这通常是期望的效果（对于黑名单），但当更改是作为问题修复时，它可能不一定符合预期。请参阅 CLI 接口的 "add acl" 操作。

当 HAProxy 以 "-d" 选项启动时，它会保持在前台运行，并为每个事件打印一行，例如传入连接、连接结束，以及看到的每个请求或响应头行。此调试输出在内容处理之前发出，因此它们不考虑本地修改。主要用途是显示请求和响应，而无需运行网络嗅探器。当并行处理多个连接时，输出的可读性会降低，尽管 examples/ 目录中的 "debug2ansi" 和 "debug2html" 脚本通过为输出着色对此有很大帮助。如果请求或响应因为 HAProxy 发现其格式错误而被拒绝，最好的做法是连接到 CLI 并发出 "show errors" 命令，它将报告每个前端和后端捕获的最后一个错误请求和响应，并提供所有必要的信息，以精确指出输入流中被拒绝的第一个字符。这有时需要向客户或开发人员证明他们的代码中存在错误。在这种情况下，通常可以使用 "option accept-invalid-http-request" 或其等效的服务器响应选项 "option accept-invalid-http-response" 来放宽检查（但仍保留捕获）。有关更多详细信息，请参阅配置手册。

> show errors Total events captured on [13/Oct/2015:13:43:47.169] : 1 [13/Oct/2015:13:43:40.918] frontend HAProxyLocalStats (#2): invalid request backend <NONE> (#-1), server <NONE> (#-1), event #0 src 127.0.0.1:51981, session #0, session flags 0x00000080 HTTP msg state 26, msg flags 0x00000000, tx flags 0x00000000 HTTP chunk len 0 bytes, HTTP body len 0 bytes buffer flags 0x00808002, out 0 bytes, total 31 bytes pending 31 bytes, wrapping at 8040, error at position 13: 00000 GET /invalid request HTTP/1.1\r\n

CLI 上的“show info”命令输出提供了许多有用的信息，涉及曾达到的最大连接速率、曾达到的最大 SSL 密钥速率，以及通常所有有助于解释有关 CPU 或内存使用的临时问题的信息。示例： > show info Name: HAProxy Version: 1.6-dev7-e32d18-17 Release_date: 2015/10/12 Nbproc: 1 Process_num: 1 Pid: 7949 Uptime: 0d 0h02m39s Uptime_sec: 159 Memmax_MB: 0 Ulimit-n: 120032 Maxsock: 120032 Maxconn: 60000 Hard_maxconn: 60000 CurrConns: 0 CumConns: 3 CumReq: 3 MaxSslConns: 0 CurrSslConns: 0 CumSslConns: 0 Maxpipes: 0 PipesUsed: 0 PipesFree: 0 ConnRate: 0 ConnRateLimit: 0 MaxConnRate: 1 SessRate: 0 SessRateLimit: 0 MaxSessRate: 1 SslRate: 0 SslRateLimit: 0 MaxSslRate: 0 SslFrontendKeyRate: 0 SslFrontendMaxKeyRate: 0 SslFrontendSessionReuse_pct: 0 SslBackendKeyRate: 0 SslBackendMaxKeyRate: 0 SslCacheLookups: 0 SslCacheMisses: 0 CompressBpsIn: 0 CompressBpsOut: 0 CompressBpsRateLim: 0 ZlibMemUsage: 0 MaxZlibMemUsage: 0 Tasks: 5 Run_queue: 1 Idle_pct: 100 node: wtap description: 当一个问题似乎在新版本的 HAProxy 上随机出现时（例如：每隔一个请求就中止、偶尔崩溃等），值得尝试启用内存投毒（memory poisoning），这样每次调用 malloc() 后，会立即用一个可配置的字节填充该内存区域。默认情况下，这个字节是 0x50（'P' 的 ASCII 码），但也可以使用任何其他字节，包括零（其效果与 calloc() 相同，可能会使问题消失）。内存投毒通过命令行选项“-dM”启用。它会轻微影响性能，不建议在生产环境中使用。如果启用后问题总是发生，或者在使用字节零进行投毒时问题从不发生，这清楚地意味着你发现了一个 bug，并且绝对需要报告它。否则，如果没有明显变化，则问题与此无关。 当调试某些延迟问题时，重要的是在本地机器上同时使用 strace 和 tcpdump，并在远程系统上使用另一个 tcpdump。这样做的原因在于，处理链的每个环节都存在延迟，重要的是要知道是哪一个环节导致了延迟，以便知道在哪里采取行动。实践中，本地的 tcpdump 将指示输入数据何时到达。Strace 将指示 haproxy 何时接收到这些数据（使用 recv/recvfrom）。警告，openssl 使用 read()/write() 系统调用而不是 recv()/send()。Strace 还会显示 haproxy 何时发送数据，而 tcpdump 将显示系统何时将这些数据发送到接口。然后，外部的 tcpdump 将显示发送的数据何时被真正接收（因为本地的 tcpdump 只显示数据包何时被加入队列）。在本地系统上抓包的好处是 strace 和 tcpdump 将使用相同的参考时钟。Strace 应与“-tts200”一起使用，以获取完整的时间戳并报告足够大的数据块以便读取。Tcpdump 应与“-nvvttSs0”一起使用，以报告完整的报文、真实的序列号和完整的时间戳。 实践中，接收到的数据几乎总是立即被 haproxy 接收（除非机器的 CPU 饱和或这些数据无效而未被传递）。如果这些数据被接收但未被发送，通常是因为输出缓冲区饱和了（即：接收方消耗数据的速度不够快）。这可以通过观察到轮询在一段时间内没有通知输出文件描述符可写来确认（在 strace 输出中，当数据最终发出时，往回追溯查看写事件何时被通知，通常更容易发现）。这通常与从接收方收到的 ACK 相匹配，并被 tcpdump 检测到。一旦数据发送出去，它们可能会在系统中停留一段时间什么也不做。这里，TCP 拥塞窗口可能受到限制，不允许这些数据离开，等待一个 ACK 来打开窗口。如果流量是空闲的，数据需要 40 毫秒或 200 毫秒才能离开，这是另一个不同的问题（其实也不是问题），这是因为 Nagle 算法阻止空数据包立即离开，希望它们能与后续数据合并。HAProxy 在纯 TCP 模式和隧道模式下会自动禁用 Nagle 算法。然而，在转发 HTTP 主体时，它肯定是启用的（这通过减少数据包数量有助于提高性能）。一些不符合 HTTP 规范的应用程序可能对传递不完整的 HTTP 响应消息时的延迟很敏感。在这种情况下，你将需要启用“option http-no-delay”来禁用 Nagle 算法，以解决其设计问题，同时要记住，链中的任何其他代理也可能受到类似的影响。 如果 tcpdump 报告数据立即离开，但另一端没有很快看到它们，这可能意味着存在拥塞的广域网（WAN）链路、启用了流控制并阻止数据离开的拥塞局域网（LAN），或者更常见的是，HAProxy 实际上运行在虚拟机中，并且由于某种原因，虚拟机监控程序（hypervisor）决定了数据不需要立即发送。在虚拟化环境中，延迟问题几乎总是由虚拟化层引起的，因此为了节省时间，首先比较虚拟机内和外部组件上的 tcpdump 是值得的。任何差异都必须归因于虚拟机监控程序及其附带的驱动程序。 当在 tcpdump 跟踪中看到一些 TCP SACK 段时（使用 -vv），这总是意味着发送方已确认有数据包丢失。虽然没有看到它们并不意味着没有丢包，但看到它们绝对意味着网络是有损的。网络上的丢包是正常的，但其速率应低到肉眼无法察觉 SACK。如果它们在跟踪中大量出现，就值得调查究竟发生了什么以及数据包在哪里丢失。HTTP 不能很好地应对 TCP 丢包，这会引入巨大的延迟。 “netstat -i”命令将报告每个接口的统计信息。一个 Rx-Ovr 计数器增长的接口表明系统没有足够的资源来接收所有传入的数据包，并且它们在被网络驱动程序处理之前就丢失了。Rx-Drp 表示一些接收到的数据包在网络栈中丢失，因为应用程序处理它们的速度不够快。这在某些攻击期间也可能发生。Tx-Drp 意味着输出队列已满，数据包不得不被丢弃。当使用 TCP 时，这种情况应该非常罕见，但可能表明出向链路已饱和。

HAProxy 被设计为以非常有限的权限运行。其标准使用方式是将其隔离在一个 chroot 监牢中，并将其权限降级为一个在该监牢内没有任何权限的非 root 用户，这样一来，即使未来发现任何漏洞，其被攻破也不会影响系统的其余部分。为了执行 chroot，它首先需要以 root 用户身份启动。手动构建 chroot 来启动进程是毫无意义的，这些 chroot 不仅构建过程痛苦，而且永远无法得到妥善维护，并且总是比主文件系统包含更多的 bug。而且一旦被攻破，入侵者可以利用这个特意构建的文件系统。不幸的是，许多管理员混淆了“以 root 身份启动”和“以 root 身份运行”，导致在启动 haproxy 之前就更改了 uid，从而降低了有效的安全限制。HAProxy 需要以 root 身份启动以便： - 调整文件描述符限制 - 绑定到特权端口号 - 绑定到特定的网络接口 - 透明地监听一个外部地址 - 将自身隔离在 chroot 监牢内 - 降权到另一个非特权的 UID HAProxy 可能需要以 root 身份运行以便： - 为出向连接绑定到一个接口 - 为出向连接绑定到特权源端口 - 为出向连接透明地绑定到一个外部地址 大多数用户永远不需要“以 root 身份运行”的情况。但“以 root 身份启动”涵盖了大多数用法。一个安全的配置将包含： - 一个 chroot 语句，指向一个没有任何访问权限的空位置。这可以在 UNIX 命令行上这样准备： # mkdir /var/empty && chmod 0 /var/empty || echo "Failed" 并在 HAProxy 配置的 global 部分这样引用： chroot /var/empty - 在 global 部分同时有 uid/user 和 gid/group 语句： user haproxy group haproxy - 一个 stats socket，其 mode、uid 和 gid 被设置为匹配允许访问 CLI 的用户和/或组，以便任何人都无法访问它： stats socket /var/run/haproxy.stat uid hatop gid hatop mode 600