CN116185956A - 分布式系统中设备故障巡检方法、装置、设备和介质 - Google Patents
分布式系统中设备故障巡检方法、装置、设备和介质 Download PDFInfo
- Publication number
- CN116185956A CN116185956A CN202310149572.5A CN202310149572A CN116185956A CN 116185956 A CN116185956 A CN 116185956A CN 202310149572 A CN202310149572 A CN 202310149572A CN 116185956 A CN116185956 A CN 116185956A
- Authority
- CN
- China
- Prior art keywords
- log
- keyword
- logs
- equipment
- target
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/14—Details of searching files based on file metadata
- G06F16/148—File search processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/14—Details of searching files based on file metadata
- G06F16/144—Query formulation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
- G06F16/1815—Journaling file systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/205—Parsing
- G06F40/216—Parsing using statistical methods
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Library & Information Science (AREA)
- Mathematical Physics (AREA)
- Probability & Statistics with Applications (AREA)
- Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请提供一种分布式系统中设备故障巡检方法、装置、设备和介质,涉及金融科技领域或其他相关领域,该方法包括:从日志中心获取分布式系统中每个设备产生的日志;获取关键词并确定每个关键词的检索顺序,关键词包括加载缓存失败、异常、重启失败中的至少一种,不同的关键词的检索顺序不相同;根据每个关键词的检索顺序,从日志中检索出与关键词匹配的目标日志;根据目标日志,确定分布式系统中的设备是否存在故障。该技术方案通过关键词来从海量的日志文件中检索出与关键词匹配的目标日志,然后对目标日志进行分析即可精准的定位到所有报错信息,并确定出产生该日志文件的设备是否存在故障,提高巡检的效率和准确性。
Description
技术领域
本申请涉及金融科技领域或其他相关领域,尤其涉及一种分布式系统中设备故障巡检方法、装置、设备和介质。
背景技术
在分布式场景下,设备的数量较多而且通常都处于不同的空间地域,为此设备的巡检通常都是基于日志进行的,而由于设备的数量较多,产生的日志数量也很大,需要从海量的日志文件中巡检出异常设备较为困难。
现有技术中,在对设备进行巡检时,一般采用的是人工巡检的方式,即人工取出所有设备的日志文件,然后对日志文件进行排查以确定是否有异常现象对应的故障。但是,这种人工巡检的方式成本高,效率低。
发明内容
本申请提供一种分布式系统中设备故障巡检方法、装置、设备和介质,用于解决现有人工对设备巡检效率低,成本高的问题。
第一方面,本申请提供一种分布式系统中设备故障巡检方法,包括:
从日志中心获取分布式系统中每个设备产生的日志,不同的设备产生的日志存储在所述日志中心的不同目录下;
获取关键词并确定每个关键词的检索顺序,所述关键词包括加载缓存失败、异常、重启失败中的至少一种,不同的关键词的检索顺序不相同;
根据每个关键词的检索顺序,从所述日志中检索出与所述关键词匹配的目标日志;
根据所述目标日志,确定所述分布式系统中的设备是否存在故障。
在第一方面的一种可能设计中,所述获取关键词并确定每个关键词的检索顺序,包括:
获取关键词并确定每个关键词的重要程度;
根据每个关键词的重要程度,确定每个关键词的检索顺序;
对应的,所述根据每个关键词的检索顺序,从所述日志中检索出与所述关键词匹配的目标日志,包括:
从所述日志中检索确定是否存在与检索顺序靠前的关键词匹配的第一日志;
若从所述日志中检索得到与检索顺序靠前的关键词匹配的第一日志,则直接将所述第一日志作为所述目标日志;
若从所述日志中检索不到与检索顺序靠前的关键词匹配的第一日志,则继续从所述日志中检索出与检索顺序靠后的关键词匹配的第二日志,并将所述第二日志作为所述目标日志。
在第一方面的另一种可能设计中,所述根据所述目标日志,确定所述分布式系统中的设备是否存在故障,包括:
确定产生所述目标日志的设备的类别、所述关键词在所述目标日志中出现的次数,所述设备至少分为核心设备和非核心设备两种类别;
若所述设备为核心设备且所述关键词在所述目标日志中出现的次数大于或等于1,则根据所述核心设备产生的目标日志,确定所述核心设备是否存在故障。
在第一方面的再一种可能设计中,所述根据所述目标日志,确定所述分布式系统中的设备是否存在故障,包括:
当所述设备为非核心设备且所述关键词在所述目标日志中出现的次数大于1时,继续确定所述关键词在所述目标日志中出现的次数是否大于或等于预设阈值,
若所述关键词在所述目标日志中出现的次数大于或等于预设阈值,则根据所述非核心设备产生的目标日志,确定所述非核心设备是否存在故障。
在第一方面的又一种可能设计中,所述方法还包括:
根据各个设备所属的类别,对各个设备产生的日志进行分类,所述设备至少分为核心设备和非核心设备两种类别;
将不同类别的日志分别存储至所述日志中心的不同目录下。
在第一方面的又一种可能设计中,所述根据每个关键词的检索顺序,从所述日志中检索出与所述关键词匹配的目标日志,包括:
获取存储在第一目录下的日志和存储在第二目录下的日志,所述第一目录下存储的日志为所述核心设备产生的,所述第二目录下存储的日志为所述非核心设备产生的;
根据每个关键词的检索顺序,从所述第一目录下存储的日志中检索确定是否存在与所述关键词匹配的日志;
若所述第一目录下存在与所述关键词匹配的日志,则将该日志作为目标日志;
若所述第一目录下不存在与所述关键词匹配的日志,则从所述第二目录下的日志中检索出与所述关键词匹配的日志,作为目标日志。
在第一方面的又一种可能设计中,所述根据所述目标日志,确定所述分布式系统中的设备是否存在故障,包括:
获取在所述目标日志中出现所述关键词时,产生该目标日志的设备的巡检指标,所述巡检指标至少包括CPU占用数据、内存使用数据、磁盘读写数据繁忙度中的至少一种;
根据所述巡检指标,确定所述设备是否存在故障。
在第一方面的又一种可能设计中,所述方法还包括:若所述设备存在故障,则输出报警信息。
第二方面,本申请提供一种分布式系统中设备故障巡检装置,包括:
日志获取模块,用于从日志中心获取分布式系统中每个设备产生的日志,不同的设备产生的日志存储在所述日志中心的不同目录下;
顺序确定模块,用于获取关键词并确定每个关键词的检索顺序,所述关键词包括加载缓存失败、异常、重启失败中的至少一种,不同的关键词的检索顺序不相同;
日志检索模块,用于根据每个关键词的检索顺序,从所述日志中检索出与所述关键词匹配的目标日志;
故障判定模块,用于根据所述目标日志,确定所述分布式系统中的设备是否存在故障。
第三方面,本申请实施例提供一种计算机设备,包括:处理器,以及与所述处理器通信连接的存储器;所述存储器存储计算机执行指令;所述处理器执行所述存储器存储的计算机执行指令,以实现如上述的方法。
第四方面,本申请实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机指令,所述计算机指令被处理器执行时用于实现如上述的方法。
第五方面,本申请实施例提供一种计算机程序产品,包括计算机指令,该计算机指令被处理器执行时实现上述的方法。
本申请实施例提供的分布式系统中设备故障巡检方法、装置、设备和介质,通过关键词来从海量的日志文件中检索出与关键词匹配的目标日志,然后对目标日志进行分析即可精准的定位到所有报错信息,并确定出产生该日志文件的设备是否存在故障,提高巡检的效率和准确性。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本申请的实施例,并与说明书一起用于解释本申请的原理;
图1为本申请实施例提供的设备故障巡检系统的示意图;
图2为本申请实施例提供的分布式系统中设备故障巡检方法流程示意图;
图3为本申请另一实施例提供的分布式系统中设备故障巡检方法的流程示意图;
图4为本申请实施例提供的分布式系统中设备故障巡检装置结构示意图;
图5为本申请实施例提供的计算机设备的结构示意图。
通过上述附图,已示出本申请明确的实施例,后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围,而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
需要说明的是,本公开分布式系统中设备故障巡检方法、装置、设备和介质可用于金融领域。也可用于除金融领域以外的任意领域。本公开分布式系统中设备故障巡检方法、装置、设备和介质应用领域不作限定。
目前在分布式系统中由于设备的数量较多,产生日志的数量也非常多,在对设备进行巡检时,一般采用的是人工巡检的方式确定是否有异常现象对应的故障(例如人工拿出设备应用的日志。但是在实际应用中,由于手工分析日志也是抽样性的(日志数量多,不便于遍历),设备的异常报错可能发现不了,比如设备自动进行重启,但是健康检测(如心跳检测)又没有检查出问题,只有到外部交易过来,发生交易失败了该设备才会被关注,并且通过人工巡检的方式确定是否有异常现象对应的故障,人工成本高,效率低。
针对上述问题,本申请实施例提供了一种分布式系统中设备故障巡检方法、装置、设备和介质,通过关键词来从海量的日志文件中检索出与关键词匹配的目标日志,然后对目标日志进行分析即可精准的定位到所有报错信息,并确定出产生该日志文件的设备是否存在故障,提高巡检的效率和准确性。
下面,通过具体实施例对本申请的技术方案进行详细说明。需要说明的是,下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例中不再赘述。
图1为本申请实施例提供的设备故障巡检系统的示意图,如图1所示,应用容器引擎(又称为Docker)可以让开发者打包他们的应用以及依赖包到一个可移植的镜像中,然后发布到任何流行的操作系统的机器上,也可以实现虚拟化。容器集群管理系统(例如kubernetes,简称K8s)可以在集群的每个节点上运行特定的程序,来对节点中的容器进行管理,目的是实现资源管理的自动化,以kubernetes作为容器集群管理系统为例,其中Pod是k8s系统中可以创建和管理的最小调度单元,是资源对象模型中由用户创建或部署的最小资源对象模型,也是在k8s上运行容器化应用的资源对象,其他的资源对象都是用来支撑或者扩展Pod对象功能的。消息中间件(例如kafka)是一种高吞吐量的分布式发布订阅消息系统,它可以处理消费者在网站中的所有动作流数据。搜索与数据分析引擎(例如Elasticsearch)能很方便的使大量数据具有搜索、分析和探索的能力。系统资源采集器在安装到设备的操作系统上之后,即可采集数据。
其中,设备应用所产生的日志文件主要通过日志采集器进行采集,之后通过搜索与数据分析引擎自带的搜索能力,发现哪些日志里面的记录存在错误,然后通过巡检节点进行异常检测分析,确定出设备是否存在故障。同时,存在错误的日志还可以由搜索与数据分析引擎反馈给日志分析可视化分析前端,实现错误日志的直观展示。
图2为本申请实施例提供的分布式系统中设备故障巡检方法流程示意图,该方法可以应用于上述的设备故障巡检系统,如图2所示,该方法具体可以包括如下步骤:步骤S201,从日志中心获取分布式系统中每个设备产生的日志,不同设备产生的日志存储在日志中心的不同目录下。
在本实施例中,分布式系统的设备数量较多,并且不同的设备可能位于不同的空间地域,设备是否存在故障通常只能通过其设备应用的日志文件来判定,当日志文件中出现异常信息时,则该设备可能存在故障。但是每个设备的应用所产生的日志数量更多,示例性的,日志可以通过ElasticSearch的存储库按照结构化的形式存储,其前端的分布式应用可以基于ElasticSearch提供的搜索能力,去发现哪些日志里面存在异常信息并显示到前端界面,针对这些异常信息就可以直接定位到前端的业务功能上,实现故障原因的快速排查。
其中,在ElasticSearch的存储库中可以配置多个目录,不同的设备所产生的日志可以存储到不同的目录下,例如设备A为核心设备,其产生的日志对应的存储的核心目录下,而设备B为非核心设备,其产生的日志对应的存储到非核心目录下。示例性的,在其他实施例中,还可以根据设备所承载的业务功能、安装的应用软件、所处空间区域等,为该设备所产生的日志配置对应的存储目录。
步骤S202,获取关键词并确定每个关键词的检索顺序,关键词包括加载缓存失败、异常、重启失败中的至少一种,不同的关键词的检索顺序不相同。
在本实施例中,当关键词只有一种时(例如只有加载缓存失败),则该关键词既可以视为检索顺序靠前的,又可以视为检索顺序靠后的,当关键词具有两种以上时(例如加载缓存失败和重启失败),则可以为加载缓存失败和重启失败分别配置检索顺序,例如配置加载缓存失败这一关键词的检索顺序为检索顺序靠前,配置重启失败这一关键词的检索顺序为检索顺序靠后。
其中,可以根据每个关键词的重要程度来为每个关键词配置检索顺序,例如加载缓存失败这一关键词的重要程度较高,则给其配置的检索顺序为检索顺序靠前。
步骤S203,根据每个关键词的检索顺序,从日志中检索出与关键词匹配的目标日志。
在本实施例中,可以按照每个关键词的检索顺序,依序展开检索。示例性的,以检索顺序靠前的加载缓存失败和检索顺序靠后的重启失败这两个关键词为例,可以先从日志中检索出与加载缓存失败匹配的日志,然后再从日志中检索出与重启失败匹配的日志,基于这两个检索出的日志来确定出目标日志。
示例性的,在其他实施方式中,当存在两个以上的关键词且这两个关键词的检索顺序是相同的情况时,则可以构建正则表达式,同时在日志中进行检索与这两个关键词均匹配的日志或者与这两个关键词中任意一个相匹配的日志,然后再从检索出的日志中确定出目标日志。例如关键词C1和关键词C2的检索顺序是相同的,则可以构建正则表达式同时进行检索,在日志文件中查找出与关键词C1和/或关键词C2匹配的日志。
步骤S204,根据目标日志,确定分布式系统中的设备是否存在故障。
在本实施例中,可以通过对目标日志进行分析,根据目标日志中的异常信息(即与关键词匹配的信息)确定设备是否存在故障。示例性的,在其他实施方式中,还可以基于日志所产生的时间、异常信息定位设备故障。
本申请实施例通过关键词来从海量的日志文件中检索出与关键词匹配的目标日志,然后对目标日志进行分析即可精准的定位到所有报错信息,并确定出产生该日志文件的设备是否存在故障,提高巡检的效率和准确性。
图3为本申请另一实施例提供的分布式系统中设备故障巡检方法的流程示意图,在上述实施例的基础上,如图3所示,上述步骤S202具体可以通过如下步骤实现:步骤S301,获取关键词并确定每个关键词的重要程度。步骤S302,根据每个关键词的重要程度,确定每个关键词的检索顺序。对应的,上述步骤S203具体可以通过如下步骤实现:步骤S303,从日志检索确定是否存在与检索顺序靠前的关键词匹配的第一日志。步骤S304,若从日志检索得到与检索顺序靠前的关键词匹配的第一日志,则直接将第一日志作为目标日志。步骤S305,若从日志中检索不到与检索顺序靠前的关键词匹配的第一日志,则继续从日志检索出与检索顺序靠后的关键词匹配的第二日志,并将第二日志作为目标日志。
在本实施例中,可以配置关键词的重要程度,例如将上述的加载缓存失败、重启失败配置这两个词为重要程度较高的核心关键词,而异常这一词配置为重要程度较低的非核心关键词。其中,核心关键词的检索顺序靠前,而非核心关键词的检索顺序靠后。关键词的重要程度越高,则说明当日志中存在与该关键词匹配的日志时,设备存在的故障可能性越高。
其中,在进行检索时,由于日志数量较多容易造成检索耗费较多的时间,故而可以优先检索重要程度较高(即检索顺序靠前)的关键词,如果日志中存在有与检索顺序靠前的关键词匹配的第一日志,则可以先基于第一日志进行故障分析,确定分布式系统中该设备是否存在故障。如此可以及时尽快的发现故障,提高对故障的响应速度。
示例性的,在其它实施方式中,还可以包括如下步骤:从日志检索确定是否存在与检索顺序靠前的关键词匹配的第一日志;若从日志检索得到与检索顺序靠前的关键词匹配的第一日志,则继续从日志检索出与检索顺序靠后的关键词匹配的第二日志,并将第一日志和/或第二日志作为目标日志。
其中,当检索出第一日志之后,在不考虑检索耗时的情况下,可以继续检索确定出第二日志,基于第一日志和第二日志分析确定设备是否存在故障,能够使得故障判定的准确性更高。
本申请实施例通过配置关键词的检索顺序,可以结合实际情况灵活的进行检索得到目标日志,提高设备故障巡检的灵活性。
在一些实施例中,上述步骤S204具体可以通过如下步骤实现:确定产生目标日志的设备的类别、关键词在目标日志中出现的次数,设备至少分为核心设备和非核心设备两种类别;若设备为核心设备且关键词在目标日志中出现的次数大于或等于1,则根据核心设备产生的目标日志,确定核心设备是否存在故障。
在本实施例中,关键词通常是一些异常信息,如果日志中出现关键词,则说明该日志存在异常,产生该日志的设备可能存在故障,故而可以配置日志中关键词的出现次数,例如对于一些核心设备的应用,其不能够容忍任何一次异常现象,如果该核心设备的应用所产生的日志中出现过一次关键词(例如加载缓存失败),就需要去分析查找故障原因。
另外,在其他实施方式中,还可以包括如下步骤:确定产生目标日志的设备的类别、在目标日志中出现的关键词的重要程度;若设备为核心设备且关键词为核心关键词,则根据核心设备产生的目标日志,确定核心设备是否存在故障。
其中,对于核心设备而言,其同样不能够容忍日志中出现核心关键词,核心关键词的出现通常表征了该设备有较大的故障可能性,为此该日志中出现核心关键词,就需要进行故障分析。进一步的,如果目标日志中出现的是非核心关键词,则可以跳过,不进行故障分析。
本申请实施例通过配置关键词的出现次数和设备的所属类别,可以对一些核心设备进行重点关注,一旦其产生的日志出现关键词,则会对该日志进行分析以确定核心设备是否存在故障,保障核心设备的安全。
进一步的,在上述实施例的基础上,在另一些实施例中,当设备为非核心设备且关键词在目标日志中出现的次数大于1时,继续确定关键词在目标日志中出现的次数是否大于或等于预设阈值,若关键词在目标日志中出现的次数大于或等于预设阈值,则根据非核心设备产生的目标日志,确定非核心设备是否存在故障。
其中,预设阈值为大于1的正整数,示例性的,预设阈值可以取值为3。
在本实施例中,当非核心设备所产生的目标日志中关键词出现次数大于或等于3次时,则可以对该目标日志进行分析,确定是否存在故障。而如果关键词出现次数小于3次,则可以跳过,不进行故障分析。这主要是考虑到分布式系统中设备的数量较多,对于一些非核心设备来说,如果其目标日志每出现一次关键词就进行一次故障分析,会占用数据处理资源,影响核心设备的故障分析效率。
另外,在另一些实施例中,还可以包括如下步骤:确定产生目标日志的设备的类别、在目标日志中出现的关键词的重要程度;若设备为非核心设备且关键词为核心关键词,则根据核心设备产生的目标日志,确定核心设备是否存在故障。
其中,对于非核心设备而言,其同样不能够容忍日志中出现核心关键词,核心关键词的出现通常表征了该设备有较大的故障可能性,为此该日志中出现核心关键词,就需要进行故障分析。进一步的,如果目标日志中出现的是非核心关键词,则可以跳过,不进行故障分析。
本申请实施例通过配置关键词出现的次数和设备所属的类别,当非核心设备所产生的目标日志出现关键词的次数小于预设阈值时可以直接跳过,不进行故障分析,减少故障分析所占用的资源,提高核心设备的分析效率。
在一些实施例中,上述方法还包括如下步骤:根据各个设备所属的类别,对各个设备产生的日志进行分类,设备至少分为核心设备和非核心设备两种类别;将不同类别的日志分别存储至日志中心的不同目录下。
在本实施例中,核心设备所产生的日志可以存储到核心目录下,而非核心设备所产生的日志可以存储到非核心目标下。
示例性的,在ElasticSearch的存储库中可以配置多个目录,不同的设备所产生的日志可以存储到不同的目录下,例如设备A为核心设备,其产生的日志对应的存储的核心目录下,而设备B为非核心设备,其产生的日志对应的存储到非核心目录下。
示例性的,在设备还可以基于所承载的业务功能、所安装的应用软件、所处的空间区域等进行分类,例如设备A承载的为核心业务,设备B承载的为非核心业务,则设备A所产生的日志可以出存储在目录A,设备B产生的日志可以存储在目录B。
本申请实施例通过将不同设备所产生的日志存储到不同的目录下,实现了日志的分类存储,在日志检索时可以缩小检索范围,提高日志检索的效率。
进一步的,在上述实施例的基础上,在另一些实施例中,上述步骤S203具体可以通过如下步骤实现:获取存储在第一目录下的日志和存储第二目录下的日志,第一目录下的日志为核心设备产生的,第二目录下的日志为非核心设备产生的;根据每个关键词的检索顺序,从第一目录下的日志中检索确定是否存在与关键词匹配的日志;若第一目录下存在与关键词匹配的日志,则将该日志作为目标日志;若第一目录下不存在与关键词匹配的日志,则从第二目录下的日志中检索出与关键词匹配的日志,作为目标日志。
在本实施例中,在进行日志检索时,除了依据关键词的检索顺序进行日志检索之外,还可以为日志配置检索顺序(即优先检索第一目录下的日志,然后再检索第二目录下的日志),优先确定核心设备所产生的日志中是否存在目标日志,如果承载,则可以优先对该核心设备进行故障分析,如此可以优先对核心设备进行巡检,提高故障排查的灵活性。
进一步的,在其他实施方式中,当第一目录下存在与关键词匹配的日志时,也可以继续从第二目录下的日志中检索出与关键词匹配的日志,将第一目录下存在与关键词匹配的日志、第二目录下与关键词匹配的日志均作为目标日志,同时进行故障分析,全方位实现故障巡检。
本申请实施例通过配置各类设备所产生的日志的检索顺序,可以针对性的对某类设备所产生的日志进行优先检索,提高日志检索的灵活性。
在另一些实施例中,在确定设备是否存在故障时,可以通过如下步骤实现:获取目标日志中在出现关键词时,产生该目标日志的设备的巡检指标,巡检指标至少包括CPU占用数据、内存使用数据、磁盘读写数据繁忙度中的至少一种;根据巡检指标,确定设备是否存在故障。
在本实施例中,可以设置指标阈值,并通过目标日志记录下的时间,查找到的在出现关键词对应的时间点时,该设备的巡检指标,然后将该巡检指标与指标阈值对比,由此确定出设备是否故障。
示例性的,指标阈值可以配置如下表1:
巡检指标 | 指标阈值 |
CPU占用数据 | 第一指标阈值 |
内存使用数据 | 第二指标阈值 |
磁盘读写数据繁忙度 | 第三指标阈值 |
表1
如上表1所示,示例性的,当巡检指标为CPU占用数据时,则可以将CPU占用数据的值与第一指标阈值对比,如果CPU占用数据的值大于第一指标阈值,则确定该设备存在故障。
另外,在另一些实施例中,如果设备存在故障,则可以输出报警信息,其中,报警信息可以是邮件信息、短信通知等。通过输出报警信息可以及时的通知工作人员对设备进行维护。
另外,在另一些实施例中,可以配置日志的检索时间周期,例如10分钟,即每间隔一个时间周期,则基于关键词的检索顺序,从日志中检索与关键词匹配的目标日志。这主要是考虑到分布式系统中各个设备在工作时日志会不断的更新,故需要实时的进行日志检索,以确保故障能够及时发现。
本申请实施例通过巡检机制,获取报错的目标日志对应时间的巡检指标,并且通过巡检指标和关键词确定是否有异常现象,如果有异常现象,则确定异常现象是否存在真实的故障,并定位故障原因,实现故障的准确定位。
下述为本申请装置实施例,可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节,请参照本申请方法实施例。
图4为本申请实施例提供的分布式系统中设备故障巡检装置结构示意图,如图4所示,该分布式系统中设备故障巡检装置400具体可以包括日志获取模块401、顺序确定模块402、日志检索模块403和故障判定模块404。其中,日志获取模块401用于从日志中心获取分布式系统中每个设备产生的日志,不同的设备产生的日志存储在日志中心的不同目录下。顺序确定模块402用于获取关键词并确定每个关键词的检索顺序,关键词包括加载缓存失败、异常、重启失败中的至少一种,不同的关键词的检索顺序不相同。日志检索模块403用于根据每个关键词的检索顺序,从日志中检索出与关键词匹配的目标日志。故障判定模块404用于根据目标日志,确定分布式系统中的设备是否存在故障。
可选的,顺序确定模块具体可以用于:获取关键词并确定每个关键词的重要程度;根据每个关键词的重要程度,确定每个关键词的检索顺序。对应的,日志检索模块具体可以用于:从日志中检索确定是否存在与检索顺序靠前的关键词匹配的第一日志;若从日志中检索得到与检索顺序靠前的关键词匹配的第一日志,则直接将第一日志作为目标日志;若从日志中检索不到与检索顺序靠前的关键词匹配的第一日志,则继续从日志中检索出与检索顺序靠后的关键词匹配的第二日志,并将第二日志作为目标日志。
可选的,故障判定模块具体可以用于:确定产生目标日志的设备的类别、关键词在目标日志中出现的次数,设备至少分为核心设备和非核心设备两种类别;若设备为核心设备且关键词在目标日志中出现的次数大于或等于1,则根据核心设备产生的目标日志,确定核心设备是否存在故障。
可选的,故障判定模块具体可以用于:当设备为非核心设备且关键词在目标日志中出现的次数大于1时,继续确定关键词在目标日志中出现的次数是否大于或等于预设阈值,若关键词在目标日志中出现的次数大于或等于预设阈值,则根据非核心设备产生的目标日志,确定非核心设备是否存在故障。
可选的,还包括日志存储模块,用于根据各个设备所属的类别,对各个设备产生的日志进行分类,设备至少分为核心设备和非核心设备两种类别;将不同类别的日志分别存储至日志中心的不同目录下。
可选的,日志检索模块具体还可以用于:获取存储在第一目录下的日志和存储在第二目录下的日志,第一目录下存储的日志为核心设备产生的,第二目录下存储的日志为非核心设备产生的;根据每个关键词的检索顺序,从第一目录下存储的日志中检索确定是否存在与关键词匹配的日志;若第一目录下存在与关键词匹配的日志,则将该日志作为目标日志;若第一目录下不存在与关键词匹配的日志,则从第二目录下的日志中检索出与关键词匹配的日志,作为目标日志。
可选的,故障判定模块具体可以用于:获取在目标日志中出现关键词时,产生该目标日志的设备的巡检指标,巡检指标至少包括CPU占用数据、内存使用数据、磁盘读写数据繁忙度中的至少一种;根据巡检指标,确定设备是否存在故障。
可选的,还包括报警模块,用于若设备存在故障,则输出报警信息。
本申请实施例提供的装置,可用于执行上述实施例中的方法,其实现原理和技术效果类似,在此不再赘述。
需要说明的是,应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分,实际实现时可以全部或部分集成到一个物理实体上,也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现;也可以全部以硬件的形式实现;还可以部分模块通过处理元件调用软件的形式实现,部分模块通过硬件的形式实现。例如,日志获取模块可以为单独设立的处理元件,也可以集成在上述装置的某一个芯片中实现,此外,也可以以程序代码的形式存储于上述装置的存储器中,由上述装置的某一个处理元件调用并执行以上日志获取模块的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起,也可以独立实现。这里的处理元件可以是一种集成电路,具有信号的处理能力。在实现过程中,上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。
图5为本申请实施例提供的计算机设备的结构示意图。如图5所示,该计算机设备500包括:至少一个处理器501、存储器502、总线503及通信接口504。其中:处理器501、通信接口504以及存储器502通过总线503完成相互间的通信。通信接口504用于与其它设备进行通信。该通信接口包括用于进行数据传输的通信接口以及用于进行人机交互的显示界面或者操作界面等。处理器501用于执行存储器存储的计算机执行指令,具体可以执行上述实施例中所描述的方法中的相关步骤。
其中,处理器可能是中央处理器,或者是特定集成电路(Application SpecificIntegrated Circuit,ASIC),或者是被配置成实施本发明实施例的一个或多个集成电路。计算机设备包括的一个或多个处理器,可以是同一类型的处理器,如一个或多个CPU;也可以是不同类型的处理器,如一个或多个CPU以及一个或多个ASIC。
存储器,用于存放计算机执行指令。存储器可能包含高速RAM存储器,也可能还包括非易失性存储器,例如至少一个磁盘存储器。
本实施例还提供一种计算机可读存储介质,可读存储介质中存储有计算机指令,当计算机设备的至少一个处理器执行该计算机指令时,计算机设备执行上述的各种实施方式提供的方法。
本实施例还提供一种计算机程序产品,该程序产品包括计算机指令,该计算机指令存储在可读存储介质中。计算机设备的至少一个处理器可以从可读存储介质读取该计算机指令,至少一个处理器执行该计算机指令使得计算机设备实施上述的各种实施方式提供的方法。
本申请中,“至少一个”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,描述关联对象的关联关系,表示可以存在三种关系,例如,A和/或B,可以表示:单独存在A,同时存在A和B,单独存在B的情况,其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系;在公式中,字符“/”,表示前后关联对象是一种“相除”的关系。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示:a,b,c,a-b,a-c,b-c,或a-b-c,其中,a,b,c可以是单个,也可以是多个。
可以理解的是,在本申请实施例中涉及的各种数字编号仅为描述方便进行的区分,并不用来限制本申请的实施例的范围。在本申请的实施例中,上述各过程的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本申请的实施例的实施过程构成任何限定。
最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。
Claims (12)
1.一种分布式系统中设备故障巡检方法,其特征在于,包括:
从日志中心获取分布式系统中每个设备产生的日志,不同的设备产生的日志存储在所述日志中心的不同目录下;
获取关键词并确定每个关键词的检索顺序,所述关键词包括加载缓存失败、异常、重启失败中的至少一种,不同的关键词的检索顺序不相同;
根据每个关键词的检索顺序,从所述日志中检索出与所述关键词匹配的目标日志;
根据所述目标日志,确定所述分布式系统中的设备是否存在故障。
2.根据权利要求1所述的方法,其特征在于,所述获取关键词并确定每个关键词的检索顺序,包括:
获取关键词并确定每个关键词的重要程度;
根据每个关键词的重要程度,确定每个关键词的检索顺序;
对应的,所述根据每个关键词的检索顺序,从所述日志中检索出与所述关键词匹配的目标日志,包括:
从所述日志中检索确定是否存在与检索顺序靠前的关键词匹配的第一日志;
若从所述日志中检索得到与检索顺序靠前的关键词匹配的第一日志,则直接将所述第一日志作为所述目标日志;
若从所述日志中检索不到与检索顺序靠前的关键词匹配的第一日志,则继续从所述日志中检索出与检索顺序靠后的关键词匹配的第二日志,并将所述第二日志作为所述目标日志。
3.根据权利要求1所述的方法,其特征在于,所述根据所述目标日志,确定所述分布式系统中的设备是否存在故障,包括:
确定产生所述目标日志的设备的类别、所述关键词在所述目标日志中出现的次数,所述设备至少分为核心设备和非核心设备两种类别;
若所述设备为核心设备且所述关键词在所述目标日志中出现的次数大于或等于1,则根据所述核心设备产生的目标日志,确定所述核心设备是否存在故障。
4.根据权利要求3所述的方法,其特征在于,所述根据所述目标日志,确定所述分布式系统中的设备是否存在故障,包括:
当所述设备为非核心设备且所述关键词在所述目标日志中出现的次数大于1时,继续确定所述关键词在所述目标日志中出现的次数是否大于或等于预设阈值,
若所述关键词在所述目标日志中出现的次数大于或等于预设阈值,则根据所述非核心设备产生的目标日志,确定所述非核心设备是否存在故障。
5.根据权利要求1所述的方法,其特征在于,所述方法还包括:
根据各个设备所属的类别,对各个设备产生的日志进行分类,所述设备至少分为核心设备和非核心设备两种类别;
将不同类别的日志分别存储至所述日志中心的不同目录下。
6.根据权利要求5所述的方法,其特征在于,所述根据每个关键词的检索顺序,从所述日志中检索出与所述关键词匹配的目标日志,包括:
获取存储在第一目录下的日志和存储在第二目录下的日志,所述第一目录下存储的日志为所述核心设备产生的,所述第二目录下存储的日志为所述非核心设备产生的;
根据每个关键词的检索顺序,从所述第一目录下存储的日志中检索确定是否存在与所述关键词匹配的日志;
若所述第一目录下存在与所述关键词匹配的日志,则将该日志作为目标日志;
若所述第一目录下不存在与所述关键词匹配的日志,则从所述第二目录下的日志中检索出与所述关键词匹配的日志,作为目标日志。
7.根据权利要求1-6中任一项所述的方法,其特征在于,所述根据所述目标日志,确定所述分布式系统中的设备是否存在故障,包括:
获取在所述目标日志中出现所述关键词时,产生该目标日志的设备的巡检指标,所述巡检指标至少包括CPU占用数据、内存使用数据、磁盘读写数据繁忙度中的至少一种;
根据所述巡检指标,确定所述设备是否存在故障。
8.根据权利要求7所述的方法,其特征在于,所述方法还包括:
若所述设备存在故障,则输出报警信息。
9.一种分布式系统中设备故障巡检装置,其特征在于,包括:
日志获取模块,用于从日志中心获取分布式系统中每个设备产生的日志,不同的设备产生的日志存储在所述日志中心的不同目录下;
顺序确定模块,用于获取关键词并确定每个关键词的检索顺序,所述关键词包括加载缓存失败、异常、重启失败中的至少一种,不同的关键词的检索顺序不相同;
日志检索模块,用于根据每个关键词的检索顺序,从所述日志中检索出与所述关键词匹配的目标日志;
故障判定模块,用于根据所述目标日志,确定所述分布式系统中的设备是否存在故障。
10.一种计算机设备,其特征在于,包括:处理器,以及与所述处理器通信连接的存储器;
所述存储器存储计算机执行指令;
所述处理器执行所述存储器存储的计算机执行指令,以实现如权利要求1-8中任一项所述的方法。
11.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机指令,所述计算机指令被处理器执行时用于实现如权利要求1-8任一项所述的方法。
12.一种计算机程序产品,包括计算机指令,其特征在于,该计算机指令被处理器执行时实现权利要求1-8任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310149572.5A CN116185956A (zh) | 2023-02-22 | 2023-02-22 | 分布式系统中设备故障巡检方法、装置、设备和介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310149572.5A CN116185956A (zh) | 2023-02-22 | 2023-02-22 | 分布式系统中设备故障巡检方法、装置、设备和介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116185956A true CN116185956A (zh) | 2023-05-30 |
Family
ID=86451954
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310149572.5A Pending CN116185956A (zh) | 2023-02-22 | 2023-02-22 | 分布式系统中设备故障巡检方法、装置、设备和介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116185956A (zh) |
-
2023
- 2023-02-22 CN CN202310149572.5A patent/CN116185956A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103513983B (zh) | 用于预测性警报阈值确定工具的方法和系统 | |
CN111881011A (zh) | 日志管理方法、平台、服务器及存储介质 | |
JP7405773B2 (ja) | マルチコア相互接続のレベル2キャッシュへのアクセスを検証する方法 | |
US9489379B1 (en) | Predicting data unavailability and data loss events in large database systems | |
JP6996812B2 (ja) | 分散データベースにおけるデータブロックを処理する方法、プログラム、およびデバイス | |
WO2019153550A1 (zh) | Sql自动优化方法、装置、计算机设备及存储介质 | |
CN113360722B (zh) | 一种基于多维数据图谱的故障根因定位方法及系统 | |
JP2014134956A (ja) | 障害分析支援装置、障害分析支援方法、及びプログラム | |
US20190207826A1 (en) | Apparatus and method to improve precision of identifying a range of effects of a failure in a system providing a multilayer structure of services | |
CN113590432A (zh) | 数据库的巡检方法与装置 | |
CN110912757A (zh) | 业务的监控方法和服务器 | |
CN112579552A (zh) | 日志存储及调用方法、装置及系统 | |
CN117271184A (zh) | 一种基于观测云进行根因分析的决策分析方法及系统 | |
CN116185956A (zh) | 分布式系统中设备故障巡检方法、装置、设备和介质 | |
CN117806899A (zh) | 数据监控分析方法、装置、服务器、运维系统及存储介质 | |
KR102349495B1 (ko) | 가상 서버들로부터 대용량 로그 파일들을 프로세싱하는 컴퓨터 시스템 및 방법. | |
CN113742213A (zh) | 一种用于数据分析的方法、系统和介质 | |
CN113157555A (zh) | 用于线上压测数据漏库实时检测的系统、方法及设备 | |
CN111831754A (zh) | 数据库中数据的复制方法、装置、系统和介质 | |
CN110750569A (zh) | 数据提取方法、装置、设备及存储介质 | |
CN116431872B (zh) | 可观测系统及基于可观测系统的服务观测方法 | |
CN117407207B (zh) | 一种内存故障处理方法、装置、电子设备及存储介质 | |
US20240143666A1 (en) | Smart metric clustering | |
CN118733219A (zh) | 任务优化方法、装置、电子设备及存储介质 | |
CN115827302A (zh) | 一种数据处理方法、装置、设备及介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |