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