通过查看配置和指标来诊断问题
监视 Azure 负载均衡器的性能可能会对任何可能的故障发出早期警告。 Azure Monitor 提供了许多重要的指标，可用于检查负载均衡器性能的趋势。 如果一个或多个虚拟机 (VM) 的运行状况探测请求失败，也可以触发警报。
在示例方案中，需要监视负载均衡系统的性能以确保性能满足要求。 如果性能下降，并且到 VM 的连接开始失败，则需要对系统进行故障排除，以确定原因并解决问题。 完成本单元的学习后，你将能够：
- 描述可用于测量负载均衡系统的吞吐量和性能的指标。
- 使用 Azure 门户中的资源运行状况页监视系统的运行状况。
- 说明如何解决负载均衡系统中的常见问题。
使用 Azure Monitor 对负载均衡器进行故障排除
通过使用 Azure Monitor，可捕获和检查负载均衡器的诊断日志和性能数据。
监视连接
可使用 Azure 门户中的“指标”窗格来可视化负载均衡器的指标。 从连接故障排除的角度来看，最重要的指标是“数据路径可用性”和“运行状况探测状态”。
负载均衡器不断测试路径的可用性：从前端 IP 地址通过负载均衡规则和后端池，再到 VM 上运行的应用程序。 此信息记录为“数据路径可用性”指标。 应用“平均”指标可显示给定时间间隔的平均可用性。 此聚合是介于 0（无可用性）和 100（至少有一个可从前端 IP 地址到达后端池中的 VM 的成功路径）之间的值。
“运行状况探测状态”指标与此类似，但仅适用于 VM 的运行状况探测，而不是通过负载均衡器的完整路径。 同样，此指标的“平均”聚合会提供一个介于 0（所有 VM 都不正常且无法响应）和 100（所有 VM 都响应运行状况探测）之间的值。
以下屏幕截图显示了后端池中有两个 VM 的负载均衡器的平均数据路径可用性和平均运行状况探测状态图表。 其中一个虚拟机未响应运行状况探测。 平均运行状况探测状态徘徊在 50% 左右。
检查这些指标的另一种方法是使用“计数”聚合。 这种方法可以提供关于配置的潜在问题的其他见解。 下面的示例显示了运行状况探测状态和数据路径可用性指标的计数图。 此图显示了一段时间内已成功完成的探测数。
此图中有趣的地方在于，成功的数据路径可用性探测数保持在一致的范围内。 但是，成功的运行状况探测状态检查数瞬间达到峰值，然后又下降到出现峰值前的值的一半左右。
在用于生成此图的设置中，后端池仅包含两个 VM。 其中一个虚拟机已停止，以模拟故障。 数据路径可用性指标显示，客户端应用程序仍然可以连接到另一台仍在工作的 VM 上的应用程序。 但是运行状况探测状态表明，后端池的总体运行状况仅为以前的一半。
查看服务运行状况
负载均衡器的“资源运行状况”页报告系统的常规状态。 可以通过 Azure Monitor 在门户中访问此页面。 选择“服务运行状况”，选择“资源运行状况”，然后选择“负载均衡器”作为资源类型。
选择你的负载均衡器。 你会看到一份报告，其中详细说明了服务的运行状况历史。 可以展开报告中的任何一项来查看详细信息。 下图显示后端池中的一个 VM 脱机时生成的摘要。
监视每个 VM 的工作负载
面向负载均衡器的其他指标可用于跟踪每个前端通过负载均衡器的字节数和网络数据包数。 前端定义为负载均衡器的 IP 地址、用于接受传入请求的协议和负载均衡规则用于连接到 VM 的端口号的组合。 这些指标可以按活动的 VM 度量系统吞吐量。
下图显示了在运行 500 个并发用户的测试工作负载两分钟时，流经负载均衡器的平均数据包计数。 该工作负载运行了两次。 第一次，后端池包含两个 VM 实例。 第二次运行时，其中一个 VM 已关闭（模拟故障）。
在此图中，当某个 VM 关闭时，每个前端的平均数据包计数加倍。 此工作量可能会重载剩余的 VM，可能导致响应时间延长，还可能导致超时。
负载均衡器常见问题的调查与修复
本节介绍负载均衡器可能遇到的一些常见故障方案。 每个方案汇总了故障的表现，以及如何解决该问题。
负载均衡器后的 VM 对探测端口上的流量没有响应
此问题可能由以下问题引起：
后端池中的 VM 未侦听正确的探测端口。
验证负载均衡器中的运行状况探测是否设置正确。 确保每个 VM 上运行的应用程序代码都对探测请求做出了适当的响应。 它们应返回 HTTP 200 (OK) 响应消息。
承载 VM 的虚拟网络子网的 NSG 阻止探测端口。
检查包含 VM 的虚拟网络子网的 NSG 配置。 确保 NSG 允许来自负载均衡器的流量通过运行状况探测端口。
你正在尝试从同一 VM 和虚拟网卡访问负载均衡器。 此问题与探测无关，但它是不受支持的数据路径方案。
你正在尝试从后端池中的 VM 访问负载均衡器前端。
这两项都是应用程序设计问题。 避免从后端池中的 VM 向相同的负载均衡器实例发送请求。
后端池中的 VM 运行不正常
在这种情况下，大多数 VM 的响应正常，但其中一个或两个没有正常响应。 由于某些 VM 接受流量，因此可能会正确配置运行状况探测。 子网的 NSG 不会阻止运行状况探测使用的端口。 此问题可能与运行不正常的 VM 有关。 此问题可能是由于 VM 不可访问或已关闭，或者这些虚拟机上存在应用程序问题。
使用以下步骤来确定运行不正常的 VM 的问题原因：
- 登录到运行不正常的 VM，验证其是否已启动。 检查 VM 是否可以响应来自后端池中另一个 VM 的基本检查，例如 ping、rdp，或 ssh 请求。
- 如果 VM 已启动且可访问，请验证应用程序是否正在运行。
- 运行
netstat -an命令，并验证运行状况探测和应用程序使用的端口是否列为“正在侦听”。
负载均衡器中的配置错误
负载均衡器要求正确配置将传入流量从前端定向到后端池的路由规则。 如果路由规则缺失或未正确配置，则会丢弃到达前端的流量。 丢弃流量后，应用程序的无法访问状态将被报告给客户端。
验证从前端通过负载均衡器到达后端池的路由。 可以使用诸如 Ping、TCPing 和 netsh 等工具，它们在 Windows 和 Linux 上可用。 还可以在 Windows 上使用 psping。 以下部分介绍如何使用这些工具。
使用 ping
ping 命令使用 ICMP 协议测试通过终结点的 ping 连接性。 若要验证从客户端经过负载均衡器到达 VM 的路由是否可用，请运行以下命令。 使用负载均衡器实例的 IP 地址替换“IP 地址”<>。
ping -n 10 <ip address>
| Switch | 描述 |
|---|---|
| -n | 此开关指定要发送的 ping 请求数。 |
典型的输出如下所示：
ping -n 10 nn.nn.nn.nn
Pinging nn.nn.nn.nn with 32 bytes of data:
Reply from nn.nn.nn.nn: bytes=32 time=34ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=29ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=31ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=29ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=31ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Reply from nn.nn.nn.nn: bytes=32 time=30ms TTL=114
Ping statistics for nn.nn.nn.nn:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 34ms, Average = 30ms
使用 PsPing
PsPing 命令通过终结点测试 ping 连接。 此命令还度量服务的延迟和带宽可用性。 若要验证从客户端经过负载均衡器到达 VM 的路由是否可用，请运行以下命令。 将 <ip address> 和 <port> 替换为负载均衡器实例的 IP 地址和前端端口。
psping -n 100 -i 0 -q -h <ip address>:<port>
| 标记 | 描述 |
|---|---|
| -n | 指定要执行的 ping 操作的次数。 |
| -i | 指示迭代之间的间隔（以秒为单位）。 |
| -q | 在 ping 过程中取消输出。 最后只显示摘要。 |
| -h | 打印显示请求延迟的直方图。 |
典型的输出如下所示：
TCP connect to nn.nn.nn.nn:nn:
101 iterations (warmup 1) ping test: 100%
TCP connect statistics for nn.nn.nn.nn:nn:
Sent = 100, Received = 100, Lost = 0 (0% loss),
Minimum = 7.48ms, Maximum = 9.08ms, Average = 8.30ms
Latency Count
7.48 3
7.56 2
7.65 2
7.73 2
7.82 7
7.90 4
7.98 4
8.07 6
8.15 9
8.24 9
8.32 11
8.40 7
8.49 11
8.57 12
8.66 3
8.74 2
8.82 2
8.91 1
8.99 2
9.08 1
使用 tcping
tcping 实用工具类似于 ping，不同之处在于它通过 TCP 连接而不是 ICMP 运行。 按如下所示使用 tcping：
tcping <ip address> <port>
典型的输出如下所示：
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.042ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.810ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.266ms
Probing nn.nn.nn.nn:nn/tcp - Port is open - time=9.181ms
Ping statistics for nn.nn.nn.nn:nn
4 probes sent.
4 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 9.042ms, Maximum = 9.810ms, Average = 9.325ms
使用 netsh
netsh 实用工具是常规用途的网络配置工具。 使用 netsh 中的 trace 命令来捕获网络流量。 然后，使用 Wireshark 等工具对其进行分析。 测试通过负载均衡器的连接时，使用 netsh trace 来检查 psping 发送和接收的网络数据包，如下所示：
从以管理员身份运行的命令提示符启动网络跟踪。 以下示例跟踪往返 IP 地址的 Internet 客户端流量（HTTP 请求）。 用负载均衡器实例的地址替换 <IP 地址>。 跟踪数据将写入名为 trace.etl 的文件。
netsh trace start ipv4.address=<ip address> capture=yes scenario=internetclient tracefile=trace.etl运行 psping 以测试通过负载均衡器的连接。
psping -n 100 -i 0 -q <ip address>:<port>停止跟踪。
netsh trace stop此命令需要几分钟才能完成，因为它在创建跟踪输出文件时关联和合并信息。
启动 Wireshark 并打开跟踪文件。
将以下筛选器添加到跟踪。 将 <nn> 替换为负载均衡器的前端端口号。
TCP.Port==80 or TCP.Port==<nn>将 HTTP 请求源和目标作为字段添加到跟踪输出。
检查跟踪消息：
- 如果没有传入到负载均衡器的数据包，则可能存在网络安全问题或用户定义的路由问题。
- 如果没有向客户端返回的传出数据包，则可能存在应用程序配置问题或用户定义的路由问题。
VM 防火墙或 NSG 阻止端口
如果正确配置了网络和负载均衡器，VM 已启动，并且应用程序正在运行，则 VM 的防火墙或 NSG 配置可能会阻止运行状况探测或应用程序使用的端口。 使用以下步骤来确定情况是否如此：
如果 VM 上存在防火墙，它可能会阻止运行状况探测和应用程序使用的端口上的请求。 验证主机上的防火墙配置，以确保它允许运行状况探测和应用程序使用的端口上的流量。
验证 VM 的 NIC 的任何 NSG 是否允许在必要的端口上进出流量。 检查 VM 的 NIC 上的 NSG 中是否有优先级高于默认规则的“全部拒绝”规则。
重要
可以将 NSG 与子网和子网中 VM 的单个 NIC 相关联。 你可能已为子网配置了 NSG 以允许流量通过端口。 但是，如果 VM 的 NSG 关闭了该端口，请求将无法通过该 VM。
负载均衡器的限制
负载均衡器在 ISO 网络堆栈的第 4 层运行，并且不会检查或以其他方式操作网络数据包的内容。 不能使用它来实现基于内容的路由。
所有客户端请求都由后端池中的 VM 终止。 负载均衡器对客户端不可见。 如果没有可用的 VM，客户端请求将失败。 客户端应用程序无法与负载均衡器或其任何组件通信，或以其他方式询问其状态。
如果需要实现基于消息内容的负载均衡，请考虑使用 Azure 应用程序网关。 或者，可以配置代理 Web 服务器来处理传入的客户端请求，并将其指向特定的 VM。