技术运营团队的由来
在运维更名为技术运营的两年内，我们对这个团队的工作目标产生了新的理解，工作内容也逐渐从传统的维护往DevOps方向转化。技术运营，简单地讲就是利用技术手段，降低资源消耗，提高基础资源的运行效率，提高整个软件生命周期运行的效率。这意味着对团队内的每个工程师都提出了更高的要求：一方面我们要支持目前的系统运行；同时也要针对目前的业务流程去开发自己的工具，让整个基础资源和能力工具化，把经验和自己对流程的理解变成Web化的工具，提供给程序员使用。
为什么必须自主研发监控系统
目前在TalkingData的Developer除了负责代码的编写，还要负责生产系统自己程序的性能指标提供监控接口，以及生产环境程序bug的处理。Developer能够一定程度的获取生产权限，方便常规的维护和简单故障的处理。这样一来，技术运营的挑战就来了：权限的管理、性能指标的监控、日志的管理以及资源的隔离，都需要有成熟的工具去支撑。目前市面上有很多开源的软件可以实现这样的功能，但是在不同程度上存在各种各样的问题。以监控为例，开源的监控很多，Zabbix、Nagios、Cacti，都是不错的监控软件，但是首先它们并不能满足大数据场景下的数据存储；其次，如果监控项和主机数量过多，数据查询时会出现速度慢等一系列问题。所以技术运营首先选择在监控上做了全新的设计和开发，新监控命名为OWL（猫头鹰），意思就是在技术人员睡觉的时候提供值班服务。
自研监控系统的三大技术要点
传统的监控很多还是在停留在设备、网络、系统相关的监控上，重视数据的采集，但是在数据算法和Role上比较传统。对监控系统简化抽象下，传统监控可以大致分为三个过程：数据采集、数据存储、响应处理。OWL监控在传统监控基础上，增加了Algorithm模块，支持复杂的算法规则报警，如下图所示：
1.监控数据采集
DataCollection就是数据采集，这里指的数据不光是基础硬件的指标，也可以是业务指标。下面介绍两个实例。
第一个例子是主机硬盘状态的采集：
下面的数据采集中第一列是硬盘设备标号，第二列是硬盘的状态，在监控的这个层面，一切都是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的访问状态的数据采集：
第一列是 懒人码农专注于移动互联网资讯、程序员编程资料、编程经验、职场面试分享，并提供最全最好的手机网站模板、响应式网站模板、html5游戏源码下载。
懒人码农（lazycode）
