从大数据的角度来谈谈运维监控这件事儿

2019-09-10 15:58:42 采集侠

做运维的人对监控这件事儿都太熟悉了,但是对于监控这么一件老生常谈的事儿,我们今天换个角度,从大数据的角度来看看有什么新的发现。

为什么要从大数据的角度来看监控这件事儿呢?首先,以大家最熟悉的服务器监控为例,虽然原理很简单,但从数据角度来看,其仍是一个典型且完整的数据采集(监控数据采集)、分析(报警)和可视化(趋势图、仪表盘)处理过程。其次,监控领域需要关心的数据不仅仅是服务器监控数据,还包含各种角度、各种来源的数据,如日志数据、网络通信数据等,数据呈现种类多、体量大和时效性要求高的特点,符合典型的大数据基本特征。

Gartner在2016年第一次提出AIOps概念时,AI代表了Algorithmic(算法),算法的基石正是海量的数据,在2017年将AI含义改为Artificial Intelligence(人工智能)后,同样需要海量的数据进行处理和学习。我们从下文的Gartner描绘的AIOps平台架构中同样能看到数据对于AIOps、对于运维、对于监控的重要性。

从大数据的角度来谈谈运维监控这件事儿

我们从数据来源的角度对监控数据进行分类,比较常用的几种数据来源如下:

机器数据,常用指数★★★★★,获取难度★☆☆☆☆

日志数据,常用指数★★★★☆,获取难度★★★☆☆

网络通信数据,常用指数★☆☆☆☆,获取难度★★★★★

拨测数据,常用指数★★★★☆,获取难度★☆☆☆☆

Agent代理数据,常用指数★★☆☆☆,获取难度★★★★☆

用户行为数据,常用指数★★★☆☆,获取难度★★☆☆☆

指数仅供参考

这么多种数据来源,各有什么特点和用途呢?接下来我们详细聊一下:

机器数据

机器数据是指服务器、网络设备等硬件或虚拟硬件运行过程中产生的状态数据,往往有对应的协议或规范,例如SNMP、IPMI、WMI等。通过机器数据可以准确的掌握业务承载平台的基本运行状态,例如CPU、内存、磁盘等资源的使用情况和网络流量情况,是运维监控领域最常用的数据来源,各类开源或商业监控产品对此类数据的处理也大同小异,例如Zabbix、Nagios等。

云计算时代,同样离不开机器数据,虽然用户不用再关心底层物理设备的运行状态,但云厂商提供的各类云服务器、网关、负载均衡等虚拟设备同样会产生大量机器数据,需要用户时刻关注,例如云服务器的资源使用情况、带宽的使用情况、网关的负载情况等。

做好机器数据的监控可以说是做好运维监控的第一步,但仅仅有机器数据是不够的,因为机器数据存在与业务运行状态脱节的问题,机器运行平稳、资源充足并不能够代表业务运行正常,这就需要我们去丰富自己的监控数据来源,各位看官请往下看。

日志数据

日志数据是指应用程序、中间件和机器等在运行过程中由事件触发而产生的文本类数据,数据格式灵活多样。

通过日志数据可以深入的了解应用等运行过程中的详细情况,但其详细程度和覆盖面取决于产生日志的规则,有些应用产生的日志非常详细,包含了每一笔事务的处理过程,有些应用产生的日志非常简单,只会在应用报错时产生一些错误信息。

日志数据的应用场景非常广泛,上到业务指标分析,下到Bug追踪定位,是监控领域的全能选手。但由于日志数据的灵活性,要想利用好日志数据,必须先想好监控什么,再通过制定日志规范获取到需要的数据。日志数据的采集和分析最常用的开源方案就是ELK Stack了,可以说已经形成了一定的行业标准。

网络通信数据

网络通信数据是指通过抓包获取到的设备间网络通信数据,例如两台服务器之间存在网络通信,通过抓包分析可以详细的了解两台服务器之间通信的端口、协议、数据量甚至内容。常用的方式是通过硬件设备将网络流量进行镜像,对镜像数据进行分析,以避免干扰业务数据的正常流转。

网络通信数据非常全面,只要有网络通信理论上就能够抓取到详细的数据,而不需要日志数据那样提前制定好数据输出规则。想象一下你在管理一个交易系统,不需要吐任何日志就可以获取到每一笔交易的详细情况,而且这种数据获取方式还不会影响到应用的运行,是不是很爽。

但是网络通信数据的利用是较少的,难度也较大,小编私以为主要是由于网络相关的运维和业务相关的运维往往是不同的Team在负责,不同运维团队的关注点和侧重点不同造成的。网络运维团队更加关心网络本身的稳定性,对业务的理解不是非常深入,即使通过抓包拿到详细数据,也很难进行详细的分析。而业务相关的运维和研发团队对网络又缺乏完全的掌控,对网络的理解也不够深刻。