再谈服务异常监控(9.3)

标签: SOA架构实施 | 发表时间:2019-09-03 11:07 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
实际上对于服务运行期间的异常监控,我们在前面已经定制开发了类似业务系统异常查询,业务异常监控告警,服务心跳监控等诸多的功能,今天还是要考虑下如何将这些监控功能进一步做到自动化异常监控推送。

初步的思路就是对于业务系统异常监控,系统异常监控,心跳监控等当前拆分的各个功能,设定进一步的异常监控规则,将每天需要关注的异常情况统一输出到一张异常监控报表中。对于异常监控报表主要包括了省份,业务系统,服务英文名,中文名,异常信息,告警时间。

异常监控报表可以每5分钟运行一次,所有写入到这种异常报表中的数据都应该有邮件通知功能,对于通知的时间间隔也可以做到灵活通知。原则就是我们当前要手工去见监控和发现的内容都能够通过监控告警推送出来。

业务系统提供的服务大面积出现异常

要注意,如果业务系统提供的单个服务出现异常,我们一般不会马上通知业务系统,但是如果是大面积的服务都出现异常,那么则可能是业务系统本身出现了严重故障,必须第一时间进行通知。而且这种通知本身还需要进行区分,究竟是业务系统异常还是ESB导致的系统异常。

异常标题:业务系统异常
异常内容:某某系统出现大面积的服务提供方异常
计算时间:开始时间-结束时间
计算规则:业务系统提供的服务中出现业务系统异常服务>60%同时业务系统服务本身的异常率>80%。

Token和授权类系统异常

对于系统异常,如果是ESB系统级的异常将在心跳监控中出现告警,因此在这里主要分析两种系统异常类型,一种是Token系统异常,一种是服务访问授权异常。对于这两种系统异常。

异常标题:Token异常或服务访问授权异常
异常内容:某某系统出现Token访问异常,某某系统出现服务访问授权异常
计算时间:开始时间-结束时间
计算规则:统计区间出现Token访问异常调用量大于80%,出现服务授权异常大于80%且调用次数>100次

对于服务授权类异常,如果调用次数较小的没必要通知,否则影响到异常报表关键信息的查看。如果是5到10分钟的时间间隔,建议是调用次数>100次的才进行异常提示。而对于Token异常则必须立即提示。

大数据量和长耗时异常

对于大数据量,主要是要分析是否在最近的一个时间间隔里面出现了某个服务的大数据量调用,如果出现则需要高度重视和分析。具体的分析为:

异常标题:大数据量调用异常
异常内容:某某系统提供的某某服务出现大数据调用异常,消费方为
计算时间:开始时间-结束时间
计算规则:单个服务的数据调用总量>200M,具体可配置

长耗时异常则需要考虑单位时间扩大,一般我们可以分析最近1个小时的服务运行时长进行分析,因为一个短时间间隔出现的长耗时调用往往并不能明细说明问题,这个只应该统计工作时间段即可。

异常标题:长耗时调用异常
异常内容:某某系统提供的某某服务出现长耗时调用异常,平均时长>多少秒
计算时间:开始时间-结束时间
计算规则:服务平均时长>10秒,且运行次数>50次,即可以进行通知

ESB系统内部异常预警

对于ESB系统内部异常主要是指整个ESB应用服务器集群出现访问变慢,系统异常或访问超时的情况。对于内部异常我们当前主要来源于两个方面的信息监控,一个是本身的业务系统异常查询中出现的系统级异常错误,一个就是心跳监控里面我们原来设置的分钟级超时信息。

异常标题:ESB内部异常告警
异常内容:ESB系统内部出现异常,异常次数,分钟告警数多少
计算时间:开始时间-结束时间
计算规则:系统异常次数>1%或分钟级告警次数出现率>80%,每次出现均大于3次。

ESB系统内部异常预警是最后一道关口,实际上对于这块的异常告警必须具备提前告警能力,而不是事后再进行故障告警。如果当期计算规则无法满足,则应该增加JVM内存监控的计算规则同时进行计算。

心跳监控异常

对于心跳监控异常,则是对业务系统提供的原始服务进行心跳监控,其中包括了连通性检查和服务检查两个维度,对于这两个维度都可以进行异常监控和通知。

