【监控】数据平台运营实战之如何打造应用级别的监控系统

　　本文介绍了如何设计监控系统的客户端包、后端服务以及存储的解决方案。

　　传统IT公司可能最核心的应用就是Web服务器和各类Web应用。得益于开源系统以及大数据理念的盛行，大大小小的公司逐渐造成了数据采集、存储、计算一体化的类似而又不一样的架构。而在这些架构之上，咱们能够丰富本身主营业务或者产品线的各类应用，或者说，技术团队有了这样的平台，咱们能够更加方便的搭建各类应用程序。之前咱们仅仅比较关注基础设置层面的监控(好比：服务器的load、内存使用、磁盘使用、CPU使用，像ganglia，zenoss就有这样的监控功能)，在这些趋势的影响下，除了基础设施以外，咱们不得不着眼于平台层面和各类应用的监控。

　　有人说，之前咱们也关注Web应用的QPS、PV等等，但那个时候监控更多的是本身单独实现的几个指标统计。今天咱们换个角度去审视监控的问题：如今咱们平台上运行着各类各样的应用，这些应用有本身的运维或者开发人员，平台运维与应用运维须要各司其职，那么问题来了：如何保证他们能够很好的协做，又不互相干扰？

　　上面的图就表示了平台和应用分工的状态。试想一下，若是应用开发者的程序出现Bug或者有性能问题就跑过来问平台运维人员：“是否是你的服务端没数据？”，“是否是服务器挂了？”，因而平台运维人员就要费劲的查明真相，那一定会浪费你们的时间。因此最好的方式就是让双方都能了解本身负责的程序的状态如何，那么监控就是最好的方式，确切的说，是一个支持多用户的监控平台。

那么，搞清楚需求，就能够开工了。须要从何搞起呢？我先根据本身的经验列个清单，不全的各位帮我补充。

1. 监控数据的模型
2. 采集监控数据
3. 存储监控数据
4. 展现监控数据

咱们先一步一步来，根据需求，须要什么信息（监控数据模型），而后在去实现如何获取这些数据（采集），以后就是存储，数据到手后，无论你是报表也好，曲线也好，实时预警，离线分析其实都不是问题。步步为营，且听我细细道来。

监控数据的模型

　　首先要考虑面向什么？是面向应用，仍是面向用户？如今企业里离职率那么高，并且工做都是以负责的应用为准的，而且咱们YY之后监控平台作大作强对外开放，那么仍是面向应用吧！（一我的当五我的用的挨踢狗团队除外！由于一我的负责那么多应用了就只用面向人设计就好了，否则每一个应用都要记住一些信息，本身看的累。。哈哈，你们不要介意，这是自黑！）。OK，面向应用去设计这条路很对，能够避免不少问题。那么，若是对于一个应用来讲，它须要监控什么呢？试想一下，应用监控其实分了不一样的角度，好比：我要监控它的性能负载，也要监控它的数据量是否有丢失，这实际上在描述两个不一样的关注角度。也就是说，一个应用分了多个监控场景，为何要这么区分呢？答：为了之后展现起来更容易理解，并且监控指标的扩展更加方便。那么，还须要什么？想象一下，其实监控数据的本质是日志，咱们之前排查问题就是看日志的。日志的基本行为就是：追加 三元组（时间，地点，事件）。因此，咱们把监控数据看作是一个日志文件，他的字段以下：

appID: 应用的惟一标识 sceneID：场景ID，应用下面的惟一标识 timestamp：时间戳 location：汇报该指标所在的位置，能够是一个ip，也能够是一个ip+端口，也能够是用户自定义的一种特定标识 dimValue：具体指标名称，好比在负载场景下，具体指标就有：QPS，刷磁盘速率，Buffer大小等等 kpiValue：对应指标的值，能够是速率类型的，也能够是百分比类型的，也能够是个绝对值大小

如此一来，你就能够根据这些标准格式的日志数据去排除应用程序出现的问题，固然了，若是你采集的足够实时，彻底能够作到预警。固然，如何展现数据，决定了你工做效率的高低，图形曲线或者饼图多是很是好的选择，性能指标的走势看起来像股市曲线同样爽，固然不能YY太早，数据展现尚未具体分析，我将会在下文提到。

采集监控数据

　　咱们搞清楚须要什么数据了，但数据怎么来呢？采集，是张口就来的方案，最好的方式就是不动一行代码就能够抓取想要的数据。你当计算机是你肚子里的蛔虫呢？那不可能。不入侵原来应用的代码，彷佛是全部开发人员的共同需求。可是既然通用就必需要有个标准，摆在你面前的只有两条路：要么改代码，要么改代码。你此时心中必定万匹草泥马奔腾，但事实就是如此：要么改代码标准化本地log的规范，使得抓取程序能够读取完成统计和计数的功能；要么入侵代码，使用简单的API直接调用便可完成统计和汇报数据。你选择哪一个？后者能够保证应用开发人员改动最小的前提下完成更多的功能。不明白吗？我给你讲一下具体怎么实现。

 

　　具体的效果就是如上图所示，App1使用了监控客户端包以后，那么它会自动的汇报一个sce_load(负载监控场景)中的qps（表明近一分钟内平均访问次数）指标，100机器上测得的是9120，即每秒会有9120次访问。“QPS”彻底是用户本身取得名字，他知道其含义，而监控的客户端包仅仅负责汇报数据。

