再谈服务异常监控(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 人发表留言,猛击->> 这里<<-参与讨论. —软件人才免语言低担保 赴美带薪读研.

Redis服务器监控工具redis-live

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

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

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

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

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

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

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

监控Tomcat方案调研(监控应用服务器系列文章一)

- - 博客园_首页
前言: 最近在做一个监控应用服务器(Tocmat、WebSphere、WebLogic)的项目,目前已小有规模,回头看看,一路走来,也算是磕磕绊绊,遇到过种种问题,走过不少弯路,不过程序员最不怕的就是遇到问题——有什么问题就解决什么问题. 为了给后来人留下点经验之谈,助之少走弯路,特意把这些经验整理出来,与大家分享.

Linux服务器的16个监控命令

- - inJava
想不想知道你的服务器到底在干什么?那么你要知道本文介绍的这些基本命令. 一旦你熟悉掌握了这些命令,就为成为专业的 Linux系统管理员打下了基础. 你可以通过图形化用户界面(GUI)程序来获取这些外壳命令提供的大量信息,具体取决于使用哪一种Linux发行版. 比如说,SUSE Linux就有一款出色的、图形化配置和管理工具YaST,KDE的KDE System Guard同样很出色.

你需要知道的 16 个 Linux 服务器监控命令

- - 水煮沉浮
如果你想知道你的服务器正在做干什么,你就需要了解一些基本的命令,一旦你精通了这些命令,那你就是一个 专业的 Linux 系统管理员. 有些 Linux 发行版会提供 GUI 程序来进行系统的监控,例如 SUSE Linux 就有一个非常棒而且专业的工具 YaST,KDE 的 KDE System Guard 同样很出色.