CN104915263B - 基于容器技术的进程故障处理方法及装置 - Google Patents

基于容器技术的进程故障处理方法及装置 Download PDF

Info

Publication number
CN104915263B
CN104915263B CN201510375126.1A CN201510375126A CN104915263B CN 104915263 B CN104915263 B CN 104915263B CN 201510375126 A CN201510375126 A CN 201510375126A CN 104915263 B CN104915263 B CN 104915263B
Authority
CN
China
Prior art keywords
container
normal operation
module
subelement
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201510375126.1A
Other languages
English (en)
Other versions
CN104915263A (zh
Inventor
许斯亮
赵鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Hongxiang Technical Service Co Ltd
Original Assignee
Beijing Qihoo Technology Co Ltd
Qizhi Software Beijing Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Qihoo Technology Co Ltd, Qizhi Software Beijing Co Ltd filed Critical Beijing Qihoo Technology Co Ltd
Priority to CN201510375126.1A priority Critical patent/CN104915263B/zh
Publication of CN104915263A publication Critical patent/CN104915263A/zh
Application granted granted Critical
Publication of CN104915263B publication Critical patent/CN104915263B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Debugging And Monitoring (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

本发明公开了一种基于容器技术的进程故障处理方法及装置,涉及web平台技术领域,解决了在容器技术中因无法有效修复故障容器,而导致的数据内容失效的问题。本发明主要的技术方案为:对容器的进程进行监控;若发现容器的进程异常,则发出容器异常的报警信息;根据所述报警信息对所述容器的进程进行修复恢复容器的正常运行。本发明主要用于对故障容器的修复。

Description

基于容器技术的进程故障处理方法及装置
技术领域
本发明涉及web平台技术领域,尤其涉及一种基于容器技术的进程故障处理方法及装置。
背景技术
LXC为Linux Container的简写。Linux Container容器是一种内核虚拟化技术,可以提供轻量级的虚拟化,以便隔离进程和资源,而且不需要提供指令解释机制以及全虚拟化的其他复杂性。相当于C++中的NameSpace。容器有效地将由单个操作系统管理的资源划分到孤立的组中,以更好地在孤立的组之间平衡有冲突的资源使用需求。与传统虚拟化技术相比Linux Container是一种轻量级的虚拟化的手段,提供了在单一可控主机节点上支持多个相互隔离的server container同时执行的机制,同时也提供了一个拥有自己进程和网络空间的虚拟环境。
LXC在资源管理方面依赖于Linux内核的cgroups子系统,cgroups子系统是Linux内核提供的一个基于进程组的资源管理的框架,可以为特定的进程组限定可以使用的资源。此外,在LXC技术在Linux内核中对进程组管理的基础机制采用了namespace(命名空间)技术,使用Namespace(命名空间),可以让每个进程组具有独立的PID、IPC和网络空间,从而起到对进程组的隔离作用。
由于容器技术共享Linux内核,因此会容易产生更多的潜在漏洞,这些漏洞可以影响物理机上每个容器的操作,特别是当底层操作系统出现故障时。在这种情况下,所有容器中的工作负载会出现性能下降。对于出现故障的容器,目前的处理方式是将故障的容器删除,再重新创建一个容器来运行原有的进程组,这种做法虽然可以快速的恢复进程组的运行,但是由于原有的容器被删除,会导致根据原容器制定的访问路径失效,而新容器中的进程无法调用原有的数据内容。
发明内容
有鉴于此,本发明提供一种基于容器技术的进程故障处理方法及装置,能够有效修复故障容器,防止数据内容失效。
依据本发明一个方面,提出了一种基于容器技术的进程故障处理方法,该方法包括:
对容器的进程进行监控;
若发现容器的进程异常,则发出容器异常的报警信息;
根据所述报警信息对所述容器的进程进行修复恢复容器的正常运行。
依据本发明另一个方面,提出了一种基于容器技术的进程故障处理装置,该装置包括:
监控单元,用于对容器的进程进行监控;
报警单元,用于当所述监控单元发现容器的进程异常时,发出容器异常的报警信息;
修复单元,用于根据所述报警单元发出的报警信息对所述容器的进程进行修复恢复容器的正常运行。
本发明所采用的基于容器技术的进程故障处理方法及装置,是在容器化技术的环境下,通过对容器中的进程进行实时监控,在发现容器的进程异常时,可以根据报警信息快速准确地定位出现异常的容器位置,并对容器的进程进行修复,从而恢复容器的正常运行。相比于现有的容器故障处理方式,本发明的方法不需要再重新创建一个容器来运行原有的进程,而是对原有的容器进行修复,使原容器能够重新运行原有的进程,从而使原进程所创建的数据内容不会因访问路径的改变而失效作废。
上述说明仅是本发明技术方案的概述,为了能够更清楚了解本发明的技术手段,而可依照说明书的内容予以实施,并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂,以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
图1示出了本发明实施例提出的一种基于容器技术的进程故障处理方法的流程图;
图2示出了本发明实施例提出的另一种基于容器技术的进程故障处理方法的流程图;
图3示出了本发明实施例提出的一种基于容器技术的进程故障处理装置的组成框图;
图4示出了本发明实施例提出的第二种基于容器技术的进程故障处理装置的组成框图;
图5示出了本发明实施例提出的第三种基于容器技术的进程故障处理装置的组成框图;
图6示出了本发明实施例提出的第四种基于容器技术的进程故障处理装置的组成框图;
图7示出了本发明实施例提出的第五种基于容器技术的进程故障处理装置的组成框图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例,然而应当理解,可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本公开,并且能够将本公开的范围完整的传达给本领域的技术人员。
本发明实施例提供了一种基于容器技术的进程故障处理方法,如图1所示,该方法应用于运行有容器化技术环境的物理机上,该物理机上安装有监控客户端并运行有至少一个容器,具体步骤包括:
101、对容器的进程进行监控。
容器技术,可以视作一种轻量级的虚拟化技术手段。基于虚拟化技术,对已有的资源进行更细粒度的资源控制,为此,在Linux内核通过添加众所周知的cgroup技术,对服务运行时的环境进行隔离,被隔离出来的运行环境就称为容器。一般情况下,一台应用容器技术的物理机上会同时运行有多个容器,以供物理机同时执行多个服务进程。
为了对容器中的进程实施监控,首先是要获取该物理机上所有运行着的容器,本实施例是通过监控客户端向物理机发送容器获取指令,由物理机的Linux内核进行响应,将该物理机上运行的容器以及容器的标识信息发送给监控客户端。之后由监控客户端利用所获取到的标识信息在物理机上再次进行查询,获取对应容器中的进程信息。根据监控客户端的监控模式需要,可以设置成获取物理机中一个容器内的进程信息,也可以设置为对所有物理机中运行的容器逐一获取对应的进程信息,并将所获取到的进程信息与容器制成相对应的列表,本实施例对此不进行限定。
本实施例在对物理机上容器的进程进行监控,相对现有技术中的实现方式,可以实现对单独容器中的进程进行实时监控,获取进程的运行状态。
102、若发现容器的进程异常,则发出容器异常的报警信息。
进程退出意味着进程生命期的结束,系统资源被回收,进程从操作系统环境中销毁。进程异常退出是进程在运行过程中被意外终止,从而导致进程本来应该继续执行的任务无法完成。
进程异常退出可能给软件用户造成以下的负面影响:软件丧失部分或者全部功能性,无法完成既定任务;如果进程正在处理数据,可能造成数据损坏;如果是关键软件服务,必然导致服务异常中止,造成无法预计的损失;进程异常退出或者进程崩溃,也会给软件用户造成恐慌和困惑。
进程异常退出是生产环境中经常遇到的问题,但是导致进程异常退出的场景和原因是多种多样的,甚至令人琢磨不透。综合来看导致进程异常退出的这两类情况:
第一类:向进程发送信号导致进程异常退出;
第二类:代码错误导致进程运行时异常退出。
其中,第一类情况是因为外部环境向进程发送信号,这种情况下发送的信号是异步信号,信号的到来与进程的运行是异步的;第二类情况是进程非法操作触发处理器异常,然后异常处理函数在内核态向进程发送信号,这种情况下发送的信号是同步信号,信号的到来与进程的运行是同步的。这两种情况都有信号产生,并且最终都是信号处理程序终止进程运行。所以,信号是进程异常退出的直接原因。当进程异常退出时,进程必然接收到了信号。同时,监控客户端在对容器中的进程进行监控时,也必然会接收到信号,确定该进程异常退出。
在监控客户端发现有进程异常退出后,会发出报警信息,提示该容器的进程出现异常。
103、根据报警信息对容器的进程进行修复恢复容器的正常运行。
在监控客户端发出报警信息后,将查询报警信息中所提示的容器,并对其中的进程进行修复,恢复该容器的正常运行。需要指出的是,对容器的进程进行修复,可以在监控客户端发出报警后,自动对该容器的进程进行修复,也可以在监控客户端发出报警后,根据修复的指令信息决定是否对容器的进程进行修复,本实施例对此不进行限定。
结合上述的实现方式可以看出,本发明实施例所采用的基于容器技术的进程故障处理方法,是在容器化技术的环境下,通过对容器中的进程进行实时监控,在发现容器的进程异常时,可以根据报警信息快速准确地定位出现异常的容器位置,并对容器的进程进行修复,从而恢复容器的正常运行。相比于现有的容器故障处理方式,本发明的方法不需要再重新创建一个容器来运行原有的进程,而是对原有的容器进行修复,使原容器能够重新运行原有的进程,从而使原进程所创建的数据内容不会因访问路径的改变而失效作废。
为了更加详细地说明本发明提出的一种基于容器技术的进程故障处理方法,本实施例还提供了一种基于容器技术的进程故障处理方法,如图2所示,该方法包括:
201、获取容器的标识信息。
监控客户端在获取物理机上容器的标识信息时,首先,需要在物理机内设置一个容器识别模块,该容器识别模块是由监控客户端通过获取具有自动识别功能的脚本文件,并将该脚本文件解析后,添加上容器自动识别功能而构建出的一个具有容器自动识别功能的模块。其中,监控客户端在获取到具有自动识别功能的脚本文件后,首先需要确认该脚本文件可以在当前物理机的系统下被识别,如果无法识别,则需要对该脚本文件进行适配,获得可以在当前系统下可以识别的格式文件,在适配过程中可能涉及变量名称的更改、源代码的替换、改变调用的函数、初始化状态等,具体的适配方式已是现有技术手段,其具体做法本实施例就不再详细说明。
此外,容器识别获取模块在将获取到的脚本文件解析后,可以取得该脚本文件的源代码,之后在源代码中提取其中的自动识别功能的字段,然后修改该段源代码,将自动识别功能的识别范围限定为容器,之后将修改后的源代码进行格式化编译就获得了具有容器自动识别功能的脚本文件,通过该脚本文件的执行,就可令容器识别模块在物理机上自动识别获取容器了。
通过容器识别获取模块,监控客户端可以自动获取物理机中当前运行的容器。由于物理机上运行的容器数量并非是固定不变的,因此,监控客户端在每次执行监控指令时,都要先运行容器识别获取模块,以达到更新物理机当前系统中运行的容器数量的目的。
其次,在构建完成容器识别获取模块后,监控客户端会将该模块设置在物理机上,等待监控客户端的监控指令。当监控客户端启动,容器识别获取模块也将接收到执行指令,自动获取当前物理机上运行的所有容器以及相应的容器标识信息,并将所获取到的信息以列表的形式发送给监控客户端。在该列表中除了列出有当前运行的容器数量的信息外,容器的标识信息还包括有容器的名称以及容器的ID号。
202、根据容器的标识信息获取该容器的进程信息。
通过步骤201,监控客户端可以实现实时地获取物理机中运行的容器以及容器的标识信息。之后,再根据获取到的标识信息,主要是通过容器的ID号,到物理机的内存中查找该地址上的容器名称是否与所获取的容器名一致,若一致,则获取在该地址中运行的进程信息。
相对于现有的监控实现方式,本步骤可以获取Linux内核中单个容器的进程信息,从而可以实现对单个容器中的进程实施监控管理。
203、根据预定检测标准判断容器的进程信息是否异常。
监控客户端在获取到容器的进程信息后,会根据预定检测标准判断容器的进程信息是否异常。其中,预定检测标准为经验值,可以根据系统的需求进行值的改变,例如,在检测进程的CPU占用率时,可以设置该进程的占用率在超过80%时,视为异常情况并发出异常的报警信息,也可以设置在占用率为100%时,才视为异常情况并发出异常的报警信息。
204、若发现容器的进程异常,则发出容器异常的报警信息。
监控客户端所发出的报警信息中,含有进程异常容器的标识信息和异常的类型信息。其中,容器的标识信息在上文中已做说明,此处不再赘述。进程异常的类型信息用于简要说明该报警信息中进程出现异常的种类,在本实施例中主要包括:进程停止或者进程故障。进程停止是指当前进程停止运行,不能响应物理机的相关指令无法正常工作,而进程故障则是指当前进程已经停止并退出,更为严重的进程故障也称作进程崩溃。
进程停止和进程故障的区别在于,进程停止的情况下,该进程仍然存在,只是不再工作,而进程故障是该进程已经意外终止并退出,系统资源已被回收。
205、根据报警信息对容器的进程进行修复恢复容器的正常运行。
根据204中的说明,本实施例在对容器的进程进行修复时,也可以分为两种情况来处理:
第一种是当进程异常的类型信息为进程停止时,该进程本身还存在于容器内,对此监控客户端的修复方法为:
1)根据所述标识信息获取对应容器进程。
由于监控客户端中以获取过物理机中运行的容器的标识信息,因此,监控客户端只需要将报警信息中提取的容器标识信息与获取物理机中的容器的标识信息进行比对,找到相同的容器,再根据该容器的地址获取该容器中的进程信息。
2)向容器进程发送重启指令,重启所述容器进程。
在获取到进程信息后,监控客户端会查询该进程信息的内容,获取该进程的重启指令,并发送该指令以便在该容器中重启进程。
3)若所述容器进程重启成功,则恢复容器的正常运行。
重启后,监控客户端将持续监测该容器中的进程是否重启成功,如果判断重启成功,则监控客户端认为该容器已经恢复正常运行,将结束本次修复的流程。
4)若所述容器进程重启不成功,则获取进程运行的命令环境并初始化所述命令环境,实现对所述容器进程进行修复恢复容器的正常运行。
如果监控客户端判断本次重启不成功,那么将获取该进程运行的命令环境,即获取该进程所在容器的运行环境。由于物理机中的容器为一个独立的运行环境,因此,每一个容器的运行环境都可以根据运行进程的需要而设置,所以在同一个物理机中是可以存在不同运行系统的容器共存的。所以,在重启容器中的进程失败时,有可能是因为该进程的运行环境遭到破坏,对于此种情况,就可以将该容器的运行环境先进行初始化,从而恢复该进程的命令环境,而当进程的命令环境恢复后,进程将可以再次重新运行。
其中,由于进程运行的命令环境只是该进程在执行任务时完成具体操作的系统环境,并不涉及到与该进程相关的数据内容,因此,在初始化进程运行的命令环境后,并不会连同该进程的数据存储空间一同初始化。所以,初始化进程运行的命令环境可以在恢复异常进程的同时,还保留住原进程的相关数据。
第二种是当进程异常的类型信息为进程故障时,该进程已在容器的系统环境中被销毁,对此监控客户端的修复方法为:
1)根据所述标识信息获取对应容器进程。
2)获取进程运行的命令环境并初始化所述命令环境,实现对所述容器进程进行修复恢复容器的正常运行。
此种方式与上述的第一种情况的区别只是在于将其中对进程的重启步骤进行省略,因为进程本身已经被销毁,重启步骤也就没有了可执行的对象,因此,在本方式下就直接对进程运行的命令环境进行初始化,以达到恢复容器正常运行的目的。
以上两种方式中的进程运行的命令环境初始化步骤中,在完成命令环境的初始化后,监控客户端会发送运行指令,启动容器进程。此时,如果容器的进程恢复正常,监控客户端将结束本次的修复流程,如果容器的进程扔无法正常运行,监控客户端将向该容器发送进程的重启指令,容器在接收到该指令后,会在初始化的容器中重启该进程,从而恢复容器的正常运行。
进一步的,作为对上述方法的实现,本发明实施例提供了一种基于容器技术的进程故障处理装置,该装置设置于使用了容器化技术的物理机内,如图3所示,该装置包括:
监控单元31,用于对容器的进程进行监控。
报警单元32,用于当所述监控单元31发现容器的进程异常时,发出容器异常的报警信息。
修复单元33,用于根据所述报警单元32发出的报警信息对所述容器的进程进行修复恢复容器的正常运行。
进一步的,如图4所示,所述监控单元31包括:
第一获取子单元311,用于获取所述容器的标识信息。
第二获取子单元312,用于根据所述第一获取子单元311获取的所述容器的标识信息获取所述容器的进程信息。
判断子单元313,用于根据预定检测标准判断所述第二获取子单元312获取的所述容器的进程信息是否异常。
进一步的,如图5所示,所述第一获取子单元311包括:
构建模块3111,用于获取具有自动识别功能的脚本文件,对所述脚本文件进行解析后,将容器自动识别功能添加到所述脚本文件中,得到容器识别获取模块。
运行模块3112,用于运行所述构建模块3111得到的容器识别获取模块获取容器的标识信息。
进一步的,所述报警单元32发出的报警信息中包含进程异常容器的标识信息和异常的类型信息。
所述修复单元33根据所述标识信息和异常的类型信息,对对应的容器进程进行修复恢复容器的正常运行。
进一步的,所述报警单元32发出的进程异常的类型信息包括:进程停止或者进程故障。
进一步的,如图6所示,所述修复单元33包括:
第一获取子单元331,用于当所述进程异常的类型信息为进程停止时,根据所述标识信息获取对应容器进程。
重启子单元332,用于向所述第一获取子单元331获取的容器进程发送重启指令,重启所述容器进程。
恢复子单元333,用于判断当重启子单元332将容器进程重启成功时,恢复容器的正常运行。
第一初始化子单元334,用于判断当所述重启子单元332将容器进程重启不成功时,获取进程运行的命令环境并初始化所述命令环境,实现对所述容器进程进行修复恢复容器的正常运行。
进一步的,如图6所示,所述修复单元33包括:
第二获取子单元335,用于当所述进程异常的类型信息为进程故障时,根据所述标识信息获取对应容器进程。
第二初始化子单元336,用于获取所述第二获取子单元335获取的对应容器进程运行的命令环境并初始化所述命令环境,实现对所述容器进程进行修复恢复容器的正常运行。
进一步的,如图7所示,所述第一初始化子单元334包括:
初始化模块3341,用于初始化所述命令环境,并发送运行指令直接执行所述容器进程。
终止模块3342,用于当所述初始化模块3341已经恢复容器的正常运行时,结束修复。
发送模块3343,用于当所述初始化模块3341没有恢复容器的正常运行时,发出重启进程的提示信息。
重启模块3344,用于在接收到发送模块3343发出的重启进程的命令之后,重启所述容器的进程恢复容器的正常运行。
进一步的,如图7所示,所述第二初始化子单元336包括:
初始化模块3361,用于初始化所述命令环境,并发送运行指令直接执行所述容器进程。
终止模块3362,用于当所述初始化模块3361已经恢复容器的正常运行时,结束修复。
发送模块3363,用于当所述初始化模块3361没有恢复容器的正常运行时,发出重启进程的提示信息。
重启模块3364,用于在接收到发送模块3363发出的重启进程的命令之后,重启所述容器的进程恢复容器的正常运行。
综上所述,本发明实施例所采用的一种基于容器技术的进程故障处理方法及装置,是在容器化技术的环境下,通过对容器中的进程进行实时监控,在发现容器的进程异常时,可以根据报警信息快速准确地定位出现异常的容器位置,并对容器的进程进行修复,从而恢复容器的正常运行。相比于现有的容器故障处理方式,本发明的方法不需要再重新创建一个容器来运行原有的进程,而是对原有的容器进行修复,使原容器能够重新运行原有的进程,从而使原进程所创建的数据内容不会因访问路径的改变而失效作废。
本发明还公开了下述方案:
A1、一种基于容器技术的进程故障处理方法,所述方法包括:
对容器的进程进行监控;
若发现容器的进程异常,则发出容器异常的报警信息;
根据所述报警信息对所述容器的进程进行修复恢复容器的正常运行。
A2、根据A1所述的方法,所述对容器的进程进行监控包括:
获取所述容器的标识信息;
根据所述容器的标识信息获取所述容器的进程信息;
根据预定检测标准判断所述容器的进程信息是否异常。
A3、根据A2所述的方法,所述获取所述容器的标识信息包括:
获取具有自动识别功能的脚本文件,对所述脚本文件进行解析后,将容器自动识别功能添加到所述脚本文件中,得到容器识别获取模块;
运行所述容器识别获取模块获取容器的标识信息。
A4、根据A1所述的方法,所述报警信息中包含进程异常容器的标识信息和异常的类型信息;
根据所述标识信息和异常的类型信息,对对应的容器进程进行修复恢复容器的正常运行。
A5、根据A4所述的方法,所述进程异常的类型信息包括:进程停止或者进程故障。
A6、根据A5所述的方法,当所述进程异常的类型信息为进程停止时,根据所述标识信息和异常的类型信息,对对应的容器进程进行修复恢复容器的正常运行包括:
根据所述标识信息获取对应容器进程;
向所述容器进程发送重启指令,重启所述容器进程;
若所述容器进程重启成功,则恢复容器的正常运行;
若所述容器进程重启不成功,则获取进程运行的命令环境并初始化所述命令环境,实现对所述容器进程进行修复恢复容器的正常运行。
A7、根据A5所述的方法,当所述进程异常的类型信息为进程故障时,根据所述标识信息和异常的类型信息,对对应的容器进程进行修复恢复容器的正常运行包括:
根据所述标识信息获取对应容器进程;
获取进程运行的命令环境并初始化所述命令环境,实现对所述容器进程进行修复恢复容器的正常运行。
A8、根据A6或A7所述的方法,所述初始化所述命令环境,实现对所述容器进程进行修复恢复容器的正常运行包括:
初始化所述命令环境,并发送运行指令直接执行所述容器进程;
若已经恢复容器的正常运行,则结束修复;
若没有恢复容器的正常运行,则发出重启进程的提示信息;
在接收到重启进程的命令之后,重启所述容器的进程恢复容器的正常运行。
B9、一种基于容器技术的进程故障处理装置,所述装置包括:
监控单元,用于对容器的进程进行监控;
报警单元,用于当所述监控单元发现容器的进程异常时,发出容器异常的报警信息;
修复单元,用于根据所述报警单元发出的报警信息对所述容器的进程进行修复恢复容器的正常运行。
B10、根据B9所述的装置,所述监控单元包括:
第一获取子单元,用于获取所述容器的标识信息;
第二获取子单元,用于根据所述第一获取子单元获取的所述容器的标识信息获取所述容器的进程信息;
判断子单元,用于根据预定检测标准判断所述第二获取子单元获取的所述容器的进程信息是否异常。
B11、根据B10所述的装置,所述第一获取子单元包括:
构建模块,用于获取具有自动识别功能的脚本文件,对所述脚本文件进行解析后,将容器自动识别功能添加到所述脚本文件中,得到容器识别获取模块;
运行模块,用于运行所述构建模块得到的容器识别获取模块获取容器的标识信息。
B12、根据B9所述的装置,所述报警单元发出的报警信息中包含进程异常容器的标识信息和异常的类型信息;
所述修复单元根据所述标识信息和异常的类型信息,对对应的容器进程进行修复恢复容器的正常运行。
B13、根据B12所述的装置,所述报警单元发出的进程异常的类型信息包括:进程停止或者进程故障。
B14、根据B13所述的装置,所述修复单元包括:
第一获取子单元,用于当所述进程异常的类型信息为进程停止时,根据所述标识信息获取对应容器进程;
重启子单元,用于向所述第一获取子单元获取的容器进程发送重启指令,重启所述容器进程;
恢复子单元,用于判断当所述重启子单元将容器进程重启成功时,恢复容器的正常运行;
第一初始化子单元,用于判断当所述重启子单元将容器进程重启不成功时,获取进程运行的命令环境并初始化所述命令环境,实现对所述容器进程进行修复恢复容器的正常运行。
B15、根据B13所述的装置,所述修复单元包括:
第二获取子单元,用于当所述进程异常的类型信息为进程故障时,根据所述标识信息获取对应容器进程;
第二初始化子单元,用于获取所述第二获取子单元获取的对应容器进程运行的命令环境并初始化所述命令环境,实现对所述容器进程进行修复恢复容器的正常运行。
B16、根据B14所述的装置,所述第一初始化子单元包括:
初始化模块,用于初始化所述命令环境,并发送运行指令直接执行所述容器进程;
终止模块,用于当所述初始化模块已经恢复容器的正常运行时,结束修复;
发送模块,用于当所述初始化模块没有恢复容器的正常运行时,发出重启进程的提示信息;
重启模块,用于在接收到发送模块发出的重启进程的命令之后,重启所述容器的进程恢复容器的正常运行。
B17、根据B15所述的装置,所述第二初始化子单元包括:
初始化模块,用于初始化所述命令环境,并发送运行指令直接执行所述容器进程;
终止模块,用于当所述初始化模块已经恢复容器的正常运行时,结束修复;
发送模块,用于当所述初始化模块没有恢复容器的正常运行时,发出重启进程的提示信息;
重启模块,用于在接收到发送模块发出的重启进程的命令之后,重启所述容器的进程恢复容器的正常运行。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
可以理解的是,上述方法及装置中的相关特征可以相互参考。另外,上述实施例中的“第一”、“第二”等是用于区分各实施例,而并不代表各实施例的优劣。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述,构造这类系统所要求的结构是显而易见的。此外,本发明也不针对任何特定编程语言。应当明白,可以利用各种编程语言实现在此描述的本发明的内容,并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中,说明了大量具体细节。然而,能够理解,本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中,并未详细示出公知的方法、结构和技术,以便不模糊对本说明书的理解。
类似地,应当理解,为了精简本公开并帮助理解各个发明方面中的一个或多个,在上面对本发明的示例性实施例的描述中,本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而,并不应将该公开的方法解释成反映如下意图:即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说,如下面的权利要求书所反映的那样,发明方面在于少于前面公开的单个实施例的所有特征。因此,遵循具体实施方式的权利要求书由此明确地并入该具体实施方式,其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解,可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件,以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外,可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述,本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外,本领域的技术人员能够理解,尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征,但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如,在下面的权利要求书中,所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现,或者以在一个或者多个处理器上运行的软件模块实现,或者以它们的组合实现。本领域的技术人员应当理解,可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的发明名称(如确定网站内链接等级的装置)中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如,计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上,或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到,或者在载体信号上提供,或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制,并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中,不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中,这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (11)

