33

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

 5 years ago
source link: http://blog.sina.com.cn/s/blog_493a84550102y02o.html?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

最近一直在思考心跳检查和实时监控报表功能,这个报表重点就是监控当前的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接口服务地址在哪里。同时还涉及到具体的全局变量配置,比如探测的时间间隔,总览图表的刷新时间间隔,模拟服务消费调用的时候默认传递的参数,如何判断返回正常等,这些都需要进行配置。

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK