为什么必须自主研发监控系统
目前在TalkingData的Developer除了负责代码的编写，还要负责生产系统自己程序的性能指标提供监控接口，以及生产环境程序bug的处理。Developer能够一定程度的获取生产权限，方便常规的维护和简单故障的处理。这样一来，技术运营的挑战就来了： 权限的管理、性能指标的监控、日志的管理以及资源的隔离，都需要有成熟的工具去支撑。 目前市面上有很多开源的软件可以实现这样的功能，但是在不同程度上存在各种各样的问题。以监控为例，开源的监控很多，Zabbix、Nagios、Cacti，都是不错的监控软件，但是首先它们并不能满足大数据场景下的数据存储;其次，如果监控项和主机数量过多，数据查询时会出现速度慢等一系列问题。所以技术运营首先选择在监控上做了全新的设计和开发，新监控命名为OWL(猫头鹰)，意思就是在技术人员睡觉的时候提供值班服务。
自研监控系统的三大技术要点
传统的监控很多还是在停留在设备、网络、系统相关的监控上，重视数据的采集，但是在数据算法和Role上比较传统。对监控系统简化抽象下， 传统监控可以大致分为三个过程：数据采集、数据存储、响应处理。 OWL 监控在传统监控基础上，增加了 Algorithm 模块，支持复杂的算法规则报警 ，如下图所示：
1. 监控数据采集
Data Collection 就是数据采集，这里指的数据不光是基础硬件的指标，也可以是业务指标。下面介绍两个实例。
第一个例子是 主机硬盘状态的采集 ：
下面的数据采集中第一列是硬盘设备标号，第二列是硬盘的状态，在监控的这个层面，一切都是metric，不同的层级可以抽象到不同的metric，结合 metric + timestamp + tagk1 + tagv1… + tagkN + tagvN，这样针对相同的metric去加tag，用来标示数据，方便后期的查询。
{
"0_1_12": 0,
"0_1_13": 0,
"0_1_10": 0,
"0_1_11": 0,
"0_1_4": 0,
"0_1_5": 0,
"0_1_6": 0,
"0_1_7": 0,
"0_1_0": 0,
"0_1_1": 0,
"0_1_2": 0,
"0_1_3": 0,
"0_1_8": 0,
"0_1_9": 0
}
第二个例子是 Nginx 的访问状态的数据采集 ：
第一列是http请求的状态，第二列是计数器
{
"200": 29312,
"404": 0,
"499": 60,
"412": 0,
"400": 114,
"502": 0,
"408": 179
}
2. 监控数据存储
监控数据的存储也是一个很有意思的话题，监控数据在数据结构上是很有特色的。仔细观察发现监控数据基本上都是和时间维度相关的，以metric + timestamp 的组合形式的数据占了所有监控数据量的大部分，相比而言，多维度的监控数据比较少;如果出现了多维度的监控数据，也可以通过其他的方式绕开处理。 RDBMS由于要考虑数据的关联，所以它在整体数据存储设计上充分考虑了数据的完整性和关系型，同时在 schema设计上还要遵守数据库的几大范式。传统的监控大多数还是使用了RDBMS，但是这造成了性能上和扩展性上的局限性。针对监控数据这样简单的数据结构，却采用了一套复杂的存储格式。随着近些年各种各样的垂直的
技术领域对数据的存储不同要求的演变，如Graph database，Time Series Databases等数据库得到了不断发展;监控数据在存储上有了更多的选择，InfluxDB，OpenTSDB，KairosDB都是不错的选择，最后我们选择了OpenTSDB，这主要是因为TalkingData的大数据基因，Hadoop和HBase在我们的业务系统中大规模使用。从现有的数据体量上，OpenTSDB能够满足现在的业务要求。简单的总结了一下OpenTSDB的优点：
使用HBase存储，不存在单点故障。
使用HBase存储，存储空间几乎无限。支持永久存储，可以做容量规划。
易于定制图形
能扩展采集数据点到100亿级。
能扩展metrics数量到K级别(比如CPU的使用情况，可以算作一个metric，即metric就是1个监控项)