CN117614853A - 云原生环境下的告警监控方法、系统、设备及介质 - Google Patents

云原生环境下的告警监控方法、系统、设备及介质 Download PDF

Info

Publication number
CN117614853A
CN117614853A CN202311581697.1A CN202311581697A CN117614853A CN 117614853 A CN117614853 A CN 117614853A CN 202311581697 A CN202311581697 A CN 202311581697A CN 117614853 A CN117614853 A CN 117614853A
Authority
CN
China
Prior art keywords
alarm
data
monitoring
target
container cluster
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
Application number
CN202311581697.1A
Other languages
English (en)
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.)
Ping An Life Insurance Company of China Ltd
Original Assignee
Ping An Life Insurance Company of China 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 Ping An Life Insurance Company of China Ltd filed Critical Ping An Life Insurance Company of China Ltd
Priority to CN202311581697.1A priority Critical patent/CN117614853A/zh
Publication of CN117614853A publication Critical patent/CN117614853A/zh
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/02Capturing of monitoring data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0631Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/04Processing captured monitoring data, e.g. for logfile generation
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02PCLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Alarm Systems (AREA)

Abstract

本申请提供了云原生环境下的告警监控方法、系统、设备及介质,属于告警监控和金融科技领域。方法包括:通过多个从监控组件分别获取所在的容器集群内的初始监控数据;将各个从监控组件获取的初始监控数据,发送到与各个从监控组件通信连接的主监控组件中;对初始监控数据进行过滤,得到多个容器集群下的全量数据,并将全量数据发送到与主监控组件通信连接的告警中心中;将告警中心的全量数据与预设的告警阈值进行对比,根据对比结果确定全量数据中的目标告警数据;基于目标告警数据,在告警中心中生成对应的容器集群的告警信息。本申请能够在一个告警中心上监控多渠道容器集群的数据,从而提高了拓展性,降低了监控的设计难度,提高了监控效率。

Description

