CN116010212A - 一种监控报警管理系统、方法、计算机设备及存储介质 - Google Patents
一种监控报警管理系统、方法、计算机设备及存储介质 Download PDFInfo
- Publication number
- CN116010212A CN116010212A CN202310083720.8A CN202310083720A CN116010212A CN 116010212 A CN116010212 A CN 116010212A CN 202310083720 A CN202310083720 A CN 202310083720A CN 116010212 A CN116010212 A CN 116010212A
- Authority
- CN
- China
- Prior art keywords
- alarm
- fault
- module
- faults
- server
- 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
Landscapes
- Debugging And Monitoring (AREA)
Abstract
本申请公开了一种监控报警管理系统、方法、计算机设备及存储介质,所述系统包括:预测故障模块,用于通过分析历史运维日志,对未来一段时间可能发生的故障进行预测;故障告警及自动故障愈合模块,用于对故障进行报警;根据预测故障模块的预测结果,利用预置的策略对预测的故障进行预处理,根据处理结果再进行报警或发送处理结果操作;动态抑制报警模块,用于通过历史运维日志的分析,为服务器网络性能指标计算合适的报警阈值,防止误报。本申请的优势在于:报警接收配置灵活,减少了配置工作量;减少了服务器上下线的运维人员工作;通过自动化方式完成一定工作使得人工无需介入故障修复,减少人工维护工作量;根据业务情况灵活报警,减少误报。
Description
技术领域
本申请涉及运维服务领域,更具体地说,涉及一种监控报警管理系统、方法、计算机设备及存储介质。
背景技术
大型公司的信息化平台涉及的项目多,使用的服务器数量也多。业务量大时,每次新项目上线的服务器及下线的旧服务器会到达几十台甚至更多,运维人员需要手动注册新服务器,注销旧服务器,工作量繁重。
由于应用众多,运维人员及研发人员每天都会收到海量的报警,使得相关人员很难从众多报警中真正定位有价值的报警信息。不同的应用有不同的场景造成不同时间段报警阈值均会不同,但传统的监控报警系统无法按时间段匹配应用特点报警,同时复杂的配置文件及报警规则不方便维护人员的配置。
如图1所示,现有监控报警管理系统的架构往往采用prometheus+consul+alertmanager的结构。prometheus通过拉取方式从每台服务器收集数据存入时序数据库,对历史数据做聚合处理节省存储空间,降低查询延迟,提高查询并发。因此对于海量的监控数据其性能高于关系型数据库。配合consul的自动发现方案可解放维护监控人员不必频繁操作系统,添加要监控的服务信息。Alertmanager组件为prometheus的报警组件,通过该组件的标签匹配可将要告警的信息通过email或企业微信等方式告警出去,另外prometheus支持一段时间内同等报警标题的邮件组合发送,降低报警邮件的数量。因此该套系统可满足大部分中小企业对于监控报警的需求。但是对于业务量巨大,报警接收人员经常变更,服务器不同时间段报警阈值不同,故障处理时间长但处理期间仍旧报警,配置规则复杂学习成本高,上线服务器还需人工注册服务器到系统等场景的公司,此套系统便就无法提供支持。
现有技术的缺陷有:
1、大型企业服务器众多,服务结构复杂。除运维人员外,业务或研发人员也要接收报警。此时传统的prometheus或zabbix等监控报警工具如果按IP维度添加报警接受人员则会带来大量的工作并且容易出错;
2、因企业服务的复杂性经常会导致服务器上线或下线,传统的监控报警系统无法自动感知服务器的上线或下线动作,需要人为介入;
3、对于传统的监控报警系统虽然能对有故障的服务或系统进行报警但却无法对有故障的服务进行自动的治愈,每次需要人为介入处理;
4、现有的监控报警系统都是服务发生故障时进行报警,却无法根据以往的历史数据进行预警,无法将故障处理在萌芽之中;
5、prometheus的报警规则或服务收集等配置均需要通过配置文件进行配置,并要配合prometheus的语法,这无形中增加了运维的学习成本,不够便捷及人性化;
6、某些特殊的服务器在不同时间段的同一个指标会有反差巨大的报警值,例如:数据库服务器主从同步时间白天为1000s内,但晚上因业务会超过1000s也算正常。但因阈值设置为超过1000s电话报警。则夜间会对运维人员造成困扰。
因此,如何减少运维人员对服务器上下线的操作、对报警日志的处理工作成为本领域需要解决的技术问题。
发明内容
有鉴于此,本申请提出了一种监控报警管理系统、方法、计算机设备及存储介质,以实现服务器网络性能的监控并提高生产效率。
根据本申请,提出了一种监控报警管理系统,所述系统包括:
预测故障模块,用于通过分析历史运维日志,对未来一段时间可能发生的故障进行预测;
故障告警及自动故障愈合模块,用于对故障进行报警;还用于根据预测故障模块的预测结果,利用预置的策略对预测的故障进行预处理,根据处理结果再进行报警或发送处理结果操作;和
动态抑制报警模块,用于通过历史运维日志的分析,为服务器网络性能指标计算合适的报警阈值,防止误报。
基于上述系统的一种改进,所述预测故障模块功能具体包括:采用线性回归方法分析历史运维日志,建立服务器网络性能指标的预测模型,对未来一段时间的故障进行预测。
基于上述系统的一种改进,所述故障告警及自动故障愈合模块功能具体包括:
通过包含运维人员信息的办公软件与监控报警管理系统对接,按不同维度设置不同的接收组,将报警信息推送到对应的接收组;
当预测故障模块预测出故障后,首先抑制报警,根据报警分类执行预设的恢复脚本,等待设定时间后再探测故障节点,若尚未恢复则发出报警,若已经恢复则只发送处理结果邮件。
基于上述系统的一种改进,所述动态抑制报警模块功能具体包括:
采用线性回归方法分析历史运维日志,计算服务器网络性能指标不同时段的合理报警阈值,防止误报;
当发生网络故障并报警后,在设定时间间隔内抑制后续报警,设定时间间隔过后,若问题还未解决,则继续报警并重新开始设定时间间隔的计时。
基于上述系统的一种改进,所述系统还包括:
收集历史数据模块,用于收集历史运维日志。
基于上述系统的一种改进,所述系统还包括:
服务器注册模块,用于新上线的服务器进行自动注册。
基于上述系统的一种改进,所述服务器注册模块功能具体包括:
上线的服务器在初始化脚本里增加注册脚本,启动时注册脚本初始化系统所需环境,向监控报警管理系统注册本身IP和应用信息,完成自动注册。
本申请还提供一种监控报警管理方法,基于上述任一监控报警管理系统实现,所述方法包括:
预测故障:通过分析历史数据,对未来一段时间可能发生的故障利用回归算法进行故障预判;
故障告警及自动故障愈合:对故障进行报警;根据故障的预测结果,利用预置的策略对预测的故障进行预处理,根据处理结果再进行报警或发送处理结果操作;
动态抑制报警:对于经常报警的服务器网络性能指标通过历史数据的回归分析,计算合适的报警阈值,防止误报。
基于上述方法的一种改进,所述方法还包括:
收集历史数据:收集历史运维日志;
服务器注册:新上线的服务器进行自动注册。
本申请还提供一种计算机设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如上述任一项所述的方法。
本申请还提供一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序当被处理器执行时使所述处理器执行如上述任一项所述的方法。
根据本申请的技术方案,本申请的优势在于:
1、通过企业微信或飞书等办公软件接口获取公司员工信息后,可方便灵活的为企业员工添加报警接收组。同时按项目或应用维度为不同的接收组挂载应用或项目标签。所有服务器上线会自动录入consul自动发现统一存储中并配以相应项目或应用标签,当有服务器报警后,对应的服务器的标签与组标签匹配后,便会报警给相应的组内成员(邮件、企业微信、电话、短信等多种方式)。报警接收配置灵活,减少了配置工作量。
2、每天上线的物理机或虚拟机全部在初始化脚本里面增加创建自研的golang开发的agent,每台机器通过联动cmdb(资源管理系统)动态获取将上线的服务器所在应用或项目后,动态内存中加载应用或项目名称并落地磁盘保存。然后agent自动初始化系统所需环境,加载prometheus所需nodeexporter后,调用consul自动注册本身IP,应用等信息,并通过prometheus以拉取方式从consul接口获取信息存储本地时序数据库,完成自动注册及自动发现步骤。减少了服务器上下线的运维人员工作。
3、通过将prometheus生成的存储数据进行抽样采集后通过人工智能线性回归算法对所有服务器的各项指标(CPU、内存、磁盘空间、io)进行归类,并收入一定因子(因活动服务流量增加,夜间跑批等操作),通过预测算法预判即将发生的故障,例如磁盘的增长速度过快是否导致磁盘将满,因活动导致服务流量增加是否影响机器负载等。通过以上预判可调用录入的脚本插件或接口进行相应的操作恢复服务。例如按时间清除磁盘日志,对服务限流保障服务的可用性等。通过自动化方式完成一定工作使得人工无需介入故障修复,减少人工维护工作量。
4、通过对prometheus所有收入监控指标的分类归纳,利用正则表达式对常用的监控指标进行简化拼写,例如对node_disk_write_time_seconds_total磁盘每秒写入简化后为disk_write.并对prometheus报警规则进行改进,通过UI的方式配置报警规则,简化了报警规则的配置。
5、通过回归测试智能算法对不同时间段报警值反差巨大的报警进行判断,对于正常时间段的超过阈值的报警进行抑制,并根据历史数据分析后自动修改数据库中预存的指标报警阈值,使得系统可以根据业务情况灵活报警,减少误报。
本申请的其它特征和优点将在随后的具体实施方式部分予以详细说明。
附图说明
构成本申请的一部分的附图用来提供对本申请的进一步理解,本申请的示意性实施方式及其说明用于解释本申请。在附图中:
图1为现有监控报警管理系统架构图;
图2为本申请监控报警管理系统架构图;
图3为预测故障模块线性回归分析结果示意图;
图4为故障告警及自动故障愈合模块结构示意图;
图5为动态抑制报警模块线性回归分析结果示意图。
具体实施方式
下面将参考附图并结合实施方式来详细说明本申请的技术方案。
本申请一种监控报警管理系统,支持服务器上下线的自动注册和注销;对历史运维日志进行智能分析,可以预测事故,并调用预制的测量进行预防性处理;可以根据历史业务情况,智能设置报警阈值,减少误报。
如图2所示,监控报警管理系统包括收集历史数据模块、预测故障模块、故障告警即自动故障愈合模块、动态抑制报警模块和服务器注册模块。
1、收集历史数据模块,用于收集历史运维日志。
本系统利用prometheus以拉取形式向各个部署在服务器的导出器拉取信息后存储在本地tsdb时序数据库中14日。超过14日的数据存储在分布式文件系统ceph中作为永久保存数据使用。
2、预测故障模块,通过分析历史数据,对未来一段时间可能发生的故障进行预测。
本系统对tsdb数据库历史数据采样后,通过回归算法进行故障预判。回归分析中,只包括一个自变量和一个因变量,且二者的关系可用一条直线近似表示,这种回归分析称为一元线性回归分析。如果回归分析中包括两个或两个以上的自变量,且因变量和自变量之间是线性关系,则称为多元线性回归分析。
如图3所示,有n组数据,自变量(特征值)x(x1,x2,...xn)与因变量(目标值)y(y1,y2,...yn)之间线性相关,假设他们之间关系为:y=ax+b,这个就是构建的一元线性方程。如图3所示,y是试图预测的因变量,x是用来进行预测的自变量,a是回归线的斜率,b是一个常数,称为截距。将算法应用于监控报警系统的故障预判中。例如:网络出口流量是否过高的判断为:
f(x)=W0+W1日常流量+W2历史突高流量+W3应用历史活动
由上式得出的值来判断一个网络流量是否将会超过阈值。线性模型中的向量W值,客观的表达了各属性在预测中的重要性,因此线性模型有很好的解释性。对于多特征预测即多元线性回归算法,就是寻找合适的W值,然后以这些值来建立模型,预测测试数据。简单的来说就是学习得一个线性模型以尽可能准确的预测实值输出标记。
利用线性预测算法提前预判即将报警的故障,并通过自动化监控报警系统对于预判出的故障根据重要程度进行干预,例如当预判2小时候出口流量过高将会占用网络带宽时,可调用统一运维平台脚本wondershaper-aeth0-u10240-d10240限制网卡流量。
3、故障告警及自动故障愈合模块,用于对故障进行报警,根据预测故障模块的预测结果,利用预置的策略对预测的故障进行预处理。
通过企业微信或飞书等办公软件接口获取公司员工信息后,可方便灵活的为企业员工添加报警接收组。同时按项目或应用维度为不同的接收组挂载应用或项目标签。所有服务器上线会自动录入consul自动发现统一存储中并配以相应项目或应用标签,当有服务器报警后,对应的服务器的标签与组标签匹配后,便会报警给相应的组内成员(邮件、企业微信、电话、短信等多种方式)。
如图4所示,当本系统预判断出故障后首先借助webhook抑制报警,并根据报警分类触发自动恢复报警的脚本,并等待n秒后(此处系统可配置)再探测故障节点,若尚未恢复则触发webhook按warning,error,disaster等级别选择不同媒介报警。但若此处探测故障节点已经恢复,则只触发恢复邮件告知完成。
本系统定时循环检测prometheus中时序数据库存储的数据。例如检测得出A服务器CPUload>2且同比10分钟前增长了1,系统采集到样本后通过回归测试算法进行计算判断,CPU负载x与磁盘ioy之间的关系。一般来说磁盘io越频繁,CPU负载会越高,加上一些其他因素,例如跑一些脚本等。于是可以利用y=ax+b这个评估模型来判断CPU一段时间的负载增长是否正常。假设历史数据中4天内CPU负载与在当前同一时间段的数据样本集为:
Loadx为1时,磁盘ioy为45;
Loadx为2时,磁盘ioy为85;
Loadx为3时,磁盘ioy为100;
Loadx为4时,磁盘ioy为120。
假设y与x是线性关系:
y=ax+b
假设a的范围为[-2,2],a的梯度为1;
假设b的范围为[80,120],b的梯度为10;
经过计算得出受磁盘io升高影响CPU负载升高,因此可触发脚本查询io异常进程,并用命令将服务器从前端负载摘除后(此处为不影响服务,先将服务器摘除)重启进程。若重启进程后问题依旧,系统在n秒后将触发error报警通过企业微信或邮件由人工介入处理。
4、动态抑制报警模块,对于经常报警的服务器的某些指标通过历史数据的回归分析,计算合适的报警阈值,防止误报。
例如,大数据相关应用夜间经常会运行批量脚本,会造成服务器负载远远高于白天。若此时还按照传统监控报警设置负载报警阈值将会对报警接收人员造成袭扰,若指标值超过电话报警阈值还会进行电话播报,对于每天接收大量报警的人员造成影响。若提高CPU负载的监控阈值,虽然晚上运行批量脚本不会再受影响,但是白天有可能一些非正常操作导致CPU负载过高,超过往日阈值,但是此时因为调高报警阈值造成故障发生却未能及时发现。
因此通过对某服务的历史数据的分析按报警时间段及时间段内报警平均阈值统计出一个以时间段为x轴,报警时的值为纵轴的函数。
如图5所示,通过参数w1和回归方程f(x)=w1*x+w0预测当前值是否需要报警。并根据历史数据自动录入合适的阈值进入数据库,调整报警,降低报警频率。
另外对于已经报警,例如进程因oom导致销毁的故障,此刻可能已经电话通知相应运维处理,但因该故障可能会修复很长时间,因此若在修复期间故障尚未恢复之时一直电话报警,会对运维人员造成困扰。因此可按报警级别程度对当天频繁报警的指标进行暂时关闭。
报警级别可分为warning、error、disaster等级别。对于error级别的指标例如Free_memory<1G,当前内存不足1G触发报警。按规则error级别除发邮件与企业微信报警外并不拨打报警电话。因此当error级别触发后,运维人员可能已经在进行干预。但因为时间问题,5分钟后再次触发报警,此刻系统可根据自定义规则,按error级别将当日报警的统一的ip的指标进行抑制2小时处理,若2小时候还未解决可再次报警,并再次进行规则触发将当日该服务器的内存指标报警抑制。
5、服务器注册模块,用于新上线的服务器进行自动注册。
每天上线的物理机或虚拟机全部在初始化脚本里面增加创建自研的golang开发的agent,每台机器通过联动cmdb(资源管理系统)动态获取将上线的服务器所在应用或项目后,动态内存中加载应用或项目名称并落地磁盘保存。然后agent自动初始化系统所需环境,加载prometheus所需nodeexporter后,调用consul自动注册本身IP,应用等信息,并通过prometheus以拉取方式从consul接口获取信息存储本地时序数据库,完成自动注册及自动发现步骤。
本申请还提供一种监控报警管理方法,该方法包括:
收集历史数据:收集历史运维日志。
预测故障:通过分析历史数据,对未来一段时间可能发生的故障利用回归算法进行故障预判。
故障告警及自动故障愈合:对故障进行报警,根据故障的预测结果,利用预置的策略对预测的故障进行预处理。
动态抑制报警:对于经常报警的服务器的某些指标通过历史数据的回归分析,计算合适的报警阈值,防止误报。
服务器注册:新上线的服务器进行自动注册。
本申请还可提供一种计算机设备,包括:至少一个处理器、存储器、至少一个网络接口和用户接口。该设备中的各个组件通过总线系统耦合在一起。可理解,总线系统用于实现这些组件之间的连接通信。总线系统除包括数据总线之外,还包括电源总线、控制总线和状态信号总线。
其中,用户接口可以包括显示器、键盘或者点击设备。例如,鼠标,轨迹球(trackball)、触感板或者触摸屏等。
可以理解,本申请公开实施例中的存储器可以是易失性存储器或非易失性存储器,或可包括易失性和非易失性存储器两者。其中,非易失性存储器可以是只读存储器(Read-OnlyMemory,ROM)、可编程只读存储器(ProgrammableROM,PROM)、可擦除可编程只读存储器(ErasablePROM,EPROM)、电可擦除可编程只读存储器(ElectricallyEPROM,EEPROM)或闪存。易失性存储器可以是随机存取存储器(RandomAccessMemory,RAM),其用作外部高速缓存。通过示例性但不是限制性说明,许多形式的RAM可用,例如静态随机存取存储器(StaticRAM,SRAM)、动态随机存取存储器(DynamicRAM,DRAM)、同步动态随机存取存储器(SynchronousDRAM,SDRAM)、双倍数据速率同步动态随机存取存储器(DoubleDataRateSDRAM,DDRSDRAM)、增强型同步动态随机存取存储器(EnhancedSDRAM,ESDRAM)、同步连接动态随机存取存储器(SynchlinkDRAM,SLDRAM)和直接内存总线随机存取存储器(Direct RambusRAM,DRRAM)。本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。
在一些实施方式中,存储器存储了如下的元素,可执行模块或者数据结构,或者他们的子集,或者他们的扩展集:操作系统和应用程序。
其中,操作系统,包含各种系统程序,例如框架层、核心库层、驱动层等,用于实现各种基础业务以及处理基于硬件的任务。应用程序,包含各种应用程序,例如媒体播放器(MediaPlayer)、浏览器(Browser)等,用于实现各种应用业务。实现本公开实施例方法的程序可以包含在应用程序中。
在本上述的实施例中,还可通过调用存储器存储的程序或指令,具体的,可以是应用程序中存储的程序或指令,处理器用于:
执行上述方法的步骤。
上述方法可以应用于处理器中,或者由处理器实现。处理器可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器、数字信号处理器(DigitalSignalProcessor,DSP)、专用集成电路(ApplicationSpecificIntegratedCircuit,ASIC)、现场可编程门阵列(FieldProgrammableGateArray,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行上述公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合上述公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器读取存储器中的信息,结合其硬件完成上述方法的步骤。
可以理解的是,本申请描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现,处理单元可以实现在一个或多个专用集成电路(ApplicationSpecificIntegratedCircuits,ASIC)、数字信号处理器(DigitalSignalProcessing,DSP)、数字信号处理设备(DSPDevice,DSPD)、可编程逻辑设备(ProgrammableLogicDevice,PLD)、现场可编程门阵列(Field-ProgrammableGateArray,FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。
对于软件实现,可通过执行本申请的功能模块(例如过程、函数等)来实现本申请技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。
本申请还可提供一种非易失性存储介质,用于存储计算机程序。当该计算机程序被处理器执行时可以实现上述方法实施例中的各个步骤。
迄今为止对于监控报警系统二次开发或自研开发报警监控系统的企业或团队不胜枚举。但所有报警监控系统能做到的只有合并相同种类的报警,或多报警的途径及种类繁多的报警规则项目,所有系统对于报警后的操作均需要人工参与。对于一些执行清理脚本,调用接口限流,重启进程,或调用其他系统接口的并不繁琐的操作完全可由系统判断后通过调用脚本处理。本申请可以预判故障提前执行操作脚本,通过该技术可完全将清理磁盘,限流或提前重启服务等操作提前进行,将15%的故障提前处理,节约人工成本。
以上详细描述了本申请的优选实施方式,但是,本申请并不限于上述实施方式中的具体细节,在本申请的技术构思范围内,可以对本申请的技术方案进行多种简单变型,这些简单变型均属于本申请的保护范围。
另外需要说明的是,在上述具体实施方式中所描述的各个具体技术特征,在不矛盾的情况下,可以通过任何合适的方式进行组合,为了避免不必要的重复,本申请对各种可能的组合方式不再另行说明。
此外,本申请的各种不同的实施方式之间也可以进行任意组合,只要其不违背本申请的思想,其同样应当视为本申请所公开的内容。
Claims (11)
1.一种监控报警管理系统,其特征在于,所述系统包括:
预测故障模块,用于通过分析历史运维日志,对未来一段时间可能发生的故障进行预测;
故障告警及自动故障愈合模块,用于对故障进行报警;还用于根据预测故障模块的预测结果,利用预置的策略对预测的故障进行预处理,根据处理结果再进行报警或发送处理结果操作;和
动态抑制报警模块,用于通过历史运维日志的分析,为服务器网络性能指标计算合适的报警阈值,防止误报。
2.根据权利要求1所述的监控报警管理系统,其特征在于,所述预测故障模块功能具体包括:采用线性回归方法分析历史运维日志,建立服务器网络性能指标的预测模型,对未来一段时间的故障进行预测。
3.根据权利要求1所述的监控报警管理系统,其特征在于,所述故障告警及自动故障愈合模块功能具体包括:
通过包含运维人员信息的办公软件与监控报警管理系统对接,按不同维度设置不同的接收组,将报警信息推送到对应的接收组;
当预测故障模块预测出故障后,首先抑制报警,根据报警分类执行预设的恢复脚本,等待设定时间后再探测故障节点,若尚未恢复则发出报警,若已经恢复则只发送处理结果邮件。
4.根据权利要求1所述的监控报警管理系统,其特征在于,所述动态抑制报警模块功能具体包括:
采用线性回归方法分析历史运维日志,计算服务器网络性能指标不同时段的合理报警阈值,防止误报;
当发生网络故障并报警后,在设定时间间隔内抑制后续报警,设定时间间隔过后,若问题还未解决,则继续报警并重新开始设定时间间隔的计时。
5.根据权利要求1所述的监控报警管理系统,其特征在于,所述系统还包括:
收集历史数据模块,用于收集历史运维日志。
6.根据权利要求1所述的监控报警管理系统,其特征在于,所述系统还包括:
服务器注册模块,用于新上线的服务器进行自动注册。
7.根据权利要求6所述的监控报警管理系统,其特征在于,所述服务器注册模块功能具体包括:
上线的服务器在初始化脚本里增加注册脚本,启动时注册脚本初始化系统所需环境,向监控报警管理系统注册本身IP和应用信息,完成自动注册。
8.一种监控报警管理方法,基于权利要求1-8任一所述监控报警管理系统实现,所述方法包括:
预测故障:通过分析历史数据,对未来一段时间可能发生的故障利用回归算法进行故障预判;
故障告警及自动故障愈合:对故障进行报警;根据故障的预测结果,利用预置的策略对预测的故障进行预处理,根据处理结果再进行报警或发送处理结果操作;
动态抑制报警:对于经常报警的服务器网络性能指标通过历史数据的回归分析,计算合适的报警阈值,防止误报。
9.根据权利要求8所述的监控报警管理方法,其特征在于,所述方法还包括:
收集历史数据:收集历史运维日志;
服务器注册:新上线的服务器进行自动注册。
10.一种计算机设备,包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如权利要求8或9任一项所述的方法。
11.一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序当被处理器执行时使所述处理器执行如权利要求8或9任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310083720.8A CN116010212A (zh) | 2023-02-08 | 2023-02-08 | 一种监控报警管理系统、方法、计算机设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310083720.8A CN116010212A (zh) | 2023-02-08 | 2023-02-08 | 一种监控报警管理系统、方法、计算机设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN116010212A true CN116010212A (zh) | 2023-04-25 |
Family
ID=86030270
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310083720.8A Pending CN116010212A (zh) | 2023-02-08 | 2023-02-08 | 一种监控报警管理系统、方法、计算机设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116010212A (zh) |
-
2023
- 2023-02-08 CN CN202310083720.8A patent/CN116010212A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9652316B2 (en) | Preventing and servicing system errors with event pattern correlation | |
US11269718B1 (en) | Root cause detection and corrective action diagnosis system | |
US10152364B2 (en) | Predicting, diagnosing, and recovering from application failures based on resource access patterns | |
US7254750B1 (en) | Health trend analysis method on utilization of network resources | |
Garraghan et al. | An empirical failure-analysis of a large-scale cloud computing environment | |
US8082471B2 (en) | Self healing software | |
US10489232B1 (en) | Data center diagnostic information | |
US20080195369A1 (en) | Diagnostic system and method | |
CN115809183A (zh) | 基于知识图谱的信创终端故障发现及处置的方法 | |
US20200341868A1 (en) | System and Method for Reactive Log Spooling | |
CN112631887A (zh) | 异常检测方法、装置、电子设备和计算机可读存储介质 | |
Li et al. | Fighting the fog of war: Automated incident detection for cloud systems | |
CN116089231B (zh) | 一种故障告警方法、装置、电子设备及存储介质 | |
CN117313012A (zh) | 服务编排系统的故障管理方法、装置、设备及存储介质 | |
CN116260703A (zh) | 分布式消息服务节点cpu性能故障自恢复方法及装置 | |
CN116010212A (zh) | 一种监控报警管理系统、方法、计算机设备及存储介质 | |
CN113094243B (zh) | 节点性能检测方法和装置 | |
CN112131090B (zh) | 业务系统性能监控方法及装置、设备及介质 | |
CN113342596A (zh) | 一种设备指标的分布式监控方法、系统及装置 | |
CN113626288A (zh) | 故障处理方法、系统、装置、存储介质和电子设备 | |
CN111143154A (zh) | 码头操作系统运行监控方法、装置、服务器及存储介质 | |
CN111767187B (zh) | 监控jdbc连接池状态的方法及相关设备 | |
CN101807167B (zh) | 一种实现软件抗衰的方法及系统 | |
US12047223B2 (en) | Monitoring service health statuses to raise alerts | |
JP2003345629A (ja) | システム監視装置及びそれに用いるシステム監視方法並びにそのプログラム |
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 |