阿里云SLB是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。
负载均衡对于大部分云上架构来说都是基础设施组件,地位非常重要,因此,对SLB持续的监控、探测、诊断和报告是一个强需求。用户一般可以通过云厂商内置的监控报表来了解SLB实例运行状况,本文则会介绍另一种途径:通过采集SLB访问日志,结合可视化报表、查询分析引擎,最终达到实时、交互分析SLB实例状况的目标。
SLB访问日志功能当前支持基于HTTP/HTTPS的七层负载均衡,访问日志内容丰富,提供近30个字段,例如:收到请求的时间、客户端的IP地址、处理Latency、请求URI、后端RealServer(阿里云ECS)地址、返回状态码等。完整字段及功能说明请参考负载均衡7层访问日志功能。
本文基于阿里云日志服务的可视化和日志实时查询(OLTP+OLAP)能力,向大家介绍SLB实例的一些典型报表统计、日志查询分析的方法。
总体概览
负载均衡支持RealServer的水平扩展和故障冗余恢复,为应用提供大规模、高可靠的并发web访问服务支撑。典型的概览指标包括:
- PV:client(请求源IP)发起的HTTP(S)请求次数
- UV:对于相同client IP只计算一次,合计的总体请求次数
- 请求成功率:状态码为2XX的请求次数占总体PV的比例
- 请求报文流量:客户端请求报文长度(request_length字段)的总和
- 返回客户端流量:SLB返回给客户端的HTTP body的字节数(body_bytes_sent字段)总和
- 请求的热点分布:计算client IP的地理位置,按照每个地理位置来统计每个区域的PV情况
上图中,可以看到用户请求主要来自珠三角和长三角区域。
在日志服务的Dashboard中,通过添加过滤条件可以在当前图表中筛选符合条件的数据指标(例如:client IP维度、SLB实例ID维度)来展示,这里需要查询一个指定SLB实例ID的PV、UV随时间的变化趋势。
请求调度分析
从客户端过来的流量会先被SLB处理,并分发到多台RealServer的一台上做实际的业务逻辑处理。SLB可以检测不健康的机器并重新分配流量到其它正常服务的RealServer上,等异常机器恢复正常后再将流量重新加上去,这个过程是自动完成的。
对SLB实例添加一个监听,监听可以设置轮询、加权轮询(WRR)、加权最小连接数(WLC)这三种调度方法:
- 轮询:按照访问次数依次将外部请求依序分发到后端ECS上。
- 加权轮询:您可以对每台后端服务器设置权重值,权重值越高的服务器,被轮询到的次数(概率)也越高。
- 加权最小连接数:除了根据每台后端服务器设定的权重值来进行轮询,同时还考虑后端服务器的实际负载(即连接数)。当权重值相同时,当前连接数越小的后端服务器被轮询到的次数(概率)也越高。
在示例中,172.19.39.34机器同时兼有跳板机职能,其性能是其它三台机器的4倍,这里为它设置权重100,其余设置权重为20。
基于实例的访问日志,通过如下一条查询语句可以完成和两个维度的流量聚合:
* | select COALESCE(client_ip, vip_addr, upstream_addr) as source, COALESCE(upstream_addr, vip_addr, client_ip) as dest, sum(request_length) as inflow group by grouping sets( (client_ip, vip_addr), (vip_addr, upstream_addr))
结合桑基图对SQL查询结果做vip维度的聚合可视化,最终得到请求报文流量拓扑图。多个client IP向SLB vip(172.19.0.24)发起请求,请求报文流量基本遵循20:20:20:100比例转发到后端的RealServer进行处理。下图清晰地表述了每台RealServer的负载情况。
流量与Latency分析
按照1分钟时间维度对流量与latency指标做聚合计算:
- request_length、body_bytes_sent统计
- request_time、upstream_response_time统计
- 高延迟RealServer统计
用户请求概览
对访问日志中HTTP(S)请求本身的分析,可以从请求的方法、协议、状态码等维度来入手。
在一个时间段内,请求方法维度上可以做PV分布统计(如上图)。除此之外,如果再加上时间属性,同时在时间、请求方法两个维度上可以统计出各方法的PV趋势如下图。
请求响应状态码分布可以帮助我们快速掌握服务的基本状况,如果大量的500状态码则意味着我们后端RealServer的应用程序在发生内部错误。
围绕着每一个状态码,可以查看其随时间变化趋势。
工程师指定时间段、状态码快速定位RealServer的需求,借助日志服务的查询分析功能可以很快得以实现:
请求源分析
对client的IP做计算可以得到每条请求的发起地理位置(国家、省份、城市)、电信运营商信息,如下是对用户请求IP的运营商做了一个PV分布图。
按照请求PV降序,对client IP做统计可以帮助我们发现大用户请求的具体来源。
用户代理(http_user_agent)也是常常需要关注的对象,可以据此区分出谁在访问我们的网站或服务。比如搜索引擎会使用爬虫机器人扫描或下载网站资源,一般情况下的低频爬虫访问可以让搜索引擎及时更新网站内容、有助于网站的推广和SEO,但如果高PV的请求都来自于爬虫,则可能对服务的性能和机器资源造成浪费,我们需要了解到这个状况并采取手段来控制影响。
访问日志中根据查询SLB ID或应用host、http_user_agent关键词,可以很快检索出相关记录。下图是一条搜狗爬虫程序的GET请求日志,请求很稀疏,对于应用无影响。
运营概览
SLB访问日志在运营同学手里同样发挥着重要作用,可以基于日志分析出来流量模式,进而辅助业务决策。
在地理维度上,通过PV的热点分布,可以清晰了解到我们服务的重点客户在哪里,PV低的区域可能需要再推广加强。
对于一个网站而言,通过分析访客的行为可以为网站内容建设提供有力的参考。哪些内容好,哪些内容不好?这个问题可以用头部、尾部PV的host/URI来回答。
对于热门资源(访问日志的request_uri字段),可以关注一下日志详情的http_referer字段,看看我们网站的请求都来自于哪里?好的导流入口需要持续加强,对于盗链行为则需要想办法克制。下图是在日志查询页面中找到一条来自百度图片的跳转请求。
SLB访问日志分析介绍至此告一段落,意在抛砖引玉,数据已备好,等你来分析。
目前SLB访问日志(7层)已在国内所有公有云区域开放,欢迎使用。
更多资料
- 文档
- 云栖文章