异常标题:业务系统心跳监控异常
异常内容:某某系统原始服务出现心跳检查异常
计算时间:开始时间-结束时间
计算规则:连通性检查失败率>80%或服务检查失败率>80%

 

相关 [服务 异常 监控] 推荐:

再谈服务异常监控(9.3)

- - 人月神话的BLOG
实际上对于服务运行期间的异常监控,我们在前面已经定制开发了类似业务系统异常查询,业务异常监控告警,服务心跳监控等诸多的功能,今天还是要考虑下如何将这些监控功能进一步做到自动化异常监控推送. 初步的思路就是对于业务系统异常监控,系统异常监控,心跳监控等当前拆分的各个功能,设定进一步的异常监控规则,将每天需要关注的异常情况统一输出到一张异常监控报表中.

服务监控脚本

- - Linux - 操作系统 - ITeye博客
已有 0 人发表留言,猛击->> 这里<<-参与讨论. —软件人才免语言低担保 赴美带薪读研.

搭建前端异常监控系统

- - 掘金 架构
收集前端错误(原生、React、Vue). 利用Egg.js编写一个错误日志采集服务. 编写webpack插件自动上传sourcemap. 利用sourcemap还原压缩代码源码位置. 代码上线打包将sourcemap文件上传至错误监控服务器. 发生错误时监控服务器接收错误并记录到日志中. 根据sourcemap和错误日志内容进行错误分析.

Spring Boot + WebSocket 实时监控异常

- - 掘金 后端
原文:cnblogs.com/jae-tech/p/15409340.html. 此异常非彼异常,标题所说的异常是业务上的异常. 最近做了一个需求,消防的设备巡检,如果巡检发现异常,通过手机端提交,后台的实时监控页面实时获取到该设备的信息及位置,然后安排员工去处理. 因为需要服务端主动向客户端发送消息,所以很容易的就想到了用WebSocket来实现这一功能.

Redis服务器监控工具redis-live

- - 企业架构 - ITeye博客
Redis服务器监控工具redis-live. 413 views     comments 暂无评论. 目前来说,越来越多的使用多了NOSQL的业务,但是这方面的监控缺不多. 今天给大家介绍几个专业监控redis服务的工具,便于大家进行redis性能分析. 这个工具是用ruby语言写的,ruby是小鬼子弄出来的,个人真心觉得比较难用.

谈SkyWalking进行服务链监控(12.27)

- - 人月神话的BLOG
在谈Nacos服务注册的时候,刚好看到了Skywalking分布式追踪系统,而这个本身也完全可以用于微服务架构里面的服务链监控上面. 对于APM应用性能监控工具有很多,常说的主要是类似Zipkin, Pinpoint, Cat等,而Skywalking是国产的一款开源APM工具软件,包括了包括了分布式追踪、性能指标分析、应用和服务依赖分析等.

Spark Streaming + Elasticsearch构建App异常监控平台

- - 美团点评技术团队
本文已发表在《程序员》杂志2016年10月期. 如果在使用App时遇到闪退,你可能会选择卸载App、到应用商店怒斥开发者等方式来表达不满. 但开发者也同样感到头疼,因为崩溃可能意味着用户流失、营收下滑. 为了降低崩溃率,进而提升App质量,App开发团队需要实时地监控App异常. 一旦发现严重问题,及时进行热修复,从而把损失降到最低.

前端异常监控解决方案研究

- - 腾讯CDC
前端监控包括行为监控、 异常监控、性能监控等,本文主要讨论异常监控. 对于前端而言,和后端处于同一个监控系统中,前端有自己的监控方案,后端也有自己等监控方案,但两者并不分离,因为一个用户在操作应用过程中如果出现异常,有可能是前端引起,也有可能是后端引起,需要有一个机制,将前后端串联起来,使监控本身统一于监控系统.

使用meerkat进行服务监控和服务降级

- - SegmentFault 最新的文章
meerkat 是爱奇艺移动服务端团队开发的服务监控以及服务降级基础组件,主要为了解决调用外部接口的时候进行成功率,响应时间,QPS指标的监控,同时在成功率下降到预设的阈值以下的时候自动切断外部接口的调用,外部接口成功率恢复后自动恢复请求. 本文将对使用方式以及进阶特性进行介绍. 项目主页: https://github.com/qiyimbd/me....