阿里基础设施的智能监控

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: IDC、网络、服务器等基础设施承载了一次又一次的双十一奇迹。随着阿里集团业务全球化、多元化发展,作为整个集团之根本的基础设施,其运营水平显得愈发重要,智能监控成为了重中之重。

IDC、网络、服务器等基础设施承载了一次又一次的双十一奇迹。随着阿里集团业务全球化、多元化发展,作为整个集团之根本的基础设施,其运营水平显得愈发重要,智能监控成为了重中之重。

阿里IDC承载着为全球业务提供基础服务的重担,服务的稳定性和可用性有着极高的业务要求,同时又面临全球机房环境迥异、设施链条复杂、业务负载不可预估等挑战性问题。如何做到从机房风火水电相关的基础设施到服务器的全链路感知,如何通过自动化的方式为机房现场人员定位环境异常原因、争取风险处理时间,这些都是阿里IDC监控必须解决的问题。

阿里的网络极其复杂,它运行于全集团近百个机房以及数万网络设备之间,承载着全集团所有服务器/虚机运行业务所产生的网络流量。阿里内部不同BU、安全域之间的隔离,内网外网隔离,公网和私网设备,带外与带内设备,海外与国内设备,丰富多样的自研设备,网络设备与外部各个电信运营商以及合作机构的连通,还有海量端口/端口集的全面实时监控和故障预警,这些都造成了网络监控的复杂性。

智能监控架构上采用完全分布式采集和集中式的计算和存储,计算和存储具有异地多机房容灾能力。海量基础设施数据的实时采集、计算、分析、预警为阿里全集团提升运营水平提供了坚实的保障。

一、IDC监控系统
阿里巴巴的IDC遍布全球,受到机房地理位置的气候差别、电力环境差别等因素影响,机房建设做出了各具特色的设计,这也为保障所有机房的安全运营增加了业务复杂度。例如处于干旱气候环境的某些机房,使用风力制冷,会在冷通道内形成正常的空气温度波动,易造成误报警,从而影响故障判断,这与由设施故障造成的温度升高如何区别?机房内出现设施故障时,冷通道的升温通常会有一段时间的过渡期,采用传统的报警阈值判断逻辑,需在环境温度触发红线时才能产出报警信息,如何能快速地感知机房温度环境的变化、留给机房现场更多的风险处理时间?机房内电力链路是极复杂的拓扑结构,链路前端的设备出现故障时,关联的各级子设备也会受到影响,如何避免可能出现的报警风暴,准确地定位到一批关联报警的根源?IDC监控系统很好的解决了上述问题。

系统架构
IDC监控的数据流分为两条分支:IT类和基础设施类。
image.png

采集

服务器上物理信息的收集需要依赖完整的IDC资源信息链条,监控系统内放置了一棵包含全集团机房的物理信息树,从树顶到树的叶子节点依次为机房、包间、机列、机柜,机柜下层则为其实际挂载的物理机。

整个IDC监控由中心调度模块(Master)来进行配置驱动,某项特定的物理监控项(例如服务器入风口温度、单机功耗、电源模块状态、负载等)被部署在物理树上的机房层,这些机房节点下联的各级节点也自动生效。调度模块及时更新各个机房内、各级节点、各台机器上的调度任务。每个机房中的代理调度模块(Monitor)定时更新本机房内各台机器上的监控调度任务,每台服务器则向同机房内的代理调度模块进行任务咨询,确定本机上的指标采集脚本内容和采集周期等具体信息。如此,逐层的将任务指派到各机房的各台机器上。

image.png

单机服务器的配置流如上所述,从中心的配置驱动,下放到了各台物理机上,而在单机内部进行完定期的任务调度之后,会产生出该台机器当时的物理指标信息,这些信息需要被传送到中心,这是监控系统数据流的开端。

从各个机房内到中心的数据流流向和配置正好是相反的方向,数据流由单机上发起,数据第一步先中转到各个机房类的代理(Monitor),机房内的数据代理再集中向中心的数据收集器(Collector)发送,此时整个IT设备数据采集的流程完成,中心的数据流开始。

计算
监控的本质是需要在实时的海量生产数据中发现异常的信息,对于IDC场景下的数据来说,需要按照业务特点进行个性化的数据分类。

IDC的最小运营单元是机柜,通常机房内的基础设施会为单个机柜上的物理机提供共同且一致的物理环境,由此,中心单元收集到的单机物理数据需要在计算集群中按照机柜、机列、包间、机房的维度进行数据归类,从而得出满足业务需求的结果数据,例如单个机柜的总功耗、整个包间的冷通道入风口温度等信息。