　　那么看到这里，你必定会有不少疑问：9120是什么含义？如何让它能计算出这个数据？汇报时隔一段时间汇报仍是一直在汇报？OK，咱们先理一下，首先，咱们既然入侵了代码，那么这个监控客户端包就要老实一点，咱们的经验是一分钟汇报一次便可。并且，计数的代价要很是低，具体实现就应该是本地计数而已，汇报时须要异步的去读取本地内存中的统计数据，而后在一个deamon线程里面去发送数据。

　　数据的含义也须要标准化，其实开源的java metrics(或者了解一下jmx)给咱们提供了很是好的方案，它的数据统计类型仅有五种：速率、计数、绝对值、时间分布、数值分布。分别举例说明：速率即便某种方法调用次数，计数就是累加呗，绝对值便是队列大小，时间分布便是方法调用耗时所占总调用次数某个百分比的都在多少以上。。这个有些绕，好比吧50%以上调用都在700毫秒之下，那么xxxx_p50 = 0.7，xxxx是你本身取得指标名称。

　　另外，做为一个包而言，并且要很是的易用:

MonitorClient client = MonitorClient.getInst("App1","sce_load"); public void yourVisitFunc() { client.someKindOfStat("qps") ..... ...... }

只要在你的方法中嵌入了这一行client.someKindOfStat("qps")，那么上面的统计都可实现。具体统计方法，你要理解一下java metrics的客户端使用才能理解。剩下的乱七八糟的就是API封装啊，依赖包避免冲突啊，就像log4j这种你要搞成provided。

存储监控数据

Table Rolling示意图

　　上文提到，咱们的监控数据实际上就是日志。日志是怎么定义，其实就是append，仅此而已。而且经过设计它的数据模型咱们知道，这是一张包含了六个字段的大表且非稀疏表。另外它的存储时效可能有一些要求，由于咱们会要求分析历史数据。查询通常须要带上5个字段（kpiValue字段除外）。如今的选型其实没有什么特别，用MySQL能够，用Phoenix也能够。MySQL的话须要按照时间分表，由于一张表太大了查询写入都会变慢。Phoenix就没这个问题了，它基于Hbase，而且支持SQL语言，是很是理想的选型。然而咱们如何清理数据呢？这里须要指出一个问题，大量的删除HBase的数据会致使他在一次Major compaction的时候IO拥堵，由于他的删除只是作了墓碑标记，都是统一作合并时才完全删掉的。对于这个问题我多介绍一下经验，能够从日志结构的特色去设计存储结构。那就是作Table rolling，顾名思义，table就像日志文件同样，随着时间rolling起来。为何要这么作呢？是由于咱们批量删除的数据具有时间特征，也就是说在Table Rolling的设计下，咱们能够巧妙的删除之前的一整张表，而不是删除一张大表中的某些数据，这样作Major Compaction的时候就不会影响当前追加表的性能了。理解Table Rolling的设计前提是理解日志结构。

　　严谨的你确定以为缺点什么，由于直接让全部的客户端直接写入HBase或者MySQL的架构是有问题的。YY一下，若是咱们的平台应用成千上万，这么多的Hbase客户端链接必定会搞垮整个集群。因此，须要一个接收数据的服务端去完成任务，那就是Nginx+Webserver。定义好监控数据的报文协议，好比定义一个嵌套好的Json，Client异步的批量发送Json，而后经过Nginx转发给无状态的Webservers，Webserver负责解析并入库。基本的优化思路就这些了，负载均衡，批量写入等等，技能无他。

　　存储这块总结起来两点：理解日志的含义，适当加一些中间件。

展现监控数据

　　最最决定其意义的环节到来了，那就是如何将这些有意义的数据呈现给用户呢？总结起来：可交互的UI+带有分析的报表。

　　

 

　　上面的图片即显示了一个交互式查询的线框。上面有时间范围的选取、按照指标名称仍是按照主机名称的分组、选择具体的指标（维度）、选择具体的主机等等，这样，用户能够查看其关注指标在时间上的走势。这个图其实做用很是大，开发者所关注应用的某个方法调用频次，方法耗时，以及Buff队列大小等等均可以观看，另外，经过两条曲线比较能够作到核对数据的功效。总之，各类应用场景待挖掘。在此推荐一下highcharts，很是好用的控件，构造曲线图真的是分分钟。

　　另一个比较值得关注的数据产出是表报，你能够给你的Boss看，也能够利用报表去了解峰值出现时段等等。只要你能写出来的SQL，按期运行就有优质的产出。

　　另外值得一提的是，监控平台的数据是很是有价值的，你彻底能够定义好Server API开放给平台用户，让他们本身去定制报表。这样，省的他们成天来找你提需求。做为一个平台运维开发人员，不须要那么拼的~

系统架构图

 

　　最后回过头来总结一下，平台应用程序利用监控的Client包实现了应用级别的监控，静默的吧统计信息发送到Webserver，Webserver入库以后，用户能够经过交互式查询和离线分析的方式去了解本身的应用情况，用户也能够经过监控数据的API服务接口定制本身的产出报表。这样一个监控系统就搞定了，固然了，面向App的设计须要你维护一些用户与App的关联信息。建议你好好考虑一下ACL设计，若是你设计的足够好，有助于你将监控平台化，若是你不太明白，那么就看看我后续的文章吧。