为了诊断AWS全球加速器的延迟问题，您应该监视几个关键指标，并使用AWS监视工具获得详细的见解：
监视的关键指标
1。往返时间(RTT) /延迟
RTT衡量数据包从客户端到端点和返回所需的时间。它是评估网络潜伏期并受物理距离和网络条件影响的主要指标。监视RTT有助于确定路径中引入延迟的位置[1]。
2。吞吐量
这可以衡量一段时间内交付的数据或数据包数量。低吞吐量可能表明网络拥塞或终点性能问题影响潜伏期[1]。
3。网络抖动
抖动是随着时间的推移延迟的可变性。高抖动会导致不一致的应用程序性能，并且通常是网络不稳定性或拥堵的标志[1]。
4。数据包丢失
当数据包未能到达目的地时，就会发生数据包损失。即使是少量数据包损失也可以显着增加由于转载期和TCP性能退化而导致的潜伏期[1]。
5。端点健康和可用性
全球加速器不断使用TCP，HTTP和HTTPS健康检查来监视终点的健康。终点失败或降解的健康状况可能会导致流量重新路由，从而影响延迟[7]。
AWS监视工具和日志
- 亚马逊CloudWatch指标和警报
一旦流量通过加速器流动，全局加速器会自动向CloudWatch报告指标。关键的CloudWatch指标包括流量量，健康端点计数和与延迟相关的指标。当延迟超过阈值时或端点变得不健康时，您可以设置警报以通知您[2] [3] [6] [9]。
- 全局加速器流日志
流日志提供了流过加速器到端点并回到客户端的流量的详细记录。它们通过显示流量模式和潜在瓶颈来帮助解决可及性问题和性能问题。流日志需要设置并使用Amazon S3进行存储[2] [6] [9]。
- AWS CloudTrail日志
CloudTrail记录对全局加速器的API调用，可用于审核和故障排除可能影响延迟的配置更改[2] [6] [9]。
诊断延迟的最佳实践
- 测量从实际客户端位置的延迟以捕获现实世界的性能[1]。
- 收集大量样品(例如，每天至少每小时至少1,000个)来捕获由于交通高峰和互联网拥塞而引起的可变性[1]。
- 确保端点(EC2实例，ALB，NLB或EIP)能够处理连接量以避免增加潜伏期的瓶颈[1]。
- 使用不同工具的合成测试来验证延迟和吞吐量指标[1]。
- 将CloudWatch指标与流日志相关联，以确定延迟是否是由于网络问题，端点健康或配置问题引起的[6] [9]。
通过监视这些指标并利用AWS监视工具，您可以有效地诊断和解决AWS全球加速器中的延迟问题。
引用：
[1] https://aws.amazon.com/blogs/networking-and-content-delivery/measuring-aws-global-accelerator-performance-anderformance-and-analyzing-results/
[2] https://docs.aws.amazon.com/global-accelerator/latest/dg/monitoring-global-accelerator.html
[3] https://docs.aws.amazon.com/global-accelerator/latest/dg/cloudwatch-monitoring.html
[4] https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-speed-comparison-tool.html
[5] https://cloudonaut.io/review-aws-global-accelerator-latency-multi-rigion-disaster-recovery/
[6] https://docs.aws.amazon.com/global-accelerator/latest/dg/logging-and-monitoring.html
[7] https://digitalcloud.training/aws-global-accelerator/
[8] https://cloud.google.com/spanner/docs/latency-metrics
[9] https://docs.aws.amazon.com/en_us/global-accelerator/latest/dg/logging-and-monitoring.html