CN120508429A - 容器的故障处理方法、装置、电子设备及计算机程序产品 - Google Patents
容器的故障处理方法、装置、电子设备及计算机程序产品Info
- Publication number
- CN120508429A CN120508429A CN202510636239.6A CN202510636239A CN120508429A CN 120508429 A CN120508429 A CN 120508429A CN 202510636239 A CN202510636239 A CN 202510636239A CN 120508429 A CN120508429 A CN 120508429A
- Authority
- CN
- China
- Prior art keywords
- fault
- information
- container
- target
- target container
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0712—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a virtual computing platform, e.g. logically partitioned systems
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F18/00—Pattern recognition
- G06F18/20—Analysing
- G06F18/21—Design or setup of recognition systems or techniques; Extraction of features in feature space; Blind source separation
- G06F18/214—Generating training patterns; Bootstrap methods, e.g. bagging or boosting
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Data Mining & Analysis (AREA)
- Bioinformatics & Computational Biology (AREA)
- Artificial Intelligence (AREA)
- Life Sciences & Earth Sciences (AREA)
- Bioinformatics & Cheminformatics (AREA)
- Computer Vision & Pattern Recognition (AREA)
- Evolutionary Computation (AREA)
- Evolutionary Biology (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请公开了一种容器的故障处理方法、装置、电子设备及计算机程序产品。涉及人工智能领域,该方法包括:获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息;将日志信息和硬件信息输入目标模型,得到故障诊断结果;在故障诊断结果表征目标容器存在故障的情况下,从故障诊断结果中提取出故障原因和故障溯源路径;基于故障原因和故障溯源路径确定故障修复方案,对目标容器执行故障修复方案。通过本申请,解决了相关技术中容器的故障诊断准确率低的问题。
Description
技术领域
本申请涉及人工智能领域,具体而言,涉及一种容器的故障处理方法、装置、电子设备及计算机程序产品。
背景技术
在云计算和物联网技术飞速发展的背景下,容器技术凭借其轻量级、快速启动以及高资源利用率的特性,已成为微服务部署的首选方案。容器技术允许应用程序及其依赖项打包在一个轻量级、自包含的环境中运行,极大地简化了应用的部署和管理流程,提高了开发和运维的效率。然而,容器技术的广泛应用也带来了新的安全和运维挑战。容器环境可以共享宿主机的内核和资源。这种共享机制虽然能够显著提高资源的利用率,但也使得容器之间的边界变得模糊,增加了安全风险。配置错误、资源过度共享以及不安全的网络通信策略等,都可能成为容器环境中的安全隐患,为恶意攻击者提供入侵的途径。例如,不正确的容器配置可能允许攻击者通过容器逃逸技术获取宿主机的控制权;资源的不当共享可能导致容器内运行的应用程序受到资源竞争的影响;而网络通信的漏洞则可能被攻击者利用来进行网络层面的攻击。
相关技术中容器的故障诊断手段依赖于大量日志分析以及专家经验,对于容器环境的故障诊断显得尤为吃力。日志分析是一项耗时且繁琐的任务,需要从海量的日志数据中筛选、关联和分析,以定位问题的根本原因。而专家知识,虽然在某些情况下能够快速解决问题,但其依赖于个人经验,难以量化和规模化,特别是在面对复杂多变的容器环境时,其局限性更为明显。此外,容器环境的高动态性和复杂性进一步加剧了故障诊断的难度。容器的生命周期短,可能频繁启动和停止;容器之间的通信关系复杂,可能涉及不同的网络策略和资源分配;容器与宿主机以及其他容器之间的资源竞争和交互,也可能引发难以预见的故障。这些特征要求故障诊断方法不仅能够准确识别故障,还必须具备实时性和智能化的能力,以适应容器环境的快速变化。
针对相关技术中容器的故障诊断准确率低的问题,目前尚未提出有效的解决方案。
发明内容
本申请的主要目的在于提供一种容器的故障处理方法、装置、电子设备及计算机程序产品,以解决相关技术中容器的故障诊断准确率低的问题。
为了实现上述目的,根据本申请的一个方面,提供了一种容器的故障处理方法。该方法包括:获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息;将日志信息和硬件信息输入目标模型,得到故障诊断结果;在故障诊断结果表征目标容器存在故障的情况下,从故障诊断结果中提取出故障原因和故障溯源路径;基于故障原因和故障溯源路径确定故障修复方案,对目标容器执行故障修复方案。
可选地,在将日志信息和硬件信息输入目标模型,得到故障诊断结果之后,该方法还包括:获取预设周期内目标容器的故障诊断结果,从预设周期内的故障诊断结果中确定目标容器的故障类型分布、故障频次和故障修复结果;获取预设周期内目标容器的日志信息和硬件信息,基于预设周期内的日志信息和硬件信息确定目标容器的计算资源使用状态;基于计算资源使用状态确定目标容器的运行状态评估值,在运行状态评估值大于等于评估值阈值的情况下,发出警告信息,其中,警告信息用于提示目标容器存在运行风险。
可选地,目标模型由以下方式得到:获取目标容器的历史日志信息和历史硬件信息,并确定每组历史日志信息和对应的历史硬件信息的历史故障诊断结果;将每组历史日志信息、历史硬件信息和历史故障诊断结果确定为一组训练样本,得到多组训练样本;通过多组训练样本训练大语言模型,得到目标模型。
可选地,该方法还包括:每隔优化周期采集目标容器的新增日志信息、新增硬件信息和新增故障诊断结果;将每组新增日志信息、新增硬件信息和新增故障诊断结果确定为一组第一新增训练样本,得到多组第一新增训练样本;将多组第一新增训练样本与多组训练样本组合,得到优化后的多组训练样本,通过优化后的多组训练样本训练目标模型,得到优化后的目标模型。
可选地,获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息包括:将目标容器部署至集群环境中的集群节点中;通过预设采集工具采集目标容器的日志信息,其中,日志信息包括以下至少之一:标准输出、错误日志和事件信息,标准输出包含目标容器内应用程序的执行信息和非正常信息;通过预设采集工具采集集群节点的硬件信息,其中,硬件信息包括以下至少之一:中央处理器、内存、磁盘存储和网络状态。
可选地,在将日志信息和硬件信息输入目标模型,得到故障诊断结果之后,该方法还包括:在故障诊断结果表征目标容器不存在故障的情况下,获取目标容器在预设时段内的运行状态;在预设时段内目标容器的运行状态存在异常的情况下,确定异常原因;将异常原因确定为新增故障原因,确定新增故障原因的新增故障溯源路径,并将新增故障原因和新增故障溯源路径确定为目标故障诊断结果;将预设时段内目标容器的日志信息、硬件信息、目标故障诊断结果确定为第二新增训练样本,将第二新增训练样本与多组训练样本组合,得到更新后的多组训练样本,基于更新后的多组训练样本更新目标模型。
可选地,在获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息之后,该方法还包括:将日志信息中的非结构化数据转化为结构化数据,得到转化后的日志信息;对转化后的日志信息和硬件信息过滤噪声数据,并对硬件信息进行标准化处理,得到更新后的日志信息和硬件信息;基于更新后的日志信息和硬件信息执行将日志信息和硬件信息输入目标模型的步骤。
为了实现上述目的,根据本申请的另一方面,提供了一种容器的故障处理装置。该装置包括:获取单元,用于获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息;输入单元,用于将日志信息和硬件信息输入目标模型,得到故障诊断结果;提取单元,用于在故障诊断结果表征目标容器存在故障的情况下,从故障诊断结果中提取出故障原因和故障溯源路径;第一执行单元,用于基于故障原因和故障溯源路径确定故障修复方案,对目标容器执行故障修复方案。
在本申请实施例中,采用获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息;将日志信息和硬件信息输入目标模型,得到故障诊断结果;在故障诊断结果表征目标容器存在故障的情况下,从故障诊断结果中提取出故障原因和故障溯源路径;基于故障原因和故障溯源路径确定故障修复方案,对目标容器执行故障修复方案的方式,通过自动化地收集和分析容器的日志信息和硬件信息,利用目标模型快速定位故障原因,并提供准确的故障溯源路径和可行的故障修复方案,达到了增强容器化应用的安全性和可靠性的目的,从而实现了提高容器的故障诊断准确率的技术效果,进而解决了相关技术中容器的故障诊断准确率低的技术问题。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1示出了一种用于实现容器的故障处理方法的计算机终端(或移动设备)的硬件结构框图;
图2是根据本申请实施例提供的容器的故障处理方法的流程图;
图3是根据本申请实施例提供的可选的容器的故障处理方法的示意图;
图4是根据本申请实施例提供的容器的故障处理装置的示意图;
图5是根据本申请实施例的一种电子设备的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
需要说明的是,本申请中涉及的采集的信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于展示的数据、分析的数据等)是经用户授权或者经过各方充分授权的信息和数据,并且相关数据的收集、存储、使用、加工、传输、提供、公开和应用等处理,均遵守相关法律法规和标准,采取了必要保密措施,不违背公序良俗,并提供有相应的操作入口,供用户选择授权或者拒绝。如,本系统和相关用户或机构间设置有接口,为用户提供相应的操作入口,供用户选择同意或者拒绝自动化决策结果;若用户选择拒绝,则进入专家决策流程。
实施例1
根据本申请实施例,还提供了一种容器的故障处理的方法实施例,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。图1示出了一种用于实现容器的故障处理方法的计算机终端(或移动设备)的硬件结构框图。如图1所示,计算机终端10(或移动设备)可以包括一个或多个(图中采用102a,102b,……,102n来示出)处理器102(处理器102可以包括但不限于MCU(Microcontroller Unit,微处理器)或FPGA(Field-Programmable Gate Array,可编程逻辑器件)等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输装置106。除此以外,还可以包括:显示器、输入/输出接口(I/O接口)、USB(Universal Serial Bus,通用串行总线)端口(可以作为BUS(Business,总线)的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解,图1所示的结构仅为示意,其并不对上述电子装置的结构造成限定。例如,计算机终端10还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置。
应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外,数据处理电路可为单个独立的处理模块,或全部或部分的结合到计算机终端10(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的,该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
存储器104可用于存储应用软件的软件程序以及模块,如本申请实施例中的容器的故障处理方法对应的程序指令/数据存储装置,处理器102通过运行存储在存储器104内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的容器的故障处理方法。存储器104可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器104可进一步包括相对于处理器102远程设置的存储器,这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中,传输装置106包括一个网络适配器(Network Interface Controller,NIC),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输装置106可以为射频(Radio Frequency,RF)模块,其用于通过无线方式与互联网进行通讯。
显示器可以例如触摸屏式的液晶显示器,该液晶显示器可使得用户能够与计算机终端10(或移动设备)的用户界面进行交互。
在上述运行环境下,本申请提供了一种容器的故障处理方法。图2是根据本申请实施例提供的容器的故障处理方法的流程图,如图2所示,该方法包括:
步骤S201,获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息。
在步骤S201中,通过日志采集装置采集目标容器的日志信息。在生产环境中,不会直接通过命令行实时获取日志,而是会将所有容器的日志信息持续地收集到一个中心化的日志管理系统中。收集到的日志信息可能来自于不同的应用程序,格式各异。为了便于后续的分析,需要将日志格式化为统一的结构,可以采用结构化文本格式。在日志标准化处理后,对日志进行过滤和清洗,移除无关或冗余的信息,保留关键的日志条目和信息,以提高后续故障诊断的准确性和效率。
硬件信息可以包括CPU(Central Processing Unit,中央处理器)使用率、内存使用量、磁盘I/O数据量、网络I/O数据量等。收集到的硬件信息需进行标准化处理,例如差值处理以反映实际资源消耗,以及标准化处理以消除不同指标之间的量纲差异,便于统一比较和分析。
步骤S202,将日志信息和硬件信息输入目标模型,得到故障诊断结果。
在步骤S202中,预处理后的日志信息可以包含时间戳、日志级别、错误类型、容器ID、日志文本等关键字段。调用已经通过大量历史日志信息、历史硬件信息和历史故障诊断结果训练好的离线的目标模型。目标模型可以是大数据和大语言模型,具有识别复杂日志模式和理解上下文的能力。将准备好的日志信息和硬件信息以结构化或向量化的形式输入到目标模型中。目标模型在接收到输入数据后,执行内部的预测和分析算法,生成故障诊断结果。
步骤S203,在故障诊断结果表征目标容器存在故障的情况下,从故障诊断结果中提取出故障原因和故障溯源路径。
在步骤S203中,故障诊断结果可以包括一系列与容器状态、日志异常相关的数值或标签。标签可以包括异常的严重程度、异常类型、以及可能导致异常的特定日志条目或硬件指标。在目标模型输出的故障诊断结果中,识别出与目标容器故障最相关的异常。例如某些日志条目的频率异常高、特定系统指标超出正常范围,或是模型对容器状态的预测与实际不符等。
从故障诊断结果中提取故障原因。例如,内存使用率突然上升,结合日志信息,可能是由于内存泄漏造成的。通过分析异常的硬件指标,如CPU占用率激增、磁盘I/O瓶颈、网络延迟等,定位故障原因。例如,CPU使用率持续高达99%可能是因为容器内运行的应用程序中有性能不优的代码或无限循环。结合容器的运行环境、配置参数和集群的整体状态,进行上下文分析,进一步细化故障原因。例如,容器在升级后突然出现异常,可能是因为版本兼容性问题。
利用时间序列数据,追踪故障发生前后的系统状态变化。结合容器日志的时间戳,可以重建事件的顺序,从而构建出故障从开始到影响扩大的时间线。分析日志条目与硬件指标之间的关联性,识别哪些事件或操作触发了异常状态。例如,如果在容器的日志中记录了大量数据库查询失败,而同时网络I/O指标异常,可以推测是网络问题导致数据库访问延迟,进而影响容器性能。从故障诊断结果出发进行故障溯源,逆向推断哪些日志条目或硬件事件可能是故障的根源。例如,模型可能指出容器网络连接异常,进一步通过网络日志和网络监控数据追溯,发现是由于宿主机的网络堵塞导致的。
步骤S204,基于故障原因和故障溯源路径确定故障修复方案,对目标容器执行故障修复方案。
在步骤S204中,深入分析故障原因,无论是资源瓶颈(如CPU、内存)、配置错误、软件缺陷还是网络问题。同时,审查故障溯源路径,了解哪些操作或事件最终导致了故障。基于故障原因,制定针对性的修复措施。例如,对于内存泄漏,可以更新代码或重启容器;对于网络问题,可以检查网络配置或调整网络策略。如果故障原因与资源分配相关,比如CPU或内存不足,故障修复方案可以为调整容器的资源请求和限制,或在集群中重新调度容器。
根据制定的故障修复方案,对目标容器进行操作。如更新容器镜像、修改配置文件、调整资源分配或执行系统级别的操作。在执行修复方案后,持续监控容器的状态和集群的健康,验证故障是否已被解决,同时注意修复操作是否引入了新的问题。对于常见的故障类型,可以设计自动化脚本来执行修复流程,减少人工干预的需要,提高响应速度和效率。
本申请实施例提供的容器的故障处理方法,通过获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息;将日志信息和硬件信息输入目标模型,得到故障诊断结果;在故障诊断结果表征目标容器存在故障的情况下,从故障诊断结果中提取出故障原因和故障溯源路径;基于故障原因和故障溯源路径确定故障修复方案,对目标容器执行故障修复方案,通过自动化地收集和分析容器的日志信息和硬件信息,利用目标模型快速定位故障原因,并提供准确的故障溯源路径和可行的故障修复方案,达到了增强容器化应用的安全性和可靠性的目的,从而实现了提高容器的故障诊断准确率的技术效果,进而解决了相关技术中容器的故障诊断准确率低的技术问题。
为了保障容器运行安全,在确定容器故障后及时通过警告信息提示容器运行风险,可选地,在本申请实施例提供的容器的故障处理方法中,在将日志信息和硬件信息输入目标模型,得到故障诊断结果之后,该方法还包括:获取预设周期内目标容器的故障诊断结果,从预设周期内的故障诊断结果中确定目标容器的故障类型分布、故障频次和故障修复结果;获取预设周期内目标容器的日志信息和硬件信息,基于预设周期内的日志信息和硬件信息确定目标容器的计算资源使用状态;基于计算资源使用状态确定目标容器的运行状态评估值,在运行状态评估值大于等于评估值阈值的情况下,发出警告信息,其中,警告信息用于提示目标容器存在运行风险。
在一些实施例中,预设周期可以为24小时或一周,以收集目标容器的故障诊断结果。从预设周期内的故障诊断结果中统计不同故障类型的出现频率,这有助于识别常见的故障模式,指导未来预防措施的制定。计算目标容器在该周期内的故障类型分布、故障频次和故障修复结果。故障修复结果中记录每次故障的修复情况,包括是否成功修复、修复时间、以及采取的修复措施,这有助于评估容器的自愈能力,以及故障处理流程的有效性。
持续收集目标容器的CPU、内存、磁盘I/O和网络I/O等计算资源使用数据,了解其计算资源的使用趋势和峰值。基于预设周期内的计算资源使用状态,计算资源使用率的平均值、标准差和峰值,以反映容器的资源需求和波动情况。结合故障类型分布和频次,为容器的故障稳定性评分,如故障次数越多,评分越低。将资源使用指标和故障指标进行加权,得出目标容器的运行状态评估值。评估值的计算可以采用多种统计分析方法,如指数加权移动平均、最近邻算法或机器学习模型预测等。
设定一个运行状态评估值的评估值阈值,用于区分正常运行和风险状态。阈值的设定可以基于历史数据和容器的正常运行范围。当运行状态评估值大于等于评估值阈值时,自动触发警告信息。警告信息可以是电子邮件、短信、系统通知或直接在管理界面上显示。警告信息可以包含详细的风险描述,如资源过度使用的具体指标、故障类型和频次信息,以及初步的故障修复建议或应对策略。
本实施例通过对目标容器的运行状态进行周期性评估,及时识别和警告潜在的运行风险,采取预防和优化措施,确保容器服务的连续性和可靠性。
为了对目标容器进行故障诊断,需要训练出目标模型,可选地,在本申请实施例提供的容器的故障处理方法中,目标模型由以下方式得到:获取目标容器的历史日志信息和历史硬件信息,并确定每组历史日志信息和对应的历史硬件信息的历史故障诊断结果;将每组历史日志信息、历史硬件信息和历史故障诊断结果确定为一组训练样本,得到多组训练样本;通过多组训练样本训练大语言模型,得到目标模型。
在一些实施例中,从目标容器及其集群的监控系统中收集容器运行期间的所有历史日志信息和历史硬件信息。历史日志信息可以包括标准输出、错误日志、事件信息等。历史硬件信息可以包括CPU使用率、内存使用量、磁盘I/O数据量和网络I/O数据量等指标。将历史故障诊断结果作为标签,与对应的历史日志信息和历史硬件信息关联。每组历史日志信息、历史硬件信息和历史故障诊断结果共同构成一个训练样本。确保训练样本中包含充分的信息,以便模型能够学习到故障与日志、硬件指标之间的关联。
选择一个大语言模型作为基础,将构建好的训练样本输入模型,包括历史日志文本、硬件指标数据和故障诊断结果标签,进行监督学习训练。模型在训练过程中自动抽取历史日志信息与硬件信息中的特征,识别这些特征与故障诊断结果之间的关联。通过调整模型参数、增加训练轮次或使用更大数据集,不断提高模型的准确性和泛化能力。优化目标是模型在测试数据集上的性能表现,确保目标模型不仅在训练数据上表现良好,也能够准确预测未见过的容器故障。
需要说明的是,目标模型可以采用离线模型,通过大数据和大语言模型进行故障的分析和模型训练。首先负将经过预处理的数据输入大语言模型,利用历史数据对其进行打标和分类,以识别常见的故障类型。打标后的数据进入数据库,作为后续模型训练的基础。然后根据实时获取的数据,离线模型进行持续的增量训练,以提升模目标型对新故障和变化的适应能力。该增量训练通过更新权重或增加新样本的方式来优化模型。最后通过评估模型的预测准确率,定期对模型参数进行调整,以提高其在故障诊断中的表现。离线模型经过充分训练后,可以对新的故障进行快速精准的定位,并提供相应的解决方案建议。
本实施例通过训练目标模型,目标模型能够基于日志信息和硬件信息预测容器故障,并分析故障原因,为容器运维提供有力支持,提高容器故障检测的准确率。
为了保障目标模型的时效性,需要对目标模型定期优化,可选地,在本申请实施例提供的容器的故障处理方法中,该方法还包括:每隔优化周期采集目标容器的新增日志信息、新增硬件信息和新增故障诊断结果;将每组新增日志信息、新增硬件信息和新增故障诊断结果确定为一组第一新增训练样本,得到多组第一新增训练样本;将多组第一新增训练样本与多组训练样本组合,得到优化后的多组训练样本,通过优化后的多组训练样本训练目标模型,得到优化后的目标模型。
在一些实施例中,在每个优化周期(可以设置为每天、每周或按需),收集目标容器的新增日志信息、新增硬件信息,以及在此期间内生成的新增故障诊断结果。这些数据反映了容器最近的运行状态和故障事件。确保新增的日志信息和硬件信息与对应的故障诊断结果准确配对,形成第一新增训练样本。将多组第一新增训练样本与现有的多组训练样本组合,形成优化后的训练样本集。将优化后的多组训练样本输入到目标模型中,进行增量训练。目标模型将利用新数据进一步调整其参数,提高目标模型对新故障情境的识别能力。
本实施例通过持续优化目标模型,可以使其对容器故障的诊断更加准确,更好地适应容器环境的变化,从而提高容器服务的稳定性和运维效率。
通过获取容器的日志信息和硬件信息来确定容器是否发生故障,可选地,在本申请实施例提供的容器的故障处理方法中,获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息包括:将目标容器部署至集群环境中的集群节点中;通过预设采集工具采集目标容器的日志信息,其中,日志信息包括以下至少之一:标准输出、错误日志和事件信息,标准输出包含目标容器内应用程序的执行信息和非正常信息;通过预设采集工具采集集群节点的硬件信息,其中,硬件信息包括以下至少之一:中央处理器、内存、磁盘存储和网络状态。
在一些实施例中,选择一个适合的集群环境部署目标容器,确保容器能够在集群中运行并提供服务。配置或使用预设的日志采集工具,来实时监控和收集容器的日志信息。收集的目标容器日志信息可以包括标准输出、错误日志和事件信息等。标准输出中包含了应用程序的执行信息,包括正常操作和异常信息;错误日志记录了容器运行期间的错误和警告;事件信息则提供了容器生命周期事件的详细信息,如容器的启动、停止和重启等。
使用预设采集工具持续监控目标容器所部署的集群节点的硬件信息,包括中央处理器(CPU)的使用率、内存占用量、磁盘存储使用情况和网络状态等。硬件信息中,CPU使用率反映了容器对计算资源的需求;内存占用量则指示容器的内存消耗情况;磁盘存储使用情况用于监控容器的数据存储需求;网络状态包括网络I/O数据量和延迟,反映了容器的网络通信状况。
本实施例通过收集目标容器的日志信息和集群节点的硬件信息,为后续的故障诊断与分析提供了扎实的数据基础。这些数据将被用于训练大语言模型,以提升容器故障诊断的自动性和准确性,从而减少容器服务的停机时间,提高系统的可靠性和运维效率。
为了避免目标模型的故障诊断结果不准确,在预设时段内持续监测容器是否发生异常,可选地,在本申请实施例提供的容器的故障处理方法中,在将日志信息和硬件信息输入目标模型,得到故障诊断结果之后,该方法还包括:在故障诊断结果表征目标容器不存在故障的情况下,获取目标容器在预设时段内的运行状态;在预设时段内目标容器的运行状态存在异常的情况下,确定异常原因;将异常原因确定为新增故障原因,确定新增故障原因的新增故障溯源路径,并将新增故障原因和新增故障溯源路径确定为目标故障诊断结果;将预设时段内目标容器的日志信息、硬件信息、目标故障诊断结果确定为第二新增训练样本,将第二新增训练样本与多组训练样本组合,得到更新后的多组训练样本,基于更新后的多组训练样本更新目标模型。
在一些实施例中,设置一个预设的监控时段,如最近几分钟、几小时或一天,用于观察目标容器的运行状态。在预设时段内,持续收集目标容器的运行状态数据,包括但不限于应用的响应时间、吞吐量、失败请求率等业务指标,以及容器的启动、停止次数等运维指标。利用统计分析、异常检测算法或专家规则,对收集的运行状态数据进行分析,判断其是否存在异常。在确认目标容器的运行状态存在异常后,通过日志分析、资源监控和应用性能监控等手段,定位引起异常的具体原因。将异常原因细化为具体的故障类型,如资源瓶颈、配置不当、软件缺陷或外部服务中断等。确定异常原因的故障溯源路径,包括故障发生的时间点、容器的运行环境、相关的系统事件和服务交互过程等。
将确定的异常原因作为新增故障原因,将故障溯源路径作为新增故障溯源路径,二者共同构成了目标故障诊断结果。将预设时段内目标容器的日志信息、硬件信息与目标故障诊断结果结合起来,形成第二新增训练样本。将多组第二新增训练样本与原有的多组训练样本合并,形成更新后的多组训练样本。基于更新后的多组训练样本,重新训练或增量更新目标模型。通过学习新增的故障场景和原因,模型的故障诊断能力将进一步提升,尤其是对于那些初期难以识别的隐性故障。
本实施例通过持续地将更深层次的异常检测结果反馈至模型训练中,可以不断优化目标模型的故障诊断能力,使其能够更准确、更全面地识别容器中的各种故障场景,从而提升容器服务的整体稳定性和运维效率。
为了提高目标模型的训练效率,可以对日志信息和硬件信息进行结构化转换和去噪处理,可选地,在本申请实施例提供的容器的故障处理方法中,在获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息之后,该方法还包括:将日志信息中的非结构化数据转化为结构化数据,得到转化后的日志信息;对转化后的日志信息和硬件信息过滤噪声数据,并对硬件信息进行标准化处理,得到更新后的日志信息和硬件信息;基于更新后的日志信息和硬件信息执行将日志信息和硬件信息输入目标模型的步骤。
在一些实施例中,将日志信息中的非结构化数据转化为结构化数据,转化后的日志信息将以表格形式存储,每一行代表一个日志条目,每一列对应一个结构化字段。这样,目标模型可以更容易地理解和处理日志数据,提高故障诊断的效率和准确性。对转化后的日志信息和硬件信息进行噪声数据过滤,排除无关或重复的信息。例如,过滤掉与当前故障诊断无关的日志条目,或硬件指标中偶尔出现的异常值。将硬件信息(如CPU使用率、内存使用量)转换为统一的量纲和范围,如将所有CPU使用率转换为0到1之间的比例值,或所有内存使用量转换为GB作为单位。标准化处理有助于消除不同硬件指标之间的量级差异,使模型能够更公平地评价各种资源的使用情况。
本实施例通过确保输入到目标模型的日志信息和硬件信息是结构化、干净且标准化的,从而提高模型的诊断能力和预测准确性。
根据本申请的另一实施例,还提供了一种可选的容器的故障处理方法,图3是根据本申请实施例提供的可选的容器的故障处理方法的示意图,如图3所示,该方法包括:
步骤S301:将应用容器部署到集群环境中。
步骤S302:集群节点上的采集工具会持续收集容器的标准输出、错误日志、事件信息以及节点的CPU、内存、存储、网络等硬件资源的使用情况和健康状态。
步骤S303:通过数据收集模型将步骤S302收集到信息送至信息预处理模块,其中,数据收集模块负责收集容器日志及运行环境的数据,信息预处理模块负责结构化处理收集到的各项数据。
步骤S304:信息预处理模块会将非结构化的信息转化为结构化数据,然后随机抽取一部分作为训练数据上送到离线模型训练模块,另外的数据上送到在线故障诊断模块。其中,模型训练模块负责使用处理后的数据训练大模型,故障诊断模块负责使用模型对容器进行故障诊断溯源和实时监控。
步骤S305:离线模型训练模块接收步骤S304上送的训练数据。
步骤S306:将步骤S305接收到的数据进行自动化打标入库,打标后的数据进入数据库,作为后续模型训练的基础。
步骤S307:离线模型对打标入库的数据进行持续的增量训练,以提升模型对新故障和变化的适应能力。该增量训练通过更新权重或增加新样本的方式来优化模型。
步骤S308:增量训练完成后,通过评估模型的预测准确率,对模型参数进行调整,以提高其在故障诊断中的表现。
步骤S309:在线诊断模块接收步骤S304上送的数据,并使用离线模型进行故障诊断。
步骤S310:实时监控模块分析上送数据进行实时预警和健康状态警告。
步骤S311:故障溯源模块根据实时故障信息调用离线训练好的模型进行故障定位并生成可能的解决方案。
步骤S312:可视化展示模块将故障分析结果、溯源过程及历史数据进行图形化展示。
本实施例通过可选的容器的故障处理方法,自动化地收集和分析容器日志数据,利用机器学习技术快速定位故障原因,并提供准确的故障溯源信息和可行的解决方案,从而显著提高故障处理的效率和准确性,减少对专业技术人员的依赖,增强容器化应用的安全性和可靠性。通过高效的数据处理、智能化的故障诊断有效提升容器环境中的故障检测、分析与溯源能力,显著提高了容器系统的可靠性和可维护性。适用于大规模容器集群的运维管理,有助于减少系统停机时间并提高系统的稳定性和可靠性。
需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
实施例2
本申请实施例还提供了一种容器的故障处理装置,需要说明的是,本申请实施例的容器的故障处理装置可以用于执行本申请实施例所提供的用于容器的故障处理方法。以下对本申请实施例提供的容器的故障处理装置进行介绍。
根据本申请实施例,还提供了一种用于实施上述容器的故障处理方法的装置,图4是根据本申请实施例提供的容器的故障处理装置的示意图,如图4所示,该装置包括:
获取单元401,用于获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息;
输入单元402,用于将日志信息和硬件信息输入目标模型,得到故障诊断结果;
提取单元403,用于在故障诊断结果表征目标容器存在故障的情况下,从故障诊断结果中提取出故障原因和故障溯源路径;
第一执行单元404,用于基于故障原因和故障溯源路径确定故障修复方案,对目标容器执行故障修复方案。
本申请实施例提供的容器的故障处理装置,通过获取单元401,获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息;输入单元402,将日志信息和硬件信息输入目标模型,得到故障诊断结果;提取单元403,在故障诊断结果表征目标容器存在故障的情况下,从故障诊断结果中提取出故障原因和故障溯源路径;第一执行单元404,基于故障原因和故障溯源路径确定故障修复方案,对目标容器执行故障修复方案,通过自动化地收集和分析容器的日志信息和硬件信息,利用目标模型快速定位故障原因,并提供准确的故障溯源路径和可行的故障修复方案,达到了增强容器化应用的安全性和可靠性的目的,从而实现了提高容器的故障诊断准确率的技术效果,进而解决了相关技术中容器的故障诊断准确率低的技术问题。
可选地,在本申请实施例提供的容器的故障处理装置中,该装置还包括:第一确定单元,用于获取预设周期内目标容器的故障诊断结果,从预设周期内的故障诊断结果中确定目标容器的故障类型分布、故障频次和故障修复结果;第二确定单元,用于获取预设周期内目标容器的日志信息和硬件信息,基于预设周期内的日志信息和硬件信息确定目标容器的计算资源使用状态;警告单元,用于基于计算资源使用状态确定目标容器的运行状态评估值,在运行状态评估值大于等于评估值阈值的情况下,发出警告信息,其中,警告信息用于提示目标容器存在运行风险。
可选地,在本申请实施例提供的容器的故障处理装置中,该装置还包括:第三确定单元,用于获取目标容器的历史日志信息和历史硬件信息,并确定每组历史日志信息和对应的历史硬件信息的历史故障诊断结果;第四确定单元,用于将每组历史日志信息、历史硬件信息和历史故障诊断结果确定为一组训练样本,得到多组训练样本;第一训练单元,用于通过多组训练样本训练大语言模型,得到目标模型。
可选地,在本申请实施例提供的容器的故障处理装置中,该装置还包括:采集单元,用于每隔优化周期采集目标容器的新增日志信息、新增硬件信息和新增故障诊断结果;第五确定单元,用于将每组新增日志信息、新增硬件信息和新增故障诊断结果确定为一组第一新增训练样本,得到多组第一新增训练样本;第二训练单元,用于将多组第一新增训练样本与多组训练样本组合,得到优化后的多组训练样本,通过优化后的多组训练样本训练目标模型,得到优化后的目标模型。
可选地,在本申请实施例提供的容器的故障处理装置中,获取单元401包括:部署模块,用于将目标容器部署至集群环境中的集群节点中;第一采集模块,用于通过预设采集工具采集目标容器的日志信息,其中,日志信息包括以下至少之一:标准输出、错误日志和事件信息,标准输出包含目标容器内应用程序的执行信息和非正常信息;第二采集模块,用于通过预设采集工具采集集群节点的硬件信息,其中,硬件信息包括以下至少之一:中央处理器、内存、磁盘存储和网络状态。
可选地,在本申请实施例提供的容器的故障处理装置中,该装置还包括:运行状态获取单元,用于在故障诊断结果表征目标容器不存在故障的情况下,获取目标容器在预设时段内的运行状态;第六确定单元,用于在预设时段内目标容器的运行状态存在异常的情况下,确定异常原因;第七确定单元,用于将异常原因确定为新增故障原因,确定新增故障原因的新增故障溯源路径,并将新增故障原因和新增故障溯源路径确定为目标故障诊断结果;第三训练单元,用于将预设时段内目标容器的日志信息、硬件信息、目标故障诊断结果确定为第二新增训练样本,将第二新增训练样本与多组训练样本组合,得到更新后的多组训练样本,基于更新后的多组训练样本更新目标模型。
可选地,在本申请实施例提供的容器的故障处理装置中,该装置还包括:转化单元,用于将日志信息中的非结构化数据转化为结构化数据,得到转化后的日志信息;过滤单元,用于对转化后的日志信息和硬件信息过滤噪声数据,并对硬件信息进行标准化处理,得到更新后的日志信息和硬件信息;第二执行单元,用于基于更新后的日志信息和硬件信息执行将日志信息和硬件信息输入目标模型的步骤。
此处需要说明的是,上述获取单元401、输入单元402、提取单元403和第一执行单元404对应于实施例1中的步骤S201至步骤S204,4个单元与对应的步骤所实现的实例和应用场景相同,但不限于上述实施例一所公开的内容。需要说明的是,上述模块或单元可以是存储在存储器(例如,存储器104)中并由一个或多个处理器(例如,处理器102a,102b,……,102n)处理的硬件组件或软件组件,上述模块或单元也可以作为装置的一部分可以运行在实施例一提供的计算机终端10中。
实施例3
本申请的实施例可以提供一种电子设备,图5是根据本申请实施例的一种电子设备的结构框图。如图5所示,该电子设备可以包括:一个或多个(图5中仅示出一个)处理器502、存储器504、存储控制器、以及外设接口,其中,外设接口与射频模块、音频模块和显示器连接。
其中,存储器可用于存储软件程序以及模块,如本申请实施例中的方法和装置对应的程序指令/模块,处理器通过运行存储在存储器内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的方法。存储器可包括高速随机存储器,还可以包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器可进一步包括相对于处理器远程设置的存储器,这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
处理器可以通过传输装置调用存储器存储的信息及应用程序,以执行以下步骤:获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息;将日志信息和硬件信息输入目标模型,得到故障诊断结果;在故障诊断结果表征目标容器存在故障的情况下,从故障诊断结果中提取出故障原因和故障溯源路径;基于故障原因和故障溯源路径确定故障修复方案,对目标容器执行故障修复方案。
处理器还可以通过传输装置调用存储器存储的信息及应用程序,以执行以下步骤:获取预设周期内目标容器的故障诊断结果,从预设周期内的故障诊断结果中确定目标容器的故障类型分布、故障频次和故障修复结果;获取预设周期内目标容器的日志信息和硬件信息,基于预设周期内的日志信息和硬件信息确定目标容器的计算资源使用状态;基于计算资源使用状态确定目标容器的运行状态评估值,在运行状态评估值大于等于评估值阈值的情况下,发出警告信息,其中,警告信息用于提示目标容器存在运行风险。
处理器还可以通过传输装置调用存储器存储的信息及应用程序,以执行以下步骤:获取目标容器的历史日志信息和历史硬件信息,并确定每组历史日志信息和对应的历史硬件信息的历史故障诊断结果;将每组历史日志信息、历史硬件信息和历史故障诊断结果确定为一组训练样本,得到多组训练样本;通过多组训练样本训练大语言模型,得到目标模型。
处理器还可以通过传输装置调用存储器存储的信息及应用程序,以执行以下步骤:每隔优化周期采集目标容器的新增日志信息、新增硬件信息和新增故障诊断结果;将每组新增日志信息、新增硬件信息和新增故障诊断结果确定为一组第一新增训练样本,得到多组第一新增训练样本;将多组第一新增训练样本与多组训练样本组合,得到优化后的多组训练样本,通过优化后的多组训练样本训练目标模型,得到优化后的目标模型。
处理器还可以通过传输装置调用存储器存储的信息及应用程序,以执行以下步骤:将目标容器部署至集群环境中的集群节点中;通过预设采集工具采集目标容器的日志信息,其中,日志信息包括以下至少之一:标准输出、错误日志和事件信息,标准输出包含目标容器内应用程序的执行信息和非正常信息;通过预设采集工具采集集群节点的硬件信息,其中,硬件信息包括以下至少之一:中央处理器、内存、磁盘存储和网络状态。
处理器还可以通过传输装置调用存储器存储的信息及应用程序,以执行以下步骤:在故障诊断结果表征目标容器不存在故障的情况下,获取目标容器在预设时段内的运行状态;在预设时段内目标容器的运行状态存在异常的情况下,确定异常原因;将异常原因确定为新增故障原因,确定新增故障原因的新增故障溯源路径,并将新增故障原因和新增故障溯源路径确定为目标故障诊断结果;将预设时段内目标容器的日志信息、硬件信息、目标故障诊断结果确定为第二新增训练样本,将第二新增训练样本与多组训练样本组合,得到更新后的多组训练样本,基于更新后的多组训练样本更新目标模型。
处理器还可以通过传输装置调用存储器存储的信息及应用程序,以执行以下步骤:将日志信息中的非结构化数据转化为结构化数据,得到转化后的日志信息;对转化后的日志信息和硬件信息过滤噪声数据,并对硬件信息进行标准化处理,得到更新后的日志信息和硬件信息;基于更新后的日志信息和硬件信息执行将日志信息和硬件信息输入目标模型的步骤。
采用本申请实施例,提供了一种获取目标容器的日志信息,并获取目标容器所部署的集群节点的硬件信息;将日志信息和硬件信息输入目标模型,得到故障诊断结果;在故障诊断结果表征目标容器存在故障的情况下,从故障诊断结果中提取出故障原因和故障溯源路径;基于故障原因和故障溯源路径确定故障修复方案,对目标容器执行故障修复方案的方案。通过自动化地收集和分析容器的日志信息和硬件信息,利用目标模型快速定位故障原因,并提供准确的故障溯源路径和可行的故障修复方案,达到了增强容器化应用的安全性和可靠性的目的,从而实现了提高容器的故障诊断准确率的技术效果,进而解决了相关技术中容器的故障诊断准确率低的技术问题。
本领域普通技术人员可以理解,图5所示的结构仅为示意,电子设备也可以是智能手机、平板电脑、掌上电脑以及移动互联网设备(Mobile Internet Devices,MID)、PAD等终端设备。图5其并不对上述电子装置的结构造成限定。例如,电子设备还可包括比图5中所示更多或者更少的组件(如网络接口、显示装置等),或者具有与图5所示不同的配置。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:闪存盘、只读存储器(Read-Only Memory,ROM)、随机存取器(RandomAccess Memory,RAM)、磁盘或光盘等。
实施例4
本申请的实施例还提供了一种存储介质。可选地,在本实施例中,上述存储介质可以用于保存上述实施例一所提供的容器的故障处理方法所执行的程序代码。
可选地,在本实施例中,上述存储介质可以位于计算机网络中计算机终端群中的任意一个计算机终端中,或者位于移动终端群中的任意一个移动终端中。
本申请还提供了一种计算机程序产品,当在数据处理设备上执行时,适于执行容器的故障处理方法步骤的程序。
上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
在本申请的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的技术内容,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述仅是本申请的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。
Claims (10)
1.一种容器的故障处理方法,其特征在于,包括:
获取目标容器的日志信息,并获取所述目标容器所部署的集群节点的硬件信息;
将所述日志信息和所述硬件信息输入目标模型,得到故障诊断结果;
在所述故障诊断结果表征所述目标容器存在故障的情况下,从所述故障诊断结果中提取出故障原因和故障溯源路径;
基于所述故障原因和所述故障溯源路径确定故障修复方案,对所述目标容器执行所述故障修复方案。
2.根据权利要求1所述的方法,其特征在于,在将所述日志信息和所述硬件信息输入目标模型,得到故障诊断结果之后,所述方法还包括:
获取预设周期内所述目标容器的故障诊断结果,从所述预设周期内的故障诊断结果中确定所述目标容器的故障类型分布、故障频次和故障修复结果;
获取所述预设周期内所述目标容器的日志信息和硬件信息,基于所述预设周期内的日志信息和硬件信息确定所述目标容器的计算资源使用状态;
基于所述计算资源使用状态确定所述目标容器的运行状态评估值,在所述运行状态评估值大于等于评估值阈值的情况下,发出警告信息,其中,所述警告信息用于提示所述目标容器存在运行风险。
3.根据权利要求1所述的方法,其特征在于,所述目标模型由以下方式得到:
获取所述目标容器的历史日志信息和历史硬件信息,并确定每组历史日志信息和对应的历史硬件信息的历史故障诊断结果;
将每组历史日志信息、所述历史硬件信息和所述历史故障诊断结果确定为一组训练样本,得到多组训练样本;
通过所述多组训练样本训练大语言模型,得到所述目标模型。
4.根据权利要求1所述的方法,其特征在于,所述方法还包括:
每隔优化周期采集所述目标容器的新增日志信息、新增硬件信息和新增故障诊断结果;
将每组所述新增日志信息、所述新增硬件信息和所述新增故障诊断结果确定为一组第一新增训练样本,得到多组第一新增训练样本;
将所述多组第一新增训练样本与多组训练样本组合,得到优化后的多组训练样本,通过所述优化后的多组训练样本训练所述目标模型,得到优化后的目标模型。
5.根据权利要求1所述的方法,其特征在于,获取目标容器的日志信息,并获取所述目标容器所部署的集群节点的硬件信息包括:
将所述目标容器部署至集群环境中的集群节点中;
通过预设采集工具采集所述目标容器的日志信息,其中,所述日志信息包括以下至少之一:标准输出、错误日志和事件信息,所述标准输出包含所述目标容器内应用程序的执行信息和非正常信息;
通过所述预设采集工具采集所述集群节点的硬件信息,其中,所述硬件信息包括以下至少之一:中央处理器、内存、磁盘存储和网络状态。
6.根据权利要求1所述的方法,其特征在于,在将所述日志信息和所述硬件信息输入目标模型,得到故障诊断结果之后,所述方法还包括:
在所述故障诊断结果表征所述目标容器不存在故障的情况下,获取所述目标容器在预设时段内的运行状态;
在所述预设时段内所述目标容器的运行状态存在异常的情况下,确定异常原因;
将所述异常原因确定为新增故障原因,确定所述新增故障原因的新增故障溯源路径,并将所述新增故障原因和所述新增故障溯源路径确定为目标故障诊断结果;
将所述预设时段内所述目标容器的日志信息、硬件信息、所述目标故障诊断结果确定为第二新增训练样本,将所述第二新增训练样本与多组训练样本组合,得到更新后的多组训练样本,基于所述更新后的多组训练样本更新所述目标模型。
7.根据权利要求1所述的方法,其特征在于,在获取目标容器的日志信息,并获取所述目标容器所部署的集群节点的硬件信息之后,所述方法还包括:
将所述日志信息中的非结构化数据转化为结构化数据,得到转化后的日志信息;
对所述转化后的日志信息和所述硬件信息过滤噪声数据,并对所述硬件信息进行标准化处理,得到更新后的日志信息和硬件信息;
基于所述更新后的日志信息和硬件信息执行将所述日志信息和所述硬件信息输入目标模型的步骤。
8.一种容器的故障处理装置,其特征在于,包括:
获取单元,用于获取目标容器的日志信息,并获取所述目标容器所部署的集群节点的硬件信息;
输入单元,用于将所述日志信息和所述硬件信息输入目标模型,得到故障诊断结果;
提取单元,用于在所述故障诊断结果表征所述目标容器存在故障的情况下,从所述故障诊断结果中提取出故障原因和故障溯源路径;
第一执行单元,用于基于所述故障原因和所述故障溯源路径确定故障修复方案,对所述目标容器执行所述故障修复方案。
9.一种电子设备,其特征在于,包括:
存储器,存储有可执行程序;
处理器,用于运行所述程序,其中,所述程序运行时执行权利要求1至7中任意一项所述的容器的故障处理方法。
10.一种计算机程序产品,包括计算机指令,其特征在于,所述计算机指令被处理器执行时实现权利要求1至7中任意一项所述的容器的故障处理方法的步骤。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202510636239.6A CN120508429A (zh) | 2025-05-16 | 2025-05-16 | 容器的故障处理方法、装置、电子设备及计算机程序产品 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202510636239.6A CN120508429A (zh) | 2025-05-16 | 2025-05-16 | 容器的故障处理方法、装置、电子设备及计算机程序产品 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN120508429A true CN120508429A (zh) | 2025-08-19 |
Family
ID=96709981
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202510636239.6A Pending CN120508429A (zh) | 2025-05-16 | 2025-05-16 | 容器的故障处理方法、装置、电子设备及计算机程序产品 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN120508429A (zh) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN120687329A (zh) * | 2025-08-25 | 2025-09-23 | 济南浪潮数据技术有限公司 | 故障诊断方法和装置、存储介质和电子设备 |
-
2025
- 2025-05-16 CN CN202510636239.6A patent/CN120508429A/zh active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN120687329A (zh) * | 2025-08-25 | 2025-09-23 | 济南浪潮数据技术有限公司 | 故障诊断方法和装置、存储介质和电子设备 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108491305B (zh) | 一种服务器故障的检测方法及系统 | |
| CN114267178B (zh) | 一种车站的智能运营维护方法及装置 | |
| CN118826294A (zh) | 一种基于变电站的运维数字化管理方法及系统 | |
| KR20180108446A (ko) | Ict 인프라 관리 시스템 및 이를 이용한 ict 인프라 관리 방법 | |
| CN110245053A (zh) | 故障预测诊断方法及系统 | |
| CN119997074B (zh) | 一种5G随身WiFi故障诊断与恢复方法及系统 | |
| CN118446671A (zh) | 一种一体化智慧运维控制方法及系统 | |
| CN120508429A (zh) | 容器的故障处理方法、装置、电子设备及计算机程序产品 | |
| CN117670033A (zh) | 一种安全检查方法、系统、电子设备及存储介质 | |
| CN119625953B (zh) | 一种用于移动端的电力设备异常预警系统 | |
| CN119227980B (zh) | 一种基于人工智能的应急预案生成方法及系统 | |
| CN112398706A (zh) | 数据评估标准确定方法、装置及存储介质、电子设备 | |
| CN120499044A (zh) | 适用于物联网大数据中心的异常运行数据检测方法 | |
| CN120474891A (zh) | 低等级告警管理方法及装置 | |
| CN120216237A (zh) | 故障检测方法、装置及电子设备 | |
| CN117853087A (zh) | 电力设备的数据分析系统 | |
| CN117667570A (zh) | 一种统一监控数字化平台 | |
| KR102742509B1 (ko) | 서비스의 안정성, 성능, 확장성 개선을 위한 클라우드 환경 딥러닝 기반 서비스 최적화 설정 추천 및 시뮬레이션 검증 시스템 및 방법 | |
| CN119646702B (zh) | 基于核电厂技术规格书的异常处理方法、系统及相关介质 | |
| CN121542081A (zh) | 系统的故障分析方法、装置、电子设备及计算机程序产品 | |
| KR102749050B1 (ko) | 피드백과 결과 분석을 이용하여 처리 방안의 우선 순위를 제안하는 방법 및 디바이스 | |
| CN113037550B (zh) | 一种服务故障监控方法、系统及计算机可读存储介质 | |
| CN117667311A (zh) | 容器集群的监控告警方法及装置 | |
| CN119513774A (zh) | 设备的故障概率的确定方法及装置、存储介质及电子装置 | |
| CN120611158A (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 |