云原生环境下的告警监控方法、系统、设备及介质
技术领域
本申请涉及告警监控和金融科技技术领域,尤其涉及一种云原生环境下的告警监控方法、系统、设备及介质。
背景技术
金融科技领域中广泛采用云原生生态技术,云原生生态技术指的是一种针对云计算环境的软件开发和部署方法论,旨在支持构建可弹性扩展、高可用、可靠和可管理的应用程序。目前,可以通过云原生容器编排(kubernetes,k8s)平台对微服务进行容器化部署,以支持云原生监控体系。
通过告警中心进行云原生监控可以提供实时、全面和可定制的监控服务。但是,相关技术中,告警中心仅能针对单一容器集群的数据进行监控,告警中心拓展性差,若要监控多渠道容器集群的数据,往往需要重新设计,且由于不同的容器集群所使用的告警规则不同,还大大增加了监控的设计难度,降低了监控效率,使得现有的告警中心无法满足多渠道容器集群的监控要求。
发明内容
本申请实施例的主要目的在于提出一种云原生环境下的告警监控方法、系统、设备及介质,能够在一个告警中心上监控多渠道容器集群的数据,从而提高了拓展性,且只需要在告警中心中统一配置告警规则,从而降低了监控的设计难度,提高了监控效率。
为实现上述目的,本申请实施例的第一方面提出了一云原生环境下的告警监控方法,所述方法包括:通过多个从监控组件分别获取所在的容器集群内的初始监控数据,其中,每个所述容器集群部署有至少一个所述从监控组件;将各个所述从监控组件获取的所述初始监控数据,发送到与各个所述从监控组件通信连接的主监控组件中;对所述主监控组件中的所述初始监控数据进行过滤,得到多个所述容器集群下的全量数据,并将所述全量数据发送到与所述主监控组件通信连接的告警中心中;将所述告警中心的所述全量数据与预设的告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据;基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的告警信息。
在一些实施例中,所述对所述主监控组件中的所述初始监控数据进行过滤,得到多个所述容器集群下的全量数据,包括:根据预设的基础告警规则,分别对所述主监控组件中不同所述容器集群的所述初始监控数据进行过滤,得到各个所述容器集群的过滤后监控数据;在所述主监控组件中为接收各个所述初始监控数据生成所在的所述容器集群的集群标签,为各个所述过滤后监控数据附上对应的所述集群标签,得到各个带标监控数据;将所有的所述带标监控数据,作为多个所述容器集群下的全量数据。
在一些实施例中,所述将所述告警中心的所述全量数据与预设的告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据,包括:获取用户端的自定义输入数据,根据所述自定义输入数据生成监控项标准信息;根据所述监控项标准信息对所述告警中心中的所述全量数据进行格式化和数据过滤处理,得到标准化后的所述全量数据;将标准化后的所述全量数据与预设的告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据。
在一些实施例中,所述将标准化后的所述全量数据与预设的告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据,包括:基于各个所述容器集群的工作负载对象,在所述告警中心显示对应的告警规则配置界面;响应于所述告警规则配置界面上的输入指令,生成各个工作负载对象的运行指标数据,将各项所述指标数据作为告警阈值;将标准化后的所述全量数据,分别与各个工作负载对象的所述告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据。
在一些实施例中,所述基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的告警信息,包括:持续将接收到的所述全量数据与所述告警阈值进行对比,根据多次对比结果确定所述目标告警数据的告警命中次数,根据所述告警命中次数与预设的触发阈值进行对比,得到告警触发结果;获取各个所述目标告警数据的类别信息,根据各个所述类别信息确定各个所述目标告警数据之间是否为相同类别的类别对比结果;获取预设的屏蔽列表,确定各个所述目标告警数据是否处于所述屏蔽列表中,得到屏蔽确定结果;根据所述告警触发结果、所述类别对比结果和所述屏蔽确定结果中的至少一个,对每个所述目标告警数据进行收敛处理,基于收敛后的所述目标告警数据,在所述告警中心中生成对应的所述容器集群的告警信息。
在一些实施例中,所述基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的告警信息,包括:若所述对比结果表征所述全量数据与所述告警阈值之间为第一大小关系,则基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的第一级别告警信息;若所述对比结果表征所述全量数据与所述告警阈值之间为第二大小关系,则基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的第二级别告警信息;其中,所述第一级别告警信息与所述第二级别告警信息表征的告警方式不同,所述第一级别告警信息小于所述第二级别告警信息的告警级别。
在一些实施例中,所述在所述告警中心中生成对应的所述容器集群的第一级别告警信息之后,所述方法还包括:从预设的自愈策略库中确定与所述目标告警数据相匹配的目标自愈策略;向所述目标告警数据对应的所述容器集群发送所述目标自愈策略,以使所述容器集群根据所述目标自愈策略进行自愈处理。
为实现上述目的,本申请实施例的第二方面提出了一种云原生环境下的告警监控系统,所述系统包括:监控数据获取模块,用于通过多个从监控组件分别获取所在的容器集群内的初始监控数据,其中,每个所述容器集群部署有至少一个所述从监控组件;数据收集模块,用于将各个所述从监控组件获取的所述初始监控数据,发送到与各个所述从监控组件通信连接的主监控组件中;全量数据获取模块,用于对所述主监控组件中的所述初始监控数据进行过滤,得到多个所述容器集群下的全量数据,并将所述全量数据发送到与所述主监控组件通信连接的告警中心中;告警命中模块,用于将所述告警中心的所述全量数据与预设的告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据;告警生成模块,用于基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的告警信息。
为实现上述目的,本申请实施例的第三方面提出了一种电子设备,所述电子设备包括存储器和处理器,所述存储器存储有计算机程序,所述处理器执行所述计算机程序时实现上述第一方面实施例所述的方法。
为实现上述目的,本申请实施例的第四方面提出了一种存储介质,所述存储介质为计算机可读存储介质,所述存储介质存储有计算机程序,所述计算机程序被处理器执行时实现上述第一方面实施例所述的方法。
本申请实施例具有以下有益效果:通过在多个容器集群中分别部署从监控组件,可以获取各个容器集群内的初始监控数据,随后将各个从监控组件获取的初始监控数据,发送到与各个从监控组件通信连接的主监控组件中,从而实现了多渠道监控数据采集,接着在主监控组件内,可以对初始监控数据先进行基础过滤,得到的数据作为多个容器集群下的全量数据,并将全量数据发送到与主监控组件通信连接的告警中心中,使得告警中心可以监控多渠道容器集群的数据,从而提高了拓展性。而告警中心统一配置有告警规则,并部署有各个全量数据对应的告警阈值,因此可以将全量数据与预设的告警阈值进行对比,根据对比结果确定全量数据中的目标告警数据,因此即使面对多渠道来源的数据,也只需要在告警中心中统一配置告警规则,从而降低了监控的设计难度,提高了监控效率,最终基于目标告警数据,在告警中心中生成对应的容器集群的告警信息,使得告警中心可以满足多渠道容器集群的监控要求。
附图说明
图1是本申请实施例提供的云原生环境下的告警监控方法的流程图;
图2是图1中的步骤S103的流程图;
图3是图1中的步骤S104的流程图;
图4是图3中的步骤S303的流程图;
图5是图1中的步骤S105的流程图;
图6是图1中的步骤S105的另一个流程图;
图7是图6中的步骤S601之后的流程图;
图8是本申请实施例提供的完整告警过程的示意图;
图9是本申请实施例提供的云原生环境下的告警监控系统的功能模块示意图;
图10是本申请实施例提供的电子设备的硬件结构示意图。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本申请进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本申请,并不用于限定本申请。
需要说明的是,虽然在装置示意图中进行了功能模块划分,在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于装置中的模块划分,或流程图中的顺序执行所示出或描述的步骤。说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。
除非另有定义,本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的,不是旨在限制本申请。
首先,对本申请中涉及的若干名词进行解析:
云原生生态技术指的是一种针对云计算环境的软件开发和部署方法论,旨在支持构建可弹性扩展、高可用、可靠和可管理的应用程序。它包括一系列的设计原则、最佳实践和工具链,旨在使应用程序具备云原生特征并能够充分利用云计算平台的优势。云原生生态技术主要关注容器化、编排和自动化、微服务架构、敏捷开发和持续交付、弹性和可靠性等内容。云原生生态技术可以帮助企业构建具备高可用性、弹性、容错性和可扩展性的应用程序,提高开发效率和部署灵活性,并更好地适应云计算环境的特点和需求。
容器编排(Kubernetes,K8s)是一个用于自动化容器化应用程序部署、扩展和管理的开源平台,它提供了一个容器编排和管理的解决方案,旨在简化大规模容器集群的部署和运维。Kubernetes的设计目标是提供一个可移植、可扩展且自动化的平台,能够处理跨多个主机的容器集群,它能够动态地将容器调度到合适的主机上,并提供弹性伸缩、自我修复和负载均衡等功能,以确保应用程序的高可用性和可靠性。
核心容器服务集群(Pivotal Container Service,PKS)是一个基于Kubernetes的容器编排平台,它为企业提供了在私有云或公有云上运行容器化应用程序的能力,用于管理和运行大规模的容器化应用程序和服务,它包含了主节点(Master Node)、工作节点(Worker Node)、容器、存储、网络以及监控和日志等组件和功能。
目标越来越多的企业开始建设云原生生态技术,使得大部分微服务已通过云原生kubernetes容器编排平台完成了容器化部署。通过告警中心进行云原生监控可以提供实时、全面和可定制的监控服务。然而,针对云原生的监控,告警中心仅能针对单一容器集群的数据进行监控,告警中心拓展性差,若要监控多渠道容器集群的数据,往往需要重新设计,且由于不同的容器集群所使用的告警规则不同,还大大增加了监控的设计难度,降低了监控效率,使得现有的告警中心无法满足多渠道容器集群的监控要求。
在金融科技领域,监控数据的采集和告警管理是非常重要的。对于部署在各个PKS集群中的应用程序和基础设施进行监控可以帮助金融科技公司实时了解系统的健康状况、性能指标和异常事件,从而及时发现和解决问题,确保系统的正常运行和高可用性。
基于此,本申请实施例提供了一种云原生环境下的告警监控方法、系统、设备及介质,云原生环境下的告警监控方法可以应用在云原生环境下的告警监控系统中,能够在一个告警中心上监控多渠道容器集群的数据,从而提高了拓展性,且只需要在告警中心中统一配置告警规则,从而降低了监控的设计难度,提高了监控效率。
本申请实施例提供的云原生环境下的告警监控方法、系统、设备及介质,具体通过如下实施例进行说明,首先描述本申请实施例中的云原生环境下的告警监控方法。
本申请实施例可以基于人工智能技术对相关的数据进行获取和处理。其中,人工智能(Artificial Intelligence,AI)是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能,感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。
人工智能基础技术一般包括如传感器、专用人工智能芯片、云计算、分布式存储、大计算机技术、操作/交互系统、机电一体化等技术。人工智能软件技术主要包括计算机视觉技术、机器人技术、生物识别技术、语音处理技术、自然语言处理技术以及机器学习/深度学习等几大方向。
本申请实施例提供的云原生环境下的告警监控方法,涉及人工智能技术领域。本申请实施例提供的云原生环境下的告警监控方法可应用于终端中,也可应用于服务器端中,还可以是运行于终端或服务器端中的软件。在一些实施例中,终端可以是智能手机、平板电脑、笔记本电脑、台式计算机等;服务器端可以配置成独立的物理服务器,也可以配置成多个物理服务器构成的服务器集群或者分布式系统,还可以配置成提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN以及大数据和人工智能平台等基础云计算服务的云服务器;软件可以是实现云原生环境下的告警监控方法的应用等,但并不局限于以上形式。
本申请可用于众多通用或专用的计算机系统环境或配置中。例如:个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
需要说明的是,在本申请的各个具体实施方式中,当涉及到需要根据用户信息、用户行为数据,用户历史数据以及用户位置信息等与用户身份或特性相关的数据进行相关处理时,都会先获得用户的许可或者同意,例如,进行告警监控之前或者获取各项监控数据时,均会先获得用户的许可或者同意。而且,对这些数据的收集、使用和处理等,都会遵守相关法律法规和标准。此外,当本申请实施例需要获取用户的敏感个人信息时,会通过弹窗或者跳转到确认页面等方式获得用户的单独许可或者单独同意,在明确获得用户的单独许可或者单独同意之后,再获取用于使本申请实施例能够正常运行的必要的用户相关数据。
请参阅图1,图1是本申请实施例提供的云原生环境下的告警监控方法的一个可选的流程图,图1中的方法可以包括但不限于包括步骤S101至步骤S105。
步骤S101,通过多个从监控组件分别获取所在的容器集群内的初始监控数据,其中,每个容器集群部署有至少一个从监控组件;
示例性的,容器集群为PKS集群,容器集群是一种用于管理和运行多个容器实例的环境。在云原生计算中,容器集群通常由多个主机(物理机或虚拟机)组成,这些主机上部署了容器化的应用程序,容器集群提供了一种分布式的、可扩展的方式来运行容器,以满足现代应用的高可用性、弹性和可扩展性需求。可以理解的是,容器集群可以包括主节点、从节点、存储、网络和服务发现等基础设施组件,以提供管理、存储、容器间通信和服务发现等功能。
示例性的,从监控组件是在每个容器集群中部署联邦的Prometheus,Prometheus是一种开源的监控和警报工具,其中包括了完整的时序数据库和强大的查询语言。在Kubernetes中,Prometheus用于收集和存储与集群相关的监控数据,包括节点资源使用情况、容器的状态、服务的性能指标等。Prometheus可以通过在应用程序中插入指标采集代码或使用适配器来从其他监控系统获取数据,并提供丰富的图形、报警和查询功能,以监控和管理容器集群,在此不做具体限制。需要说明的是,每个容器集群可以根据需要满足监控要数量的从监控组件,本申请实施例中以每个容器集群设置有一个从监控组件为例子。
示例性的,初始监控数据是各个从监控组件从各自所在的容器集群中所采样得到的原始数据,这些数据尚没有经过告警筛选或过滤,初始监控数据可以帮助系统管理员和开发人员了解集群的整体健康状况、资源利用情况和应用程序的性能表现等,通过对监控数据的分析,可以用于筛选出告警以及时发现潜在的问题,并采取相应的措施进行优化和故障排除。
在一些实施例中,联邦Prometheus是指在每个容器集群中部署独立的Prometheus实例,这些实例可以独立地采集和存储该集群的监控数据。在容器集群环境下,如果有多个PKS集群,每个集群都有自己的Prometheus服务器来监控该集群内的指标数据,可以实现多集群的集中式监控和报警。
在一些实施例中,初始监控数据可以有多种。例如,初始监控数据可以包括CPU使用率,通过监测容器或节点的CPU利用率,可以衡量资源的消耗情况;还可以包括内存使用率,通过监测容器或节点的内存利用率,可以判断内存资源是否充足;还可以包括网络流量,通过监测容器或节点上的网络吞吐量,可以了解应用程序的网络性能;还可以包括存储利用率,通过监测容器或节点上的存储使用情况,可以判断存储资源的分配和利用情况;还可以包括Pod和容器状态,通过监测Pod和容器的运行状态,包括启动、停止、重启等情况;还可以包括节点健康状况,通过监测节点的健康状态,包括节点的连接性、负载情况等;还可以包括事件日志,用于记录集群中发生的重要事件和错误,以便及时发现和排查问题。初始监控数据还可以有其他的数据,如其他性能数据、运行数据、资源数据或自定义数据等,在此不做具体限制。
此外,在满足本申请实施例要求的前提下,还可以在容器集群中部署自定义的脚本文件,实现初始监控数据的采集。例如,通过部署自定义的Exporter脚本,用于将应用程序、服务或设备的指标数据暴露给从监控组件进行采集。需要说明的是,Exporter脚本可以采用不同的方式获取指标数据,比如通过API调用、文件解析、命令执行等,从监控组件可以通过配置来调用Exporter脚本,并定期采集这些脚本暴露的指标数据。
步骤S102,将各个从监控组件获取的初始监控数据,发送到与各个从监控组件通信连接的主监控组件中;
示例性的,主监控组件是主Prometheus,因此,主监控组件也是一个Prometheus,上述已经对Prometheus进行了介绍,在这里不再赘述。
在一些实施例中,主监控组件是一个独立的组件,可以单独在一个独立的服务器或集群中进行部署,可以作为监控告警中心的核心的Prometheus实例,负责接收并处理来自多个容器集群中各个从监控组件的初始监控数据。需要说明的是,主监控组件可以通过配置好的数据接口(如federate接口)来拉取各个从监控组件中的数据,并对这些数据进行告警配置,在此不做具体限制。
在一些实施例中,主监控组件和从监控组件形成联邦的设计方式,可以将多个容器集群中的初始监控数据集中管理和处理,各个从监控组件可以将初始监控数据发送到主监控组件进行相对持久化的存储或持久化存储,这样就减轻了各个从监控组件的存储压力和存储成本,且可以在主监控组件配置告警规则,因此不需要直接在每个集群中配置和管理告警规则,降低设计成本,提高了告警规则的设计效率。因此,本申请实施例中的主监控组件s作为中心组件,可以统一处理各个联邦的从监控组件传递过来的监控数据,并进行相应的告警处理和分发。
在一些实施例中,主监控组件获取初始监控数据的时间可以有多种。例如,主监控组件可以周期性获取从监控组件的初始监控数据,采样周期可以根据用户自定义设置,以便后续可以随时进行告警监控;或者,从监控组件可以设置采样阈值,当采样得到的初始监控数据的大小大于或等于该阈值时,确定对对应的时机为发送时间,因此再将采样得到的初始监控数据发送给主监控组件。
步骤S103,对主监控组件中的初始监控数据进行过滤,得到多个容器集群下的全量数据,并将全量数据发送到与主监控组件通信连接的告警中心中;
在一些实施例中,主监控组件中设置有告警规则,通过该告警规则可以对初始监控数据进行过滤,从而得到过滤改后的监控数据。本申请实施例中的主监控组件可以对初始监控数据进行初步的筛选过滤,例如,可以过滤掉无用的监控数据,是的过滤后的数据更加精简,方便后续处理,又例如,可以过滤掉低于一定阈值的监控数据,减少后续告警中心处理的数据量。
在一些实施例中,本申请实施例中主监控组件设置的是基础的告警规则,基础告警规则可以对初始监控数据进行简单的筛选过滤。具体的,基于基础告警规则下,可以设定较低的第一告警阈值,通过该第一告警阈值与各项初始监控数据进行对比,过滤掉低于该第一告警阈值的监控数据。可以理解的是,针对不同的初始监控数据,可以分别设定基于基础告警规则下的第一告警阈值,在此不做具体限制。
示例性的,全量数据是指完整、全部的数据集,也即告警中心可以获取主监控组件存储的全部监控数据。本申请实施例中告警中心需要从主监控组件获取全量完整的一个告警数据之后入库,才能根据用户所定义的阈值和收敛规则进行进一步的降噪等处理,如果不获取全量的数据在告警中心入库处理,那需要在主监控组件中进行大量的计算,一旦主监控组件宕机,影响的是全量的监控和告警,而且在主监控组件也不适合做一些自定义逻辑操作。
示例性的,告警中心是一个用于集中管理和处理系统或应用程序产生的告警信息的平台或系统,它通过监控系统并检测到异常情况时生成告警,然后将这些告警集中存储、分类、过滤、处理,并通知相关人员或系统管理员。告警中心旨在帮助组织及时识别和解决系统故障、性能问题、安全事件等,从而保证系统的稳定性和可靠性。
总之,基础告警规则下的第一告警阈值是由用户自行定义的,本申请实施例中需要先采集全量的告警数据入到告警中心的数据库中,所以会先评估一个相对比较低且合理的阈值去触发告警然后入库,之后在告警中心在进行进一步的处理。
步骤S104,将告警中心的全量数据与预设的告警阈值进行对比,根据对比结果确定全量数据中的目标告警数据;
示例性的,预设的告警阈值是告警中心为了对监控数据进行告警筛选所设定的阈值,预设的告警阈值可以是预先由用户输入得到的,而对于多渠道的多个容器集群,仅需要在告警中心中进行统一配置,就可以完成对多个集群的告警规则设置,提高了监控的拓展性和效率。可以理解的是,预设的告警阈值可以称为第二告警阈值,因此本申请实施例中预先在主监控组件上通过较低的第一告警阈值进行筛选后,再在告警中心中通过较高的第二告警阈值来确定最终被命中为告警的监控数据。而针对不同的监控数据,也就是全量数据中的各项监控数据,可以分别设定合适的第二告警阈值,在此不做具体限制。
在一些实施例中,将告警中心的全量数据与预设的告警阈值进行对比后,可以分别得到其中各项监控数据与对应的第二告警阈值的大小对比结果,这个对比结果可以表明各项监控数据是否超过第二告警阈值。因此,当全量数据中的某项监控数据大于对应的第二告警阈值,则可以确定这个监控数据已经超过工作要求,需要发出告警,最终该监控数据可以被确定为目标告警数据。
在一些实施例中,由于全量数据中含有多项监控数据,可以存在多项监控数据被命中为告警的情况,因此,目标告警数据有多个,这多个目标告警数据,可以分别是各个容器集群中的监控数据,也可以只是某一个容器集群中的监控数据。需要说明的是,通过确定目标告警数据,可以实现对不同容器集群中告警的确认。
步骤S105,基于目标告警数据,在告警中心中生成对应的容器集群的告警信息。
示例性的,告警信息是指在告警中心中,当监测到监控数据发生异常、达到预设的阈值或符合特定规则时所产生的通知或警示,告警信息是对潜在问题和紧急情况的即时反馈,可以帮助运维人员快速发现和解决问题,确保系统的正常运行。通过收集和分析告警信息,运维人员可以及时了解系统的健康状态,以及可能存在的问题和风险。告警信息可以通过各种渠道进行传递和通知,例如通过邮件、短信、即时通讯工具、手机应用程序等,以确保相关人员能够及时获得告警并采取相应的措施。
在一些实施例中,告警信息内的信息可以有多种。例如,告警信息可以包含告警级别,用于表示告警的重要程度和紧急程度,常见的级别有严重、高、中、低等;还可以包括告警类型,用于指示告警所属的类别或类型,例如性能问题、故障、安全事件等;还可以包括告警内容,用于具体描述告警的内容、原因和影响,通常包括相关的监测指标、故障信息、异常行为等;还可以包括告警时间,用于记录告警产生的时间戳,用于确定故障发生的时间点;还可以包括相关资源,用于指示与告警相关联的系统组件、设备、应用程序等;还可以包括告警状态,用于表示告警的当前状态,如未处理、处理中、已解决等。
综上,本申请实施例通过在多个容器集群中分别部署从监控组件,可以获取各个容器集群内的初始监控数据,随后将各个从监控组件获取的初始监控数据,发送到与各个从监控组件通信连接的主监控组件中,从而实现了多渠道监控数据采集,接着在主监控组件内,可以对初始监控数据先进行基础过滤,得到的数据作为多个容器集群下的全量数据,并将全量数据发送到与主监控组件通信连接的告警中心中,使得告警中心可以监控多渠道容器集群的数据,从而提高了拓展性。而告警中心统一配置有告警规则,并部署有各个全量数据对应的告警阈值,因此可以将全量数据与预设的告警阈值进行对比,根据对比结果确定全量数据中的目标告警数据,因此即使面对多渠道来源的数据,也只需要在告警中心中统一配置告警规则,从而降低了监控的设计难度,提高了监控效率,最终基于目标告警数据,在告警中心中生成对应的容器集群的告警信息,使得告警中心可以满足多渠道容器集群的监控要求。
本申请实施例的云原生环境下的告警监控方法可以应用在金融科技领域中。在金融科技领域,构建高度可靠和安全的系统是非常重要的,而云原生环境下的告警监控方法可以提供实时的监控和告警机制,帮助金融科技公司及时发现和解决系统中的异常情况。需要指出的是,金融科技领域对于系统的稳定性、安全性和可靠性要求较高,因此有效的告警监控方法可以帮助及时发现潜在的问题和风险,减少系统故障和数据泄露等风险的发生。同时,通过统一配置告警规则和阈值,降低了监控的设计难度,提高了监控效率,适应金融科技公司复杂多变的业务环境和需求。
需要注意的是,在实施上述告警监控方法时,金融科技公司还需考虑数据安全和合规性的问题,例如对监控数据的加密传输和存储、访问权限控制等,以确保信息的保护和符合监管要求。
请参阅图2,在一些实施例中,步骤S103可以包括步骤S201至步骤S203:
步骤S201,根据预设的基础告警规则,分别对主监控组件中不同容器集群的初始监控数据进行过滤,得到各个容器集群的过滤后监控数据;
步骤S202,在主监控组件中为接收各个初始监控数据生成所在的容器集群的集群标签,为各个过滤后监控数据附上对应的集群标签,得到各个带标监控数据;
步骤S203,将所有的带标监控数据,作为多个容器集群下的全量数据。
在一些实施例中,根据预设的基础告警规则,对主监控组件中不同容器集群的初始监控数据进行过滤,可以根据预设的规则筛选出主监控组件中各个容器集群的相关监控数据,去除不符合规则的数据,保留符合规则的数据,过滤后的监控数据被称为过滤后监控数据。
在一些实施例中,在主监控组件中为接收到的各个初始监控数据生成所在容器集群的集群标签,是为了将各个初始监控数据关联到对应的容器集群,通过生成集群标签进行标识,方便后续的数据处理和分析。随后,为各个过滤后的监控数据附上对应的集群标签,得到各个带标监控数据,可以将经过过滤后监控数据与生成的集群标签进行关联,形成带有集群标签的监控数据,称为带标监控数据,这样可以确保后续操作中可以正确地区分各个容器集群的数据。
在一些实施例中,将所有带标监控数据作为多个容器集群下的全量数据,可以将各个容器集群经过处理后的带标监控数据整合在一起,形成全量数据集合。全量数据集合包含了来自不同容器集群的监控数据,可以用于后续的数据分析、对比和告警处理。
综上,本申请实施例可以对多个容器集群内的监控数据进行收集、过滤和整合,最终得到一个综合的全量数据集合,以便于在告警中心中进行统一的数据分析和告警处理。这样可以提高监控系统的拓展性,简化监控设计,并确保监控效率和准确性。
请参阅图3,在一些实施例中,步骤S104可以包括步骤S301至步骤S303:
步骤S301,获取用户端的自定义输入数据,根据自定义输入数据生成监控项标准信息;
步骤S302,根据监控项标准信息对告警中心中的全量数据进行格式化和数据过滤处理,得到标准化后的全量数据;
步骤S303,将标准化后的全量数据与预设的告警阈值进行对比,根据对比结果确定全量数据中的目标告警数据。
在一些实施例中,本申请实施例可以获取用户端的自定义数据,该数据称为自定义输入数据,用户端可以是与告警中心连接的终端设备,也可以是告警中心的交互端。自定义输入数据可以包含用户设置的监控规则、阈值等信息,告警中心会根据这些自定义输入数据生成监控项的标准化信息,称为监控项标准信息,包括监控指标的名称、类型、单位以及预设的告警阈值等信息。通过生成标准化的监控项信息,可以确保后续对全量数据进行处理时能够准确判断是否触发告警。
需要说明的是,监控项标准信息是一个基于用户的输入定制的监控标准,本申请实施例中可以为不同的告警中心设置一份普遍和共性强监控指标阈值的初始模板,默认接入以告警中心为基础的监控系统就会绑定这份告警模板,减少了用户配置告警的工作量。除非用户特殊情况自行调整了一份告警模板进行绑定应用,则是根据用户自身的告警模板监控项阈值与告警中心所接收到的全量告警数据进行比对。例如,用户定义的cpu阈值是大于90%会告P1级别的告警,那会与告警中心接收的全量数据中的对应的应用cpu阈值进行比对,如果阈值大于90%,则写入库中并作降噪后发出告警。
在一些实施例中,本申请实施例可以将从各个容器集群中获取到的全量数据与监控项标准信息进行对比和处理。首先,本申请实施例会对全量数据进行格式化,确保数据结构与监控项标准信息一致,方便后续操作。然后,本申请实施例会根据监控项标准信息对全量数据进行过滤处理,筛选出符合标准的数据,并去除不需要的数据。这样可以确保全量数据与监控项标准信息的匹配度,减少误判和干扰。
在一些实施例中,本申请实施例可以将标准化后的全量数据与预设的告警阈值进行对比。具体会逐个监控项地比较相应的全量数据与对应的告警阈值,如果全量数据超过告警阈值,则说明该监控项触发了告警。本申请实施例会根据对比结果确定全量数据中的目标告警数据,并将其提取出来,这样可以实现根据预设的告警阈值自动检测并识别出全量数据中的异常情况,从而得到目标告警数据。
综上,本申请实施例可以根据用户的自定义输入数据生成监控项标准信息,对全量数据进行格式化和过滤处理,并将标准化后的全量数据与预设的告警阈值进行对比,最终确定目标告警数据。这样就能够实现基于目标告警数据的告警生成和通知,提供多渠道容器集群的监控要求。
请参阅图4,在一些实施例中,步骤S303可以包括步骤S401至步骤S403:
步骤S401,基于各个容器集群的工作负载对象,在告警中心显示对应的告警规则配置界面;
步骤S402,响应于告警规则配置界面上的输入指令,生成各个工作负载对象的运行指标数据,将各项指标数据作为告警阈值;
步骤S403,将标准化后的全量数据,分别与各个工作负载对象的告警阈值进行对比,根据对比结果确定全量数据中的目标告警数据。
在一些实施例中,告警中心会根据各个容器集群的工作负载对象生成对应的告警规则配置界面。工作负载对象是指容器集群中的各个应用、服务或实例等,告警规则配置界面可以展示给用户用于配置各个工作负载对象的监控规则和告警阈值等信息,通过在告警中心显示对应的告警规则配置界面,用户可以方便地对每个工作负载对象进行监控规则的配置和调整,实现应用层面的调整。
在一些实施例中,告警中心会根据用户在告警规则配置界面上的输入指令,生成各个工作负载对象的运行指标数据,并将这些指标数据作为告警阈值。运行指标数据可以包括各种性能指标、资源使用情况、错误率等等,用于描述工作负载对象的当前状态和运行情况。将各项指标数据作为告警阈值,可以根据实际情况对每个工作负载对象进行个性化的告警配置,确保监控的准确性和有效性。
在一些实施例中,告警中心会将标准化后的全量数据与各个工作负载对象的告警阈值进行对比。系统将逐个工作负载对象地比较相应的全量数据与其对应的告警阈值,如果全量数据超过或低于告警阈值,则说明该工作负载对象触发了告警,通过对比结果,可以确定全量数据中的目标告警数据,并将其提取出来。这样,告警中心可以根据预设的告警阈值自动检测并识别出全量数据中的异常情况,从而生成对应的告警信息。
综上,告警中心可以根据各个容器集群的工作负载对象生成告警规则配置界面,实现应用层面的调整,响应用户输入指令生成告警阈值,并将标准化后的全量数据与告警阈值进行对比,从而确定目标告警数据。这样可以基于目标告警数据在告警中心中生成对应的容器集群的告警信息,实现多渠道容器集群的监控要求。
需要说明的是,告警中心在录入监控的运行指标数据时,是针对部署(deployment)等工作负载对象的应用层面进行录入的,例如,可以从pod容器类型的中央处理器(Central Processing Unit,CPU)、内存(Memory,MEM)和Spring Boot中间件类型的线程数、堆内存等指标都可以一个应用层面进行监控可视化和告警规则配置。因此,在应用层面进行监控可视化和告警规则配置,可以更细粒度地监控和管理应用程序,包括容器级别的指标(如CPU、内存),以及中间件相关的指标(如线程数、堆内存)。这样可以更好地了解应用程序的运行状态和性能,并及时发现和处理可能的问题。
需要说明的是,告警中心将每个监控数据按照用户定制的监控项标准进行格式化和数据过滤,之后将数据与用户在数据库中定制的集群、应用、中间件等类型的告警阈值进行比对,命中则入库,入库后在产出最终需要发出的告警数据之前,会对每个告警进行收敛处理,例如,连续命中几次才触发告警发出,同时也会根据同一子系统下不同应用的同类别的监控告警项进行聚合,减少告警量,便于定位问题,也会识别告警对象是否在屏蔽列表中,若是则过滤该条告警。具体如下说明:
请参阅图5,在一些实施例中,步骤S105可以包括步骤S501至步骤S504:
步骤S501,持续将接收到的全量数据与告警阈值进行对比,根据多次对比结果确定目标告警数据的告警命中次数,根据告警命中次数与预设的触发阈值进行对比,得到告警触发结果;
步骤S502,获取各个目标告警数据的类别信息,根据各个类别信息确定各个目标告警数据之间是否为相同类别的类别对比结果;
步骤S503,获取预设的屏蔽列表,确定各个目标告警数据是否处于屏蔽列表中,得到屏蔽确定结果;
步骤S504,根据告警触发结果、类别对比结果和屏蔽确定结果中的至少一个,对每个目标告警数据进行收敛处理,基于收敛后的目标告警数据,在告警中心中生成对应的容器集群的告警信息。
在一些实施例中,告警中心会持续将接收到的全量数据与预设的告警阈值进行对比。通过多次对比,可以确定目标告警数据的告警命中次数,即目标告警数据超过或低于告警阈值的次数,这个告警命中次数反映了目标告警数据出现异常的频率和严重程度。
在一些实施例中,告警中心会获取各个目标告警数据的类别信息,类别信息可以描述目标告警数据所属的不同类别,例如性能问题、资源使用问题等。通过获取目标告警数据的类别信息,可以进一步分析和比较不同类别的告警数据之间的相关性。
在一些实施例中,告警中心会获取预设的屏蔽列表。屏蔽列表中包含了一些特定的告警数据,这些数据被认为是可以被忽略或暂时不需要处理的。通过获取预设的屏蔽列表,可以确定各个目标告警数据是否处于屏蔽列表中。
最后,告警中心会根据前面步骤获得的告警触发结果、类别对比结果和屏蔽确定结果中的至少一个,对每个目标告警数据进行收敛处理。收敛处理是指根据评估结果决定是否触发告警,以及是否需要进一步处理或通知相关人员。基于收敛后的目标告警数据,告警中心可以生成对应的容器集群的告警信息,用于向相关人员展示异常情况并采取相应的措施。
综上,本申请实施例得到告警信息的过程涉及对全量数据与告警阈值进行对比、获取目标告警数据的类别信息和屏蔽列表,并根据这些信息进行告警处理,最终生成容器集群的告警信息,这样可以帮助本申请实施例对异常情况进行准确的识别和通知,提高监控效率和故障响应能力。
请参阅图6,在一些实施例中,步骤S105还可以包括步骤S601至步骤S602:
步骤S601,若对比结果表征全量数据与告警阈值之间为第一大小关系,则基于目标告警数据,在告警中心中生成对应的容器集群的第一级别告警信息;
步骤S602,若对比结果表征全量数据与告警阈值之间为第二大小关系,则基于目标告警数据,在告警中心中生成对应的容器集群的第二级别告警信息;
其中,第一级别告警信息与第二级别告警信息表征的告警方式不同,第一级别告警信息小于第二级别告警信息的告警级别。
在一些实施例中,会对全量数据与告警阈值进行对比,判断两者之间的大小关系。如果对比结果表征全量数据与告警阈值之间为第一大小关系,例如全量数据稍微超过告警阈值,那么就会基于目标告警数据,在告警中心中生成对应的容器集群的第一级别告警信息。
在一些实施例中,同样会对全量数据与告警阈值进行对比,判断两者之间的大小关系。如果对比结果表征全量数据与告警阈值之间为第二大小关系,例如全量数据远超过告警阈值,那么就会基于目标告警数据,在告警中心中生成对应的容器集群的第二级别告警信息。
需要说明的是,第一级别告警信息与第二级别告警信息表征的告警方式不同。第一级别告警信息的告警级别较低,意味着该告警相对较轻微,而第二级别告警信息的告警级别较高,意味着该告警相对更为严重。因此,本申请实施例中得到告警信息的过程是通过对全量数据与告警阈值进行对比,判断全量数据是否超过或低于告警阈值,并基于此生成对应级别的告警信息,例如低等级采用邮件通知,高等级采用邮件加电话通知等。这样可以根据告警级别的不同,对容器集群的异常情况进行分类和处理,从而提高监控效率和故障响应能力。
进一步的,告警阈值可以包括第一阈值和第二阈值,第一阈值小于第二阈值,当全量数据大于第一阈值且小于第二阈值时,确定全量数据与告警阈值之间为第一大小关系,而若全量数据大于第二阈值,则确定全量数据与告警阈值之间为第二大小关系。
请参阅图7,在一些实施例中,步骤S601之后,还可以包括步骤S701至步骤S702:
步骤S701,从预设的自愈策略库中确定与目标告警数据相匹配的目标自愈策略;
步骤S702,向目标告警数据对应的容器集群发送目标自愈策略,以使容器集群根据目标自愈策略进行自愈处理。
在一些实施例中,可以通过预设的自愈策略库来确定与目标告警数据相匹配的目标自愈策略。自愈策略库中存储了一系列定义好的自愈策略,这些策略根据容器集群的特点和常见问题进行设计,旨在解决特定类型的故障或异常情况。根据目标告警数据的内容和属性,可以从自愈策略库中选择合适的自愈策略,以便对应地处理容器集群中出现的问题。
在一些实施例中,可以将选定的目标自愈策略发送到目标告警数据对应的容器集群。通过与目标容器集群建立通信连接,将目标自愈策略传递给容器集群,容器集群接收到自愈策略后,根据策略中定义的规则和指令,执行必要的操作来解决故障或异常情况,实现容器集群的自动修复、重启或其他需要的操作。这样就能够及时地对容器集群中的问题进行处理,恢复到正常的工作状态。
综上,自愈的过程是通过从预设的自愈策略库选择目标自愈策略,并将其发送到目标告警数据对应的容器集群,以实现容器集群的自动修复或重启等操作。通过自愈的过程,可以有效地提高容器集群的可靠性和稳定性,减少人工干预以及故障对业务的影响,从而提高整体系统的可用性和可靠性。
需要说明的是,本申请实施例中自愈的过程目前主要是针对一些cpu、内存、磁盘等监控项告警自愈操作。例如磁盘告警,自愈系统会实时去接收告警中心P1级别的告警数据,获取告警主机对象根据定义好的自愈套餐脚本通过云OSP平台接口下发到目标对象去进行自愈任务。
请参阅图8,示出了本申请实施例提供的完整告警过程的示意图。在这个实施例中示出了一个监控平台,含有告警中心,而该监控平台是运用vue、django、prometheusrule等技术栈实现的,通过在监控平台可以实现可视化的多PKS集群的告警规则快捷配置,该平台主要工作流程设计如下:
①通过在每个PKS集群(如PKS集群1、PKS集群2)中部署联邦Prometheus,对标准的k8s监控数据采集,或自定义开发的exporter脚本进行定时的数据采集,存储到本地单独联邦Prometheus时序数据库中,例如nas卷指标脚本采集exporter脚本和Kafka指标脚本采集exporter脚本,并获取对应的数据源;
②在主Prometheus中配置每个联邦Prometheus的数据接口(federate接口)进行数据拉取,并给每个数据源的监控数据打上PKS集群名label标签,便于区分不同的数据来源;
③在主Prometheus的告警配置中配置基础告警规则,比如获取所有告警阈值高于60%的告警数据;
④之后通过告警中心对主Prometheus的告警接口进行全量的数据获取,例如该接口为/api/v1/query?query=ALERTS;
⑤告警中心将每个告警按照用户定制的监控项标准进行格式化和数据过滤,例如应用监控项告警配置、中间件监控项告警配置和集群监控项告警配置,之后将每个告警的告警值与用户在数据库中定制的应用、中间件、集群等类型的告警阈值进行比对,命中则入库;
⑥入库后在产出最终需要发出的告警数据之前,会对每个告警进行收敛处理,连续命中几次才触发告警发出,同时也会根据同一子系统下不同应用的同类别的监控告警项进行聚合,减少告警量,便于定位问题,当然也会识别告警对象是否在屏蔽列表中,若是则过滤该条告警;
⑦告警中心将以每1分钟的频率进行告警信息输出,如若是第一级别(P1)的告警,则只会获取每条告警关联的联系人组邮件组,调用邮件接口发出;若是升级至第二级别(P2)级的告警,则会调用P2的邮件告警同时获取每条告警关联的联系人组电话号码,按顺序调用MVC电话网关接口拨出(若前一个联系人电话接通则中断下个电话拨出);
⑧如果P1级别的告警配置了自愈脚本,则会匹配对应的运维手册对应的处理方案和匹配UCMDB相关资源信息通过执行运维作业平台等工具进行自愈处理,若恢复成功则发出相应恢复通知邮件。
此外,上述告警中心还可以实现权限控制,实现登陆自动匹配、组织架构信息分配等角色权限相关的任务,做到可见即有权限,方便用户对分组应用的告警的配置和管理。
综上,通过图8中的流程,基于django+vue开发的多PKS集群监控告警中心具有以下有益效果:
通过本申请实施例,可将不同数据源输出的全量基础告警进行统一的采集清洗而后格式化成标准规范的告警数据,再根据应用层面从不同的监控维度统一配置告警规则,即实现了可扩展、多渠道的告警数据的便捷接入,也可高效灵活的配置告警规则的,无需单独切换各个监控平台;
通过本申请实施例,针对不同的监控指标对应作了解析说明,并提供大量的告警规则,可以形成告警模板,无特殊情况复制公共模板即可完成告警配置,同时也可支持同类应用的批量告警模板配置,大大减少了人工配置的工作量以及解决用户上手难度等问题;
另外本申请实施例也支持按应用维度可批量以及自定义的告警接收人分组统一接入,无需跨多平台多集群配置同份告警接收人分组,使整体的告警配置更灵活更高效。
请参阅图9,本申请实施例还提供一种云原生环境下的告警监控系统,可以实现上述云原生环境下的告警监控方法,云原生环境下的告警监控系统包括:
监控数据获取模块901,用于通过多个从监控组件分别获取所在的容器集群内的初始监控数据,其中,每个容器集群部署有至少一个从监控组件;
数据收集模块902,用于将各个从监控组件获取的初始监控数据,发送到与各个从监控组件通信连接的主监控组件中;
全量数据获取模块903,用于对主监控组件中的初始监控数据进行过滤,得到多个容器集群下的全量数据,并将全量数据发送到与主监控组件通信连接的告警中心中;
告警命中模块904,用于将告警中心的全量数据与预设的告警阈值进行对比,根据对比结果确定全量数据中的目标告警数据;
告警生成模块905,用于基于目标告警数据,在告警中心中生成对应的容器集群的告警信息。
在一些实施例中,云原生环境下的告警监控系统在执行上述云原生环境下的告警监控方法的过程中,通过在多个容器集群中分别部署从监控组件,可以获取各个容器集群内的初始监控数据,随后将各个从监控组件获取的初始监控数据,发送到与各个从监控组件通信连接的主监控组件中,从而实现了多渠道监控数据采集,接着在主监控组件内,可以对初始监控数据先进行基础过滤,得到的数据作为多个容器集群下的全量数据,并将全量数据发送到与主监控组件通信连接的告警中心中,使得告警中心可以监控多渠道容器集群的数据,从而提高了拓展性。而告警中心统一配置有告警规则,并部署有各个全量数据对应的告警阈值,因此可以将全量数据与预设的告警阈值进行对比,根据对比结果确定全量数据中的目标告警数据,因此即使面对多渠道来源的数据,也只需要在告警中心中统一配置告警规则,从而降低了监控的设计难度,提高了监控效率,最终基于目标告警数据,在告警中心中生成对应的容器集群的告警信息,使得告警中心可以满足多渠道容器集群的监控要求。
该云原生环境下的告警监控系统的具体实施方式与上述云原生环境下的告警监控方法的具体实施例基本相同,在此不再赘述。在满足本申请实施例要求的前提下,云原生环境下的告警监控系统还可以设置其他功能模块,以实现上述实施例中的云原生环境下的告警监控方法。
本申请实施例还提供了一种电子设备,电子设备包括存储器和处理器,存储器存储有计算机程序,处理器执行计算机程序时实现上述云原生环境下的告警监控方法。该电子设备可以为包括平板电脑、车载电脑等任意智能终端。
请参阅图10,图10示意了另一实施例的电子设备的硬件结构,电子设备包括:
处理器1001,可以采用通用的CPU(CentralProcessingUnit,中央处理器)、微处理器、应用专用集成电路(ApplicationSpecificIntegratedCircuit,ASIC)、或者一个或多个集成电路等方式实现,用于执行相关程序,以实现本申请实施例所提供的技术方案;
存储器1002,可以采用只读存储器(ReadOnlyMemory,ROM)、静态存储设备、动态存储设备或者随机存取存储器(RandomAccessMemory,RAM)等形式实现。存储器1002可以存储操作系统和其他应用程序,在通过软件或者固件来实现本说明书实施例所提供的技术方案时,相关的程序代码保存在存储器1002中,并由处理器1001来调用执行本申请实施例的云原生环境下的告警监控方法;
输入/输出接口1003,用于实现信息输入及输出;
通信接口1004,用于实现本设备与其他设备的通信交互,可以通过有线方式(例如USB、网线等)实现通信,也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信;
总线1005,在设备的各个组件(例如处理器1001、存储器1002、输入/输出接口1003和通信接口1004)之间传输信息;
其中处理器1001、存储器1002、输入/输出接口1003和通信接口1004通过总线1005实现彼此之间在设备内部的通信连接。
本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质存储有计算机程序,该计算机程序被处理器执行时实现上述云原生环境下的告警监控方法。
存储器作为一种非暂态计算机可读存储介质,可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外,存储器可以包括高速随机存取存储器,还可以包括非暂态存储器,例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中,存储器可选包括相对于处理器远程设置的存储器,这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
本申请实施例描述的实施例是为了更加清楚的说明本申请实施例的技术方案,并不构成对于本申请实施例提供的技术方案的限定,本领域技术人员可知,随着技术的演变和新应用场景的出现,本申请实施例提供的技术方案对于类似的技术问题,同样适用。
本领域技术人员可以理解的是,图中示出的技术方案并不构成对本申请实施例的限定,可以包括比图示更多或更少的步骤,或者组合某些步骤,或者不同的步骤。
以上所描述的装置实施例仅仅是示意性的,其中作为分离部件说明的单元可以是或者也可以不是物理上分开的,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
本领域普通技术人员可以理解,上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。
本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
应当理解,在本申请中,“至少一个(项)”是指一个或者多个,“多个”是指两个或两个以上。“和/或”,用于描述关联对象的关联关系,表示可以存在三种关系,例如,“A和/或B”可以表示:只存在A,只存在B以及同时存在A和B三种情况,其中A,B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达,是指这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b或c中的至少一项(个),可以表示:a,b,c,“a和b”,“a和c”,“b和c”,或“a和b和c”,其中a,b,c可以是单个,也可以是多个。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统和方法,可以通过其它的方式实现。例如,以上所描述的系统实施例仅仅是示意性的,例如,上述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
上述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括多指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例的方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(Read-Only Memory,简称ROM)、随机存取存储器(Random Access Memory,简称RAM)、磁碟或者光盘等各种可以存储程序的介质。
以上参照附图说明了本申请实施例的优选实施例,并非因此局限本申请实施例的权利范围。本领域技术人员不脱离本申请实施例的范围和实质内所作的任何修改、等同替换和改进,均应在本申请实施例的权利范围之内。

