Gin框架接入Prometheus,grafana辅助pprof检测内存泄露

prometheus与grafana的安装

grom接入Prometheus,grafana-CSDN博客

Prometheus 动态加载

我们想给Prometheus新增监听任务新增ginapp项目只需要在原来的配置文件下面新增ginapp相关metric

在docker compose文件下面新增

执行

复制代码
docker-compose up -d 

curl -X POST http://localhost:9090/-/reload

granfa配置新的job

配置golang dashboard模版

配置之后我们看以在dashboard看到

Gin框架中间件配置

复制代码
package initialization

import (
	"awesomeProject3/middware"
	"awesomeProject3/router"
	"github.com/Depado/ginprom"
	"github.com/gin-gonic/gin"
	_ "net/http/pprof"
)

func Routers() *gin.Engine {
	r := gin.New()
	r.Use(middware.GinRecovery(true), middware.GinZapLogger())
	r.Use(middware.Cors())
	router.InitOrderRouter(r)
	p := ginprom.New(
		ginprom.Engine(r),
		ginprom.Subsystem("gin"),
	)

	r.Use(p.Instrument())
	return r
}

pprof配置

复制代码
package router

import (
	"awesomeProject3/api"
	"github.com/gin-gonic/gin"
	"net/http"
	"net/http/pprof"
)

func InitOrderRouter(Router *gin.Engine) {
	Router.GET("/health", func(c *gin.Context) {
		c.JSON(http.StatusOK, gin.H{
			"code":    http.StatusOK,
			"success": true,
		})
	})
	// 定义一个简单的GET路由
	Router.GET("/v1/ping", func(c *gin.Context) {

		c.JSON(http.StatusOK, gin.H{
			"message": "pong",
		})
	})

	Router.GET("/test", api.TestHandler) //

	pprofGroup := Router.Group("/debug/pprof")
	{
		pprofGroup.GET("/", gin.WrapF(pprof.Index))
		pprofGroup.GET("/cmdline", gin.WrapF(pprof.Cmdline))
		pprofGroup.GET("/profile", gin.WrapF(pprof.Profile))
		pprofGroup.GET("/symbol", gin.WrapF(pprof.Symbol))
		pprofGroup.GET("/trace", gin.WrapF(pprof.Trace))
		pprofGroup.GET("/allocs", gin.WrapH(pprof.Handler("allocs")))
		pprofGroup.GET("/block", gin.WrapH(pprof.Handler("block")))
		pprofGroup.GET("/goroutine", gin.WrapH(pprof.Handler("goroutine")))
		pprofGroup.GET("/heap", gin.WrapH(pprof.Handler("heap")))
		pprofGroup.GET("/mutex", gin.WrapH(pprof.Handler("mutex")))
		pprofGroup.GET("/threadcreate", gin.WrapH(pprof.Handler("threadcreate")))
	}
}

模拟内存泄露

之前我们生产项目中出现过一次严重的内存泄露,例子如下图所示,该接口qps非常高

对当前接口压测

pprof监控

Grafana监控

我们看到goroutine数量已经爆表了,我的mac风扇开始转了

这个时候可以点击pprof groutine很好定位哪一块出现了内存泄露

结论

我们在使用golang 高并行处理下游任务的时候,一定要对下游基础设施要有敬畏之心,调用时限制goroutine的运行数量并且设置上context超时控制,做好超时熔断措施,做好监控警告,下游基础设施如果达到瓶颈,我们可对下游基础进行主从 水平扩容等。

相关推荐
stark张宇2 天前
微服务架构必备:Gin + gRPC + Consul + Nacos + GORM 打造用户服务
微服务·gin·grpc
刀法如飞4 天前
一款Go语言Gin框架MVC脚手架,满足大部分场景
go·mvc·gin
龙码精神5 天前
前端嵌入Grafana 报表的自定义方案:隐藏导航栏保留筛选工具
grafana
花酒锄作田5 天前
Gin 框架中的规范响应格式设计与实现
golang·gin
Cherry的跨界思维6 天前
【AI测试全栈:质量】47、Vue+Prometheus+Grafana实战:打造全方位AI监控面板开发指南
vue.js·人工智能·ci/cd·grafana·prometheus·ai测试·ai全栈
AC赳赳老秦6 天前
云原生AI故障排查新趋势:利用DeepSeek实现高效定位部署报错与性能瓶颈
ide·人工智能·python·云原生·prometheus·ai-native·deepseek
予枫的编程笔记6 天前
【Kafka高级篇】Kafka监控不踩坑:JMX指标暴露+Prometheus+Grafana可视化全流程
kafka·grafana·prometheus·可观测性·jmx·kafka集群调优·中间件监控
AC赳赳老秦7 天前
预见2026:DeepSeek与云平台联动的自动化流程——云原生AI工具演进的核心引擎
人工智能·安全·云原生·架构·自动化·prometheus·deepseek
认真的薛薛7 天前
13.k8s中Prometheus监控集群及其服务,endpoint暴露服务,es采集k8s日志
elasticsearch·kubernetes·prometheus