这篇主要谈服务运行监控分析方面的功能易用性优化。

对于服务运行次数统计 ，原来只考虑运行总次数，失败次数，而实际上还需要增加一个失败率。其次对于失败次数既包括了业务异常，也包括了系统异常，而我们更关系业务系统异常数和失败率。业务系统异常代表的是业务系统原始服务返回的Exception级别异常更加需要关心。

其次，对于失败率监控，如果一个服务一天本身调用量很小，我们并不关系失败率，只有当调用量达到一定值的时候才关心失败率。那么在这种情况下，需要在查询条件增加了一个运行次数的过滤。

业务系统服务心跳检测 ，对于心跳检测到的异常信息，必须要能够详细的记录到具体的错误日志信息。其次，对于连续多次，比如连续三次心跳检测到异常，应该能够进行邮件或短信通知。在这块可以直接使用业务系统异常中的发送人配置即可。

服务运行调用突变统计 ，这个在前面没有考虑到。最近在进行服务运行监控中发现这个功能有用，即一个服务的调用比上一个工作日发生突变，这个突变可以是10倍或者更大的倍数。那么这些突变的服务我们就需要关心。具体的突变包括了服务运行次数，平均运行时间，平均运行数据量，最大并发量。次数可以是10倍做为突变，而对于时间，数据量，并发一般2-3倍作为突变指标即可。当然具体的突变倍数，我们可以做为查询条件进行设置。

有突变就需要进行分析，为何会出现突变调用，对于这种突变是否合理还是异常调用？突变查询出来的是具体的服务，但是要能够快速定位到究竟是哪个消费方导致了服务调用突变。

服务日志存储消耗排名统计 ，服务日志记录由于当前入数据库存储，是最耗费数据库存储空间的。因此需要时刻关注究竟是哪些服务调用的次数高，传递的数据量大导致了在某一个周期耗费的存储最多。对于这些服务我们就需要分析是否属于正常调用，包括去分析是否需要关闭详细日志记录等。

按子组织进行服务运行情况统计 。应该提供一个可以按省或子组织对服务运行整体情况进行分类统计的功能，以方便查看各省之间的排名和差异情况。当前的组织报表实际上只能查看到一个组织的服务运行统计数据，不方便进行多省之间的横向比较。

监控-》预警-》自动调整控制-》自愈。 实际上这个才是整个SOA治理管控平台的一个重点，即前期我们只需要设置规则，那么在后期我们在进行服务运行性能数据监控的时候，只要发现到达了监控预警阈值，那么就触发告警，同时触发服务管控操作，这些操作包括了限流，熔断，服务禁用，取消消费方授权，关闭详细日志记录等等多种方式。这些应该都是基于规则自动触发行为。

做的最好的方式应该是管控限制操作触发后，在一定时间再观察性能数据是否下来，如果调用量下来后应该自动解除相关的限制措施。当前最影响到ESB服务总线运行的还是总线的AppServer的JVM内存利用率情况，如果JVM内存利用率持续升高，则很容易出现整个AppServer内存溢出而出现服务不可用。