【问题标题】:How am I getting more 503s than requests with my AWS Application Load Balancer?我的 AWS Application Load Balancer 如何获得比请求更多的 503?
【发布时间】:2021-05-25 08:54:53
【问题描述】:

我有一个使用 AWS 的应用程序类型负载均衡器,它为 3 个节点应用程序提供服务。在周末,很少有请求进来。我今天通过 cloudwatch 注意到,指标中报告的 503 比实际请求多。偶尔我会在这里和那里得到 1 或 2 个,但有时我会得到很大的峰值。最新的一个在 10-15 分钟的窗口内有数百个 503 响应,但只有 2 个请求......我认为这可能是健康检查失败,但我找不到任何表明健康检查失败的日志。这些时候我们没有部署任何东西。我们的应用日志中没有错误。应用 nginx 日志组中没有错误。我不是 IT/Devops 人,我不知道还能去哪里找。这些可能来自哪里?

编辑:这是我所看到的

如您所见,请求和 503 的高点并非同时发生,因此请求和 503 之间似乎没有相关性。

【问题讨论】:

  • 您的负载均衡器中是否有多个目标?也许请求不会发送到您的应用程序,因为它与路径/主机名不匹配。
  • 是的,我们在同一个平衡器后面提供几个不同的应用程序。如何查看不匹配请求的日志?
  • 我相当肯定 API 网关有日志记录选项,我认为它们默认是关闭的。 Google 是您的朋友
  • 谢谢,这为我指明了正确的方向,事实证明我很久以前就打开了日志记录,但忘记了它或在哪里可以找到它。日志按 IP 地址显示大量调用。诸如“GET 44.444.444.444:80/a.gz”之类的东西,他们用简单的字母和数字搜索文件名。我猜是有人扫描我们的服务器以查找具有简单/通用名称的未受保护文件。
  • 有可能!人们一直在扫描漏洞。该 IP 地址长期错误(每个段不能高于 254),所以我认为它是匿名的。有时您可以通过谷歌搜索他们提出的具体请求,以找出他们试图利用的漏洞。

标签: amazon-web-services aws-application-load-balancer


【解决方案1】:

正如@Evert 在 cmets 中所说,这些 503 来自与有效目标组的任何规则都不匹配的请求。我的默认目标组实际上并没有转发任何内容,因此它们不被计为请求。

我能够找到负载均衡器的访问日志,并发现潜在恶意用户正在扫描它以查找漏洞。他们使用了我没有规定的服务器 IP 地址,并查找了在各种平台上发现的可能未正确保护的常见文件。这会导致 503 秒数激增。

我没有设置来自负载均衡器的针对 5XX 的通用警报,而是将警报设置为侦听来自应用程序的实际请求的问题。包含 ELB 的指标似乎是负载均衡器指标,而名称中没有 ELB 的指标类似地衡量来自应用程序的内容。

【讨论】:

    猜你喜欢
    • 2018-05-27
    • 1970-01-01
    • 2017-01-14
    • 2017-07-30
    • 2021-01-21
    • 2017-11-23
    • 1970-01-01
    • 2021-06-30
    • 2020-08-03
    相关资源
    最近更新 更多