报警
以机房暖通类报警为例,当机房暖通类基础设施出现问题时,会导致给机房制冷的空气温度异常,进而影响服务器的入风口温度。机房的环境温度升高是一个持续的过程,如果使用传统的阈值检测报警模式,需要等到温度环境超过设定的报警时,才会触发报警逻辑,此时,即使发现报警,留给现场人员的处理时间也已经大幅减少,IDC的特殊业务要求对温度异常快速发现有很高的要求,所以,监控系统对温度检测逻辑进行了针对性的优化。

监控系统当前的两次温度数据放进缓存,每次新周期的数据到来时,得出两次的温度变化值,而报警的逻辑除了机房的个性化固定阈值外,也包含快速温度升高的检测逻辑,两个报警逻辑同时进行,一些机房出现温度升高趋势时,在还未到达特定阈值时,可提前发现并预警,为机房现场人员争取更多的风险处理时间。

二、网络监控系统
阿里的网络设备复杂多样,数量极多,故障难以避免,故障会影响网络所承载的业务系统,所以网络故障快速、准确地发现、定位、以及收敛成为了网络监控系统的最基本需求。此外端口集,交易机房,支付机房,各种网络专线,BGP,CDN等等的流量和水位数据都是非常重要的数据,可以帮助集团把握实时网络状况,预测未来网络流量。网络监控系统是网络故障先于业务发现的重要贡献者,以及双十一网络全局大盘的提供者。

系统架构
网络监控系统分为四部分:采集、计算、存储、和前端。由于网络的复杂性,要实施全面的网络监控需要采集的数据很多,目前采集的有网络质量数据(PING)、SNMP数据、SYSLOG数据、AAA日志数据、LVS数据、ANAT数据、ANAT日志数据;计算主要是采集数据的转换、汇聚、产生实时异常事件例如告警数据以及数据入库;存储采用集团的HBASE存储。计算、存储、和前端集中部署在一个机房内,采用异地双活做为容灾,采集分散到各个安全域的机房内。

image.png

采集

采集根据不同的机房生成采集域,对于网络质量数据的采集,一个安全域内会部署多个ICMP采集域,这些采集域会PING安全域内非本机房所有的其他机房的网络设备和服务器,然后汇聚计算的时候取最好的结果,这种交叉PING然后汇聚结果的方式能极大地减少误报的几率。例如下图所示,某一个安全域内有6个机房,其中有2个机房部署了采集域,每个采集域会PING其他5个机房的网络设备和服务器,每个机房的网络质量会由所有的采集域采集的机房服务器PING结果汇聚生成,每个网络设备的网络质量由所有的采集域采集的设备直接PING结果以及设备下联服务器的PING结果汇聚生成。

image.png

阿里机房服务器很多,这样对PING采集的性能提出了很高的要求,一个采集域由多个采集机组成,任务分配力度按照机房级别,所有被采集机房均匀地分布到每个采集机上,每个采集机对服务器每秒发一个或多个ICMP包,对网络设备每15秒发一个或多个ICMP包,根据ICMP回包和延迟数据汇聚到5秒或者1分钟粒度从而得到该目标IP周期性网络质量,目前一台服务器能支持多达5万目标地址的网络探测。由于交叉PING的架构,PING采集机的容灾不是非常重要。

image.png

SNMP采集是基于UDP协议,为了减少对设备的影响而又尽可能地保证采集到完整的信息,我们采用分步重试的方式,简单说就是任一时间的任一个设备只允许一个SNMP采集指令,这个指令也不允许一次拉回所有节点数据,但是任何指令都可以重试有限次数。SNMP采集会自动发现网络设备端口和上下联关系,然后采集所有端口状态,流入流出流量,流入流出转发速率,流入流出错(丢)包,CPU,Memory,风扇等等数据。SNMP采集域也是由一台或者多台采集机组成,被采集的设备均匀分布在每一台采集机上。如果采集域内某台采集机宕机,其他还活着的采集机可以承担宕机的采集机所承担设备的采集任务,这个称之为采集域内容灾。此外同一个安全域内不同采集域可以互相指定为备份采集域,如果某个采集域内的所有采集机都宕机,那么备份采集域的采集机会承担宕机的采集域所承担设备的采集任务,这个称之为跨采集域容灾。

Syslog和AAA日志采集是由网络设备转发到机房工具机再转发到采集域的采集机上;

LVS和ANAT采集是由部署在LVS和ANAT上的采集进程发送采集数据到采集机上;

ANAT日志采集是由ANAT服务器转发到机房工具机再转发到采集域的采集机上。

计算
计算模块采用了自研的分布式计算框架,它具有插件化、周期驱动、自协调、异步化的特点。整个集群会先选出一台服务器来做Master,Master周期性产生任务,任务平均分配到集群每台服务器上执行。任何一台服务器宕机,如果是Master,会选举生成新Master,如果不是Master,它上面的任务会很快重新分配到活着的服务器上。计算集群会根据任务主动拉取采集域所采集的数据,对于PING数据,计算任务会比较并选出最好的PING结果;对于SNMP数据,计算任务会统计端口流量、转发速率、端口错包的TOP排列数据,更为重要的是会根据端口集的定义汇聚所有子端口的流量数据以及计算水位。

