监控系统-埋点

监控系统顾名思义就是希望对业务系统进行监控，监控大致上分为这么几个环节：埋点、传输、计算、展示。每一个环节具体如何去做，方案如何抉择都是一篇很长的文章，今天就只谈谈关于如何埋点的体会。

通常的来说，埋点主要有三种形式，或者说获取客户端数据有三种方式

1. 动态字节码增强(动态代理) — 约定配置主义
2. 侵入到需要埋点的中间件 — 埋点主义
3. 采集所有的日志数据 — 现象主义

约定配置主义

    先看看第一种，所谓的动态字节码增强有两种方式，其一是在class文件被加载到JVM之前就代理了业务类，其二是在class加载到JVM后，采用cglib等手段来动态代理。这两种方式的目的都是在业务类中埋入监控代码，统计业务类的一些访问数据。这种方式优势在于在业务推进阶段，业务方是无感知的，因为业务方根本不知道自己已经被代理了。
    但是它的缺点也非常明显。首先从OO设计角度看，字节码增强是体现的是继承的思想，业务是基类，代理生成的新类是子类。子类在包含业务类的业务后，添加了自己的监控功能。这种继承思想的设计导致的问题就是，子类一挂，那么基类中的业务也无法执行。也就是说第一个较明显的缺陷，隔离线很差。
    其次，通过字节码增强的方式来操作，那么摆在前面的第一个问题就是，那么类需要被增强？业务方需要知道我的一个service调用redis的统计情况，这个如何处理？有一个简单的方案就是前几年满流行的约定大于配置的思路。业务方在包名上做出一些约定，例如xxxx.xxx.action中存放的是URL的访问请求，框架在代理这些类的时候就明确清楚增强这些类时候需要做什么处理。但是这种约定配置还是基于包层次，但是在同一个包下的业务去访问多个中间件的情况，它还是无能为力的。也就是说无法串联整个系统调用栈。
    第三。若真要动态的侵入监控代码，那么代码实现的复杂程度是非常的高，也就是说这种系统很容易被发展成专家系统，一旦成为专家系统，那么在改专家由于种种原因发生变动的情况，这个系统的维护性就非常的差。做一个系统复杂系统是件很容易的事，做一个简单的系统才是最牛逼的。

优势

• 用户接入无感知
• 格式化的数据

劣势

• 可隔离线很差
• 后期需要大量的依赖配置，可扩展性差
• 无法分析系统调用栈关系
• 系统非常的复杂，后期维护性很差

埋点主义

    埋点主义就是在我们需要监控的中间件中以插件或是过滤器的方式添加监控代码。
    这种方式的缺陷在于，需要对所有关注的中间件进行埋点，在业务推广阶段甚至需要业务进行一定配置上的修改配合。
    优势也比较明显，因为是通过插件或是过滤器方式嵌入，那么本身就是可降级的，在自身发生异常的情况不影响业务的正常流程，是隔离的。

优势

• 隔离线较好
• 格式化的数据

劣势

• 需要在所有需要关注的中间件上埋点，可扩展性一般。
• 业务方需要进行一定的配合。

    整体的说，这是一种相对平衡的做法。

现象主义

    这种做法就是客户端不埋点，也不侵入，需要拉去客户端所有的日志信息。至于日志信息到计算集群后如何解析由业务方在管理平台平台进行配置。
    显而易见，现象主义对于业务方是零侵入的，只负责拉取全量的日志，至于日志怎么解析全部交给业务方自己定义，是一个纯粹的数据收集、计算、展示平台。通过业务方的配置，获取一些日志信息的统计，由这些统计信息去推荐系统的问题所在，这个也就是它号称现象主义的缘由。
优势

• 零侵入
• 可扩展性非常的强

劣势

• 业务方有较高的一次性学习成本
• 无法分析系统调用栈关系
• 无法做容量规划

以上三种在业界都有自己的实现

约定配置主义 — 网易的哨兵系统
埋点主义 — B2B的 dragon、淘宝的鹰眼、点评的CAT
现象主义 — 支付宝的xflush

回到我们自己的业务场景，我们希望我们的监控能够满足以下三个需求

1. 系统、业务监控
2. 快速的问题排查
3. 系统架构梳理及容量规划

满足需求的前提下，最终我们选择了相对平衡的一种做法，也就是埋点主义的做法。