前段时间使用Strom实时分析实现了CC防火墙,既然Nginx的原始数据已经有了,那我们其实还可以基于Strom做更多有价值的事情,近期我们使用Strom上线了服务器拓扑图的功能,并可以实现接近实时的监控效果。
先看一下业务背景,我们的社区业务分为10个模块,模块与模块间通过RESTful形式进行交互与调用,经过多年的开发的迭代,目前整个社区的业务错综复杂,这其实也给运维造成了不小的难度,可能因某个接口出现问题导致多个业务受损,而因运维对接口间的调用并不熟悉导致接到业务问题后不能快速准确定定位问题,基于这些背景拓扑图项目就来了!
数据的采集架构与前段时间的CC防火墙采用同一套,基于Kafka支持多个消费者的特性,我们只需要重新取出一份数据来就可以了。
来看一下我们取到的数据格式:
log_format main ‘$remote_addr|$http_x_forwarded_for|-|[$time_local]|$server_name’
‘|$request|$request_length|$request_time’
‘|”$status”|$body_bytes_sent|$bytes_sent|$connection|$connection_requests’
‘|”$http_user_agent”|”$http_referer”‘
‘|$upstream_addr|$upstream_status|$upstream_response_time|”$NginxIP”‘;
本项目我们用到的为:
$remote_addr 访问的来源地址
$upstream_addr Nginx后端服务器地址(如果一台机器报错则会写多个IP,以逗号隔开)
$upstream_status 后端服务器响应状态码(与上面的$upstream_addr一一对应)
$NginxIP 当前Nginx的IP(因为我们不是一台Nginx所以需要自己多定义一个)
基于以上的数据我们来分析一下场景:
场景1:,用户从外网访问到Nginx直接转发到回应的后端地址:
$remote_addr:用户IP地址,$upstream_addr:后端服务器地址,$upstream_status:后端服务器响应码,$NginxIP:负载的NginxIP
场景2:,内部服务器见的互相调用
$remote_addr:源服务器IP地址,$upstream_addr:目标服务器地址,$upstream_status:目标服务器响应码,$NginxIP:负载的NginxIP
基于以上的这些信息我们就可以做出我们想要的内容了
1、服务器间的调用关系
2、目标服务器的状态码情况
3、源服务器到目标服务器的状态码情况
关于计算后数据库的设计比较简单,只用一张表就可以解决了,但是这个的数据量还是比较大的,我们采用按日期分区的方式,只保留一周数据,每天Drop掉一个最远的分区
为了不仅能看出关联关系而且能达到监控效果,我们的计算频率为1分钟,并且定义三个问题级别,正常,异常,严重异常,来看一下最终上线后的效果