使用网络观察程序指标和日志排查网络问题
如果要快速诊断问题，必须了解 Azure 网络观察程序日志中提供的信息。
在你的工程公司，你希望员工可以用最短的时间诊断和解决任何网络配置问题。 你需要确保他们知道各个日志中提供的信息。
在此模块中，重点介绍流日志、诊断日志和流量分析。 了解这些工具如何帮助排查 Azure 网络故障。
使用量和配额
每个 Microsoft Azure 资源的使用量不可超过其配额。 每个订阅都有单独的配额，使用量按订阅进行跟踪。 每个区域的每个订阅只需要一个网络观察程序实例。 此实例提供使用量和配额的视图，以便查看是否存在达到某个配额的风险。
若要查看使用量和配额信息，请导航到“所有服务”>“网络”>“网络观察程序”，然后选择“使用量和配额”。 随即可看到基于使用量和资源位置的精细数据。 捕获以下指标的数据：
- 网络接口
- 网络安全组 (NSG)
- 虚拟网络
- 公共 IP 地址
以下示例显示门户中的使用量和配额：
日志
网络诊断日志提供精细数据。 使用此数据以更好地了解连接性和性能问题。 网络观察程序中有三个日志显示工具：
- NSG 流日志
- 诊断日志
- 流量分析
我们来了解一下这些工具。
NSG 流日志
在 NSG 流日志中，可查看有关网络安全组中入口和出口 IP 流量的信息。 流日志根据流所应用的网络适配器按规则显示出站和入站流。 NSG 流日志根据捕获的 5 元组信息显示是允许还是拒绝流量。 此信息包括：
- 源 IP
- 源端口
- 目标 IP
- 目标端口
- 协议
此关系图显示 NSG 遵循的工作流。
流日志将数据存储在 JSON 文件中。 通过手动搜索日志文件很难深入了解此数据，尤其是在 Azure 中部署大型基础结构的情况下。 若要解决此问题，请使用 Power BI。
在 Power BI 中，可通过多种方式可视化 NSG 流日志。 例如：
- 最活跃的通信方（IP 地址）
- 按方向列出的流（入站和出站）
- 按决策列出的流（允许和拒绝）
- 按目标端口列出的流
还可使用开放源代码工具来分析日志，例如 Elastic Stack、Grafana 和 Graylog。
注意
NSG 流日志不支持 Azure 经典门户上的存储帐户。
诊断日志
在网络观察程序中，诊断日志是启用和禁用 Azure 网络资源日志的中心位置。 这些资源可能包括 NSG、公共 IP、负载均衡器和应用网关。 启用感兴趣的日志后，便可使用这些工具来查询和查看日志条目。
可将诊断日志导入 Power BI 和其他工具中进行分析。
流量分析
若要调查云网络中的用户和应用活动，请使用流量分析。
通过该工具可深入了解订阅中的网络活动。 可诊断安全威胁，例如开放端口、与已知不良网络通信的 VM 以及流量流模式。 流量分析跨 Azure 区域和订阅分析 NSG 流日志。 可使用这些数据来优化网络性能。
此工具需要 Log Analytics。 Log Analytics 工作区必须存在于受支持的区域中。
用例场景
现在，让我们看看一些 Azure 网络观察程序指标和日志可能有所帮助的用例场景。
客户报告性能降低
若要解决性能降低的问题，你需要确定问题的根本原因：
- 是否存在过多的流量限制了服务器？
- VM 大小是否适合该作业？
- 可伸缩性阈值是否设置适当？
- 是否存在任何恶意攻击？
- VM 存储配置是否正确？
首先，检查 VM 大小是否适合该作业。 然后，在 VM 上启用 Azure 诊断，获取特定指标（如 CPU 使用率和内存使用率）的更精细的数据。 若要通过门户启用 VM 诊断，请转到“VM”，选择“诊断设置”，然后启用诊断。
假设你有一个运行良好的 VM。 但是，VM 的性能最近有所下降。 你需要查看捕获的数据才能确定是否存在任何资源瓶颈。
从报告问题之前、期间和之后捕获数据的时间范围开始，以获得准确的性能视图。 这些图对于交叉引用同一时期的不同资源行为也很有用。 你将检查：
- CPU 瓶颈
- 内存瓶颈
- 磁盘瓶颈
CPU 瓶颈
可在查看性能问题时检查趋势，了解它们是否会影响服务器。 若要找出门户中的趋势，请使用监视图。 监视图上可能会显示不同类型的模式：
- 独立多峰。 峰值可能与计划任务或预期事件相关。 如果你知道此任务是什么，那么它是否按所需的性能级别运行？ 如果性能正常，则可能无需增加容量。
- 飙升然后恒定。 新的工作负荷可能导致这种趋势。 在 VM 中启用监视，查明导致该负荷的进程。 增加的消耗可能是由于代码效率低下，也可能是新工作负载的正常消耗。 如果消耗正常，此进程是否在所需的性能级别运行？
- 恒定。 VM 一直是处于这种趋势吗？ 如果是，应确定使用最多资源的进程，并考虑增加容量。
- 稳定增长。 消耗量是否持续增长？ 如果是，这种趋势可能表明代码效率低下或者某进程承担了更多的用户工作负荷。
如果观察到 CPU 使用率高，则可以执行以下任一操作：
- 增加 VM 的大小以扩展更多核心。
- 进一步调查该问题。 找到该应用和进程，并进行相应的故障排除。
如果纵向扩展了 VM，而 CPU 仍被占用 95% 以上，这表示应用性能较好，还是应用吞吐量高于可接受的水平？ 如果不能，则对单个应用进行故障排除。
内存瓶颈
可以查看 VM 使用的内存量。 可通过日志了解趋势，以及确定它是否与你发现问题的时间相符。 任何时候可用内存都不应少于 100 MB。 注意以下趋势：
- 消耗量飙升，然后恒定。 高内存使用率可能不是导致性能不佳的原因。 从设计上来说，某些应用（例如关系数据库引擎）本来就会耗费大量内存。 但是，如果有多个内存密集型应用，你可能会发现性能不佳，因为内存争用会导致磁盘修整和分页。 这些进程会对性能造成负面影响。
- 消耗量稳定增长。 这种趋势可能是应用正在预热。 当数据库引擎启动时，通常会出现这种情况。 然而，这也可能是应用内存泄漏的迹象。
- 页面文件或交换文件使用量。 检查是否在大量使用 Windows 页面文件，或 Linux 交换文件（位于 /dev/sdb）。
若要解决高内存利用率问题，请考虑以下解决方案：
- 若要立即减少页面文件的使用，请增加 VM 的大小以增加内存，然后进行监视。
- 进一步调查该问题。 找到导致瓶颈的应用或进程并对其进行故障排除。 如果知道该应用，请查看是否可限制内存分配。
磁盘瓶颈
网络性能也可能与 VM 的存储子系统相关。 可以在门户中调查 VM 的存储帐户。 若要确定存储的问题，请查看存储帐户诊断和 VM 诊断中的性能指标。 在特定时间范围内发生问题时，查找关键趋势。
- 若要检查 Azure 存储超时，请使用指标 ClientTimeOutError、ServerTimeOutError、AverageE2ELatency、AverageServerLatency 和 TotalRequests。 如果 TimeOutError 指标中显示了值，则 I/O 操作耗时太长且已超时。如果发现 AverageServerLatency 与 TimeOutErrors 同时增加，则可能是平台问题。 向 Microsoft 技术支持提出案例。
- 若要检查 Azure 存储限制，请使用存储帐户指标 ThrottlingError。 如果显示了限制，则即将达到帐户的 IOPS 限制。 可以在调查指标 TotalRequests 时检查此问题。
修正高磁盘利用率和延迟问题：
- 优化 VM I/O，扩展以超过虚拟硬盘 (VHD) 的限制。
- 提高吞吐量并减少延迟。 如果发现你有一个延迟敏感的应用并需要高吞吐量，请将 VHD 迁移到 Azure 高级存储。
阻止流量的虚拟机防火墙规则
若要解决 NSG 流问题，请使用网络观察程序 IP 流验证工具和 NSG 流日志记录确定 NSG 或用户定义的路由 (UDR) 是否在干扰流量流。
运行 IP 流验证并指定本地 VM 和远程 VM。 选择“检查”后，Azure 对现有规则运行逻辑测试。 如果结果为允许访问，则使用 NSG 流日志。
在门户中，转到 NSG。 在“流日志设置”下，选择“启用”。 现在尝试再次连接 VM。 使用网络观察程序流量分析来可视化数据。 如果结果为允许访问，则没有阻止流量的 NSG 规则。
如果此时仍未诊断出问题，则远程 VM 可能有问题。 在远程 VM 上禁用防火墙，并重新测试连接性。 如果可在禁用防火墙的情况下连接到远程 VM，请验证远程防火墙设置。 然后重新启用防火墙。
前端子网和后端子网无法通信
默认情况下，所有子网都可以在 Azure 中进行通信。 如果两个子网上的两个 VM 无法通信，则一定存在阻止通信的配置。 在检查流日志之前，先从前端 VM 向后端 VM 运行 IP 流验证工具。 此工具对网络上的规则运行逻辑测试。
如果结果是后端子网上的 NSG 阻止了所有通信，请重新配置该 NSG。 出于安全考虑，必须阻止某些与前端的通信，因为前端是对公共 Internet 公开的。
通过阻止与后端的通信，可限制恶意软件或安全攻击发生时的暴露程度。 但是，如果 NSG 阻止所有操作，则它的配置是错误的。 启用所需的特定协议和端口。