再谈服务异常监控(9.3)

实际上对于服务运行期间的异常监控，我们在前面已经定制开发了类似业务系统异常查询，业务异常监控告警，服务心跳监控等诸多的功能，今天还是要考虑下如何将这些监控功能进一步做到自动化异常监控推送。

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

异常监控报表可以每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系统内部异常预警是最后一道关口，实际上对于这块的异常告警必须具备提前告警能力，而不是事后再进行故障告警。如果当期计算规则无法满足，则应该增加JVM内存监控的计算规则同时进行计算。

心跳监控异常

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