同套架构实现监控及选择性数据推送,业务数据一目了然
前言
老板给提的一个需求,希望能打通一套监控链路,能够采集系统的一些业务监控指标,比如想了解用户各个微服务的使用情况,使用时间等信息,4xx / 5xx 错误率,并将一些关键业务指标按需推送到公司的中心仓库,并且展示出来
设计
采集
说到微服务、云原生的监控,大家第一时间肯定想到的是 Prometheus,不过如果有同学用 Prometheus 的 go client 写过推送就知道,这个东西不大好用,推的费劲儿,之前用过一次,但是自从后面用了一次 VictoriaMetrics/metrics: Lightweight alternative to github.com/prometheus/client_golang 这个之后,就再也不想用 Prometheus 的 go client 了,这个是真的简单,而且可以很方便的主动推数据。而 Prometheus 那边是起 Exporter 导数据出来,不好主动去推数据。
和公司写 Java 的佬交流了一下,他们选的也是这个,主要也是因为可以主动推业务数据,这样在请求逻辑里面直接把数据推出来很方便,虽然说 API 都是兼容的,不过咱就直接选简单好用而且性能高的 VictoriaMetrics (可以说是 Prometheus Plus 版)
推送与架构
选定了使用 VictoriaMetrics 之后,我们就可以开始围绕它了做设计,VictoriaMetrics 有着丰富的生态组件,来先看一下官方给的这个图,我们设计也围绕它来走
对于客户侧部署的,我们让开发把数据推送到 vmagent 而不是 victoria-metrics ,而 vmagent 使用 RemoteWriteProtocol(Prometheus 也有这个协议,二者兼容) 再把数据推到两处:
- 客户侧本地部署的 VictoriaMetrics
- 我们自己写的 Go 项目
客户侧本地部署的 VictoriaMetrics 这个很好说,这里存储了用户产生的全量监控指标
而我们自己写的 Go 项目则判断业务侧上来的数据有没有打上推中心仓库的 label (标签),如果有,就在数据里面加上租户名称的 label (方便中心仓库区分是谁的数据),然后对中心仓库本项目的 Go 起的接口推数据,中心仓库接收客户侧推送数据的这个接口实际上是带鉴权的反向代理,目标(源站)是中心仓库的 VictoriaMetrics ,鉴权通过了,就让数据过去,这样可以防止万一接口泄漏了被别人随意推数据
实现难点
对 vmagent 使用 RemoteWriteProtocol 推送上来的数据的解析
为了提高性能,Prometheus 的数据不是使用传统 http 协议推送的,而是类似 grpc ,但是自己搞了一套带高效压缩机制的 protobuf 协议,也就是这个 RemoteWriteProtocol ,我们需要解析该协议推送的数据,修改推送上来的数据(判断是否含有某 label / 添加 label),并重新编码成这个协议推送到中心仓库
具体代码不方便贴出来,这里列出需要使用的库,有需要的同学可以研究一下,重点关注 github.com/prometheus
import ( |
效果
结合之前做的服务器监控项目里面的 Grafana 做展示,下图是中心仓库的数据
由于业务侧的同学都比较忙,目前只有部分模块和页面做了使用次数采集和推送,数据采集上来做了个简单的图表长这样,图中表明 xx 学院部署的微服务“通知 PC 端”在这个时段被访问了 12 次