大型ESB服务总线平台服务运行分析和监控预警实践( 三 ) _ESB服务

2. 如果JVM内存持续上升而没有释放，如何快速定位到服务？
这个也是经常遇到的问题，当JVM内存持续增加，或者连接数不断的增加而不释放的时候，如果我们不进行及时的处理往往就导致整个JVM内存溢出而影响到所有ESB服务的运行。因此在这种场景下我们需要尽快的发现导致问题的服务，并对服务采取相应的措施。
3. 从服务运行告警到自动熔断
为了不因为一个具体服务的异常非法调用而影响到所有服务的运行，对于单个服务在出现持续性的告警后，应该有策略直接对该服务进行熔断处理。比如直接对服务进行禁用处理。
增加实时的心跳检查在前面部分已经详细分析了服务本身的运行并发，次数和数据量与JVM内存，与CPU和内存利用率等各个关键指标之间的勾稽关系。
这些指标之间本身相互影响和作用，我们对指标的监控本身应该是风险驱动的，即在系统出现宕机或内存溢出等故障问题前快速的发现问题并进行处理。
因此，我们就需要对各种关键指标进行心跳监控和实时预警。
对JVM内存利用率进行监控
在前面我们已经谈到了，实际上出现JVM溢出的时候，往往会由于请求漂移影响到整个集群大量节点内存溢出而导致集群不可用。
因此需要时刻监控JVM内存利用率的情况，如果发现JVM内存持续在某个高位，无法通过Gc操作将内存回收下来的时候就应该实时进行预警。
在预警后我们既可以进行人工处理，也可以设置策略直接对问题节点进行重启操作。

文章插图

如上，我们对所有集群节点的JVM内存利用率进行实时监控，当发现利用率持续大于70%的时候就进行相应的预警操作，如果超过80%就推送严重警告信息。
对后端业务系统和服务本身可用性监控
其次， ESB服务总线如果出现服务调用异常，除了ESB总线本身的异常故障外，更大的可能性是后端业务系统不可用，或者说后端业务系统提供的业务服务不可用导致。
对于ESB总线本身，我们可以实时心跳检查ESB总线暴露的服务可用性，如下：

文章插图

如果是后端系统本身不可用，那么往往会快速的返回connection timeout异常信息，这样不会影响到整个ESB总线平台稳定性。但是如果是后端业务系统服务假死或处于长时间无响应的状态，那么就会导致大量的连接无法释放，最终导致资源被消耗完。
因此对后端系统和后端服务进行实时心跳监控也是有必要的。

文章插图

不论是对于ESB集群还是后端业务系统的监控，实际上都包括两个方面的监控，一个我们叫技术联通性监控，一个叫业务联通性监控。
技术连通性即是否出现conneciton timeout访问超时，是就返回异常。而对于业务联通性，则是调用真实的某个业务服务接口，如果出现read time out则返回业务连通失败错误。
对服务运行进行实时心跳监控
其次，我们还需要对服务运行进行实时心跳监控，即时刻监控服务运行的并发量，数据量，运行时长等几个关键数据指标。
在前面已经谈到过以上几个指标本身存在勾稽关系，比如发现服务运行平均时长增加，那么很可能是服务并发量增加或调用数据量增加导致。其次，如果发现服务调用的消息报文数据量猛增，那么很可能导致服务运行时长增加。
因此需要对以上几个关键指标进行实时监控，时刻监控是否发生了峰值突变情况。