负载均衡器黄金指标

2018-04-17 Steve Mushero
负载均衡器是大多数现代系统当中的关键性组成部分，通常位于应用程序之前，但也被越来越多地引入用于支持容器、套接服务以及数据库等系统当中。
目前市面上存在多种高人气负载均衡器，这里我们主要讨论其中三款：
HAProxy: 人人喜爱的非云负载均衡器
AWS ELB: 弹性负载均衡服务
AWS ALB: 应用负载均衡器
对于 Nginx，请参阅本系列第三篇 Web 服务器部分。
一些常规负载均衡器问题首先，我们需要对负载均衡器的一些通性进行思考——其监控复杂性要远超 Web 服务器。
结合或独立前端我们可以通过两种方式审视负载均衡器信号 ——立足前端或立足后端。在前端方面，我们需要面向不同域或网站部分（例如 API 以及验证等）关注数种信号。
我们通常比较关注负载均衡器的总体信号（OVERALL），即面向所有前端。当然，如果分别有不同系统对接 Web、应用、API 以及搜索等对象，我们也可能需要分别追踪与之对应的各前端。这意味着我们将独立处理功能各异的单独信号。
需要注意的是，某些系统对于 HTTP 与 HTTPS 采用不同的监听程序 / 后端，但其支持几乎相同的 URL，因此大家完全可以将合并为统一视图并进行实际监控。
监控负载均衡器与 Web 服务器中的后端服务器负载均衡器通常拥有多套后端服务器，而我们能够从各后端服务器当中获取信号。在理想情况下，我们并不需要弄得这么麻烦，因为理论上我们可以直接从后端 Web/ 应用服务器处直接获取更好的数据。
然而正如我们在 Web 与应用服务器章节中将要看到的，这样的想法根本无法实现——因为 Web 服务器监控非常困难。具体来讲，立足负载均衡器获取每服务器后端服务器信号通常更简单易行，信息质量也更好。
我们将在后文当中具体讨论如何实现具体监控操作。
HAProxyHAProxy 是目前最受欢迎的非云负载均衡器。作为一套功能强大、灵活且性能出色的平台，HAProxy 受到广大用户的积极拥护。HAProxy 亦拥有强大的日志记录功能以及一套不错的用户界面。然而，要从中获得实用数据，我们仍然需要一些技巧——有时候其数据太过丰富，我们必须从中筛选出最为重要的部分。
注意——单进程与多进程 HAProxy大多数（甚至全部）HAProxy 版本只面向单一进程报告统计数据，这种方法对于 99% 的用例都没有问题，但极少数高性能系统会使用多进程模式，这意味着其监控难度将直线提升。因为统计数据将随机提取自某一进程，这可能引发混乱，因此大家必须尽可能避免多进程监控情况。
注意——复杂性HAProxy 当中的实用统计信息包括 PER 监听程序、后端或者服务器几种，虽然这些指标都很重要，但却会给整体评估带来复杂性挑战。简单的网站或应用程序通常只有一个（www.）监听程序与后端，但更为复杂的系统却通常包含多个监听程序与后端。这意味着我们会很快收集到数百项指标并陷入混乱。
你可以决定是否要追踪全部监听程序 / 前端信号，或者对这些信号加以总结以获取整体观点——具体取决于你系统的实际统一方式。如上所述，我们通常希望将使用相同 URL 的 HTTP 与 HTTPS 加以合并。然而，如果你拥有彼此独立的 Web、应用、API 以及搜索服务器，则可能需要分别收集对应信号。
HAProxy，我要如何监控？目前有三种方法可用于监控 HAProxy，且其皆使用同样的格式。
从内置网页当中提取 CSV 数据
使用 CLI 工具
使用 Unix Socket
请参阅 HAProxy 说明文档以了解如何实现这三种监控方法，具体取决于你所使用的监控系统与工具。
在将我们的信号映射至 HAProxy 时，其复杂性开始初步显现出来：
请求率：即每秒请求数量，我们可以使用以下两种方式：
请求 Count REQ_TOT 不适用于每服务器，而仅计算全部服务器的总体请求率（虽然仅限于最后一秒）。
你也可以使用 REQ_RATE (每秒请求)，但其仅限于最后一秒，因此大家可能会错过数据峰值时段——特别是你的监控时长在一分钟以下时。
错误率：响应错误（简称 ERESP），代表来自后端的错误数量。这是一个计数器，因此你必须对其进行增量计算。不过需要注意的是，相关文档指出其中包含“客户端套接上的写入错误”，所以我们很难搞清这一数值中包含哪些客户端错误类型（特别是在移动设备上）。大家也可以使用这种方法获取每后端服务器信号。
关于更多细节信息以及纯 HTTP 错误，大家通常会得到 4xx 及 5xx 错误计数，用户对这类提示也表现得最为敏感。其中 4xx 错误通常不属于客户自身的问题，但如果其突然出现，则通常源自代码错误或者某种形式的攻击。而监控 5xx 错误对于所有系统都非常重要。  你可能还希望查看请求错误（简称 EREQ），但请注意，这类错误中包括可能带来大量噪声的客户端关闭（特别是在低速或移动网络情况下）。仅限于前端。
延迟：即每后端响应时间（简称 RTIME），代表过去 1024 条请求的平均延迟（在繁忙系统上，1024 条请求周期可能太短并导致错失峰值状况 ; 但在新启动的系统上，1024 条请求周期可能太长而混入大量噪声）。此项信号适用于每服务器。
饱和度：队列请求的数量（简称 QCUR）。这一信号适用于后端（代表未被分配至服务器的请求）以及每服务器（代表未被发送至目标服务器的请求）。
你可能需要将各项数值相加以计算整体饱和度，或追踪每服务器信号以了解单服务器饱和度（详见 Web 服务器章节）。如果使用每服务器监控方式，则应追踪每套后端服务器的饱和度（但请注意，该服务器自身可能同样在排队，因此负载均衡器中的任何队列都代表着一项严重问题）。
利用率：HAProxy 通常不会耗尽全部容量，除非 CPU 资源已经被全部占用，但你也可以监控实际会话 SCUR/SLIM。
AWS ELB 与 ALBAWS ELB/ALB 负载均衡器在各类基于 AWS 的系统当中极为普遍。从简单的 ELB 起步，再到 ALB 的补充性加入，二者已经逐步发展成为功能齐全且相当强大的均衡器方案。
与大多数 AWS 服务一样，各项指标将通过 Cloud Watch 与推送至 S3 的日志共同实现提取。其格式易于处理，但处理 S3 中的日志却稍有难度，因此我们会尽量避免这种处理方法（部分原因在于，我们无法立足 S3 中的日志进行实时处理，也无法借此实现警报机制）。
需要注意的是，以下内容适用于 HTTP，但 ELB 与 ALB 同时提供面向 TCP 连接的其它指标，你可通过同样的方法加以使用。
若需了解更多细节信息，请参阅 ELB CloudWatch 说明文档。
典型 ELBELB 指标适用于 ELB 整体，但遗憾的是无法由后端组或服务器处提取。需要注意的是，若每个可用区内只有一套后端服务器，则可使用可用区维度过滤器。
将信号映射至 ELB 后，我们可从 CloudWatch 处获取全部信号。请注意，指标当中的 sum() 部分为 CloudWatch 的统计函数。具体指标包括：
请求率：每秒请求数量，即我们从 sum(RequestCount) 得到的指标再除以配置 CloudWatch 采样时间（ 1 或 5 分钟）。其中包含请求错误。
错误率：大家还应添加以下两项指标： sum(HTTPCode_Backend_5XX) 与 sum(HTTPCode_ELB_5XX)，二者分别负责捕捉服务器产生的错误与负载均衡器产生的错误（请务必计量因队列已满造成的后端不可用与拒绝情况）。你可能还需要添加 sum(HTTPCode_Backend_5XX)。
延迟：即平均延迟值。就这么简单。
饱和度—即在后端队列当中获取请求的 max(SurgeQueueLength)。需要注意的是，其仅关注后端饱和度，而非负载均衡器自身在 CPU 上的饱和度（在自动规模伸缩之前）——后者目前似乎尚无法监控。
你也可以监控并警报 sum(SpilloverCount)，若其〉0 则代表负载均衡器已经饱和，且由于 Surge Queue 已满而拒绝后续请求。与 5xx 错误一样，这代表已经出现非常严重的问题。
利用率：目前还没有比较好的 ELB 利用率数据获取办法，因为 ELB 会在内部容量不足以进行自动规模伸缩（但可以抢在规模扩展之前进行提取）。
写给需要计算 ELB 百分位值的朋友
如果大家需要计算上述信号的百分位与统计指标，请务必阅读 CloudWatch 说明文档中“典型负载均衡器指标统计数据”部分提到的警告与问题。
新成员 ALBALB 数据与 ELB 非常相似，但其中包含更多可用数据且在指标名称方面略有区别。
ALB、指标适用于 ALB 整体，且可由目标组（通过维度过滤器）提供，大家可以借此获取给定一组后端服务器的数据（而无需直接监控 Web/ 应用服务器）。ALB 不提供每服务器数据（不过你可以根据可用区进行过滤，这样若你在每个可用区内仅拥有一套目标后端服务器，即可实现每服务器监控）。
将我们的信号映射至 ELB 后，即可通过 CloudWatch 进行总体查看。需要注意的是，指标当中的 sum() 部分属于 CloudWatch 的统计函数。
请求率：每秒请求数量，即我们从 sum(RequestCount) 得到的指标再除以配置 CloudWatch 采样时间（ 1 或 5 分钟）。其中包含请求错误。
错误率：大家还应添加以下两项指标： sum(HTTPCode_Backend_5XX) 与 sum(HTTPCode_ELB_5XX)，二者分别负责捕捉服务器产生的错误与负载均衡器产生的错误（请务必计量因队列已满造成的后端不可用与拒绝情况）。你可能还需要添加 sum(TargetConnectionErrorCount)。
延迟：即平均延迟值。就这么简单。
饱和度— 我们似乎无法从 ALB 处获取任何队列数据，因此这里我们只使用 sum（RejectedConnectionCount），其负责对 ALB 达到最大连接数量后的拒绝连接进行计数。
利用率—目前还没有比较好的 ELB 利用率数据获取办法，因为 ELB 会在内部容量不足以进行自动规模伸缩（但可以抢在规模扩展之前进行提取）。需要注意的是，你可以监控 sum(ActiveConnectionCount) 与最大连接数量——需要以手动方式或者通过 AWS Config 方可获取。
写给需要计算 ALB 百分位的朋友
如果大家需要计算上述信号的百分位与统计指标，请务必阅读 CloudWatch 说明文档中“典型负载均衡器指标统计数据”部分提到的警告与问题。
作者简介Steve Mushero：云络科技创始人，上海云敞网络科技有限公司全球技术顾问。Steve Mushero 具有 25 年以上的 IT 运维经验，曾任职土豆网第一任 CTO，OaaS 开创者以及多项专利持有人。
 写留言
精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。