首页>梦蝶头条>大数据下的技术运营:数据采集系统设计与实现
大数据下的技术运营:数据采集系统设计与实现

作者:梦蝶云运营团队 2019-04-17 00:00:00

数据监控 数据采集

简述

监控系统是全部IT架构中的重中之重,小到故障排查、问题定位,大到业务预测、经营管理,都离不开监控系统,可以说一个稳定、健康的IT架构中必定会有个值得信赖的监控系统,而一个监控系统的根基则是一个稳定而健硕的数据采集系统。

数据结构的选择

监控数据是标准的时间序列数据,粗放型的监控系统中,一条监控数据通常是由监控指标、时间戳和值构成,例如有十台服务器的内存使用率需要监控,一个时间周期内投射到系统中可能就是十条mem.userd.percent时间值这类格式的数据,随后分別和相匹配的服务器关联。

这样做的缺陷是,假如某一时间想统计某一产品线、业务管理系统、集群、数据中心的一些监控指数的应用情况,或者就不大好实现。因此人们必须在粗放型的数据结构基础上增加1个字段,用于储存我们自定义的数据标识。因而,人们调查了当今流行的时序数据库,如RRDtool、Graphite、openTSDB等,因此在数据结构的界定上,人们效仿了openTSDB的数据结构,每条数据由metric、timestamp、value、tags组成,用tags键值对来标志不一样的特性。例如网卡发送数据包数量为例,其数据结构如下:

Metric是一个可测定的单位的标称。metric不包含一个数值或一个时间,其只是是一个标签,包括数值和时间的叫datapoints,metric是用逗号连接的不容许有空格,比如:cpu.idle,app.latency等。

Tags:一个metric应当表述什么东西被测量,其不应当界定的太简单。一般而言,更好的做法是用Tags来描述具备同样维度的metric。Tags由tagk和tagv构成,前者表示一个分组,后者表示一个特定的项

Timestamp。一个绝对时间,用于描述一个数值或者一个给定的metric是在何时界定的。

Value。一个Value表示一个metric的具体数值。

这样对于相同的metric数据,人们能够随意的通过tag的组合来获得我们真正需要的数据。

三种数据类型

既然有了上面的数据结构的界定,当然就会有数据类型,不一样的数据可能象征的含义都不同,OWL中采用了RRDtool中较为常见的三种数据类型,分別为GAUGE、COUNTER、DRIVER。

GAUGE类型是一个计量器,能够理解最后存储的数据就是收集到的数据,例如服务器上的硬盘使用率,内存使用率,cpu使用率,硬件的温度,风扇的转速,业务系统中的访问时间等,这种数据会随时间的转变而转变,而且没什么规律可循。

COUNTER类型是一个计数器,该类型通常用以记录持续增长的记录,比如操作系统中的网卡流量,磁盘的io,交换机接口的流量,业务的吞吐量等等,COUNTER类型会假定计数器的值永远不会减小,除非达到数据类型的最高值产生溢出,OWL客户端会存储最近一次的值和上一次的值,每一次上报的过程中会取每秒的速率发送到repeater,当计数器溢出,agent会自动对数据进行补值,不然可能会由于溢出造成一个极大的异常值造成错误告警。

DRIVER类型用以表示单位时间内的数据变化,简单而言就是用于表达现阶段值和上一次值中间的差值,在监控领域中的现实应用领域或者不是太多。

架构的变化

对比于上一版本的架构,我门的数据采集系统还是发生了很大的转变,转变具体体现在服务逻辑拆分和重新规划。

 

 

服务端在上个版本中,主要负责agent端配置的维护,监控数据的接收和转存,网络设备数据的采集,端口健康状态监测等功能,当服务端需要进行维护的时候,整个监控服务相当于不可用的。另外也不利于扩展。所以在该版本中对server进行了拆分,分别为cfc、repeater、net-collect,其中cfc主要负责配置维护,repeater负责监控数据接收和转发,net-collect负责采集网络设备数据,任何一个组件都可用做到水平扩展,极大的减小了系统的危害性。

模块的角色功能

agent:通过内置metric及其自定义插件方式采集主机系统配置、操作系统、中间件、业务系统等数据,并利用tcp长连接异步发送到repeater。

net-collect:承担收集网络设备各类性能指标,包括各接口接收发送字节数、数据包数、错误数这些,监控数据通过tcp长连接发送到repeater中,配置和接口信息发送到cfc中。

cfc:通常部署于数据中心,直连MySQL,负责维护agent或net-collect同步过来的metric信息及其插件的同步等

cfc-proxy:通常部署于分支机构或异地机房,是agent/net-collect和cfc之间的通信桥梁。

repeater:可随意部署,负责接收时间序列数据并转发到特定的后端,支持repeater->repeater、repeater->openTSDB、repeater->Redis等。

采集系统的上层应用封装

基于该系统,我们可以在上层构建报警系统,统计分析系统,报表系统等等。

其中,报警服务在上个版本中是基于Python的Celery去实现的,由于依赖众多模块,安装部署复杂,在开源过程中大部分反馈的问题都是在该模块的部署上。因此,在该版本中我们使用go语言对重构了报警服务,分为控制器和报警逻辑处理模块:其中控制器负责报警策略生成和报警结果处理;逻辑处理模块负责从控制器获取策略并去OpenTSDB读取数据进行对比,产生的结果返回给控制器处理。整体而言这是一个生产者消费者模型,理论上消费者可用无限扩展。

总结

数据的采集是起点而非终点,如何对采集到的数据进一步加工处理,并且能够帮助我们改善工作和生活才是最终目标,我们坚信,数据改变人们的决策方式,数据改善人类自身和环境。


下一篇 离散制造业的数据采集之路
联系客服,定制专属数据需求
立刻定制
需求提出

客户将目标网站、数据要求等信息提交给梦蝶云

需求评估

与客户进行仔细的需求沟通评估确认,确保双方人之一致

实施采集

与客户确认后实施采集任务

数据交付

审核完成后为客户交付完整数据