通过埋点实现代码层面上报Prometheus

一、活在当下，脚踏实地

在上一篇文章中，我给大家介绍了Prometheus、Grafana的一些基本概念，并提供了腾讯云上部署方式。相信大家已经对整个流程有了一定理解。不过，按照文章实操的同学肯定还是有一些疑问，这些Metrics（指标）是哪里来的呢🤔️？为什么我的Grafana上就没有指标？本文就是在上篇文章的基础上给大家介绍一些干货，让大家也可以自定义的上报指标，让代码监控真正的达到落地。如果没有读过之前文章的，传送门：一文搞懂Prometheus、Grafana（含腾讯云上实战）

二、兵马未动，粮草先行

俗话说巧妇难为无米之炊，我们想通过代码自定义上报Prometheus也是有前提的，而这个前提就是需要我们在代码脚手架里引入Prometheus。因为作者日常工作中主要还是使用golang和java，所以在这里针对gin、springboot各提供一种引入Prometheus的方式。

1.golang的方式

go-gin-prometheus是一个针对gin脚手架做的指标监视器，github地址：go-gin-prometheus(https://github.com/zsais/go-gin-prometheus

README中有一些demo，有需要的同学按照教程引入～

2.java的方式

SpringBoot接入prometheus相对于简单一些，官方文档：prometheus官网接入SpringBoot方法

当然网上也有大量的文章，可以参考：Spring Boot 使用 Micrometer 集成 Prometheus 监控 Java 应用性能

三、埋头苦干，放眼全局

在完成了代码的Prometheus接入后，我们便可以在代码中自定义的埋点啦。现在在代码里埋进去的点，便是我们后续在Grafana中看到的指标啦～埋点的方式，上一节的文章中都是有的，大家参考食用。现在就是埋头苦干的时候啦，现在埋的点越多，将来我们能获取到的指标也就越多～

那为什么还要放眼全局呢？其实我是想为大家提供一些我指标上报时候的一些小思路，借此抛砖引玉。

在实际用户场景中，业务越复杂，服务之间的调用链也就越复杂。当用户给我们反馈说服务响应缓慢时，我们很难找到具体是哪个接口相应缓慢。针对这一场景，我们就可以通过对服务的响应时间加上指标来实现接口响应时间的监控。这里我利用的是Counter的方式，代码如下：

图1:业务方法运行完调用方法上报时间

图2:针对不同时间上报

图1代码位于要获取响应时间的接口的开始。我在接口处首先创建开始时间starTime，然后通过defer去调用图2中的TimeCostMonitor方法，并给方法提供区分具体接口的module和method参数及接口开始响应时间starTime。在图2的方法中，再次获取一个新时间，两个时间相减获取到业务逻辑处理使用的时间。然后通过不同的指标名称去上报响应时间。即：响应时间少于10ms的，通过指标_ReqTimeLessThan10ms进行上报；响应时间大于10ms，小于100ms的，通过指标_ReqTime10msTo100ms进行上报......

通过这样的方法，再每次接口处调用工具方法TimeCostMonitor，既可以将整个服务所有的接口的响应时间进行归纳上报～

四、硕果累累，满载而归

有了这些指标，我们就可以在Grafana上配置仪表盘啦～

配置仪表盘

配置仪表盘总览

按照上图配置仪表盘的思路将仪表盘配置起来，就得到了下图，之后我们就可以通过Grafana全面了解我们接口的响应时间啦～

成果展示

参考资料

• https://github.com/zsais/go-gin-prometheus
• prometheus官网接入SpringBoot方法
• Spring Boot 使用 Micrometer 集成 Prometheus 监控 Java 应用性能

本文章采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。

原作者： yuann，欢迎转载，但请注明出处。

原文链接：《通过埋点实现代码层面上报Prometheus》

发布日期：2021-03-02