原创:猿天地(微信公众号ID:cxytiandi),欢迎分享,转载请保留出处。
监控这个话题永远都不会过时,之前也有跟大家聊过监控的内容,以及如何快速实现监控满足日常需求。比如基于日志告警,基于全局异常处理器告警,基于Cat,Prometheus,Sentry等告警。
无论公司是什么规模,创业小公司,稳定大公司,你都需要做监控的呀。特别是大公司的监控做的更全,也更在意监控这件事情。小公司相对来说会好点,因为业务可能还不是很稳定,用户少,出故障就出呗,能修复就行。
监控的痛点
有监控总比没监控要强吧,但是监控多了也不见得是件好事。此处的监控多了有两层含义。
含义一:监控体系多或者说监控的框架多
很多时候,公司里的监控五花八门,有Sentry做异常告警,又有日志异常告警。有Cat又有SkyWalking,弄的你怀疑人生,到底用哪个,异常信息各种重复。
o.png唯一的好处就是一有问题,你就慌的不行,怎么这么多异常告警。马上去排查问题了,导致自驱力非常好。
含义二:监控告警量多
监控框架多了,告警的数量自然是翻倍的,这点毋庸置疑。其实更为重要的一点是告警没有做等级划分,一顿乱报,导致告警群里一直有告警信息。有点像狼来了的意思,后面你就懒得去看了,因为太多了。
去.png如何解决痛点
监控体系统一
首先,监控体系要进行整理,采用统一的监控框架。a但很多时候往往某一个框架无法满足所有需求,这种场景下就出现了混合使用,控制的不好就跟前面提的一样,五花八门了。
在某一个监控层面能够覆盖大部分的场景即可。如果不行,可能需要基于已有的开源监控体系进行自研扩展功能了。
告警定级
监控体系统一后,最大的问题就是异常的告警。是否所有的异常需要告警?告警能不能分类定级?
异常分为两种,运行时异常,比如NPE之类的。另一种非常多的就是业务异常,比如库存不足,商品已下架等。
对于运行时异常,一定是第一优先级,因为这就是Bug,需要马上关注并且处理。这类异常往往不会很多,如果非常多,那就是你的代码真的写的不咋的。
告警分类细化
对于业务异常,告警级别可以下降。这类异常虽然不能反馈系统有问题,但是能反馈业务的状态,还是需要稍微关注下。比如电商中最核心的下单接口,1分钟内下单失败100次,这种情况能不关注吗?必须得关注。
业务异常除了降级之外还得分类,这个就需要在抛出业务异常的时候声明对应的code码才行。这样在告警的时候直接带上对应的code码,一看便知什么问题。比如前面将的下单频繁失败,如果你只是告警说下单失败了多少,那么此时你一定很慌,因为你压根就不知道为什么?
还得屁颠屁颠的去看日志之类的,排查报错的真正原因。如果告警时就已经带上了code码 1001,你一看就知道,库存不足了,肯定是某个商品在抢购。code码1002风控校验超时了,马上联系风控的同学进行排查。这样的告警才符合标准,否则太累了。
最重要的是保留好现场数据,也就是出参****和****响应以及traceId,否则谈何去解决这个告警****问题****。
总结
改造完后,只有运行时异常或者某分钟内大量报错才会短信或者电话紧急告警,减少骚扰。其他业务异常等直接走钉钉啊,飞书啊这种告警群即可。告警群也可以细化,划分为需要关注的code和不需要关注的code, 分开不同的群,提高信息的精准度触达和消费。
本文主要讲的还是项目内的异常告警,其他的像一些中间件啊,数据库之类的告警就不用这么分了,这些一旦告警,无论是cpu飙高还是内存飙高都是很严重的问题,都需要关注以及做预案处理。
关于作者:尹吉欢,简单的技术爱好者,《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》作者, 公众号猿天地发起人。
网友评论