如何对弹性负载均衡中应用程序负载均衡器的高延迟问题进行故障排除？

4 分钟阅读

我想对弹性负载均衡 (ELB) 中应用程序负载均衡器的高延迟问题进行故障排除。

简述

以下是应用程序负载均衡器出现高延迟的原因：

网络问题，例如连接问题、数据包丢失或客户端与应用程序负载均衡器之间的 DNS 解析延迟
应用程序负载均衡器或基础设施配置错误，例如空闲超时设置不当、子网容量不足、路由缺失，或者限制性安全组或网络访问控制列表 (ACL) 规则设置不当
处理 POST 请求的 AWS WAF 开销
SSL/TLS 握手开销或证书问题
运行状况检查失败导致剩余正常目标的流量过载
后端问题，例如 CPU 或内存使用率高、Web 服务器配置不正确或应用程序依赖项缓慢

解决方法

要对应用程序负载均衡器上的高延迟问题进行故障排除，请执行以下操作。

确定延迟发生的阶段

要确定延迟发生的阶段，请在您的应用程序负载均衡器访问日志中查看以下字段的值：

request_processing_time
target_processing_time
response_processing_time

访问日志条目示例：

loadbalancer/50dc6c495c0c9188  
 192.168.131.39:2817 10.0.0.1:80 0.001 12.401  0.001 200 200 34 366  
 "GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -  
 arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/example-targets/73e2d6bc24d8a067  
 "Root=1-58337262-36d228ad5d99923122bbe354"  "-" "-"  
 0 2024-04-01T22:22:48.364000Z  "forward" "-" "-" "10.0.0.1:80"  "200" "-" "-"

在此示例中，request_processing_time 为 0.001，target_processing_time 为 12.401，response_processing_time 为 0.001。较高的 target_processing_time 表示后端目标导致了延迟。有关详细信息，请参阅 Access log entries（访问日志条目）。将客户端观测到的总延迟与三个计时字段的总和进行比较。较大的差异表示客户端和应用程序负载均衡器之间存在网络问题。

检查您 CloudWatch 指标的以下内容：

TargetResponseTime 的 Average 统计数据。较高的值表示存在后端或依赖项问题。有关详细信息，请参阅如何对应用程序负载均衡器的 TargetResponseTime 指标增加进行故障排除？
UnHealthyHostCount。如果目标未通过运行状况检查，则应用程序负载均衡器仅将流量路由到运行正常的目标，这会使它们过载并增加延迟。

检查各可用区的指标，以确定延迟是否特定于某个或某些可用区。如果特定可用区的延迟较高，请调查该可用区中的目标运行状况和跨可用区依赖项。

检查是否存在网络和 DNS 问题

客户端和应用程序负载均衡器之间的网络连接问题可能会导致高延迟。要检查网络和 DNS 问题，请完成以下步骤：

验证与应用程序负载均衡器的基本连接。有关详细信息，请参阅 Troubleshoot your Application Load Balancers（对应用程序负载均衡器进行故障排除）。

使用 My Traceroute (MTR) 检查客户端和应用程序负载均衡器之间的数据包丢失和延迟。运行以下命令：

mtr -rw  example-alb.us-east-1.elb.amazonaws.com -report-cycles 100

注意：将 example-alb.us-east-1.elb.amazonaws.com 替换为您的应用程序负载均衡器 DNS 名称。

输出示例：

HOST: ip-10-0-1-50                Loss%   Snt    Last   Avg  Best   Wrst StDev  
 1.|-- 10.0.1.1                    0.0%   100     0.5    0.6   0.4      1.2   0.1  
 2.|-- 52.93.1.100                 0.0%   100     1.2    1.3   1.0      3.5   0.3  
 3.|-- 54.239.110.5                2.0%   100     1.5    1.8   1.2      5.1   0.5  
 4.|-- example-alb.us-east-1.elb.amazonaws.com   0.0%   100    2.1    2.3   1.8   4.2    0.4

每个编号的行对应于流量在客户端和应用程序负载均衡器之间通过的网络设备。

查找 Loss% 值高或 Avg 与 Wrst 延迟值比率高的网络设备。中间网络设备丢包会显示网络拥塞。如果最终网络设备出现数据包丢失，则问题出在应用程序负载均衡器子网配置或网络路径上。

在客户端和与应用程序负载均衡器处于同一 Amazon Virtual Private Cloud (Amazon VPC) 中的 Amazon EC2 实例上运行 MTR。比较结果以确定问题是 AWS 外部问题还是内部问题。有关详细信息，请参阅 Diagnosing packet loss and latency with MTR（使用 MTR 诊断数据包丢失和延迟问题）。

运行以下 curl 命令：

curl -kso /dev/null -w  "\n===============\n  
 | DNS lookup: %{time_namelookup}\n  
 | Connect: %{time_connect}\n  
 | App connect: %{time_appconnect}\n  
 | Pre-transfer: %{time_pretransfer}\n  
 | Start transfer: %{time_starttransfer}\n  
 | Total: %{time_total}\n  
 | HTTP Code:  %{http_code}\n===============\n" https://example.com/

注意：请将 example.com 替换为您的 DNS 名称。
输出示例：

===============| DNS lookup: 0.002346| Connect: 0.003080| App connect: 0.008422| Pre-transfer: 0.008587| Start transfer: 0.050238| Total: 0.057486| HTTP Code: 200===============

要找出导致延迟的原因，请使用您的应用程序负载均衡器运行前面的命令，然后再次运行该命令并绕过应用程序负载均衡器。有关详细信息，请参阅 curl 网站上的 curl man page（curl 使用手册页）。如果 App connect（应用程序连接）时间（TLS 握手）明显长于 Connect（连接）时间（TCP 握手），则 TLS 协商会很慢。

