再谈系统运维和性能监控(12.17)

系统已经上线2个月，在这两个月整个平台基本能够做到平稳运行，同时整体性能也能够完全满足当初的业务测算和性能需求，从最近两个月的系统运维工作和性能监控来看，还是有一些简单感受和总结，特记录如下：

对于ESB总线来说简单粗暴的限流或断流往往并不合适，这将直接影响到业务的正常运行 ，比如有些服务大并发异常调用，虽然存在调用方法不对的问题，但是仍然不能简单断流，也需要我们去监控发现这种异常调用情况，然后反馈给业务系统消费方，进行调用方式优化。

对于最近两个月，我们大部分人力安排都在进行系统运行监控，服务运行监控，目的就是及早的发现服务响应缓慢，或者服务调用次数和并发量大的服务，然后和业务系统一起分析是否合理，并进行改进。

1.对于服务响应缓慢的服务 ，如果并发量大前面分析过将导致连接和内存不能及时释放，导致内存溢出。

2.对于并发量大的服务 ，如果响应快本身无问题，但是会导致ESB总线本身的日志记录量快速增长。

对于当前的ESB总线的日常服务运行监控，我们基本遵循的方法主要还是看 服务运行时长，次数，并发量，异常日志等几个关键管控平台提供的功能，同时我们还设计了服务运行基准监控功能 ，每日跑服务运行报表，去分析服务运行统计数据超过我们预设的服务基准数据的服务，以进一步分析这些服务是否需要进一步优化和调整。

1.运行时长一般我们会看服务平均运行时长，对于超过10S的服务我们一般会重点关注。

2.运行时长数据还会和服务调用次数，服务输入输出数据量一起比对分析，看时长超长的数据是否合理。

3.对服务运行数据量也进行重点监控，分析哪些服务传输数据量大，是否大数据量服务存在大并发。

4.从服务运行次数排名分析，哪些服务调用次数大，通过单服务报表分析哪个系统消费量大，是否合理。

5.查看服务基准监控数据报表，分析按天或按周的服务基准异常监控数据。

6.对服务运行异常日志进行重点监控，包括业务系统异常和ESB总线异常，出现问题实时跟踪解决。

我们最近增加了业务系统服务心跳监测报表，对于业务系统和服务可用性进行准实时的探查 ，一旦发现问题会及时进行预警和邮件短信通知，这样可以方便我们实时发现业务系统或服务运行故障问题并及时报警。但是对于服务异常日志监控，我们还需要一个替代人工的实时监控预警分析功能，这个功能仍然有必要。

比如一旦发现某个系统在某个单位时间对于业务系统异常超出基准次数，平台就应该报警并跟踪解决。一旦我们监控ESB总线本身单位时间内出现系统级异常次数超过某个阈值也进行预警。对于ESB本身的异常当前我们也分了安全校验内异常，转换解析异常或平台内部故障如内存溢出管道破裂等异常，这些异常本身的基准次数设置都应该不一样，能够灵活定制。

比如当前我们会手工监控异常日志，看下最近1到2个小时有无ESB平台的系统级异常故障，也会查询下是否有业务系统异常故障（即业务系统服务不可用导致的Exception级别的异常）。对于发现的异常我们也会马上进行分析，如果是业务系统的问题就及时反馈给业务系统。

对于业务系统本身的异常，我们最怕的就是业务系统处于一种假死状态，即服务仍然可以处于调用，但是一直等到Socket Read Timeout ，但是我们现在这个超时值都设置为10分钟，也就是说如果服务调用并发量大，那么就会导致大量请求把可用连接全部占有调，而导致整体ESB集群出现宕机的问题。这也是我们针对一些大并发实时调用服务，将Socket Read Timeout值单独设置小的一个原因，比如设置为30秒。

对于Oracle SOA统计的OSB集群，我们前期在验证过程中还发现一个很奇怪的问题无法解决，比如出现了 大并发和大数据量的异常服务调用，这个时候不仅仅是单个集群节点出现问题，而是导致问题由单个集群节点蔓延到整个OSB集群 ，通知导致整个Weblogic Cluster集群的Admin节点出现问题，只有对整个集群进行重启启动才能够解决。这本身已经失去了集群的意义。

对于OSB集群，出现大数据量服务调用的时候，前面我们也在分析能够通过JVM启动参数的调整来实现遇到大数据量调用超长时间的，直接将连接断掉释放资源，而不是一直等到内存溢出导致整体集群出现故障。这种故障的最明显体现就是所有服务运行全部变慢或者超时，这对一个完整的高可用性集群一定是无法接受的。近期对于Oracle MFT文件传输集群，我们也发现过同样的问题，就是单个MFT文件传输通道出现问题，会导致整个MFT集群出现问题，这个也是无法接受的。即单个MFT文件传输的影响处于不可控状态。

对于JMS服务，现在实现1对多的服务消息发布和订阅机制，订阅端也实现自动的重连机制。前期我们出现过对于消费JMS服务导致的服务运行失败问题，后面发现是连接池和主题设置方面的问题，后面已经解决。但是现在仍然会发现订阅端系统不及时取走消息的情况。在原来我们是通过手工监控JMS消息的暂挂情况，但是涉及到好几十个主题，上百个订阅系统，在Weblogic JMS管控台上去检查相对麻烦。因此在最近我们也通过JMS提供的接口API，实时来查询JMS暂挂消息情况，以方便对JMS订阅情况进行实时跟踪和监控。

OSB集群，最怕的就是整个集群宕机导致所有服务都处于不可用状态，这也是我们前面考虑将集群进行分域规划的原因， 对于分域既可以按服务提供方进行，也可以按服务消费方进行，最后我们是以服务消费方进行分域，这种方式最好的地方就是可以规避OSB集群本身的故障导致的所有消费端系统不可用，但是无法规避服务提供方业务系统出现故障导致的不可用。比如如果ERP系统提供的服务出现故障，那么会导致两个分域集群都出现超时或内存溢出问题，这个仍然无法完全避免。

对于Weblogic Cluster集群本身的高可用性如何保证，仍然需要进一步进行优化分析。

在并发量起来后服务运行性能慢还好办，可以有针对性的进行分析和诊断，对资源和服务进行优化。最怕的就是单个计算资源的性能影响到整个集群，单个服务性能影响到所有资源，这些都导致集成平台整体不可用，影响面巨大。

一定要记住，对于运维监控和性能分析，一定是风险驱动而不是问题驱动。

真正出现问题或故障的时候，我们很难有快速的处理和响应时间第一时间解决问题，能够真正用的只有对集群进行重启，这种糟糕的方式不到万不得已最好是不要采用的。通过对服务器或虚拟机资源的监控，可以间接的反应出服务异常调用场景；同时，对于服务运行性能监控，我们又可以反推或预测潜在可能出现的资源耗尽风险，这两者本身的是相辅相成的，需要结合两者共同分析。