支持秒级别的数据。
此外， OpenTSDB 支持 API 查询 ，可以轻松地和其他系统进行数据对接，也方便其他系统抽取监控相关的数据。 并且， 查询方式灵活 ：查询数据可以使用query接口，它既可以使用get的query string方式，也可以使用post方式以JSON格式指定查询条件。
3. 监控的报警算法
Algorithm这块是传统监控系统所欠缺的，基本上都是单个指标的大于，小于这样的算法，但是 遇到集群或者复杂的指标，就需要自己去增加一些算法，比如多个指标的加和，平均值， top10 ，历史相似度等。 这些算法的引入，可以增加报警的准确度，有效的减少报警数量，让报警变得人性化。 关于报警的算法会在本系列的后续文章进行详细介绍。
自研监控系统一览
简单的介绍一下OWL的整体架构，下面目前的架构是第四个大版本。在研发的过程中，我们也尝试了很多的开源技术，如RRDtools、Graphlite，也踩了很多的技术坑，最后我们整体选择了OpenTSDB，在这个技术栈下面演进了两个版本：
方案特点一：语言栈统一为Go
2015年的版本，由于技术人员的稀缺，我们采用了一部分Python一部分Golang的系统，在开源推广中带来了很多问题，主要是部署难度增加。2016年即将发布的版本中，metric collection模块、Controller模块、Inspector模块全部采用Golang开发，简单摘录一下Golang的优点：
部署简单 。Go 编译生成的是一个静态可执行文件，除了 glibc 外没有其他外部依赖。这让部署变得异常方便：目标机器上只需要一个基础系统和必要的管理、监控工具，完全不需要操心应用所需的各种包、库的依赖关系，大大减轻了维护的负担。这是与Python 的巨大区别。
并发性好 。goroutine 和 channel 使得编写高并发的服务端软件变得相当容易，很多情况下完全不需要考虑锁机制以及由此带来的各种问题。单个 Go 应用也能有效的利用多个 CPU 核，并行执行的性能好。
良好的语言设计 。
执行性能好 。虽然不如 C 和 Java，但通常比原生 Python 应用还是高一个数量级的，适合编写一些瓶颈业务。内存占用也非常节省。
我们也同样意识到这样的问题，所以在OWL V4.0 的版本中，全部统一了语言栈，降低了大家的使用难度，和后期技术栈的维护难度。
方案特点二：定制化自己的图表
上面的架构图中，大家不难发现，整个OWL 的设计核心是Custom Report。将整个系统从以工具为核心，转向 以数据和用户为核心 ，OWL的好处是首先使用者会自己定义感兴趣的数据指标;其次在指标上添加rule，用户可以更专注数据;随后可以做一些简单的数据处理，一些数据加和等这样的简单运算;并且定制不同样式的图表，饼图、柱状图、线图。
在整个监控上形成一个立体的结构，不同层面的工程师可以在同一个层面上工作。
有了好的工具支持，才能让工程师 DevOps 起来 。OWL 新版本中也将会支持Docker的支持，这块目前采用的主要是google 开源的cAdvisor作为数据采集的，通过二次开发将cAdvisor变成plugin集成进入OWL。
方案特点三：报警模块的划分
关于报警方式，目前没有放置在OWL中。在TalkingData，所有的报警采用Message center的方式，Message center有独立的Web，支持基础的信息查询，信息的发送对外采用 restful API暴露给其他的系统，信息的传送方式上，按照消息的优先级程度，采用不同的下行方式，高=短信+企业微信+email;中=企业微信+email;低=email，目前正在考虑加入商业化的呼转服务。 具体详情参见本系列的后续文章：《报警系统的设计与实现》。
总结
OWL 只是TalkingData在DevOps尝试的其中一个平台。如果从长期的角度去考虑，企业构建自己的运维平台，应该 按照云平台的思路去建设，将工程师定义为整个平台的使用者，要简化工程师在基础资源上消耗的时间，降低资源使用的时间成本，这样才会在 DevOps 的路上越走越好。