存储
目前除了网络质量有一部分秒级数据外,其余大部分都是分钟级数据存在HBASE里,相信随着以后秒级监控的增加,HBASE的TPS和QPS都会极大的提高。

前端
前端可以展示所有机房和网络设备的网络质量,所有网络设备的所有端口的状态和流量,所有自定义端口集的流量,LVS/ANAT流量,和所有告警信息。此外还提供自定义大盘的功能,用户可以根据业务定义自己大盘展示。

告警
监控的告警需要实时分析所有采集的数据,以及依靠强大的收敛算法产生真正root告警内容。告警包括连接UPDOWN,端口/端口集水位,错包,思科设备FEX,设备板卡状态,机房和网络设备PING丢包,OTN……

阿里智能监控系统全面掌控了所有基础设施的实时运营状态,在双十一大促活动中,监控系统为及时发现风险、定位风险、处理风险、避免对交易和支付业务的影响提供了有利保障。监控系统提供的基础设施的全面运行数据为智能化、智慧化运营打下了坚实的基础,期待阿里基础设施运维向更加智能、自动、稳定、高效的方向迈进!

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
3月前
|
运维 监控 安全
云上智能监控:引领未来安防与运维的新纪元
通过智能视频分析技术自动识别违章行为(如闯红灯、超速等)并触发报警机制。同时结合交通流量监测和信号灯控制功能实现交通流量的优化和拥堵缓解。 智能零售监控:在零售行业中云上智能监控可以应用于店铺的客流统计和商品管理。
|
5月前
|
运维 算法 物联网
五大智能运维场景
【5月更文挑战第3天】智能运维场景分5类:异常检测、根因诊断、故障自愈、事件预警、效能优化。
|
SQL 运维 资源调度
开源大数据可观测性方案实践 - 助力集群运维智能化、便捷化
在本篇文章中,我们将介绍大数据集群领域所需的可观测性,实践大数据集群可观测所需要的条件和面临的挑战,以及阿里云EMR 产品如何通过 EMR Doctor 实现大数据可观测并向用户提供相关能力。
17268 4
开源大数据可观测性方案实践 - 助力集群运维智能化、便捷化
|
运维 Prometheus 监控
《2023云原生实战案例集》——01 汽车/制造——传音 基于ARMS构建全球一体化可观测平台,高效支撑业务创新
《2023云原生实战案例集》——01 汽车/制造——传音 基于ARMS构建全球一体化可观测平台,高效支撑业务创新
|
监控
《构建立体化的监控体系——58集团监控实践》电子版地址
构建立体化的监控体系——58集团监控实践
59 0
《构建立体化的监控体系——58集团监控实践》电子版地址
|
人工智能 运维 Prometheus
鼎茂科技和阿里云完成产品集成认证,深度发力云上智能运维建设
近日,鼎茂科技旗下智能运维AIOps平台与阿里云旗下可观测套件ACOS产品,经过严格测试程序,完成了产品集成认证,这是继阿里云云原生加速器生态合作后,双方在云上智能运维领域的深度产品化合作。
242 0
鼎茂科技和阿里云完成产品集成认证,深度发力云上智能运维建设
|
人工智能 运维 监控
助力企业提升运维效率 蚂蚁数科发布业务智能可观测平台
蚂蚁数科发布业务智能可观测平台 可助力企业提升运维效率3倍以上
299 0
助力企业提升运维效率 蚂蚁数科发布业务智能可观测平台
|
数据采集 人工智能 运维
运维监控走向数智融合时代,博睿数据发布一体化智能可观测平台 ONE
5 月 20 日,博睿数据正式推出了一体化智能可观测平台 ONE。据介绍,这是业界第一个将所有运维监控需求“All in ONE”的统一平台。
409 0
运维监控走向数智融合时代,博睿数据发布一体化智能可观测平台 ONE
|
机器学习/深度学习 人工智能 运维
智能运维机器人 开启数据中心智能运维“下半场”
“硬件+人工智能”,解放运维人力,提高数据中心运营效率
智能运维机器人  开启数据中心智能运维“下半场”
|
边缘计算 人工智能 运维
《边缘计算技术白皮书2021》发布:云边一体、智能运维
4月15日,ODCC边缘计算大会在京举行,中国信通院、阿里巴巴、中国电信研究院、中国移动研究院、Intel等各行各业交流碰撞行业新趋势,会上同期发布了《边缘计算白皮书(2021)》,业界共同分享及探讨了边缘计算的产业发展新趋势。阿里云也受邀参与本次会议并分享了对边缘计算的发展理念和思考。
《边缘计算技术白皮书2021》发布:云边一体、智能运维
下一篇
无影云桌面