Claims (10)

1.一种云原生环境下的告警监控方法,其特征在于,所述方法包括:
通过多个从监控组件分别获取所在的容器集群内的初始监控数据,其中,每个所述容器集群部署有至少一个所述从监控组件;
将各个所述从监控组件获取的所述初始监控数据,发送到与各个所述从监控组件通信连接的主监控组件中;
对所述主监控组件中的所述初始监控数据进行过滤,得到多个所述容器集群下的全量数据,并将所述全量数据发送到与所述主监控组件通信连接的告警中心中;
将所述告警中心的所述全量数据与预设的告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据;
基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的告警信息。
2.根据权利要求1所述的云原生环境下的告警监控方法,其特征在于,所述对所述主监控组件中的所述初始监控数据进行过滤,得到多个所述容器集群下的全量数据,包括:
根据预设的基础告警规则,分别对所述主监控组件中不同所述容器集群的所述初始监控数据进行过滤,得到各个所述容器集群的过滤后监控数据;
在所述主监控组件中为接收各个所述初始监控数据生成所在的所述容器集群的集群标签,为各个所述过滤后监控数据附上对应的所述集群标签,得到各个带标监控数据;
将所有的所述带标监控数据,作为多个所述容器集群下的全量数据。
3.根据权利要求1所述的云原生环境下的告警监控方法,其特征在于,所述将所述告警中心的所述全量数据与预设的告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据,包括:
获取用户端的自定义输入数据,根据所述自定义输入数据生成监控项标准信息;
根据所述监控项标准信息对所述告警中心中的所述全量数据进行格式化和数据过滤处理,得到标准化后的所述全量数据;
将标准化后的所述全量数据与预设的告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据。
4.根据权利要求3所述的云原生环境下的告警监控方法,其特征在于,所述将标准化后的所述全量数据与预设的告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据,包括:
基于各个所述容器集群的工作负载对象,在所述告警中心显示对应的告警规则配置界面;
响应于所述告警规则配置界面上的输入指令,生成各个工作负载对象的运行指标数据,将各项所述指标数据作为告警阈值;
将标准化后的所述全量数据,分别与各个工作负载对象的所述告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据。
5.根据权利要求1所述的云原生环境下的告警监控方法,其特征在于,所述基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的告警信息,包括:
持续将接收到的所述全量数据与所述告警阈值进行对比,根据多次对比结果确定所述目标告警数据的告警命中次数,根据所述告警命中次数与预设的触发阈值进行对比,得到告警触发结果;
获取各个所述目标告警数据的类别信息,根据各个所述类别信息确定各个所述目标告警数据之间是否为相同类别的类别对比结果;
获取预设的屏蔽列表,确定各个所述目标告警数据是否处于所述屏蔽列表中,得到屏蔽确定结果;
根据所述告警触发结果、所述类别对比结果和所述屏蔽确定结果中的至少一个,对每个所述目标告警数据进行收敛处理,基于收敛后的所述目标告警数据,在所述告警中心中生成对应的所述容器集群的告警信息。
6.根据权利要求1所述的云原生环境下的告警监控方法,其特征在于,所述基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的告警信息,包括:
若所述对比结果表征所述全量数据与所述告警阈值之间为第一大小关系,则基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的第一级别告警信息;
若所述对比结果表征所述全量数据与所述告警阈值之间为第二大小关系,则基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的第二级别告警信息;
其中,所述第一级别告警信息与所述第二级别告警信息表征的告警方式不同,所述第一级别告警信息小于所述第二级别告警信息的告警级别。
7.根据权利要求6所述的云原生环境下的告警监控方法,其特征在于,所述在所述告警中心中生成对应的所述容器集群的第一级别告警信息之后,所述方法还包括:
从预设的自愈策略库中确定与所述目标告警数据相匹配的目标自愈策略;
向所述目标告警数据对应的所述容器集群发送所述目标自愈策略,以使所述容器集群根据所述目标自愈策略进行自愈处理。
8.一种云原生环境下的告警监控系统,其特征在于,所述系统包括:
监控数据获取模块,用于通过多个从监控组件分别获取所在的容器集群内的初始监控数据,其中,每个所述容器集群部署有至少一个所述从监控组件;
数据收集模块,用于将各个所述从监控组件获取的所述初始监控数据,发送到与各个所述从监控组件通信连接的主监控组件中;
全量数据获取模块,用于对所述主监控组件中的所述初始监控数据进行过滤,得到多个所述容器集群下的全量数据,并将所述全量数据发送到与所述主监控组件通信连接的告警中心中;
告警命中模块,用于将所述告警中心的所述全量数据与预设的告警阈值进行对比,根据对比结果确定所述全量数据中的目标告警数据;
告警生成模块,用于基于所述目标告警数据,在所述告警中心中生成对应的所述容器集群的告警信息。
9.一种电子设备,其特征在于,所述电子设备包括存储器和处理器,所述存储器存储有计算机程序,所述处理器执行所述计算机程序时实现权利要求1至7任一项所述的云原生环境下的告警监控方法。
10.一种计算机可读存储介质,所述存储介质存储有计算机程序,其特征在于,所述计算机程序被处理器执行时实现权利要求1至7任一项所述的云原生环境下的告警监控方法。
CN202311581697.1A 2023-11-23 2023-11-23 云原生环境下的告警监控方法、系统、设备及介质 Pending CN117614853A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202311581697.1A CN117614853A (zh) 2023-11-23 2023-11-23 云原生环境下的告警监控方法、系统、设备及介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202311581697.1A CN117614853A (zh) 2023-11-23 2023-11-23 云原生环境下的告警监控方法、系统、设备及介质

