标签：
转自：http://chuansong.me/n/1208635
动机
在业务系统开发的初期，我们往往只关注到核心逻辑，而忽略了对系统本身的监控。运维同学提供的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风暴。
标签：
原文地址：http://www.cnblogs.com/cxzdy/p/5259231.html
