OWL：一种新型、分布式企业级监控解决方案

嘉宾介绍

潘松柏 TalkingData 运维总监

曾在中国移动12580，惠普中国等公司任职，目前负责TalkingData 整个大数据平台的运维支撑。

前言

这5年来互联网高速发展，很多技术不断演进，Python 本来是为科学计算而生，在国内变成了运维人员的基础要求；LAMP 使用场景开始拆分，最为突出的是Linux 的X86架构以及MySQL，并应运而生地出现了轻量级容器Docker。

整个技术栈快速推进，这些给运维人员提出了更高的要求和挑战：怎样在如此复杂的环境中，确保业务的稳定性，快速发现系统问题呢？

有没有那样一个企业级解决方案，能同时迎合运维和开发的需求？即，既能帮助运维人员做基础设施监控，又很灵活地帮助开发人员做业务监控？

这恰巧是我们推出OWL，这种一种新型分布式、企业级监控解决方案的初衷。出于我们公司的大数据基因，在设计OWL 时，便充分考虑了各种算法及分布式存储，使得监控报警更加灵活，后期数据分析更加丰富多彩，业务的数据监控也更加方便、受人喜爱。

本文也是第一次系统化的阐述OWL 的体系架构和特色功能（在此特别感谢小米Open-Falcon 团队，和你们的技术交流，确实受益匪浅）。主要内容包括：

1. OWL 是什么？

2. OWL 体系架构简述

3. OWL 特色功能

4. OLW 开源计划

OWL 是什么？

如上所述，OWL 是一款新型的、分布式的企业级监控解决方案。既能监控IT基础资源，同时能够支持其他数据的监控，其融合了运维人员喜闻乐见的语言和技术（如Python ，shell等），又能够把开发人员也拉进来，方便灵活地放入更多的业务监控指标。

特此说明：不仅仅Nagois 和 Zabbix，其实国内外近期都出了很多新兴监控工具，如prometheus、facebook的bosun；国内小米的Open-Falcon，也是一款广受欢迎的产品。

在这里我先略说OWL 的主要特点，后文将有更详细的阐述：

1. 基于复杂算法的浮动报警规则

2. 灵活方便的用户自定义报表

3. 真正可视化的资产管理

4. 部署方便的Agent ，支持进程守护

5. 可平行扩展的底层数据存储

好吧，我们正式开始。

OWL 体系架构简述

如下为OWL 的主要结构，可能和大家所了解的其他产品，区别较大。请容我略作阐述。

• 左侧是整个后端，主要是围绕opentsdb ＋ MySQL 来做的展示端，MySQL 存储字典表以及相关的基础数据，opentsdb 只存储采集的metric数据。

• 中间是Server 端，负责数据的接收，Server 端目前有两种模式，一种是single mode ，可以直接接收Agent na’z的数据；另外一种是proxy mode，代理模式是采用的透明模式，只负责转发。无论那种模式，Server 自己会有一个内存的MQ，缓冲一部分数据，MQ超长之后会出发报警。

• 右侧是client 侧，负责采集os等需要采集的数据，使用 golang编写，底层插件库支持多种语言shell ，Python ，golang等，Agent 为双生结构，以保证可用性（详见下文）。如下为client 侧的详细图示：

  

OWL 的特色功能

OWL 在设计之初就充分评估、考虑了现有各种开源工具的优劣，先汇总如下：

1. 基于复杂算法的浮动报警规则

在目前新的互联网业务中，监控需要能够比较好的探知业务的状态，并通过算法予以实现。简单的用比如加减运算即可，但复杂的可能涉及到方差以及相似度等算法，再配以其他灵活的报警策略。

一般监控工具的报警设置都仅限于固定的阀值，这类简单阀值报警机制明显是不够友好。因为，一旦到达阀值，需要人工处理干预才能取消报警，而有些报警可能是容量的问题，或者短期无法处理的情况，这样带来的悲剧是，系统恢复之前，报警信息会不断的发送。

OWL 不仅支持固定报警阈值，也支持浮动报警。即在到达预设的阀值后，自动追加阀值，这样一定程度上可以降低信息的发送量，在系统恢复正常之后，OWL 监控系统也能自动恢复到之前的阀值。

相似度算法

在真实的环境中，我们的技术监控数据会有比较多的燥点，在后期绘图以及报警过程中怎么合理的处理一些数据燥点、并且能够真实地体现业务情况，是一个比较难把握的问题。我们在一部分metric尝试采用了时间维度的相似度来实现一些报警。

2. 灵活方便的用户自定义报表

这可能是OWL 的特色功能了。

