谈服务运行监控和分析(8.1)

虽然在当前的ESB管控平台已经有了服务运行预警和告警功能，但是这篇文章还是从服务日常运行监控来分析如何发现潜在的一些服务运行问题，其中既包括了服务异常非法大并发调用，也包括了服务中传递大数据量，服务运行时长超长，运行异常等各类问题。

问题排查的基本思路-先总后分

对于问题分析和排查，其基本思路仍然是先总后分，即首先看服务运行统计分析数据，然后在针对统计分析数据中发现的异常数据来排查详细的服务运行日志数据。

我们可以考虑下，我们日常做服务运行周报，月报汇报的时候，或者做其它项目实施和执行进展汇报的时候，也基本沿用该思路。即首先要先看统计表格，如果统计表格数据都按计划执行OK，那就没有必要看明细。否则就需要基于暴露的偏差和问题，查看和分析具体的明细数据，以确定最终的原因。

增加统计分析功能-实现基准值和实际值之间的比较

当前有服务运行预警和告警功能，但是完全可以再增加一个功能，即首先对于每个服务都维护单位时间内的平均运行时长，运行次数（并发数）数据。然后将实际服务运行实例数据取某一个时间段的统计数据计算单位时间内的实际运行情况，然后进行统计分析比较。

在查询条件处我们可以自己设定阈值，即超过基准百分比多少就查询出来。这样就可以第一时间发现服务运行数据中出现大偏差的服务日志有哪些内容。

服务运行统计分析

服务运行次数统计，当前可以直接查询到某个时间段的服务运行次数数据。也可以直接通过服务运行并发数统计分析来服务服务运行并发数。通过这两个数据结合，可以查看到哪些服务运行次数和并发数高，是否合理？对于并发高的时间段我们还需要查看下具体的服务详细日志，看下是否都是同样的条件在查询数据，或者咨询业务系统大并发调用的原因。

对于出现服务大并发调用，一般需要考虑几个方面去优化，第一就是需要消费系统自己去做数据的缓存，短时间间隔内部需要重复实时调用；其次就是对于精确查询类服务，需要考虑支持多个单号或ID，一次查询回来所有的数据而不是循环调用服务去查询。

服务运行时间统计，当前的服务运行时间实际上我们会统计服务运行最大时长，平均时长和最短时长，真正有意义的数据仍然是平均时长。对于平均时长调用超长的服务我们都需要进行原因分析。其中仍然是要先看服务详细调用日志，看下耗时究竟是在ESB还是在源端系统，同时分析服务传递的数据量，看下耗时是否是由于传输的数据量较大引起的。

如果源端系统不可用，会直接导致服务运行时长等待到超时后才会返回，这个时候服务运行时长数据就很大，因此我们的服务统计分析需要考虑既统计服务的范围（成功，失败和所有服务）。

服务运行的数据量，这个当前我们的统计分析没有该功能，而该功能实际上是相对重要的一个功能点，即服务运行平均传输的数据量究竟是多少？这个数据将和服务运行时长密切相关，同时也和服务运行并发和系统性能密切相关。既然我们记录了详细的服务运行日志，因此要计算出服务运行的数据量也没有太大问题。

运行次数，时长，数据量三者的关联分析才是最重要的。因此需要考虑增加查询单位时间间隔里面服务运行的三者关联统计数据。比如一个用户查询服务，我们可以直接看到单位时间里面的运行次数，运行平均时长，运行的数据量的情况。并结合三个数据进一步进行异常和问题分析。

• 并发大，时长短，数据量小：对并发调用进行优化，比如缓存，多单号一次查询等。
• 并发大，时长长，数据量小：源端提供服务需要进行性能优化。
• 并发大，时长长，数据量大：必须优化，这种服务既占有线程连接资源，同时大量耗费JVM内容。具体优化的方法包括了数据分页查询，源端服务性能优化等。
• 并发小，时长长，数据量大：如果本身是定时同步类服务，可以不用理会。
• 并发小，时长长，数据量小：源端提供服务需要进行性能优化。

服务运行监控的目的就是发现各种潜在的服务运行性问题和风险，并第一时间进行解决。否则当前服务运行出现的各种异常情况，很可能导致最终ESB整个平台的不稳定，包括类似管道破裂，JVM内存溢出等各种问题。