被监控轰炸了，不得不使出绝招

点击上方蓝色字体，选择“设为星标”

监控这个话题永远都不会过时，之前也有跟大家聊过监控的内容，以及如何快速实现监控满足日常需求。比如基于日志告警，基于全局异常处理器告警，基于 Cat，Prometheus，Sentry 等告警。

无论公司是什么规模，创业小公司，稳定大公司，你都需要做监控的呀。特别是大公司的监控做的更全，也更在意监控这件事情。小公司相对来说会好点，因为业务可能还不是很稳定，用户少，出故障就出呗，能修复就行。

监控的痛点

有监控总比没监控要强吧，但是监控多了也不见得是件好事。此处的监控多了有两层含义。

含义一：监控体系多或者说监控的框架多

很多时候，公司里的监控五花八门，有 Sentry 做异常告警，又有日志异常告警。有 Cat 又有 SkyWalking，弄的你怀疑人生，到底用哪个，异常信息各种重复。

唯一的好处就是一有问题，你就慌的不行，怎么这么多异常告警。马上去排查问题了，导致自驱力非常好。

含义二：监控告警量多

监控框架多了，告警的数量自然是翻倍的，这点毋庸置疑。其实更为重要的一点是告警没有做等级划分，一顿乱报，导致告警群里一直有告警信息。有点像狼来了的意思，后面你就懒得去看了，因为太多了。

如何解决痛点

监控体系统一

首先，监控体系要进行整理，采用统一的监控框架。a 但很多时候往往某一个框架无法满足所有需求，这种场景下就出现了混合使用，控制的不好就跟前面提的一样，五花八门了。

在某一个监控层面能够覆盖大部分的场景即可。如果不行，可能需要基于已有的开源监控体系进行自研扩展功能了。

告警定级

监控体系统一后，最大的问题就是异常的告警。是否所有的异常需要告警？告警能不能分类定级？

异常分为两种，运行时异常，比如 NPE 之类的。另一种非常多的就是业务异常，比如库存不足，商品已下架等。

对于运行时异常，一定是第一优先级，因为这就是 Bug，需要马上关注并且处理。这类异常往往不会很多，如果非常多，那就是你的代码真的写的不咋的。

告警分类细化

对于业务异常，告警级别可以下降。这类异常虽然不能反馈系统有问题，但是能反馈业务的状态，还是需要稍微关注下。比如电商中最核心的下单接口，1 分钟内下单失败 100 次，这种情况能不关注吗？必须得关注。

业务异常除了降级之外还得分类，这个就需要在抛出业务异常的时候声明对应的 code 码才行。这样在告警的时候直接带上对应的 code 码，一看便知什么问题。比如前面将的下单频繁失败，如果你只是告警说下单失败了多少，那么此时你一定很慌，因为你压根就不知道为什么？

还得屁颠屁颠的去看日志之类的，排查报错的真正原因。如果告警时就已经带上了 code 码 1001，你一看就知道，库存不足了，肯定是某个商品在抢购。code 码 1002 风控校验超时了，马上联系风控的同学进行排查。这样的告警才符合标准，否则太累了。

最重要的是保留好现场数据，也就是出参和响应以及 traceId，否则谈何去解决这个告警问题。

总结

改造完后，只有运行时异常或者某分钟内大量报错才会短信或者电话紧急告警，减少骚扰。其他业务异常等直接走钉钉啊，飞书啊这种告警群即可。告警群也可以细化，划分为需要关注的 code 和不需要关注的 code, 分开不同的群，提高信息的精准度触达和消费。

本文主要讲的还是项目内的异常告警，其他的像一些中间件啊，数据库之类的告警就不用这么分了，这些一旦告警，无论是 cpu 飙高还是内存飙高都是很严重的问题，都需要关注以及做预案处理。

欢迎关注微信公众号：互联网全栈架构，收取更多有价值的信息。