基于规则的运维监控预警(12.19)

对于服务运行性能监控，ESB总线本身的性能监控前面我们已经写过一些文章来说明，对于SOA管控来说很早我们也实现了监控预警功能。即可以针对单个服务或者针对所有服务灵活的配置监控预警策略，然后对所有服务运行进行实时监控，在内存中动态计算是否触发监控预警策略，如果触发就实时进行监控告警。

由于对于监控预警策略，实际的服务运行实例数据和性能指标都在内存中，对于计算过程也在内存中，因此整个监控预警计算过程也全部在内存中完成，因此可以保证很高的性能监控实时性，但是缺点就是本身对内存资源和应用服务器的CPU计算资源消耗较大。

其次，这种方式我们当前只配置了对于服务运行时长，服务运行次数，服务运行异常数三个指标。也就是说对于服务只能够针对这三个指标进行监控预警，比如所有服务的异常次数达到某个阈值就实时触发预警，或者说某个指定的服务平均运行时长超过某个值就预警。

即我们提前预设的服务范围，监控时间周期，服务指标(次数，时长，错误数），所有的监控预警策略只能够围绕上面几个参数进行设置。就对服务本身的性能分析和管控层面来看，上面这种方式基本能够达到目标，但是如果对ESB服务总线本身的性能监控和预警分析来说，上面的监控预警往往还不够。

即： 服务本身的监控预警往往并不一定就导致了ESB总线出现性能问题或预警，同时ESB总线本身的性能问题预警又在当前的监控指标和范围上无法体现出来。

举例来说，如果服务实例数据出现大量的长耗时调用，或者服务运行总时长是源时长的多倍情况，这种情况基本会导致ESB总线本身资源预警或出现内存溢出，是我们需要重点监控的内容。现在我们的运行时长本身基于平均数或最大数都不适合去做该判断。

其次，前面已经谈到过，我们当前的性能监控预警全部是针对服务运行实例日志表进行的，需要动态的实时进行分组统计和计算，对计算资源耗费大，同时本身也影响应用服务器性能和内存使用。

因此我们新的自动化监控预警方法应该考虑如下几个方面的问题：

1. 不要基于实时的实例日志表计算，降低资源使用，也提高动态计算效率

2. 监控的规则可以进行灵活的手工配置，包括动态的公式化或脚本配置

3. 对于监控预警后，能否即使的触发后续行动，比如直接进行限流或者熔断

基于该需求，我们可以考虑实现一个基于动态规则的自动化监控预警功能。同时对于基础计算表不再使用实际的服务日志数据表，而是改为服务的分钟级中间汇总表。分钟级汇总表基本能够满足准实时进行数据监控的需求，同时在分钟级汇总表上仍然能够保留类似服务次数，服务运行最大时长，最小时长，平均时长，最大数据量，平均数据量等关键的KPI指标项。

对于监控规则的配置我们可以考虑编写动态 Sql 来进行配置，即监控预警规则为动态Sql语句，而实际的执行则对动态Sql语句进行解析后执行。动态Sql预警即前面谈到的服务名，业务系统，时间段，KPI指标项，成功或失败都可以作为关键的计算指标项。

我们举例来说明，比如对所有服务进行监控，我们需要计算单位周期内的一个指标计算，即服务运行总时长超过100秒，或者服务运行总时长/源时长>10 and 源时长<10s，或者 服务运行总时长/源时长>5 and 源时长>10s都进行计数。

即我们的动态Sql可以编写为：

select count(*) from Table1 

where TotalTime>100 

or (TotalTime/SourceTime>10 and SourceTime<10)

or (TotalTime/SourceTime>5 and SourceTime>10)

在指标值计算出来后，我们再设置具体的规则项，规则项保留简单的大于，小于，等于即可。即计算的指标值大于或小于我们设置的规则值，就实时的监控预警。

对于单个服务，我们也可以进行灵活的设置，比如拿单个服务的数据量来说，我们现在都是死约束，即只要超过10M，服务消费调用就直接拒绝，但是如果1000次服务只出现几次10M以上的调用往往是完全正常的，那么这个时候就不太时候一揽子的全部拒绝掉服务请求。

比如对QueryVendorInfoSrv服务，对于MsgSize我们可以做如下设置

select count(*) from Table1 

where MaxSize>10M or Avg-MsgSize>2M

如果这个数据量超出的总次数超过多少，我们就实时触发预警。（在这种模式下，如果采用分钟级报表，我们需要提前计算10M以上的报文在单位分钟里面的出现次数，并记录到分钟级报表的中间表中才行。）

同时对于第三点谈到的，在预警完成后，我们还可以实时的触发对该服务启用更加严格的数据量报文大小约束，比如前面是20M报文约束，但是发现大报文的并发量很大，那么就实时触发约束到10M甚至更小。但是这种操作下有个点需要处理，就是在如果对触发的约束规则进行恢复或解除的问题。

当然基于以上动态规则，我们也很容易实现按单个系统来观察异常情况，比如一个接入的业务系统是否出现问题。不能简单的说某个服务出现异常调用就一定业务系统有问题。因此我们可以观察如果该业务系统提供的服务有超过5个甚至更多服务都出现超过10次以上的业务系统异常，我们就可以初步判断业务系统出现问题并实时预警。对于这种情况，我们也很容易进行设置。

select count(*) from (select servicename, count(errortimes) from Table1 where sysname = ERP

group by servicename having count(errortimes)>10)

通过这种方式我们可以计算处理指标值，然后在规则中进行灵活配置即可。

在一个单位监控周期内，究竟出现了多少次大报文量调用，出现过多少次的长耗时调用，出现过多少异常调用，或者在异常数占比达到某个值，大报文调用占比达到某个值，这些都可以做为我们灵活进行各种配置的条件。通过灵活的规则配置，我们可以更加灵活高效的进行服务运行性能监控和实时预警。

这篇文章有些实现细节还需要进一步完善，但是整体基于灵活脚本化规则动态触发预警思路是可行的。