赞
踩
生产环境日志查看到大量的404请求写入。
通过日志分析得到结论是 查看日志内存 "agent": "SLBHealthCheck",疑似是alb的健康检查
- "0.012","request_GlobalId": "","response_GlobalId": """response_body": "{\"timestamp\":\"2024-08-09T07:05:39.136+00:00\",\"path\":\"/\",\"status\":404,\"error\":\"Not Found\",\"message\":null,\"requestId\":\"bdfxxxxxxxxxx942\"}","request_body": "" }
- {"timestamp":"2024-08-09T15:05:39+08:00","remote_addr": "100.110.110.110", "referer": "", "request": "GET / HTTP/1.1", "status": 404, "bytes": 136, "agent": "SLBHealthCheck", "x_forwarded": "", "up_addr": "10.110.110.110:110","up_host": "","up_resp_time": "0.011","request_time":
进一步打开阿里云控制台确认信息。
查看alb健康检查是否配置,确认是alb的健康检查接口一直在探测。这里可以看到是一个get请求,和上面的日志对应上了。
这里一开始想把所有404请求都不写入到日志中,404全部屏蔽掉,但是考虑到服务是互联网的,是否有攻击者,如果有人恶意遍历http的路径,这边无法收到日志,就会造成一定的损失。
所以既要保留正常的404请求,又要把alb的404请求都屏蔽掉。这里还是分析日志,这里想根据IP地址进行屏蔽,觉得alb这个是vip,如果alb变动的这个配置会无用,还是根据"agent": "SLBHealthCheck" 来屏蔽alb的404请求,这样其它项目上也可以使用这个配置文件。把判断逻辑写到了server里,检查ng的配置文件并且重启。
- server {
- listen 80 ;
- listen 7309 ;
- server_name xxxxxx.cn;
- charset utf-8 ;
- #日志配置
- lua_need_request_body on;
- set $resp_body "";
- body_filter_by_lua '
- local resp_body = string.sub(ngx.arg[1], 1, 1000)
- ngx.ctx.buffered = (ngx.ctx.buffered or "") .. resp_body
- if ngx.arg[2] then
- ngx.var.resp_body = ngx.ctx.buffered
- end
- ';
-
- location / {
- proxy_pass http://prod;
-
- # 屏蔽404的请求日志 写入到日志文件中,这个404是alb健康检查接口
- if ($http_user_agent ~* "SLBHealthCheck") {
- access_log off;
- return 200;
- }
-
-
- }
- access_log /data/logs/log;
- error_log /data/logs/log error;
- }
- }

持续观察正常日志都可以进来,alb的404日志已不会再写入到日志文件中了,其它请求的404依然会写进日志来。
[root@iZbp129xxxxxxtfhe3Z logs]# tail -fn 300 logs2024-08-09 | grep 404,
验证完成,配置正常。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。