p/prometheus-gateway/

[giscus[bot]]

p/prometheus-gateway/

近期，我们对 APP 网关 Gateway 做了升级，由于项目创建时间过早（6年前的项目），那时候还没有好的包管理工具，使用的是最原始的 Go Path 来进行项目的依赖管理，历史包袱比较重，项目中很多的第三方引用都是直接将代码拷贝到项目目录下，升级与维护起来特别麻烦，升级之后就是现在官方主推的是 Go module 包管理方式。
解决了上面的这个痛点，网关程序就可以集成一些业界主流的基础工具，升级与维护起来就简单多了。
言归正传，本文主要是讲的我们是如何用 Prometheus 对网关进行监控的，之前我们的网关程序也是集成了我们公司开源打点监控工具 Open falcon，并且使用 Grafana 进行绘图并查看，但是为啥我们不再继续使用了？之后我们为啥拥抱了 Prometheus 生态？还有一些打点、报警、绘图的思考，还有一些我们在使用的过程中出现的问题以及解决方案，一一讲解一下。
抛弃 Open falcon 拥抱 Prometheus 在决定使用 Prometheus 之前，我们的 Gateway 使用的是 Open falcon，但是一直存在着一个对于我们而言的痛点，就是作为网关程序，历史维护的路由太多了，接口可用性及接口报错无法聚合报警，也就是我们的监控体系存在着盲区，这个对我们而言来说是最为致命的，那个接口出现了问题会直接导致用户的使用，并且我们使用的那些上游服务出现问题我们也无法及时感知。
使用 Prometheus 最主要的是我们可以通过 PromQL 语法进行正则匹配，实现对某个或多个接口的聚合计算并报警，这样就可以解决我们无法聚合报警的一个痛点。
打点、绘图、报警 打点 全面、量小 作为业务使用，怎么设计点位，既可以满足报警使用，对每个接口进行各项指标的监控，同时要保证点位数据是可穷举的（避免出现 OOM）和产生数据量比较小。简而言之，就是“监控要全面、打点数据量要小”，因为数据量大的话在 Prometheus 拉取指标的时间及周期就不得不设置的过大，这样的后果就是造成图的绘制缓慢甚至超时，同时报警也失去了实效性。 我们网关使用的是 http 协议，可以充分利用 Go 的 net/http 特性，使用中间件设计，对请求与返回进行打点，于是我们是这样设计的：
对任意一个请求做一个 qps 的打点记录（无任何的业务参与其中）； 对单个路由请求进行打点（区分业务状态码）； 对单个路由请求进行耗时打点（区分业务状态码）。 请求路由按照业界通用的设计：/version/model/action
以上的场景，仅仅使用指标类型中的两种 Counter（计数器） 和 Histogarm（直方图）就可以满足我们打点需求。
绘图 清晰、快速 构建一栋房子所需的材料都准备好了，准备建造， building……
点位指标收集到了，接下来就是对点位进行各个维度的拼装，来呈现我们想要的图，这里解答一下为什么我们要把业务状态码打到指标中去，以及我们是如何使用的：我们的系统设计采用业务封装错误码，只要是传输调用链路没有问题，所有的场景都走业务状态码，类似的返回解决如下：
1 2 3 4 5 6 7 { "code": 0, "desc": "success", "data":{ "result": "ok" } } code 为 0，代表当前请求是正常的，返回数据会封装在 data 中； code 不为 0，代表着当前请求存在业务上可捕获或者自定义的错误。 作为网关程序，与下游微服务采用相同的接口设计，对我们现在的打点设计也是非常友好的。

https://blog.debuginn.cn/p/prometheus-gateway/