1.一种基于容器技术的进程故障处理方法,其特征在于,所述方法包括:
对容器中的进程进行监控;
若发现所述容器中的进程异常,则发出容器异常的报警信息,所述报警信息中包含进程异常容器的标识信息和异常的类型信息,而所述进程异常的类型信息包括进程停止或者进程故障;
根据所述报警信息对所述容器中的进程进行修复恢复容器的正常运行;
当所述进程异常的类型信息为进程停止时,所述根据所述报警信息对所述容器中的进程进行修复恢复容器的正常运行包括:
根据所述标识信息获取对应容器中的进程;
向所述容器中的进程发送重启指令,重启所述容器中的进程;
若所述容器中的进程重启成功,则恢复容器的正常运行;
若所述容器中的进程重启不成功,则获取进程运行的命令环境并初始化所述命令环境,实现对所述容器中的进程进行修复恢复容器的正常运行。
2.根据权利要求1所述的方法,其特征在于,所述对容器中的进程进行监控包括:
获取所述容器的标识信息;
根据所述容器的标识信息获取所述容器中的进程信息;
根据预定检测标准判断所述容器中的进程信息是否异常。
3.根据权利要求2所述的方法,其特征在于,所述获取所述容器的标识信息包括:
获取具有自动识别功能的脚本文件,对所述脚本文件进行解析后,将容器自动识别功能添加到所述脚本文件中,得到容器识别获取模块;
运行所述容器识别获取模块获取容器的标识信息。
4.根据权利要求1所述的方法,其特征在于,当所述进程异常的类型信息为进程故障时,根据所述标识信息和异常的类型信息,对对应的容器中的进程进行修复恢复容器的正常运行包括:
根据所述标识信息获取对应容器中的进程;
获取进程运行的命令环境并初始化所述命令环境,实现对所述容器中的进程进行修复恢复容器的正常运行。
5.根据权利要求1或4所述的方法,其特征在于,所述初始化所述命令环境,实现对所述容器中的进程进行修复恢复容器的正常运行包括:
初始化所述命令环境,并发送运行指令直接执行所述容器中的进程;
若已经恢复容器的正常运行,则结束修复;
若没有恢复容器的正常运行,则发出重启进程的提示信息;
在接收到重启进程的命令之后,重启所述容器中的进程恢复容器的正常运行。
6.一种基于容器技术的进程故障处理装置,其特征在于,所述装置包括:
监控单元,用于对容器中的进程进行监控;
报警单元,用于当所述监控单元发现所述容器中的进程异常时,发出容器异常的报警信息,所述报警信息中包含进程异常容器的标识信息和异常的类型信息,而所述进程异常的类型信息包括进程停止或者进程故障;
修复单元,用于根据所述报警单元发出的报警信息对所述容器中的进程进行修复恢复容器的正常运行;
当所述进程异常的类型信息为进程停止时,所述修复单元包括:
第一获取子单元,用于当所述进程异常的类型信息为进程停止时,根据所述标识信息获取对应容器中的进程;
重启子单元,用于向所述第一获取子单元获取的容器中的进程发送重启指令,重启所述容器中的进程;
恢复子单元,用于判断当所述重启子单元将容器中的进程重启成功时,恢复容器的正常运行;
第一初始化子单元,用于判断当所述重启子单元将容器中的进程重启不成功时,获取进程运行的命令环境并初始化所述命令环境,实现对所述容器中的进程进行修复恢复容器的正常运行。
7.根据权利要求6所述的装置,其特征在于,所述监控单元包括:
第一获取子单元,用于获取所述容器的标识信息;
第二获取子单元,用于根据所述第一获取子单元获取的所述容器的标识信息获取所述容器中的进程信息;
判断子单元,用于根据预定检测标准判断所述第二获取子单元获取的所述容器中的进程信息是否异常。
8.根据权利要求7所述的装置,其特征在于,所述第一获取子单元包括:
构建模块,用于获取具有自动识别功能的脚本文件,对所述脚本文件进行解析后,将容器自动识别功能添加到所述脚本文件中,得到容器识别获取模块;
运行模块,用于运行所述构建模块得到的容器识别获取模块获取容器的标识信息。
9.根据权利要求6所述的装置,其特征在于,所述修复单元包括:
第二获取子单元,用于当所述进程异常的类型信息为进程故障时,根据所述标识信息获取对应容器中的进程;
第二初始化子单元,用于获取所述第二获取子单元获取的对应容器中的进程运行的命令环境并初始化所述命令环境,实现对所述容器中的进程进行修复恢复容器的正常运行。
10.根据权利要求6所述的装置,其特征在于,所述第一初始化子单元包括:
初始化模块,用于初始化所述命令环境,并发送运行指令直接执行所述容器中的进程;
终止模块,用于当所述初始化模块已经恢复容器的正常运行时,结束修复;
发送模块,用于当所述初始化模块没有恢复容器的正常运行时,发出重启进程的提示信息;
重启模块,用于在接收到发送模块发出的重启进程的命令之后,重启所述容器中的进程恢复容器的正常运行。
11.根据权利要求9所述的装置,其特征在于,所述第二初始化子单元包括:
初始化模块,用于初始化所述命令环境,并发送运行指令直接执行所述容器中的进程;
终止模块,用于当所述初始化模块已经恢复容器的正常运行时,结束修复;
发送模块,用于当所述初始化模块没有恢复容器的正常运行时,发出重启进程的提示信息;
重启模块,用于在接收到发送模块发出的重启进程的命令之后,重启所述容器中的进程恢复容器的正常运行。
CN201510375126.1A 2015-06-30 2015-06-30 基于容器技术的进程故障处理方法及装置 Active CN104915263B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510375126.1A CN104915263B (zh) 2015-06-30 2015-06-30 基于容器技术的进程故障处理方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201510375126.1A CN104915263B (zh) 2015-06-30 2015-06-30 基于容器技术的进程故障处理方法及装置

