阿里云 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 层) 已在国内所有区域开放, 欢迎使用. 数据已备好, 等你来分析.
更多资料
文档
负载均衡 7 层访问日志功能
SLB 访问日志
云栖文章
新功能: 阿里云负载均衡支持访问日志功能
来源: https://yq.aliyun.com/articles/590761