带宽监测系统的重要性不言而喻。它为运营商结算、网络质量监控提供必要的数据支持,是每个拥有自建资源的互联网公司必配系统之一。白山云科技(以下简称“白山”)目前线上设备数千台、分布于全球十几个国家、跨越数十家运营商,在如此复杂的网络环境下如何确保各设备带宽数据精准监测,后期能按不同应用场景灵活整合,并且在网络规模扩大到上万台后仍然能轻松应对,是技术上需要面对的挑战。本文来自白山研发副总裁苗辉,与大家分享白山带宽监测系统背后的秘密。
和大多数其他公司一样白山最初也选择cacti作为带宽监测系统,但是随着公司网络规模和复杂度的不断提高,在设备将近800台时cacti已表现出严重的问题:
在此背景下,我们放弃了对cacti的继续改造,在参考借鉴诸多开源系统的基础上开发出当前的带宽监测系统。系统的核心设计目标是:99.9%的数据完整性完美跨运营商和跨国家监测问题、平台可以水平扩张至承载上万台服务器的监测、支持秒级粒度数据监测、提供简单高效的数据查询接口。
(点击放大图像)
如这张架构图所示:
swcollector负责数据的收集,以后台进程模式运行在全网各个服务器上。收集来的数据传输给数据收集中心swtfr组件,在跨网或跨国环境下,如果swcollector无法将数据传给swtfr,swcollector会主动尝试通过多台gateway中转的方式确保将监测数据最终发送到swtfr。
全网共部署三套swtfr + influxdb + flow-api组件组合,任意一台swtfr收到数据后立即copy三份,写入三个influxdb中。flow-api负责数据的查询和聚合,当收到一个查询请求后,将查询数据拆分成最小粒度的查询事件并发向三台influxdb发起查询,数据收齐后再做聚合处理。flow-api支持统计最大值、平均值、最小值、group by等常用聚合操作。
当前一分钟监测15w条数据,90%以上的数据能3s入库,最大规模数据查询耗时3s内,完全满足业务需要。当监测规模较大时,可以通过水平扩展swtfr + influxdb + flow-api组件组合提升系统性能,此外influxdb本身也可以方便地水平扩展,以达到更大的存储容量和更高的读写效率。
服务器的带宽监测为自发现方式,除支持各网卡进出带宽监测外,还支持服务器内/外网进出带宽的分开监测、以及指定端口服务的内/外网进出带宽的分开监测。
交换机的带宽数据监测多份,一台交换机会同时被本节点内的一个swcollector和另外两个不同节点的swcollector监测,监测周期20s,三份数据通过flow-api聚合后输出1分钟粒度的带宽数据更为精准。
与CMDB打通后可以自动按节点网络拓扑分层展示、合并展示、按用途合并展示、与客户计费带宽对比分析等多种方式展现,数据查询秒开。
下图为该系统数据展示场景之一:
(点击放大图像)
带宽监测系统是一个看似简单但实则复杂的系统,当你的网络规模达到一定程度你不得不克服网络不通、数据不精准、处理效率低等问题,白山已将Octopux系统开源,希望给大家带来更多灵感和参考,地址如下:
https://github.com/baishancloud/octopux-swcollector
https://github.com/baishancloud/octopux-swtfr
https://github.com/baishancloud/octopus-gateway
另外随着influxdb生态的不断完善,influxdb无依赖易维护、轻量级高效率、丰富的可视化组件、自带数据聚合能力等优势逐渐凸显出来,白山正在尝试基于该系统架构打造第三代监测系统,以实现更好的聚合分析和复杂策略报警功能。
苗辉,白山创始合伙人兼研发副总裁。苗辉先生负责白山第一个产品线CDN-X的相关研发工作,带领团队在3个月内实现CDN-X系统从无到有,依靠独特的SHAQUE、MANTA、TUNA、DOLFIN技术和质量化运维体系取得平台4个月上量500G,90%以上客户PK第一名的成绩。
作为网络传输优化专家,苗辉先生在运营支撑与性能优化方面积累了丰富经验。2007年至2011年,就职于网宿,带领团队创建网宿科技CDN运营监控体系;2011年至2014年任百度架构师,负责百度自建CDN架构和服务质量的优化改进,自建CDN稳定性业内首达4个9,并成功承载百度搜索等80%的百度核心业务。
感谢魏星对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博(@InfoQ,@丁晓昀),微信(微信号: InfoQChina )关注我们。