Publications (2)

Publication Number Publication Date
CN104915263A CN104915263A (zh) 2015-09-16
CN104915263B true CN104915263B (zh) 2019-04-19

Family

ID=54084344

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201510375126.1A Active CN104915263B (zh) 2015-06-30 2015-06-30 基于容器技术的进程故障处理方法及装置

Country Status (1)

Country Link
CN (1) CN104915263B (zh)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106301983A (zh) * 2015-05-29 2017-01-04 阿里巴巴集团控股有限公司 一种基于虚拟主机的网站检测方法和装置
CN105389243B (zh) * 2015-10-26 2018-06-05 华为技术有限公司 一种容器监控方法和装置
CN106933659B (zh) * 2015-12-30 2020-06-26 华为技术有限公司 管理进程的方法和装置
CN106375372B (zh) * 2016-08-23 2019-12-06 东方网力科技股份有限公司 一种大数据资源分配方法和装置
CN107783854B (zh) * 2016-08-29 2021-08-20 华为技术有限公司 处理进程的方法及其装置
CN106445634A (zh) * 2016-09-22 2017-02-22 乐视控股(北京)有限公司 一种容器的监控方法及装置
CN108595191B (zh) * 2018-04-27 2021-09-14 京东方科技集团股份有限公司 一种应用安装方法及装置
CN108632378B (zh) * 2018-05-11 2021-04-27 国云科技股份有限公司 一种面向云平台业务的监控方法
CN108718253A (zh) * 2018-05-11 2018-10-30 新华三技术有限公司 一种问题定位方法及装置
CN112148420B (zh) * 2019-06-28 2024-04-02 杭州海康威视数字技术股份有限公司 基于容器技术的异常任务处理方法、服务器及云平台
CN111324423B (zh) * 2020-03-03 2022-03-04 腾讯科技(深圳)有限公司 容器内进程的监控方法、装置、存储介质和计算机设备
CN113726553A (zh) * 2021-07-29 2021-11-30 浪潮电子信息产业股份有限公司 一种节点故障恢复方法、装置、电子设备及可读存储介质
CN113535249A (zh) * 2021-08-02 2021-10-22 京东数科海益信息科技有限公司 数据处理方法、装置、设备、存储介质及程序产品
CN114416284A (zh) * 2021-12-24 2022-04-29 北京百度网讯科技有限公司 分布式作业系统控制方法、装置、设备、介质及程序产品

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103365758A (zh) * 2013-08-05 2013-10-23 北京搜狐新媒体信息技术有限公司 一种虚拟化环境下的进程监控方法及系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100410891C (zh) * 2002-12-09 2008-08-13 联想(北京)有限公司 计算机应用软件自纠错自重起方法
JP4819644B2 (ja) * 2006-10-12 2011-11-24 株式会社日立製作所 情報処理システム、情報処理方法、情報処理装置
CN103491134B (zh) * 2013-08-30 2016-12-28 华为技术有限公司 一种监控容器的方法、装置与代理服务系统

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103365758A (zh) * 2013-08-05 2013-10-23 北京搜狐新媒体信息技术有限公司 一种虚拟化环境下的进程监控方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Docker 简单监控;codeweblog;《http://www.codeweblog.com/docker-简单监控/》;20140307;第1-3页