监控系统按照运维内部细分，工程师的角色有很多，如网络工程师，系统工程师，DBA，DevOps（我们体系里面还有研发），每个角色关注的图表是不一样的。

那么，监控系统怎么设计，使得不同用户，只看到自己感兴趣的图表，并且自定义自己的图表呢？

逻辑实现上比较简单，但是实现的细节上，需要对数据有比较好的抽象和理解。我们作为大数据的公司，在设计的时候比较多的考虑到了数据的抽象和可视化。

在OWL 中，监控系统的每个用户都可以定制自己的图表工作台，web上操作比较简单，分两步：

• 选取自己需要的主机或者设备，复选metric

  

• 工作台区域就可以看到自己需要的metric的绘图，绘图区域可以按照时间选区，拖动时间轴线，查看自己需要的绘图。

  

3. 真正可视化的资产管理

丰富的资产管理方式，这块其实是我们监控系统一直坚持做的。

运维总是要和机器IDC打交道。资产的清晰可见就变成一块迫切的需求，OWL 最新版保持了我们现前版本的特色－模拟机柜图，现实资产的同时显示主机的监控状态，位置和状态一目了然。

4. 灵活方便的Agent ，支持进程守护

OWL 的监控Agent 不依赖OS，方便部署，可支持多种插件，并借助于双生机制，实现了进程守护。

多说几句，如果回过头来看互联网架构，其实无外乎：架构的高容错性、分布式系统和廉价的X86 服务器等。

也就是说，通过成本比较低的架构和硬件去解决之前很多传统IT的高昂的小机和大机的问题，在保证高可用、高效性的同时，降低整个IT 的成本和消耗。

所以，监控系统的Agent 端，需要具备比较好的跨平台性，对OS 的基础库依赖性要低。

但Python就是一个反例，版本经常无节制更新，造成底层库支持的兼容性很差，不同的OS版本引用不同的版本的python库，这样就会导致相同的脚本在不同的os上执行结果不一样。所以，监控的agent要有通用的协议栈支持。

传统的监控Agent 基本都是基于C或者C++ 实现，一方面维护难度大，如果需要修改，对目前的运维人员，学习成本很高，维护难度大；也看到Python来实现的，之前尝试实现过，环境的依赖性很大。

OWL 最后采用了golang 来做Agent ，golang的优点不用多说了，缺点也有，但是从现在看可以满足我们的需求。

OWL的Agent 采用了双生的结构，两个进程采用socket通信，保持心跳包，如果Agent 出现了异常退出了，那么：

1. guard看门狗程序将会把Agent 自动启动；

2. Agent 继续保持心跳，恢复状态；

3. 按照Agent 缓存的服务器端的配置，通过golang的exec 库执行下层插件库；

4. 插件执行结果按照规定的KV模式返回Agent ；

5. Agent 通过私有协议回传数据到服务器；

6. Agent 在plugin的数据返回格式上做了强格式限制，不符合规则的数据不能被Agent 接受，这也从一定范围内保持数据的清洁性，降低了数据燥点。

5. 可平行扩展的底层数据存储

为了充分考虑后端数据结构，以及相关的数据展示形式，我们在初期测试了相关的数据库，关系型数据库，KV数据库，但结果都不尽如人意。

最后，我们选择了平行扩展性好的hbase，上层使用tsdb封装。这虽然丧失了灵活数据查询形式，但是对于数据存储形式的考虑，我们可以做到比较好的透明化。另外，普及一下hbase的基础知识：

Hbase是一个面向列存储的分布式存储系统，它的优点在于可以实现高性能的并发读写操作，同时Hbase还会对数据进行透明的切分，这样就使得存储本身具有了水平伸缩性。

现在时序或者KV数据库比较多，influxdb、kairos-DB、opentsdb、cassandra 以及商业化的vertica，都是考虑到了数据库的分布式扩展能力。Hbase吞吐量很高，我们目前每天的数据插入总量为每天3000W次，主机的负载在20%左右。

在此借用官方一张介绍tsdb的图，tsdb的底层存储在hbase上保持平行扩展，同时上层也保持了比较好的平行扩展型。

略有不足之处是，从数据的查询来说，tsdb上做了部分的封装，造成了数据接口的灵活性做了一定的折中，数据查询上稍稍费劲一些。

关于开源计划

OWL 确实有开源的计划，目前在整理代码，并继续完善功能（预计完成时间为2015年底左右）。开源的具体时间表，实诚的说，取决于公司的安排，但请放心，我们也会一直跟进。

欢迎感兴趣的DevOps来公司做技术交流，也欢迎新思路加入进来，我们已开始订制后期版本的roadmap，以方便新功能的迭代开发。如有需要，请加我的个人微信：hierarch_pan。