检查应用程序负载均衡器和基础设施配置

空闲超时

如果访问日志中的 target_processing_time 完全等于空闲超时值，则增加应用程序负载均衡器的空闲超时时间或优化应用程序响应时间。要修改空闲超时值，请参阅 Edit attributes for your Application Load Balancer（编辑应用程序负载均衡器的属性）。默认空闲超时值为 60 秒。要查看当前的空闲超时值，请运行以下命令：
```
aws elbv2  describe-load-balancer-attributes --load-balancer-arn  example-alb-arn --query  "Attributes[?Key=='idle_timeout.timeout_seconds']"
```
注意：将 example-alb-arn 替换为您的应用程序负载均衡器 Amazon 资源名称 (ARN)。
确保后端 Web 服务器的保持连接超时值高于应用程序负载均衡器的空闲超时值，以避免出现 HTTP 502 错误。
检查访问日志中是否有 HTTP 460 错误，这表明客户端在空闲超时时间过去之前关闭了连接。

子网容量
每个应用程序负载均衡器子网都需要至少一个 /27 无类别域间路由 (CIDR) 数据块和至少 8 个空闲的 IP 地址。在流量高峰期间，应用程序负载均衡器会扩展并需要额外的 IP 地址。如果子网用尽，应用程序负载均衡器将无法扩展，这会导致延迟或 5xx 错误。对于预期的激增，请使用 LCU 预留来预调配容量。

AWS WAF
如果 AWS WAF 与您的应用程序负载均衡器相关联，则 WAF 规则评估会增加 request_processing_time 字段的值。对于具有大型请求正文的 POST 请求，这一增幅最大，因为 WAF 在请求正文转发给目标之前会对其进行检查。有关详细信息，请参阅 Load balancer shows elevated processing times（负载均衡器显示更长的处理时间）。

SSL/TLS 配置
验证应用程序负载均衡器是否使用现代安全策略来加快握手速度。对于自定义证书，请确保配置了完整的证书链。缺少中间证书会增加 TLS 握手的延迟。

网络基础设施
验证应用程序负载均衡器子网是否有通往面向外部的互联网网关的路由或适当的内部路由。

注意： 对于内部应用程序负载均衡器，子网不需要互联网网关路由。如果后端目标需要访问外部服务，请确保子网有通往 NAT 网关的路由。您还可以使用 VPC Reachability Analyzer 来诊断应用程序负载均衡器弹性网络接口 (ENI) 和目标之间的连接问题。

检查后端服务器和依赖项

要检查后端服务器和依赖项，请执行以下操作：

要确定高 CPU 利用率，请检查您后端实例的 CloudWatch CPUUtilization 指标。要解决高 CPU 利用率问题，请将您的实例升级到更大的实例类型。

要查看在后端运行的进程并检查是否存在内存问题，请运行以下 Linux 命令。

watch  -n 1 "echo -n 'Apache Processes:' && ps -C httpd --no-headers |  wc -l && free -m"

注意：将 httpd 替换为服务器的进程名称。
输出示例：

Every  1.0s: echo -n 'Apache Processes:' && ps -C httpd --no-headers | wc -l  && free -m  Apache  Processes:6 total used free shared buff/cache availableMem:  961 332 78 3 550 483Swap:  0 0 0

要检查当前有多少 Web 服务器进程正在运行，请运行以下 Linux 命令：
```
ps aux  | grep httpd | wc -l
```
注意：将 httpd 替换为服务器的进程名称。

输出示例：
```
7
```
检查 Web 服务器的最大并发连接数或 Worker 数限制。每个 Web 服务器都有一个配置设置，用于控制自身可以处理的最大同时请求数。如果达到此限制，来自应用程序负载均衡器的新请求就会排队，这会增加延迟。检查您 Web 服务器类型的相关设置。
检查可能导致延迟问题的后端实例上的依赖项。依赖项示例包括 Amazon Simple Storage Service (Amazon S3) 存储桶、网络地址转换 (NAT) 实例或代理服务器、远程 Web 服务以及数据库。

使用 Linux 工具识别性能瓶颈

要确定服务器上的性能瓶颈，请使用以下 Linux 命令：

运行 uptime 命令以检查由于资源争用而导致的系统负载平均值是否过高。
运行 mpstat -P ALL 1 命令以查看每个内核的 CPU 使用率明细并确定不均衡的使用率。
运行 pidstat 1 命令，以识别一段时间内占用大量资源的进程和模式。
运行 dmesg | tail 命令以识别最近可能影响性能的系统级事件。输出显示最近 10 条系统消息。
运行 iostat -xz 1 命令，以识别高读取或写入操作或缓慢的磁盘性能。
运行 free -m 命令，以查看可用的系统内存。如果可用内存不足，则系统可能依赖交换来增加磁盘 I/O 和延迟。
运行 sar -n DEV 1 命令以确定带宽饱和度。输出显示网络接口吞吐量。
运行 sar -n TCP,ETCP 1 来查看 TCP 指标。retrans/s 指标显示每秒 TCP 重新传输次数。当此指标较高时，您可能会遇到数据包丢失或拥塞的情况。
要确定哪些连接在网络上使用的带宽最多，请运行 iftop 命令。输出实时显示每个连接的活动带宽使用情况。
niftop 命令是 iftop 的一个变体，可以通过 Red Hat Enterprise Linux (RHEL) 和基于 Debian 的发行版上的第三方存储库获得。如果您的系统上没有预装 iftop，请使用 niftop。