Also Published As

Publication number Publication date
CN104915263A (zh) 2015-09-16

Similar Documents

Publication Publication Date Title
CN104915263B (zh) 基于容器技术的进程故障处理方法及装置
US11226874B1 (en) System and method for hybrid kernel and user-space checkpointing using a character device
US8782666B2 (en) Methods and platforms for highly available execution of component software
KR101470712B1 (ko) 컴퓨터 애플리케이션에서의 데이터 손실을 최소화하기 위한 방법 및 시스템
Fagg et al. FT-MPI: Fault tolerant MPI, supporting dynamic applications in a dynamic world
US7908521B2 (en) Process reflection
US9996378B2 (en) Managing a check-point based high-availability backup virtual machine
US7685474B2 (en) Failsafe computer support assistant using a support virtual machine
US9058263B2 (en) Automated fault and recovery system
Candea et al. Recovery-oriented computing: Building multitier dependability
CN100461130C (zh) 测试软件应用的方法
US9448895B2 (en) Recording activity of software threads in a concurrent software environment
US8015432B1 (en) Method and apparatus for providing computer failover to a virtualized environment
CN110727547A (zh) 一种保护Docker应用容器的系统及方法
CN104391777A (zh) 基于Linux操作系统的云平台及其运行监控方法和装置
CN107943617B (zh) 数据的修复方法、装置及服务器集群
CN113535532A (zh) 故障注入系统、方法和装置
US8448014B2 (en) Self-healing failover using a repository and dependency management system
US20210149756A1 (en) Variable memory diagnostics
Etchevers et al. Reliable self-deployment of cloud applications
CN114090434B (zh) 一种代码调试方法、装置、计算机设备和存储介质
US20220334825A1 (en) Modular firmware update
US11625307B1 (en) System and method for hybrid kernel- and user-space incremental and full checkpointing
Huang et al. {PYLIVE}:{On-the-Fly} Code Change for Python-based Online Services
Jann et al. An os-hypervisor infrastructure for automated os crash diagnosis and recovery in a virtualized environment

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20220722

Address after: 300450 No. 9-3-401, No. 39, Gaoxin 6th Road, Binhai Science Park, Binhai New Area, Tianjin

Patentee after: 3600 Technology Group Co.,Ltd.

Address before: 100088 room 112, block D, 28 new street, new street, Xicheng District, Beijing (Desheng Park)

Patentee before: BEIJING QIHOO TECHNOLOGY Co.,Ltd.

Patentee before: Qizhi software (Beijing) Co.,Ltd.

TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20230710

Address after: 1765, floor 17, floor 15, building 3, No. 10 Jiuxianqiao Road, Chaoyang District, Beijing 100015

Patentee after: Beijing Hongxiang Technical Service Co.,Ltd.

Address before: 300450 No. 9-3-401, No. 39, Gaoxin 6th Road, Binhai Science Park, Binhai New Area, Tianjin

Patentee before: 3600 Technology Group Co.,Ltd.

TR01 Transfer of patent right