首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

【升职加薪秘籍】我在服务监控方面的实践(7)-业务维度的redis监控

!! 大家好,我是蓝胖子,关于性能分析的视频和文章我也大大小小出了有一二十篇了,算是已经有了一个系列,之前的代码已经上传到github.com/HobbyBear/performance-analyze,接下来这段时间我将在之前内容的基础上,结合自己在公司生产上构建监控系统的经验,详细的展示如何对线上服务进行监控,内容涉及到的指标设计,软件配置,监控方案等等你都可以拿来直接复刻到你的项目里,这是一套非常适合中小企业的监控体系。

在上一节我们完成了对mysql的监控,这一节我们来讲讲如何对redis进行监控,同样的,我们需要让监控指标更好的反映业务情况,由于我们生产上的服务是部署到云环境的,常见的redis监控指标,云服务商已经提供了,所以没必要重读对其造轮子了。

我们新建立的指标是redis key维度的qps,这样在看到redis 总qps升高时,能一眼看出是哪些key造成的,并根据key定位到具体业务代码。

监控系列的代码已经上传到github

按key维度建立redis监控

要想让redis的监控指标能更好反映业务情况,那就只有按key维度建立监控指标,这样能知道是哪部分业务访问redis最频繁。

想想我们通常使用redis时,建立key的规范,是不是一般都是  服务名:业务名:业务key  这种形式,其中业务key可以是uid,也可以是其他类型id,如果按完整的key建立redis的qps监控,将会导致key维度过多,影响prometheus聚合性能,并且由于key维度过于分散,不好定位到具体业务,所以我们需要在记录指标时,需要将业务key去掉进行记录。比如对key webapp:login:uid1  和 webapp:login:uid2  的操作都将记为webapp:login 对redis的操作,这样便能很好的反映业务访问redis的情况。

下面,我们来看看如何实现这段逻辑。

实现方式

我们的项目用的是go-redis这个库,它提供了一个WrapProcess函数可以在命令执行前后添加一些自定义的操作。如下所示,我在命令执行前记录了对应key的访问次数。其中matchkey则是将应用程序的key排除掉业务key获得最终的只携带业务名的redis key。

matchKey  的实现逻辑是看应用服务传来的redis key是不是在监控的key范围内,是的话,才会对key访问次数进行监控,所有需要监控的key都是monitorKeys 这个切片里保存的。

应用服务会将它需要监控的key写入到monitorKeys 这个切片里,写入时只写业务前缀,像下面这样。

方式弊端

不过上面的方式弊端很明显,那就是需要业务方较大的改动,基本上每次定义redis  key时,都需要手动添加一下到monitor keys里,侵入性比较大,不过我目前还是没有想好特别好的方法让redis比较透明的按业务范围监控key的办法,如果你有任何新的点子,欢迎留言,我们一起探讨探讨。

  • 发表于:
  • 原文链接https://page.om.qq.com/page/OTd1UOZr7xaa_nBTz5yfa1Eg0
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券