概述

监控体系是整个IT架构中的重中之重，小到毛病排查、问题定位，大到事务猜测、运营办理，都离不开监控体系，可以说一个安稳、健康的IT架构中必定会有一个可信赖的监控体系，而一个监控体系的柱石则是一个安稳而强健的数据收集体系。

界说收集数据

数据结构的挑选

监控数据是规范的时刻序列数据，传统的监控体系中，一条监控数据一般是由监控目标、时刻戳和值组成，比方有10台服务器的内存运用率需求监控，一个时刻周期内映射到体系中或许便是10条mem.userd.percent 时刻 值 这种格局的数据，然后别离和对应的主机相关。

这样做的缺陷是，假如某一时刻想计算某个产品线、事务体系、集群、数据中心的某些监控目标的运用情况，或许就不太好完成。所以咱们需求在传统的数据结构基础上添加一个字段，用来存储咱们自界说的数据标签。为此，咱们调研了当时干流的时序数据库，如RRDtool、Graphite、InfluxDB、openTSDB等，其间RRDtool和Graphite 只能支能持时刻维度和值维度，Cacti和Zabbix便是根据RRDtool来绘图展现的。而InfluxDB和openTSDB都能满意咱们的需求：其间InfluxDB版别比较低，而且每次更新改动都比较大;而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每次收集都会判别数据类型，并运用对应的运算规矩。

收集体系的全体架构

架构的改动

比较于上个版别的架构，咱们的数据收集体系仍是发生了很大的改动，改动首要体现在服务逻辑拆分和从头规划。

服务端在上个版别中，首要担任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等。

收集体系怎么与运用体系对接

比方咱们现在新开发一个运用，那么咱们需求整理咱们需求关怀的目标，比方体系的吞吐量、推迟、接口或url拜访量等等，因为OWL不支撑自动push数据，所以咱们需求将这些数据经过Http REST API 方法露出出来，然后运用OWL自带的app_collect插件来守时收集数据，API露出的数据结构大约如下：

收集体系的上层运用封装

根据该体系，咱们可以在上层构建报警体系，计算分析体系，报表体系等等。咱们可以自在去发挥。

其间，报警服务在上个版别中是根据Python 的Celery去完成的，因为依靠很多模块，装置布置杂乱，在开源进程中大部分反应的问题都是在该模块的布置上。因而，在该版别中咱们运用go言语对重构了报警服务，分为控制器和报警逻辑处理模块：其间控制器担任报警战略生成和报警成果处理;逻辑处理模块担任从控制器获取战略并去OpenTSDB读取数据进行比照，发生的成果回来给控制器处理。全体而言这是一个生产者顾客模型，理论上顾客可用无限扩展。更多报警的具体细节，会在本系列的报警文章中进行具体的介绍。

总结

数据的收集是起点而非结尾，怎么对收集到的数据进一步加工处理，而且可以协助咱们改进工作和日子才是终究目标，咱们深信，数据改动人们的决议计划方法，数据改进人类本身和环境。