使用网络观察程序指标和日志对网络进行故障排除
若要快速诊断问题,必须了解 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 经典门户中的存储帐户。
诊断日志
在 Network Watcher 中,诊断日志是集中管理启用和禁用 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 中启用监视,找出导致负载的进程。 消耗的增加可能是由于代码效率低下,或者可能是新工作负荷的正常消耗。 如果消耗正常,该过程是否在所需的性能级别运行?
- 常量。 您的虚拟机一直都是这样吗? 如果是这样,则应确定消耗大多数资源并考虑添加容量的进程。
- 稳步增长。 你是否看到消耗量不断增加? 如果是这样,此趋势可能表明代码效率低下或进程占用更多用户工作负荷。
如果观察到 CPU 使用率较高,则可以:
- 增大虚拟机的大小,以便使用更多核心。
- 进一步调查问题。 找到应用和进程,并相应地进行故障排除。
如果纵向扩展 VM 且 CPU 仍以高于 95% 的速度运行,应用性能是否更好,或者应用吞吐量是否高于可接受的级别? 如果没有,请对单个应用进行故障排除。
内存瓶颈
可以查看 VM 使用的内存量。 日志将帮助你了解趋势,以及它是否映射到你看到问题的时间。 在任何时候,都不应少于 100 MB 的可用内存。 注意以下趋势:
- 尖峰期和持续消耗。 高内存利用率可能不是性能不佳的原因。 某些应用(如关系数据库引擎)在设计上占用大量内存。 但是,如果有多个内存密集型应用,你可能会发现性能不佳,因为内存争用会导致磁盘修整和分页。 这些进程将对性能产生负面影响。
- 稳步增加消费。 这种趋势可能是应用正在预热。 数据库引擎启动时,这种情况很常见。 但是,它也可能是应用中内存泄漏的标志。
- 页面或交换文件使用情况。 检查您是否在大量使用 Windows 的页面文件或 Linux 的交换文件,这些文件位于 /dev/sdb 路径下。
若要解决高内存利用率问题,请考虑以下解决方案:
- 若要立即减少页面文件的使用,请增加 VM 的大小以增加内存,然后进行监视。
- 进一步调查问题。 找到导致瓶颈的应用或进程并对其进行故障排除。 如果知道应用,请查看是否可以限制内存分配。
磁盘瓶颈
网络性能也可能与 VM 的存储子系统相关。 可以在门户中调查 VM 的存储帐户。 若要识别存储问题,请查看存储帐户诊断和 VM 诊断中的性能指标。 在特定时间范围内出现问题时,查找关键趋势。
- 若要检查 Azure 存储超时,请使用 Metrics 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。 出于安全考虑,必须阻止与前端的一些通信,因为前端暴露于公共互联网。
通过阻止与后端的通信,可以限制恶意软件或安全攻击时暴露量。 但是,如果 NSG 阻止所有内容,则配置不正确。 启用所需的特定协议和端口。