低成本rpc应用监控

为什么要监控

1. 当服务越来越多时， 并且不仅满足于服务是否挂可用， 而是服务是否好用时， 就有了监控
2. 开发肯定不会无时无刻关注自己的服务， 需要一个工具， 在服务出问题时， 及时通知， 并且可以给予一定的线索帮助解决问题。

业界成熟实现

业界比较知名的 比如 阿里的鹰眼, 点评的 cat, 还有 google 的 dapper

共同点

1. 调用链追踪
2. 存在一定的延迟
3. 不占用 应用 的资源
4. 需耗费大量的机器做运算， 存储

隐患

1. 有时随着服务的规模的扩大， 为了减少io 负荷， 不得不进行采样, 而采样则会耗费 应用的资源
2. 计算资源不足时， 遇到突发大量数据时， 会导致整体计算延迟。

绝对优势

1. 即使有一个 订单遇到问题， 可以根据调用链， 追根溯源， 看到该笔订单详细的调用信息 (这在追查某些小概率发生的事件上有非常重要的价值)

trade off

在监控上， 占用应用的资源的多少， 也决定了监控系统自己耗费资源的多少。

举个例子， 如果在 应用内部 不做采样， 不做汇总统计， 每一条 数据都 落到 监控系统的存储上， 那资源耗费是很厉害的。

但是， 如果 应用内部 可以把 最近10秒钟的 状态 汇总成 一条 数据 落给 监控系统, 那监控系统耗费的资源就可以非常非常节省了。

ps: cat 其实就内部开放过一个接口， 对大流量接口，支持 自定义采样/汇总 减少后端压力。

低成本解决方案 - 缘由

启发的话来自 hyxtrix dashboard

他做了什么， 他做了一个实时的后台， 用以实时观察服务当前状态

他解决了什么, 每 10 秒钟 统计， 并且输出一下内容:

1. 服务的 每台机器 的 实时的 qps (吞吐)
2. 服务的 每台机器 的 实时的 succ, timeout, fail, reject 数 (总和等于吞吐)
3. 服务的 每台机器 的 实时的 tp 9999, 999, 95

他的本质作用其实 就是给 hyxtrix 内部的 熔断器 判断是否熔断的依据。 (阿里的限流中间件也是类似原理)

由于， 我们的 rpc 也有熔断器， 原理和他类似， 所以, 服务想着也可以直接用他的后台， 把内部的 metric 数据搞成他的格式， 用他的后台展示， 但是发现其实意义不大。

存在的问题

1. 我作为一个开发不可能实时看服务， 历史数据无罗盘， 没意义。

低成本解决方案 - 需求

其实上面缺少的就是一个存储。

至于为啥， 突然想到 想要把他存储起来， 是因为 线上遇到了一个之前没遇到过的问题。

为了解决这个问题(收集证据)， 我把 上面的 metric 数据 收集到 influxdb 中，然后用 grafana 展示。

最终发现了是 机器存在问题。

进而发现， 其实 这个很低成本的解决方案 对于 小公司来说， 其实是一个性价比很高的方案。



低成本解决方案 - 总结

这个 rpc 监控， 有以下几部分组成

1. 数据采集
   1. rpc 框架收集每一次调用的 状态以及耗时。 交由内部 rxjava 流处理。
   2. rxjava 流可以提供多个输出, 供内部使用
      1. 每个rpc 接口实例级别的 每秒 的 qps， tp
      2. 每个rpc 接口实例级别的 每10秒 的 qps， tp
      3. 每个rpc 接口服务级别的 每秒 的 qps， tp
      4. 每个rpc 接口服务级别的 每10秒 的 qps， tp
2. 数据收集
   1. 通过一个 consumer 实例， 收集 每一个应用的 metric 写入到 influxdb
3. 数据展示
   1. 用 grafana 展示
      1. 支持展示 每一台机器 的 服务级别 的 qps, tp， 以及与 历史(昨日／上周)的比较

自己通过实践用来解决的问题

1. 检测线上个别物理机不稳定的情况
2. 查 历史的 某一次 服务慢， 是因为哪一个接口慢导致的。

低成本解决方案 - 展望

1. 其实现在随着每一个服务都需要接入 限流， 熔断 等保命的模块， 它们都依赖内部的数据采集。 我们不应该 以拿来主义， 而是稍加改造， 全部用自己的 数据采集 作为数据依据， 适配 现有的开源的 限流， 熔断 框架, 以便省略不必要的重复统计。

2. 业界该出一个 上面说的 通用的 内部数据采集规范, 如果大家都适配这么个规范， 中间件产品开发的效率又可以提升不少。

有时间打算自己撸一个。