我有一个带有AWS的应用型负载均衡器,它为3个节点应用程序提供服务。在周末,收到的请求很少。我今天通过cloudwatch注意到,在指标中报告的503比实际请求更多。偶尔我会在这里或那里得到1到2个,但有时我会得到很大的峰值。最新的一个在10-15分钟的窗口内有数百个503个响应,但只有2个请求...我认为这可能是健康检查失败,但我找不到任何日志表明健康检查失败。在这种情况下,我们不会部署任何东西。我们的应用程序日志中没有错误。应用程序nginx日志组中没有错误。我不是一个IT/Devops的人,我不知道还能去哪里看。这些可能是从哪里来的?
编辑:这是我所看到的
正如您所看到的,请求和503中的最高点并不是同时发生的,因此请求和503之间似乎没有关联。
发布于 2021-02-26 01:16:12
正如@Evert在评论中所说,这些503来自与有效目标群体的任何规则都不匹配的请求。我的默认目标群实际上不会转发任何内容,因此它们不会被计入请求。
我找到了负载均衡器的访问日志,发现潜在的恶意用户正在扫描它的漏洞。他们使用服务器的IP地址,我对此没有规定,并寻找在各种平台上发现的可能没有得到适当保护的常见文件。这将导致503的峰值。
我不是从负载均衡器中为5XX设置一个通用警报,而是将我的警报设置为侦听应用程序的实际请求中的问题。其中有ELB的指标似乎是负载均衡器指标,名称中没有ELB的类似名称的指标衡量来自应用程序的内容。
https://stackoverflow.com/questions/66327154
复制相似问题