天机镜—优土大数据平台应用级别监控利器

　　转自：

　　动机

　　在业务系统开发的早期，我们常常只关注到核心逻辑，而忽视了对系统本身的监控。运维朋友提供的ZENOSS(ganglia)能挺好的满足了我们对硬件资源(IO、cpu负载、内存、load、连接数等)的监控。但介于核心功能与硬件指标之间的系统指标监控是空白的，如服务本身的负载，jvm状态，qps，tps，队列大小，等等。这些数据虽不属业务功能，但是对后续服务扩容，定位问题才能提供良好的根据。

　　天机镜的设计本意就是为解决这部份需求,提供一个轻量级的数据采集接口，采集业务系统的各类指标，并将这种指标以图表的方式直观清晰的呈现下来。也支持对关键指标的实时监控和报案，同时还为用户提供简单的营运报表服务。

　　天机镜上线一年多，历经数次版本迭代，当前已为集团上百个大数据应用场景提供了分钟级指标监控服务，每天搜集5亿条指标数据，分钟级监控数据可持久储存达30天。

　　场景示例

　　kafka全集群负载流量(byte)对比图

　　

　　每个ip表示一个kafka节点,可以直观看出流量是否均衡，是否稳定。

　　Storm应用内存泄漏

　　

　　曲线名称为ip::pid，可以看出106的进程稳定，而107的进程显存到一定值后OOM，然后重启，进程号改变。

　　Web服务页面的响应历时分布

　　

　　p999=0.196...的意义在于在近来的1024个样本中，存在了1~2(0.01%)个190毫秒以上的恳求。可以看出，99.9%的恳求延后基本都在微秒级别，但时常会出现若干190毫秒以上的恳求。你还可以依照p99,p98,p75,p50等指标进行对比。

　　度量

　　天机镜参考Metrics设计了四类统计测度：

　　绝对值：队列大小，缓存使用量,在线用户(通常是一些顿时值)

　　计数：GC次数、出错次数、累计时间，总销售额等(通常是一些求和值)

　　速率：tps，qps，每秒上线都用户数等(通常是一些比值)

　　分布:可以是时间分布，数值分布，如：某恳求调用历时须要 99.99%在100毫秒以下，通过这个指标定义响应性能。

　　监控采集的每一个指标必然属于前面的某一类测度，或是一个值或是一个分布。此外我们还提下来一个场景的概念，不同的业务人员对同一个系统的监控指标关注点会不一样，通过场景的概念，对指标进行分组，方便业务人员查看剖析。

　　数据模型与查询插口

　　数据模型的设计应权衡功能与存取效率，而查询插口须要结合模型直观多元的呈现数据。我们在设计监控数据结构时参考了现实世界的破案手段—现场复原。因为最初的设计动机就是为了快速定位系统出现的问题，寻找案发现场的蛛丝马迹（人物，时间，地点，事件）。对应到程序问题排查就是：（应用，时间戳，进程惟一标识符，指标名称 ，指标值）。

　　我们可以回过头去看里面OOM的事例，在视觉影像完全靠脑补的日子里，只能从黑白控制台北借助丑恶的命令行去查看系统日志。天机镜出现之后，在界面上简单的点击几下，它就可以帮你把现场信息回放下来。

　　存储表：

　　

　　查询插口十分简单，我们须要设定一个条件：时间区间，哪些指标，哪些进程（ip or ip+pid）。另外我们提供了多种展示方法，可以将不同来源的相同指标置于一起比较（例如：负载均衡比较），也可以将同一来源的不同指标置于一起比较 （消息系统流入流出的流量比较，命中与未命中数目的比较）。

　　采集客户端设计

　　采集客户端的设计决定了监控平台的易用性，使用者常常是业务开发人员。对于她们来说，要用最小的成本换来最大的利润。所以在设计客户端时我们从不同的角度考虑了其易用性：

　　1. 轻量化的客户端：对于完成api层面的监控，我们首先要将采集客户端植入寄主应用之中。这里我们选择在client端做轻量化的统计估算，并且开启一个沉静线程每一分钟把当前的估算结果发送到前端储存，监控模块永远都不会影响到寄主程序的运行，即使在网路不通畅的情况下，宿主客户端也感知不到异常的存在。同步监控统计结果很频繁除了会导致前端储存压力过大，也会影响用户应用的性能。更重要的一个前提是，对于实时性需求，1分钟足以。

　　2. 超简单的API：用户最希望的是写一行代码就完成了监控工作，而现实中我们也的确是如此做的。之所以能做到这一点，也正是由于我们梳理出80%的通用需求来设计API，而另外20%个性需求才须要调用较为复杂的API才可满足。另外，有些通用监控是无需设置的，比如JVM相关的各类监控。

　　对于监控数据的搜集，我们的设计目标是：归档时间长，允许遗失，近实时，统计量丰富。可能用一个词汇描述监控数据比较合适：“可视化应用日志”。

　　服务端设计

　　对于简单表结构储存大量数据的场景，Hbase是我们的极佳选择。为了满足天机镜的查询需求，我们在Hbase集群上安装了Phoenix插件。Phoenix支持了类SQL语言，很容易与后端界面集成在一起。

　　对于接收服务器，我们简单的使用nginx+webserver的形式。针对更大的并发量，可以在接收服务器做一些batch以及throttle。接收服务器组件挺好的前馈了采集层与储存层。得益于前馈的设计，天机镜不仅支持Hbase储存之外，还支持了mysql储存。另外对于不同的数据源，接收服务器还可以支持采集jmx监控数据。

　　

　　岂止于监控，数据总是有用的。我们对数据平台的基础服务层做了一定的封装，内置了好多通用指标的监控，这样可以对所有平台的使用者的应用作出大致的资源占用情况监控，比如消息系统的流量贡献、消费与生产消息量的核实、请求量统计、缓存命中率、数据扫描量等等。天机镜开放了数据访问插口，用户可以定做报表，平台管理员可以生成消费资源报表。另外，利用其逾实时（一分钟内）的特点做邮件和短信的报案等等。

　　结论与建议

　　总体而言，天机镜的工作是把应用的运行日志图形化诠释，并且可以按照任何时间以多元形式对比呈现，大大通分了排查问题的难度，同时通过报表也能使我们更直观的了解程序，预警功能防止一些问题的发生。天机镜像是一种描画数据平台生态链各环节状态的数据引擎，当然，这须要悉心设计出一个更好的交互式UI或则报表。

　　客户端

　　需求的梳理，最简单的api满足最大众的需求，如果想兼具，那么必然会使api愈加复杂难用；

　　不需要刻意追求数据的高实时性，增大80%的成本却提升了1%的利润这是得不偿失的；

　　静默，不要由于监控影响了自己的应用运行；

　　服务端

　　做好前馈，这样无论你是扩容升级，还是功能升级，都便于操作；

　　中间件的数据处理策略会使你的基础服务愈发稳定、高效、灵活。

　　存储端

　　Phoenix on hbase可以使你借助sql取代繁杂的scan查询，理解Hbase的储存原理，有助于你设计愈发高效的Phoenix库表，原则是把查询条件的高频数组置于后面。对于更大量级数据的储存，可以采用按量分表，删除操作与追加操作分离，这样可以避免IO风暴。

　　天机镜—优土大数据平台应用级别监控利器