Publications (1)

Publication Number Publication Date
CN117614853A true CN117614853A (zh) 2024-02-27

Family

ID=89947523

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202311581697.1A Pending CN117614853A (zh) 2023-11-23 2023-11-23 云原生环境下的告警监控方法、系统、设备及介质

Country Status (1)

Country Link
CN (1) CN117614853A (zh)

Similar Documents

Publication Publication Date Title
CN104407964B (zh) 一种基于数据中心的集中监控系统及方法
CN105159964B (zh) 一种日志监控方法及系统
CN108092836A (zh) 一种服务器的监控方法及装置
WO2019223062A1 (zh) 系统异常的处理方法和系统
CN110232006B (zh) 设备告警方法及相关装置
CN107995049A (zh) 电力安全区跨区同步故障监测方法、装置和系统
CN112311617A (zh) 一种配置化数据监控告警方法及系统
CN103401698A (zh) 用于服务器集群运算中对服务器状况报警的监控系统
CN111078455A (zh) 基于时间轴的异常行为序列关联处理方法以及装置、设备、存储介质
CN111046011A (zh) 日志收集方法、系统、节点、电子设备及可读存储介质
CN107544832A (zh) 一种虚拟机进程的监控方法、装置和系统
CN112306802A (zh) 系统的数据获取方法、装置、介质和电子设备
US10331484B2 (en) Distributed data platform resource allocator
CN114356499A (zh) Kubernetes集群告警根因分析方法及装置
US10990090B2 (en) Apparatus and method for automatic detection and classification of industrial alarms
US8554908B2 (en) Device, method, and storage medium for detecting multiplexed relation of applications
CN105825641A (zh) 一种业务报警方法和装置
CN115766768B (zh) 一种算力网络操作系统中感知中枢设计方法及装置
CN102986151A (zh) 监视系统及数据传输装置和方法
CN202009391U (zh) 一种对信息系统运行情况进行实时监控与预警的装置
CN115102838B (zh) 服务器宕机风险的应急处理方法和装置、电子设备
KR101973728B1 (ko) 통합 보안 이상징후 모니터링 시스템
CN117614853A (zh) 云原生环境下的告警监控方法、系统、设备及介质
CN101673472A (zh) 监控运营系统的方法、装置及系统
CN114756301A (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