再谈心跳检测报表构图(10.18)

最近一直在思考心跳检查和实时监控报表功能，这个报表重点就是监控当前的ESB服务总线，已经总线接入的所有提供接口服务的系统当前状态是否正常。经过分析有如下思考：

信息总览部分

还是需要有一个信息总览部分的内容，但是对于服务运行统计分析中的次数，时长，数据量，并发，异常等诸多内容没有必要都在信息总览这个地方显示。对于实时监控来说，我们最关心的还是ESB总线平台的可用线程数和JVM内存情况，而这属于网管类系统监控的内容。对于线程数则和系统并发数有直接关系，而对于JVM内存则和数据量有直接关系。

对于信息总览部分，初步考虑是采用百度Echart的实时动态图展示，即该图动态推送新产生的数据到图表上，同时整个图表折线和柱状图内容会动态进行滚动。通过这种方式可以实时观测到最近30分钟或1个小时的数据。初步考虑对于服务并发数，数据量和异常数三个信息都可以通过该方式进行动态滚动刷新展示。

按组织进行栏位展示

ESB总线如果接入多个组织，多个子组织的业务系统的时候，那么就要考虑按组织进行分域展示。对于实际的App应用的性能监控来说，需要包括ESB总线自身的中间件，也需要包括各个业务系统提供的Service接口服务器本身的监控。

对于ESB总线来说，应该包括了OSB服务总线，JMS消息总线，MFT文件传输，以及管控治理平台诸多集群的性能监控，确保总线本身各个组件提供能力正常。

对于每一个业务系统的监测，需要单独设计一个面板来监测该APP Server本身的关键性能指标。因此还需要考虑每一个面板如何设计。在百度的Echart里面找了下，还没有找到合适的面板设计并循环布局的图表插件，因此这块还是得自己进行设计和代码实现。

单个面板的设计

举例来说某个子公司有CMS系统需要接入到ESB服务总线，那么就需要对CMS系统本身提供的接口服务进行实时监控。那么这个实时监控究竟需要监控和实时展现哪些内容，考虑了下，初步包括几个方面：

1. 总探测次数和探测异常次数：当天中的探测总次数，已经一共有多少次探测失败的次数。

2. 技术连通性：考虑仅仅访问成功WSDL地址就算技术连通。

3. 业务连通性：ESB总线模拟消费方实际去调用业务系统提供的业务服务(query服务），有成功返回才成功。

因此单个业务系统面板需要展示如上内容，同时对于技术连通性和业务连通性，在实现的时候考虑能够显示最近10次的探测结果，比如30秒探测一次，那么也就是可以显示先最近5分钟实际的业务系统和接口服务性能检测情况。而不是只显示当前最近因此的探测情况。

当最后一次心跳检查出现无法连通和探测失败的时候，需要考虑在更加醒目的位置来显示这种警告和告警。以方面在监控的时候能够快速的发现问题并响应解决。

元数据的配置和数据存储

对于元数据的配置涉及到需要检查哪些组织，每个组织需要检查哪些系统，同时每个系统检查的WS接口服务地址在哪里。同时还涉及到具体的全局变量配置，比如探测的时间间隔，总览图表的刷新时间间隔，模拟服务消费调用的时候默认传递的参数，如何判断返回正常等，这些都需要进行配置。

其次对于数据存储，初步考虑对于实时监测正常的情况下，不对监测内容进行存储，而只是对检查失败的详细日志记录进行存储。同时检查的情况按天进行展示，对于每天实际检查的总次数，实际的错误次数等数据仍然需要进行存储。这个存储可以定时写入到数据库进行持久化即可。