一种服务保活监控方法及装置
技术领域
本发明涉及通信技术领域,更具体的说,涉及一种服务保活监控方法及装置。
背景技术
现有在监控服务的运行状态时,大多是通过判断服务启动的TCP(TransmissionControl Protocol,传输控制协议)端口是否存在来确定服务是否正常运行。
然而,在实际情况中,有时会出现TCP端口存在,而服务已经无法正常运行的情况,也即出现服务假死。因此,如何准确的监测到服务假死的情况,实现服务保活监控成为了本领域技术人员亟需解决的技术问题。
发明内容
有鉴于此,本发明公开了一种服务保活监控方法及装置,以通过在服务中添加dubbo监控接口,以及在容器内添加能够与监控系统服务端进行通信的监控探针,实现监控系统服务端能够通过监测探针和dubbo监控接口直接获取服务的运行状态监控数据,从而可以准确的监测到服务假死的情况,实现服务保活监控。
一种服务保活监控方法,包括:
通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令,其中,所述监控探针与所述服务设置在同一个容器内,且所述监控探针与所在的所述容器一起启动,所述监控指令中携带有所述容器的IP地址,所述服务中添加有dubbo监控接口,所述监控系统服务端和所述容器均位于Kubernetes容器集群中;
基于所述监控指令,根据所述监控探针的预设监控策略,通过所述监控探针调用所述dubbo监控接口获取所述服务的运行状态监控数据,所述运行状态监控数据中携带有所述服务的运行状态正常与否的标识;
将所述运行状态监控数据反馈至所述监控系统服务端,由所述监控系统服务端根据所述运行状态监控数据中的所述标识,实现对所述服务的保活监控。
可选的,所述通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令,具体包括:
通过所述监控探针接收所述监控系统服务端通过Kubernetes的api接口发送的所述监控指令。
可选的,所述dubbo监控接口为dubbo标准监控接口或dubbo自定义监控接口;
所述dubbo标准监控接口获取的所述运行状态监控数据包括:服务正常运行状态数据或服务假死数据;
所述dubbo自定义监控接口获取的所述运行状态监控数据包括:数据库和中间件的连接状态数据,以及所述服务正常运行状态数据和所述服务假死数据中的二者之一。
可选的,所述基于所述监控指令,根据所述监控探针的预设监控策略,通过所述监控探针调用所述dubbo监控接口获取所述服务的运行状态监控数据,具体包括:
当所述监控指令中携带有存活探针接口调用指令时,通过所述监控探针的存活探针接口调用所述dubbo监控接口,获取表征所述服务是否需要重启的运行状态监控数据;
当所述监控指令中携带有就绪探针接口调用指令时,通过所述监控探针的就绪探针接口调用所述dubbo监控接口,获取表征所述服务是否需要熔断的运行状态监控数据。
一种服务保活监控方法,包括:
通过监控系统服务端向监控探针发送对服务的运行状态进行监控的监控指令,其中,所述监控探针与所述服务设置在同一个容器内,且所述监控探针与所在的所述容器一起启动,所述监控指令中携带有所述容器的IP地址,所述服务中添加有dubbo监控接口,所述监控系统服务端和所述容器均位于Kubernetes容器集群中;
通过所述监控系统服务端获取所述监控探针反馈的所述服务的运行状态监控数据,所述运行状态监控数据中携带有所述服务的运行状态正常与否的标识,所述运行状态监控数据为基于所述监控指令,根据所述监控探针的预设监控策略,通过所述监控探针调用所述dubbo监控接口获取;
根据所述运行状态监控数据中的所述标识对所述服务进行保活监控。
可选的,还包括:
将所述运行状态监控数据存储于时序型数据库中。
可选的,还包括:
将所述运行状态监控数据显示在前端页面上。
可选的,还包括:
当所述运行状态监控数据的所述标识确定需要对所述服务进行重启时,输出服务重启的报警信息。
可选的,还包括:
当所述运行状态监控数据的所述标识确定需要对所述服务进行熔断时,输出服务熔断的报警信息。
一种服务保活监控装置,包括:
指令接收单元,用于通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令,其中,所述监控探针与所述服务设置在同一个容器内,且所述监控探针与所在的所述容器一起启动,所述监控指令中携带有所述容器的IP地址,所述服务中添加有dubbo监控接口,所述监控系统服务端和所述容器均位于Kubernetes容器集群中;
第一监控数据获取单元,用于基于所述监控指令,根据所述监控探针的预设监控策略,通过所述监控探针调用所述dubbo监控接口获取所述服务的运行状态监控数据,所述运行状态监控数据中携带有所述服务的运行状态正常与否的标识;
数据反馈单元,用于将所述运行状态监控数据反馈至所述监控系统服务端,由所述监控系统服务端根据所述运行状态监控数据中的所述标识,实现对所述服务的保活监控。
可选的,所述指令接收单元具体包括:
通过所述监控探针接收所述监控系统服务端通过Kubernetes的api接口发送的所述监控指令。
可选的,所述dubbo监控接口为dubbo标准监控接口或dubbo自定义监控接口;
所述dubbo标准监控接口获取的所述运行状态监控数据包括:服务正常运行状态数据或服务假死数据;
所述dubbo自定义监控接口获取的所述运行状态监控数据包括:数据库和中间件的连接状态数据,以及所述服务正常运行状态数据和所述服务假死数据中的二者之一。
可选的,所述第一监控数据获取单元具体包括:
第一监控数据获取子单元,用于当所述监控指令中携带有存活探针接口调用指令时,通过所述监控探针的存活探针接口调用所述dubbo监控接口,获取表征所述服务是否需要重启的运行状态监控数据;
第二监控数据获取子单元,用于当所述监控指令中携带有就绪探针接口调用指令时,通过所述监控探针的就绪探针接口调用所述dubbo监控接口,获取表征所述服务是否需要熔断的运行状态监控数据。
一种服务保活监控装置,包括:
指令发送单元,用于通过监控系统服务端向监控探针发送对服务的运行状态进行监控的监控指令,其中,所述监控探针与所述服务设置在同一个容器内,且所述监控探针与所在的所述容器一起启动,所述监控指令中携带有所述容器的IP地址,所述服务中添加有dubbo监控接口,所述监控系统服务端和所述容器均位于Kubernetes容器集群中;
第二监控数据获取单元,用于通过所述监控系统服务端获取所述监控探针反馈的所述服务的运行状态监控数据,所述运行状态监控数据中携带有所述服务的运行状态正常与否的标识,所述运行状态监控数据为基于所述监控指令,根据所述监控探针的预设监控策略,通过所述监控探针调用所述dubbo监控接口获取;
监控单元,用于根据所述运行状态监控数据中的所述标识对所述服务进行保活监控。
可选的,还包括:
存储单元,用于将所述运行状态监控数据存储于时序型数据库中。
可选的,还包括:
显示单元,用于将所述运行状态监控数据显示在前端页面上。
可选的,还包括:
第一报警信息输出单元,用于当所述运行状态监控数据的所述标识确定需要对所述服务进行重启时,输出服务重启的报警信息。
可选的,还包括:
第二报警信息输出单元,用于当所述运行状态监控数据的所述标识确定需要对所述服务进行熔断时,输出服务熔断的报警信息。
从上述的技术方案可知,本发明公开了一种服务保活监控方法及装置,预先在服务中添加了dubbo监控接口,并在每个容器内添加了一个监控探针,使得监控探针与服务在同一个容器内,且监控探针与所在容器一起启动,通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令,该监控指令中携带有容器的IP地址,监控系统服务端和容器均位于Kubernetes容器集群中,基于监控指令,根据监控探针的预设监控策略,通过监控探针调用dubbo监控接口获取服务的运行状态监控数据,将运行状态监控数据反馈至监控系统服务端,由监控系统服务端根据运行状态监控数据中的标识,实现对服务的保活监控。本发明通过在服务中添加dubbo监控接口,以及在容器内添加能够与监控系统服务端进行通信的监控探针,实现了监控系统服务端能够通过监测探针和dubbo监控接口直接获取服务的运行状态监控数据,从而可以准确的监测到服务假死的情况,实现服务保活监控。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据公开的附图获得其他的附图。
图1为本发明实施例公开的一种服务保活监控方法流程图;
图2为本发明实施例公开的另一种服务保活监控方法流程图;
图3为本发明实施例公开的一种服务保活监控装置的结构示意图;
图4为本发明实施例公开的另一种服务保活监控装置的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本发明实施例公开了一种服务保活监控方法及装置,通过在服务中添加dubbo监控接口,以及在容器内添加能够与监控系统服务端进行通信的监控探针,实现了监控系统服务端能够通过监测探针和dubbo监控接口直接获取服务的运行状态监控数据,从而可以准确的监测到服务假死的情况,实现服务保活监控。
参见图1,本发明实施例公开的一种服务保活监控方法流程图,该方法应用于服务器,该方法包括:
步骤S101、通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令;
其中,所述监控探针与所述服务设置在同一个容器内,且所述监控探针与所在的所述容器一起启动,所述监控指令中携带有所述容器的IP地址,所述服务中添加有dubbo(开源分布式服务框架)监控接口,所述监控系统服务端和所述容器均位于Kubernetes容器集群中。
Kubernetes,简称k8s,是Google在2014年6月开源的一个docker容器集群管理系统,用于管理云平台中多个主机上的容器化的应用,是一个自动化容器操作的开源平台,解决了传统docker容器的集群化管理和跨宿主机网络通信问题。Kubernetes的目标是让部署容器化的应用简单并且高效。
容器,即docker容器,是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器或Windows 机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。
需要特别说明的是,在实际应用中,监控系统服务端所在的服务器与容器所在的服务器可以为不同的服务器,或是为同一个服务器。
本发明在服务运行时,在服务中添加了dubbo监控接口,监控系统服务端通过dubbo监控接口直接远程获取服务的运行状态监控数据,运行状态监控数据可以包括:数据库和中间件的连接状态,可准确监控到服务假死的情况,从而实现服务保活监控。
在传统虚拟机环境部署服务时,监控系统通过固定的IP端口对服务实现保活监控。但是在Kubernetes(以下简称k8s)容器集群中部署时,服务每次运行时所在容器的IP都是随机的,而且由于k8s网络插件使用的vxlan二层虚拟网络技术,容器IP都是vxlan网络中随机分配的,监控系统所在的vlan网络的IP是无法直接和容器IP通信的,导致现有监控系统无法监控到k8s集群中服务运行的状态。
为解决这一问题,本发明采用了监控探针,将监测探针部署到容器之中,每个容器启动一个服务及一个监测探针,监控系统服务端通过k8s的api实时动态获取容器IP,采集每个容器中监测探针获取的服务的运行状态监控数据。同时将监控系统服务端也部署到k8s容器集群中,从而解决解决了监控系统服务端与容器之间的网络通信问题,实现了对k8s容器集群中服务状态的监控。
步骤S102、基于所述监控指令,根据所述监控探针的预设监控策略,通过所述监控探针调用所述dubbo监控接口获取所述服务的运行状态监控数据;
其中,所述运行状态监控数据中携带有所述服务的运行状态正常与否的标识。
步骤S103、将所述运行状态监控数据反馈至所述监控系统服务端,由所述监控系统服务端根据所述运行状态监控数据中的所述标识,实现对所述服务的保活监控。
综上可知,本发明公开的服务保活监控方法,预先在服务中添加了dubbo监控接口,并在每个容器内添加了一个监控探针,使得监控探针与服务在同一个容器内,且监控探针与所在容器一起启动,通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令,该监控指令中携带有容器的IP地址,监控系统服务端和容器均位于Kubernetes容器集群中,基于监控指令,根据监控探针的预设监控策略,通过监控探针调用dubbo监控接口获取服务的运行状态监控数据,将运行状态监控数据反馈至监控系统服务端,由监控系统服务端根据运行状态监控数据中的标识,实现对服务的保活监控。本发明通过在服务中添加dubbo监控接口,以及在容器内添加能够与监控系统服务端进行通信的监控探针,实现了监控系统服务端能够通过监测探针和dubbo监控接口直接获取服务的运行状态监控数据,从而可以准确的监测到服务假死的情况,实现服务保活监控。
本实施例中,在通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令时,具体可以通过监控探针接收所述监控系统服务端通过Kubernetes的api接口发送的所述监控指令。
在实际应用中,可以在dubbo服务中添加标准监控接口得到dubbo标准监控接口,dubbo标准监控接口获取的服务的运行状态监控数据包括:服务正常运行状态数据或服务假死数据,dubbo标准监控接口可以实现服务保活监控。
可以在dubbo服务中添加自定义监控接口得到dubbo自定义监控接口,dubbo自定义监控接口获取的服务的运行状态监控数据包括:数据库和中间件的连接状态数据,以及服务正常运行状态数据和服务假死数据中的二者之一。
本实施例中,dubbo标准监控接口只是探测服务正常运行或假死,dubbo自定义监控接口可以添加数据库及中间件的调用测试,可针对特定场景对服务进行监控。在实际应用中,根据实际业务需求选取dubbo标准监控接口或dubbo自定义监控接口。
本实施例中,监控探针包括:存活探针接口和就绪探针接口,存活探针接口和就绪探针接口都支持http(超文本传输协议)端口、tcp端口和dubbo接口的健康检查。
因此,步骤S102具体可以包括:
当所述监控指令中携带有存活探针接口调用指令时,通过所述监控探针的存活探针接口调用所述dubbo监控接口,获取表征所述服务是否需要重启的运行状态监控数据,该运行状态监控数据中携带有服务是否需要重启的标识,当标识为1时,表征服务需要重启,反之,当标识为0时,表征服务不需要重启。
当所述监控指令中携带有就绪探针接口调用指令时,通过所述监控探针的就绪探针接口调用所述dubbo监控接口,获取表征所述服务是否需要熔断的运行状态监控数据,该运行状态监控数据中携带有服务是否需要熔断的标识,当标识为1时,表征服务需要熔断,反之,当标识为0时,表征服务不需要熔断。
参见图2,本发明另一实施例公开的一种服务保活监控方法流程图,该方法应用于服务器,具有监控系统服务端的服务器与具有容器的服务器之间进行通信,实现对服务的保活监控,该方法包括:
步骤S201、通过监控系统服务端向监控探针发送对服务的运行状态进行监控的监控指令;
其中,所述监控探针与所述服务设置在同一个容器内,且所述监控探针与所在的所述容器一起启动,所述监控指令中携带有所述容器的IP地址,所述服务中添加有dubbo监控接口,所述监控系统服务端和所述容器均位于Kubernetes容器集群中。
步骤S202、通过监控系统服务端获取监控探针反馈的服务的运行状态监控数据;
其中,所述运行状态监控数据中携带有所述服务的运行状态正常与否的标识,所述运行状态监控数据为基于所述监控指令,根据所述监控探针的预设监控策略,通过所述监控探针调用所述dubbo监控接口获取。
在实际应用中,监控系统服务端可以通过pull的形式从监控探针获取服务的运行状态监控数据。在通过pull的形式从监控探针获取服务的运行状态监控数据时,监控系统服务端通过http协议定时拉取服务的运行状态监控数据,采集间隔可自定义配置。
步骤S203、根据所述运行状态监控数据中的所述标识对所述服务进行保活监控。
综上可知,本发明公开的服务保活监控方法,预先在服务中添加了dubbo监控接口,并在每个容器内添加了一个监控探针,使得监控探针与服务在同一个容器内,且监控探针与所在容器一起启动,通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令,该监控指令中携带有容器的IP地址,监控系统服务端和容器均位于Kubernetes容器集群中,基于监控指令,根据监控探针的预设监控策略,通过监控探针调用dubbo监控接口获取服务的运行状态监控数据,将运行状态监控数据反馈至监控系统服务端,由监控系统服务端根据运行状态监控数据中的标识,实现对服务的保活监控。本发明通过在服务中添加dubbo监控接口,以及在容器内添加能够与监控系统服务端进行通信的监控探针,实现了监控系统服务端能够通过监测探针和dubbo监控接口直接获取服务的运行状态监控数据,从而可以准确的监测到服务假死的情况,实现服务保活监控。
为进一步优化上述实施例,在步骤S203之后,还可以包括:
将所述运行状态监控数据存储于时序型数据库中。
时序型数据库在处理kv形式的运行状态监控数据时,读写性能是优于关系型数据库。存储运行状态监控数据时,数据库多为读写操作,改的操作几乎为零,使用时序型数据库读写性能更好。
为进一步优化上述实施例,在步骤S203之后,还可以包括:
将服务的运行状态监控数据显示在前端页面上。
其中,前端页面上可以提供自定义绘制图表的UI界面,同时支持自定义页面以json文件格式导入导出。
为进一步优化上述实施例,在步骤S203之后,还可以包括:
当服务的运行状态监控数据的标识确定需要对服务进行重启时,输出服务重启的报警信息。
当服务的运行状态监控数据的标识确定需要对服务进行熔断时,输出服务熔断的报警信息。
其中,当需要对服务进行重启时,服务的运行状态监控数据为监控探针的存活探针接口反馈的运行状态监控数据,此时存活探针接口处于异常情况,监控系统服务端在确定服务异常并重启服务的同时,会输出对应的服务重启的报警信息。
当需要对服务进行熔断时,服务的运行状态监控数据为监控探针的就绪探针接口反馈的运行状态监控数据,就绪探针接口处于异常情况,监控系统服务端在确定服务异常并熔断服务的同时,会输出对应的服务熔断的报警信息。
当就绪探针接口异常时,监控系统服务端会判定服务知识业务短暂故障,此时并不会重启服务,同时将此节点标记为故障节点并从负载均衡后端服务中摘除,避免业务流量流入故障节点。监控数据可通过数据展示模块进行前端页面展示。
综上可知,本发明在实现对服务进行保活监控的同时,还具有针对服务的故障自愈及故障熔断机制。在在服务扩充节点时,监控探针随容器自动部署,无需人工手动添加,从而减少了大量人工操作成本。
与上述方法实施例相对应,本发明还公开了一种服务保活监控装置。
参见图3,本发明实施例公开的一种服务保活监控装置的结构示意图,该装置应用于服务器,该装置包括:
指令接收单元301,用于通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令;
其中,所述监控探针与所述服务设置在同一个容器内,且所述监控探针与所在的所述容器一起启动,所述监控指令中携带有所述容器的IP地址,所述服务中添加有dubbo监控接口,所述监控系统服务端和所述容器均位于Kubernetes容器集群中。
需要特别说明的是,在实际应用中,监控系统服务端所在的服务器与容器所在的服务器可以为不同的服务器,或是为同一个服务器。
本发明在服务运行时,在服务中添加了dubbo监控接口,监控系统服务端通过dubbo监控接口直接远程获取服务的运行状态监控数据,运行状态监控数据可以包括:数据库和中间件的连接状态,可准确监控到服务假死的情况,从而实现服务保活监控。
在传统虚拟机环境部署服务时,监控系统通过固定的IP端口对服务实现保活监控。但是在Kubernetes(以下简称k8s)容器集群中部署时,服务每次运行时所在容器的IP都是随机的,而且由于k8s网络插件使用的vxlan二层虚拟网络技术,容器IP都是vxlan网络中随机分配的,监控系统所在的vlan网络的IP是无法直接和容器IP通信的,导致现有监控系统无法监控到k8s集群中服务运行的状态。
为解决这一问题,本发明采用了监控探针,将监测探针部署到容器之中,每个容器启动一个服务及一个监测探针,监控系统服务端通过k8s的api实时动态获取容器IP,采集每个容器中监测探针获取的服务的运行状态监控数据。同时将监控系统服务端也部署到k8s容器集群中,从而解决解决了监控系统服务端与容器之间的网络通信问题,实现了对k8s容器集群中服务状态的监控。
第一监控数据获取单元302,用于基于所述监控指令,根据所述监控探针的预设监控策略,通过所述监控探针调用所述dubbo监控接口获取所述服务的运行状态监控数据,所述运行状态监控数据中携带有所述服务的运行状态正常与否的标识;
数据反馈单元303,用于将所述运行状态监控数据反馈至所述监控系统服务端,由所述监控系统服务端根据所述运行状态监控数据中的所述标识,实现对所述服务的保活监控。
综上可知,本发明公开的服务保活监控装置,预先在服务中添加了dubbo监控接口,并在每个容器内添加了一个监控探针,使得监控探针与服务在同一个容器内,且监控探针与所在容器一起启动,通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令,该监控指令中携带有容器的IP地址,监控系统服务端和容器均位于Kubernetes容器集群中,基于监控指令,根据监控探针的预设监控策略,通过监控探针调用dubbo监控接口获取服务的运行状态监控数据,将运行状态监控数据反馈至监控系统服务端,由监控系统服务端根据运行状态监控数据中的标识,实现对服务的保活监控。本发明通过在服务中添加dubbo监控接口,以及在容器内添加能够与监控系统服务端进行通信的监控探针,实现了监控系统服务端能够通过监测探针和dubbo监控接口直接获取服务的运行状态监控数据,从而可以准确的监测到服务假死的情况,实现服务保活监控。
上述实施例中,指令接收单元301具体可以包括:
通过所述监控探针接收所述监控系统服务端通过Kubernetes的api接口发送的所述监控指令。
在实际应用中,可以在dubbo服务中添加标准监控接口得到dubbo标准监控接口,dubbo标准监控接口获取的服务的运行状态监控数据包括:服务正常运行状态数据或服务假死数据,dubbo标准监控接口可以实现服务保活监控。
可以在dubbo服务中添加自定义监控接口得到dubbo自定义监控接口,dubbo自定义监控接口获取的服务的运行状态监控数据包括:数据库和中间件的连接状态数据,以及服务正常运行状态数据和服务假死数据中的二者之一。
本实施例中,dubbo标准监控接口只是探测服务正常运行或假死,dubbo自定义监控接口可以添加数据库及中间件的调用测试,可针对特定场景对服务进行监控。在实际应用中,根据实际业务需求选取dubbo标准监控接口或dubbo自定义监控接口。
本实施例中,监控探针包括:存活探针接口和就绪探针接口,存活探针接口和就绪探针接口都支持http(超文本传输协议)端口、tcp端口和dubbo接口的健康检查。
因此第一监控数据获取单元302具体可以包括:
第一监控数据获取子单元,用于当所述监控指令中携带有存活探针接口调用指令时,通过所述监控探针的存活探针接口调用所述dubbo监控接口,获取表征所述服务是否需要重启的运行状态监控数据;
第二监控数据获取子单元,用于当所述监控指令中携带有就绪探针接口调用指令时,通过所述监控探针的就绪探针接口调用所述dubbo监控接口,获取表征所述服务是否需要熔断的运行状态监控数据。
当所述监控指令中携带有就绪探针接口调用指令时,通过所述监控探针的就绪探针接口调用所述dubbo监控接口,获取表征所述服务是否需要熔断的运行状态监控数据,该运行状态监控数据中携带有服务是否需要熔断的标识,当标识为1时,表征服务需要熔断,反之,当标识为0时,表征服务不需要熔断。
参见图4,本发明另一实施例公开的一种服务保活监控装置的结构示意图,该装置应用于服务器,该装置包括:
指令发送单元401,用于通过监控系统服务端向监控探针发送对服务的运行状态进行监控的监控指令,其中,所述监控探针与所述服务设置在同一个容器内,且所述监控探针与所在的所述容器一起启动,所述监控指令中携带有所述容器的IP地址,所述服务中添加有dubbo监控接口,所述监控系统服务端和所述容器均位于Kubernetes容器集群中;
第二监控数据获取单元402,用于通过所述监控系统服务端获取所述监控探针反馈的所述服务的运行状态监控数据,所述运行状态监控数据中携带有所述服务的运行状态正常与否的标识,所述运行状态监控数据为基于所述监控指令,根据所述监控探针的预设监控策略,通过所述监控探针调用所述dubbo监控接口获取;
在实际应用中,监控系统服务端可以通过pull的形式从监控探针获取服务的运行状态监控数据。在通过pull的形式从监控探针获取服务的运行状态监控数据时,监控系统服务端通过http协议定时拉取服务的运行状态监控数据,采集间隔可自定义配置。
监控单元403,用于根据所述运行状态监控数据中的所述标识对所述服务进行保活监控。
综上可知,本发明公开的服务保活监控装置,预先在服务中添加了dubbo监控接口,并在每个容器内添加了一个监控探针,使得监控探针与服务在同一个容器内,且监控探针与所在容器一起启动,通过监控探针接收监控系统服务端发送的对服务的运行状态进行监控的监控指令,该监控指令中携带有容器的IP地址,监控系统服务端和容器均位于Kubernetes容器集群中,基于监控指令,根据监控探针的预设监控策略,通过监控探针调用dubbo监控接口获取服务的运行状态监控数据,将运行状态监控数据反馈至监控系统服务端,由监控系统服务端根据运行状态监控数据中的标识,实现对服务的保活监控。本发明通过在服务中添加dubbo监控接口,以及在容器内添加能够与监控系统服务端进行通信的监控探针,实现了监控系统服务端能够通过监测探针和dubbo监控接口直接获取服务的运行状态监控数据,从而可以准确的监测到服务假死的情况,实现服务保活监控。
为进一步优化上述实施例,服务保活监控装置,还可以包括:
存储单元,用于将所述运行状态监控数据存储于时序型数据库中。
时序型数据库在处理kv形式的运行状态监控数据时,读写性能是优于关系型数据库。存储运行状态监控数据时,数据库多为读写操作,改的操作几乎为零,使用时序型数据库读写性能更好。
为进一步优化上述实施例,服务保活监控装置,还可以包括:
显示单元,用于将所述运行状态监控数据显示在前端页面上。
其中,前端页面上可以提供自定义绘制图表的UI界面,同时支持自定义页面以json文件格式导入导出。
为进一步优化上述实施例,服务保活监控装置,还可以包括:
第一报警信息输出单元,用于当所述运行状态监控数据的所述标识确定需要对所述服务进行重启时,输出服务重启的报警信息。
第二报警信息输出单元,用于当所述运行状态监控数据的所述标识确定需要对所述服务进行熔断时,输出服务熔断的报警信息。
其中,当需要对服务进行重启时,服务的运行状态监控数据为监控探针的存活探针接口反馈的运行状态监控数据,此时存活探针接口处于异常情况,监控系统服务端在确定服务异常并重启服务的同时,会输出对应的服务重启的报警信息。
当需要对服务进行熔断时,服务的运行状态监控数据为监控探针的就绪探针接口反馈的运行状态监控数据,就绪探针接口处于异常情况,监控系统服务端在确定服务异常并熔断服务的同时,会输出对应的服务熔断的报警信息。
当就绪探针接口异常时,监控系统服务端会判定服务知识业务短暂故障,此时并不会重启服务,同时将此节点标记为故障节点并从负载均衡后端服务中摘除,避免业务流量流入故障节点。监控数据可通过数据展示模块进行前端页面展示。
综上可知,本发明在实现对服务进行保活监控的同时,还具有针对服务的故障自愈及故障熔断机制。在在服务扩充节点时,监控探针随容器自动部署,无需人工手动添加,从而减少了大量人工操作成本。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下,在其它实施例中实现。因此,本发明将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。