共计 1509 个字符，预计需要花费 4 分钟才能阅读完成。
原创：猿天地（微信公众号 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 微服务 入门 实战与进阶》作者, 公众号 猿天地 发起人。
