目录
作为一个在在网络监控工具开发摸爬滚打三年的小码农,每天接触最多的就是网络监控工具的开发维护,其中属交换机、防火墙指标监控项最多。每天这些监控项产生的数据高达几十亿条,当数据出现异常时,又需要即使产生告警,让网络组的同学能快速响应,依据告警内容处理网络异常。
网络监控工具所应具备的特性
有了这些需求,我们就需要一个高效、稳定、准确的网络指标监控系统。
首先,监控系统需要的是准确。这里的准确不仅指代监控数据准确,而且告警配置的阈值也要准确。若数据不准,那监控呈现的趋势图、告警阈值判断肯定都是有问题的,没办法反应网络设备当前运行情况。若告警配置的阈值不准,有可能网络设备已经出现了问题,但是没有触发阈值告警;或是网络设备运行正常,运维同学却被短信与邮件轰炸,从而降低了对告警的敏感程度,当出现真正告警时运维同学会出现响应不及时的情况。
其次,监控系统需要的是稳定。每时每刻,监控系统都需要稳定运行,实时监控网络设备的运行情况。若经常出现宕机情况,系统不但会丢失一部分运行数据,导致无法查看这段时间网络设备指标数据;而且还会导致告警无法有效产生,可能在网络设备出现严重故障时运维同学没有收到相应告警,从而对上层业务造成不可挽回的损失。除了上面的原因,还有一个对系统稳定性提出要求的是我们自己,因为想偷懒,作为运维开发,我们不想因为担心监控系统出问题而随时随地都背着电脑,所以在制作系统时,让系统尽量稳定运行。实际得出的效果是我们制作的指标监控系统可以在无人监管的情况下运行一年以上不出问题。
最后,监控系统需要的才是高效。在数据准确与系统稳定的基础上,监控系统最后的要求才是高效,因为即使监控数据延迟5-10分钟展示,也不是很让人抓狂。同样告警延迟5-10分钟产生,也不是一件无法接受的事情。毕竟网络作为底层支持,大型的上层应用肯定是做了一定的容灾处理,底层出现一部分问题,上层会依据方案做应急处理,除非底层全挂,那就只能等死了。所以在无可奈何的时候,监控数据延迟5-10分钟,运维同学慢5-10分钟处理问题,也不是不能接受。
但作为精益求精的我,这就是不能接受,既然做到了数据准确、系统稳定,为何不再配上系统高效这一道主菜让整个系统使用得更舒服呢。所以在接手了公司监控系统,并完全理清楚其中的逻辑后,就要对原有的监控系统进行大刀阔斧的重构了。
网络指标告警系统
在真正介绍监控系统重构之前,先说明一下使用到的数据库:
mysql - 存储告警配置、告警数据
clickhouse - 列存储数据库,用于存储海量设备指标数据
系统设计
在我接手原有监控系统时,系统结构是这样的:
1. 探针采集设备指标数据->存入clickhouse表
2. 定时拉起监控系统后台执行程序->读取mysql告警规则->依据告警规则查询clickhouse表获取指标数据->判断指标数据是否异常->生成告警→存入mysql
3. 拉起推送系统推送后台执行程序->读取mysql中的告警-