CN109992471A - 一种内存监控的方法及装置 - Google Patents

一种内存监控的方法及装置 Download PDF

Info

Publication number
CN109992471A
CN109992471A CN201810002480.3A CN201810002480A CN109992471A CN 109992471 A CN109992471 A CN 109992471A CN 201810002480 A CN201810002480 A CN 201810002480A CN 109992471 A CN109992471 A CN 109992471A
Authority
CN
China
Prior art keywords
service
memory
ems
agent apparatus
ems memory
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
CN201810002480.3A
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.)
China Mobile Communications Group Co Ltd
China Mobile Communications Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Communications Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd, China Mobile Communications Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN201810002480.3A priority Critical patent/CN109992471A/zh
Publication of CN109992471A publication Critical patent/CN109992471A/zh
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3034Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a storage system, e.g. DASD based or network based
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3051Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明涉及计算机技术,公开了一种内存监控的方法及装置,用以在zabbix框架下,在降低sever的运行负荷的前提下,保证多个关键性服务的正常工作。该方法为:将多个关键性服务的内存使用情况的分析及告警下沉至agent侧完成,agent会将系统中的各个服务进行分类,agent主要针对各个第一类服务在一段时间内积累的内存使用情况进行监控,一旦确定第一类服务的内存使用情况符合预警条件,便会进行告警。这样,agent优先监测了内存高敏感度的第一类服务的内存使用情况,既可以及时发现内存使用情况出现异常,保证第一类服务的正常工作,又没有影响内存低敏感度的第二类服务的正常工作,既保证了系统的服务质量,又没有增加实现复杂度。

Description

一种内存监控的方法及装置
技术领域
本发明涉及计算机技术,尤其涉及一种内存监控的方法及装置。
背景技术
zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参数,保证服务器系统的安全运营;并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。
zabbix由2部分构成,zabbix服务器(server)与可选组件zabbix代理(agent)。agent负责将监控项的相关指标值定时上报,server负责收集各个agent上报的信息,并判断是否超出预设告警条件(阈值),如若超出,就报警。
若是基于zabbix的基本工作原理来监控系统和关键任务,只需要将监控项配置到zabbix框架中,zabbix就会定时拉取数据,并依据预设报警的判断条件决定是否发出警告。这种做法虽然简单清晰,易于操作。但是存在两个缺点:
1)agent只负责定时上报数据,所有的告警判断都由server完成,当被监控项非常多时,server的性能一定是大大折扣的,server会变成瓶颈。
2)虽然agent所在机器可能部署了多个关键性服务,但各个服务的监控项都是按照相同策略分别上报各自的监控指标,没有考虑服务本身的内存使用情况的特殊性。
已有方案中给出的解决办法是根据系统的负荷,动态调整监控信息的上报频次和上报方式,这在一定程度上解决了server某些情况下负荷过重的问题。但此解决方法单纯从机器的内存、CPU等指标入手调整监控方式,完全没有考虑由于服务本身的特点而造成的内存使用情况的特殊性,因此可能会造成部分关键性服务由于内存需求得不到满足而退出,从而影响系统服务质量。
有鉴于此,需要设计一种新的在zabbix框架下的内存监控方法,以克服上述缺陷。
发明内容
本发明的目的是提供一种内存监控的方法及装置,用以在zabbix框架下,在降低sever的运行负荷的前提下,保证关键性服务的正常工作。
本发明的目的是通过以下技术方案实现的:
第一方面,提供一种内存监控的方法,应用于zabbix系统,包括:
代理装置基于预设的服务分类,确定具有内存高敏感度的第一类服务,其中,具有内存高敏感度的服务,为在内存不能满足需求时直接退出的服务;
所述代理装置监测所述第一类服务的内存使用情况,获得监测结果;
所述代理装置基于所述监测结果,确定所述第一类服务的内存使用情况满足预设的告警条件时,触发告警。
可选的,预设所述服务分类,包括:
所述代理装置将在内存不能满足需求时直接退出的服务,划分为第一类服务,
以及所述代理装置将在内存不能满足需求时不直接退出的服务,划分为第二类服务。
可选的,所述代理装置监测所述第一类服务的内存使用情况,包括:
所述代理装置分别定期查看每一个第一类服务的内存占用量;
所述代理装置确定所述第一类服务的内存使用情况满足预设的告警条件,包括:
所述代理装置确定至少一个第一类服务的内存占用量达到预设的第一内存占用门限,并且在第一指定历史时长内所述至少一个第一类服务的内存占用量处于持续增长状态时,判定所述第一类服务的内存使用情况满足预设的告警条件。
可选的,触发告警之后,进一步包括:
所述代理装置针对每一个内存占用量达到预设的第一内存占用门限的第一类服务执行以下操作:
判断一个第一类服务是否运行有垃圾文件;
若是,则删除垃圾文件,释放相应内存;
否则,确定所述第一类服务在第三指定历史时长内,内存占用量达到预设的第一内存占用门限的次数达到设定阈值时,增加所述一个第一类服务的最大内存分配量。
可选的,所述代理装置监测所述第一类服务的内存使用情况,包括:
所述代理装置定期查看每一个第一类服务的内存占用量,以及定期查看系统内所有服务的内存占用总量;
所述代理装置确定所述第一类服务的内存使用情况满足预设的告警条件,包括:
所述代理装置基于所述所有服务的内存占用总量,计算系统的内存剩余量;
所述代理装置基于每一个第一类服务的内存占用量以及相应的最大内存分配量,计算所有第一类服务的内存占用总量以及内存需求总量;
所述代理装置确定所有第一类服务的内存占用总量达到预设的第二内存占用门限,并且所有第一类服务的内存需求总量不小于所述系统的内存剩余量,以及至少一个第一类服务的内存占用量在第二指定历史时长内处于持续增长状态时,判定所述第一类服务的内存使用情况满足预设的告警条件。
可选的,触发告警之后,进一步包括:
判断是否每一个第一类服务的内存占用量均小于预设的第三内存占用门限,若判断结果为是,则查看内存低敏感度的第二类服务的内存占用量,确定至少一个第二类服务在第四指定历史时长内的内存占用量达到预设的第四内存占用门限时,减少所述至少一个第二类服务的最大内存分配量,其中,所述第三内存占用门限低于所述第四内存占用门限。
第二方面,提供一种内存监控的装置,应用于zabbix系统,包括:
确定单元,用于基于预设的服务分类,确定具有内存高敏感度的第一类服务,其中,具有内存高敏感度的服务,为在内存不能满足需求时直接退出的服务;
监测单元,用于监测所述第一类服务的内存使用情况,获得监测结果;
处理单元,用于基于所述监测结果,确定所述第一类服务的内存使用情况满足预设的告警条件时,触发告警。
可选的,进一步包括:
配置单元,用于预设所述服务分类,具体用于:
将在内存不能满足需求时直接退出的服务,划分为第一类服务,
以及将在内存不能满足需求时不直接退出的服务,划分为第二类服务,
可选的,监测所述第一类服务的内存使用情况时,所述监测单元用于:
分别定期查看每一个第一类服务的内存占用量;
确定所述第一类服务的内存使用情况满足预设的告警条件,包括:
确定至少一个第一类服务的内存占用量达到预设的第一内存占用门限,并且在第一指定历史时长内所述至少一个第一类服务的内存占用量处于持续增长状态时,判定所述第一类服务的内存使用情况满足预设的告警条件。
可选的,触发告警之后,所述处理单元进一步用于:
针对每一个内存占用量达到预设的第一内存占用门限的第一类服务执行以下操作:
判断一个第一类服务是否运行有垃圾文件;
若是,则删除垃圾文件,释放相应内存;
否则,确定所述第一类服务在第三指定历史时长内,内存占用量达到预设的第一内存占用门限的次数达到设定阈值时,增加所述一个第一类服务的最大内存分配量。
可选的,监测所述第一类服务的内存使用情况时,所述监测单元用于:
定期查看每一个第一类服务的内存占用量,以及定期查看系统内所有服务的内存占用总量;
确定所述第一类服务的内存使用情况满足预设的告警条件,包括:
基于所述所有服务的内存占用总量,计算系统的内存剩余量;
基于每一个第一类服务的内存占用量以及相应的最大内存分配量,计算所有第一类服务的内存占用总量以及内存需求总量;
确定所有第一类服务的内存占用总量达到预设的第二内存占用门限,并且所有第一类服务的内存需求总量不小于所述系统的内存剩余量,以及至少一个第一类服务的内存占用量在第二指定历史时长内处于持续增长状态时,判定所述第一类服务的内存使用情况满足预设的告警条件。
可选的,触发告警之后,所述处理单元进一步用于:
判断是否每一个第一类服务的内存占用量均小于预设的第三内存占用门限,若判断结果为是,则查看内存低敏感度的第二类服务的内存占用量,确定至少一个第二类服务在第四指定历史时长内的内存占用量达到预设的第四内存占用门限时,减少所述至少一个第二类服务的最大内存分配量,其中,所述第三内存占用门限低于所述第四内存占用门限。
第三方面,提供一种存储介质,应用于zabbix系统,存储用于实现内存监控的程序,所述程序被处理器运行时,执行以下步骤:
基于预设的服务分类,确定具有内存高敏感度的第一类服务,其中,具有内存高敏感度的服务,为在内存不能满足需求时直接退出的服务;
监测所述第一类服务的内存使用情况,获得监测结果;
基于所述监测结果,确定所述第一类服务的内存使用情况满足预设的告警条件时,触发告警。
第四方面,提供一种通信装置,应用于zabbix系统,包括一个或多个处理器;以及
一个或多个计算机可读介质,所述可读介质上存储有指令,所述指令被所述一个或多个处理器执行时,使得所述装置执行上述第一方面中的任一项所述的方法。
本发明实施例中,zabbix框架下,多个关键性服务的内存使用情况的分析及告警下沉至agent侧完成,server只提供通用的能力(如,历史监控数据的存储和图标展示等等),而agent会将系统中的各个服务进行分类,针对内存高敏感度的第一类服务和内存低敏感度的第二类服务分别采用不同的监控策略,其中,agent主要针对各个第一类服务在一段时间内积累的内存使用情况进行监控,一旦确定第一类服务的内存使用情况符合预警条件,便会进行告警。
这样,agent优先监测了内存高敏感度的第一类服务的内存使用情况,既可以及时发现内存使用情况出现异常,保证第一类服务的正常工作,又没有影响内存低敏感度的第二类服务的正常工作,既保证了系统的服务质量,又没有增加实现复杂度。
附图说明
图1为本发明实施例中进行内存监控流程示意图;
图2为本发明实施例中agent功能结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,并不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
由于内存对于运行程序至关重要,一旦系统分配不出内存或服务已使用的内存超过其内存分配上限,都会导致服务意外退出,因此,本发明实施例中,选择作为程序运行的核心资源的内存作为监控对象,具体阐述如何实现对多个关键性服务进行联合监控。所谓关键性服务(又可称为核心服务)可以是指企业消息系统(rabbitmq)、数据库管理系统(mysql)、Key-Value数据库(redis)、tomcat等等服务。
因此,本发明实施例中,为了减轻zabbix server(以下简称为server)的告警判断负担,将告警判断功能下沉到被监测的机器,即下降到各个zabbix agent(以下简称为agent),server只提供通用的报警功能。
agent在判断何时报警时,以系统的内存资源和核心服务的内存使用现状及趋势为基础,综合分析它们之间的相互影响,尽可能早地做出预判,发出报警信息,以便server及时作出调整,避免服务运行不正常了才滞后报警。
参阅图1所示,本发明实施例中,对内存进行监控的详细流程如下:
步骤100:agent基于预设的服务分类,确定具有内存高敏感度的第一类服务,其中,具有内存高敏感度的服务,为在内存不能满足需求时直接退出的服务。
本发明实施例中,在预处理阶段,agent会对本地运行的各个任务进行分类。可选的,可以至少从内存敏感度这一个维度进行分类,进一步地,也可以基于内存敏感度和内存使用量这两个维度进行分类。
内存敏感度是指,当内存不能满足需求时,有些服务会直接异常退出,而有些服务会将部分数据存储到硬盘,虽然运行速度减缓,但不会异常退出。前者属于内存高敏感度的服务,如,tomcat;后者属于内存低敏感度的服务,如rabbitmq。
内存使用量是指,服务是否需要占用大量内存才能保证正常运行。比如,redis需要占用大量内存保证运行正常;而mysql对内存的需求量就相对较小。
基于上面的原则,以内存敏感度和内存使用量这两个维度为例,各个服务可以大致分为以下四类:
高内存量高敏感(SHH):这类服务既要关注其内存占用是否过多,还要同时兼顾内存占用量是否达到自身的上限规定。
高内存量低敏感(SHL):这类服务需要特别关注是否占用了过多内存,而对别的服务正常工作存在潜在影响。
低内存量低敏感(SLL):这类服务不用特别关注,只要在每次进行告警判断时查看其内存占用情况。
低内存量高敏感(SLH):这类服务虽然占用内存不多,但当少量内存得不到保证时,就会意外退出。所以也要监控其内存占用量是否接近上限,或其占用内存持续增加时,系统内存不够分配。
上述四类服务中,SHH和SLH属于内存高敏感度的服务,后续称为第一类服务,而SHL和SLL属于内存低敏感度的服务,后续称为第二类服务。
步骤110:agent监测上述第一类服务的内存使用情况,获得监测结果。
具体的,在执行步骤120时,agent可以分别定期查看内存高敏感度的每一个第一类服务(即SHH和SLH)的内存占用量;
或者,agent也可以在分别定期查看内存高敏感度的每一个第一类服务(即SHH和SLH)的内存占用量,以及定期查看系统内所有服务的内存占用总量。
步骤120:agent基于上述监测结果,确定上述第一类服务的内存使用情况满足预设的告警条件,则触发告警。
可选的,在执行步骤130时,agent可以采用但不限于以下两种方法:
第一种方法为:agent分别定期查看内存高敏感度的每一个第一类服务(即SHH和SLH)的内存占用量,只要在某一时刻,agent确定至少一个第一类服务(即SHH或/和SLH)当前的内存占用量达到预设的第一内存占用门限,并且在第一指定历史时长内上述至少一个第一类服务的内存占用量处于持续增长状态,则第一类服务的内存使用情况判定满足预设的告警条件。
例如,在某一时刻,agent确定SHH或/和SLH且在过去的5分钟(仅为举例)内Scur(i)处于持续增长状态,其中,p表示预设的第一内存占用门限,Scur(i)表示agent上运行的某个内存高敏感度的第一类服务i当前的内存占用量,Smax表示上述第一类服务i最大内存分配量。
此时,agent会预判SHH或/和SLH当前的内存占用量即将达到相应的预设内存占用门限,这很容易导致SHH或/和SLH因意外退出,为了保证内存高敏感度的第一类服务的服务质量,agent应该立即向sever发出预警信息,通知运维人员干预。
实际应用中,每一种第一类服务都可以设置相应的第一内存占用门限,也可以使用统一的第一内存占用门限,本发明实施例中有,采用的是统一的第一内存占用门限,仅为举例,将不再赘述。
使用第一种方法时,agent会优先监测内存高敏感度的各个第一类服务的内存使用情况,因为第一类服务随时都有可能因为内存不够而退出,因此需要着重关注,从而保证服务质量,另一方面,agent优先监测了内存高敏感度的第一类服务的内存使用情况,而不是监测所有服务的内存使用情况,这在一定程序上降低了agent的运行负荷,既可以及时发现内存使用情况出现异常,又没有增加实现复杂度,此类实现方案适合处理能力稍低于sever的agent执行。
第二种方法为:agent定期查看每一个第一类服务的内存占用量,以及定期查看系统内所有服务的内存占用总量,然后,agent基于所有服务的内存占用总量,定期计算系统当前的内存剩余量,以及基于每一个第一类服务当前的内存占用量以及相应的最大内存分配量,定期计算所有第一类服务当前的内存占用总量以及内存需求总量,只要在某一时刻,agent确定所有第一类服务当前的内存占用总量达到预设的第二内存占用门限,并且所有第一类服务当前的内存需求总量不小于系统当前的内存剩余量,以及至少一个第一类服务的内存占用量在第二指定历史时长内处于持续增长状态,则判定第一类服务的内存使用情况满足预设的告警条件。
例如,在某一时刻,agent确定SHH或/和SLH的 以及在过去的5分钟(仅为举例)内处于持续增长状态,其中,P’表示预设的第二内存占用门限,Scur表示所有第一类服务当前的内存占用总量,MEMtotal表示系统内所有服务的内存占用总量,MEMleft表示系统当前的内存剩余量,Scur(i)表示agent上运行的某个内存高敏感度的第一类服务i当前的内存占用量,Smax表示上述第一类服务i最大内存分配量。
此时,系统内的内存剩余量不足以满足所有第一类服务(即SHH或/和SLH))的内存增长需求,同时,若至少一个第一类服务的内存占用量在历史5分钟之内处于持续上升状态,则该至少一个第一类服务很有可能会在未来时间段内持续增加内存占用量,那么,在不久的将来,很有可能内存剩余量无法满足第一类服务运行所需要的内占用量,从而导致第一类服务异常退出,因此,为了保证内存高敏感度的第一类服务的服务质量,agent应该立即向sever发出预警信息,通知运维人员干预。
使用第二种方法时,agent会基于第一类服务的整体内存使用情况进行监测,即使单个第一类服务的内存占用量均未达到预设的第一预设门限值,但由于还存在内存低敏感度的第二类服务,因此,所有服务的内存占用总量还是有可能过高,从而导致系统的内存剩余量不足,不足以支持第一类服务在未来时间段内的内存需求,所以,要综合考虑第一类服务的内存占用总量与所有服务的内存占用总量的关系,以及第一类服务的内存需求总量和系统的内存剩余量之间的关系,才能准确预测有可能发生的异常事件,在第一类服务因内存不能满足需求而意外退出之前及时告警,从而保证了系统的整体服务质量。
基于上述实施例,实际应用中,在告警之后,若运维人员未能及时处理,在agent处理能力允许的前提下,agent还可以自行进行内存整合,从而缓解自身的内存使用压力。
具体的可以采用但不限于以下两种解决方案:
解决方案a(针对上述第一方法):
agent针对每一个内存占用量达到预设的第一内存占用门限的第一类服务执行以下操作:
1)判断一个第一类服务是否运行有垃圾文件;所谓垃圾文件即是指已相关任务已经完成但仍未释放资源的服务。
2)若是,则删除垃圾文件,释放相应内存;
3)否则,确定上述一个第一类服务在第三指定历史时长内,内存占用量达到预设的第一内存占用门限的次数达到设定阈值时,增加上述一个一类服务的最大内存分配量。
如,假设第一类服务i对应的且在过去的10分钟内这种情况出现了4次(假设设定阈值为3),并且第一类服务i中未运行垃圾文件,则需要适量增加第一类服务i的Smax。
解决方案b(针对上述第二方法):
agent判断是否每一个第一类服务的内存占用量均小于预设的第三内存占用门限,若判断结果为是,则查看内存低敏感度的第二类服务(即SHL和SLL)的内存使用情况,确定至少一个第二类服务在第四指定历史时长内的内存占用量达到预设的第四内存占用门限时,减少上述至少一个第二类服务的最大内存分配量,其中,第三内存占用门限低于第四内存占用门限。
如,假设每一个第一类服务i对应的说明第一类服务均未占用过多内存,则agent会去查看第二类服务(即SHL和SLL)的内存使用情况,若至少一个第二类服务在过去的5分钟内对应的则说明上述至少一个第二类服务长时间占用了大量内存,则需要降低上述至少一个第二类服务的Smax。
当然上述解决方案a和解决方案b仅仅是针对一次告警的救火式处理,在后续过程中,运维人员还需要监控发生告警的agent中各个服务的内存使用情况,除了保证各个服务正常运行,还应该进一步优化上述agent中各个服务的部署。确保内存高敏感度的第一类服务(即SHH和SHL)能尽可能多地占用内存,满足自身需要,同时不影响其他的服务。同时,确保上述第一类服务不会因自身的最大内存分配量Smax设置过小或系统分配不出内存而意外退出。
进一步地,如果发生多次靠警后,需要分析各个服务的历史数据,查找到那些无论内存占用量还是均位于前N位的服务,其中,N为预设值,考虑将此类服务做迁移(针对单点部署的服务),或者,增加分布式处理节点(针对分布式部署的服务)。
基于上述实施例,参阅图2所示,本发明实施例中,zabbix系统中用于内存监控的装置(如,agent),至少包括确定单元20、监测单元21和处理单元22,其中,
确定单元20,用于基于预设的服务分类,确定具有内存高敏感度的第一类服务,其中,具有内存高敏感度的服务,为在内存不能满足需求时直接退出的服务;
监测单元21,用于监测所述第一类服务的内存使用情况,获得监测结果;
处理单元22,用于基于所述监测结果,确定所述第一类服务的内存使用情况满足预设的告警条件时,触发告警。
可选的,进一步包括:
配置单元23,用于预设所述服务分类,具体用于:
将在内存不能满足需求时直接退出的服务,划分为第一类服务,
以及将在内存不能满足需求时不直接退出的服务,划分为第二类服务。
可选的,监测第一类服务的内存使用情况时,监测单元21用于:
分别定期查看每一个第一类服务的内存占用量;
确定所述第一类服务的内存使用情况满足预设的告警条件,包括:
确定至少一个第一类服务的内存占用量达到预设的第一内存占用门限,并且在第一指定历史时长内所述至少一个第一类服务的内存占用量处于持续增长状态时,判定所述第一类服务的内存使用情况满足预设的告警条件。
可选的,触发告警之后,处理单元22进一步用于:
针对每一个内存占用量达到预设的第一内存占用门限的第一类服务执行以下操作:
判断一个第一类服务是否运行有垃圾文件;
若是,则删除垃圾文件,释放相应内存;
否则,确定所述第一类服务在第三指定历史时长内,内存占用量达到预设的第一内存占用门限的次数达到设定阈值时,增加所述一个第一类服务的最大内存分配量。
可选的,监测第一类服务的内存使用情况时,监测单元21用于:
定期查看每一个第一类服务的内存占用量,以及定期查看系统内所有服务的内存占用总量;
确定所述第一类服务的内存使用情况满足预设的告警条件,包括:
基于所述所有服务的内存占用总量,计算系统的内存剩余量;
基于每一个第一类服务的内存占用量以及相应的最大内存分配量,计算所有第一类服务的内存占用总量以及内存需求总量;
确定所有第一类服务的内存占用总量达到预设的第二内存占用门限,并且所有第一类服务的内存需求总量不小于所述系统的内存剩余量,以及至少一个第一类服务的内存占用量在第二指定历史时长内处于持续增长状态时,判定所述第一类服务的内存使用情况满足预设的告警条件。
可选的,触发告警之后,处理单元22进一步用于:
判断是否每一个第一类服务的内存占用量均小于预设的第三内存占用门限,若判断结果为是,则查看内存低敏感度的第二类服务的内存占用量,确定至少一个第二类服务在第四指定历史时长内的内存占用量达到预设的第四内存占用门限时,减少所述至少一个第二类服务的最大内存分配量,其中,所述第三内存占用门限低于所述第四内存占用门限。
在本发明一个实施例中,提供一种存储介质,应用于zabbix系统,存储用于实现内存监控的程序,所述程序被处理器运行时,执行以下步骤:
基于预设的服务分类,确定具有内存高敏感度的第一类服务,其中,具有内存高敏感度的服务,为在内存不能满足需求时直接退出的服务;
监测所述第一类服务的内存使用情况,获得监测结果;
基于所述监测结果,确定所述第一类服务的内存使用情况满足预设的告警条件时,触发告警。
在本发明一个实施例中,提供一种通信装置,应用于zabbix系统,包括一个或多个处理器;以及
一个或多个计算机可读介质,所述可读介质上存储有指令,所述指令被所述一个或多个处理器执行时,使得所述装置执行上述实施例中的任意一种方法。
本发明实施例中,zabbix框架下,多个关键性服务的内存使用情况的分析及告警下沉至agent侧完成,server只提供通用的能力(如,历史监控数据的存储和图标展示等等),而agent会将系统中的各个服务进行分类,针对内存高敏感度的第一类服务和内存低敏感度的第二类服务分别采用不同的监控策略,其中,agent主要针对各个第一类服务在一段时间内积累的内存使用情况进行监控,一旦确定第一类服务的内存使用情况符合预警条件,便会进行告警。
这样,agent优先监测了内存高敏感度的第一类服务的内存使用情况,既可以及时发现内存使用情况出现异常,保证第一类服务的正常工作,又没有影响内存低敏感度的第二类服务的正常工作,既保证了系统的服务质量,又没有增加实现复杂度。
进一步地,agent在判断第一类服的内存使用情况是否出现异常时,不仅考虑了系统的内存资源问题,还会考虑系统中各个第一类服务及第二类服务当前的内存占用量以及情况以及历史趋势,使得判断条件充分考虑了服务之间的相互影响,而非服务本身,令判断结果更准确,更符合系统的实时工作状态,从而能够采用更为合理的策略加以解决,进一步保证了系统的服务质量。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本发明的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。
显然,本领域的技术人员可以对本发明实施例进行各种改动和变型而不脱离本发明实施例的精神和范围。这样,倘若本发明实施例的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。

Claims (9)

1.一种内存监控的方法,应用于zabbix系统,其特征在于,包括:
代理装置基于预设的服务分类,确定具有内存高敏感度的第一类服务,其中,具有内存高敏感度的服务,为在内存不能满足需求时直接退出的服务;
所述代理装置监测所述第一类服务的内存使用情况,获得监测结果;
所述代理装置基于所述监测结果,确定所述第一类服务的内存使用情况满足预设的告警条件时,触发告警。
2.如权利要求1所述的方法,其特征在于,预设所述服务分类,包括:
所述代理装置将在内存不能满足需求时直接退出的服务,划分为第一类服务;
以及所述代理装置将在内存不能满足需求时不直接退出的服务,划分为第二类服务。
3.如权利要求1或2所述的方法,其特征在于,所述代理装置监测所述第一类服务的内存使用情况,包括:
所述代理装置分别定期查看每一个第一类服务的内存占用量;
所述代理装置确定所述第一类服务的内存使用情况满足预设的告警条件,包括:
所述代理装置确定至少一个第一类服务的内存占用量达到预设的第一内存占用门限,并且在第一指定历史时长内所述至少一个第一类服务的内存占用量处于持续增长状态时,判定所述第一类服务的内存使用情况满足预设的告警条件。
4.如权利要求3所述的方法,其特征在于,触发告警之后,进一步包括:
所述代理装置针对每一个内存占用量达到预设的第一内存占用门限的第一类服务执行以下操作:
判断一个第一类服务是否运行有垃圾文件;
若是,则删除垃圾文件,释放相应内存;
否则,确定所述第一类服务在第三指定历史时长内,内存占用量达到预设的第一内存占用门限的次数达到设定阈值时,增加所述一个第一类服务的最大内存分配量。
5.如权利要求1或2所述的方法,其特征在于,所述代理装置监测所述第一类服务的内存使用情况,包括:
所述代理装置定期查看每一个第一类服务的内存占用量,以及定期查看系统内所有服务的内存占用总量;
所述代理装置确定所述第一类服务的内存使用情况满足预设的告警条件,包括:
所述代理装置基于所述所有服务的内存占用总量,计算系统的内存剩余量;
所述代理装置基于每一个第一类服务的内存占用量以及相应的最大内存分配量,计算所有第一类服务的内存占用总量以及内存需求总量;
所述代理装置确定所有第一类服务的内存占用总量达到预设的第二内存占用门限,并且所有第一类服务的内存需求总量不小于所述系统的内存剩余量,以及至少一个第一类服务的内存占用量在第二指定历史时长内处于持续增长状态时,判定所述第一类服务的内存使用情况满足预设的告警条件。
6.如权利要求5所述的方法,其特征在于,触发告警之后,进一步包括:
所述代理装置判断是否每一个第一类服务的内存占用量均小于预设的第三内存占用门限,若判断结果为是,则查看内存低敏感度的第二类服务的内存占用量,确定至少一个第二类服务在第四指定历史时长内的内存占用量达到预设的第四内存占用门限时,减少所述至少一个第二类服务的最大内存分配量,其中,所述第三内存占用门限低于所述第四内存占用门限。
7.一种内存监控的装置,应用于zabbix系统,其特征在于,包括:
确定单元,用于基于预设的服务分类,确定具有内存高敏感度的第一类服务,其中,具有内存高敏感度的服务,为在内存不能满足需求时直接退出的服务;
监测单元,用于监测所述第一类服务的内存使用情况,获得监测结果;
处理单元,用于基于所述监测结果,确定所述第一类服务的内存使用情况满足预设的告警条件时,触发告警。
8.一种存储介质,应用于zabbix系统,其特征在于,存储用于实现内存监控的程序,所述程序被处理器运行时,执行以下步骤:
基于预设的服务分类,确定具有内存高敏感度的第一类服务,其中,具有内存高敏感度的服务,为在内存不能满足需求时直接退出的服务;
监测所述第一类服务的内存使用情况,获得监测结果;
基于所述监测结果,确定所述第一类服务的内存使用情况满足预设的告警条件时,触发告警。
9.一种通信装置,应用于zabbix系统,其特征在于,包括一个或多个处理器;以及
一个或多个计算机可读介质,所述可读介质上存储有指令,所述指令被所述一个或多个处理器执行时,使得所述装置执行如权利要求1至6中任一项所述的方法。
CN201810002480.3A 2018-01-02 2018-01-02 一种内存监控的方法及装置 Pending CN109992471A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810002480.3A CN109992471A (zh) 2018-01-02 2018-01-02 一种内存监控的方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810002480.3A CN109992471A (zh) 2018-01-02 2018-01-02 一种内存监控的方法及装置

Publications (1)

Publication Number Publication Date
CN109992471A true CN109992471A (zh) 2019-07-09

Family

ID=67128548

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810002480.3A Pending CN109992471A (zh) 2018-01-02 2018-01-02 一种内存监控的方法及装置

Country Status (1)

Country Link
CN (1) CN109992471A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111162965A (zh) * 2019-12-17 2020-05-15 杭州迪普科技股份有限公司 监控Buffer的方法和装置
CN114253457A (zh) * 2020-09-21 2022-03-29 华为技术有限公司 内存控制方法和装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140137131A1 (en) * 2012-11-15 2014-05-15 International Business Machines Corporation Framework for java based application memory management
CN104991849A (zh) * 2015-06-30 2015-10-21 浪潮软件股份有限公司 一种通过zabbix监控Linux进程占用系统资源的方法
CN105740078A (zh) * 2016-01-29 2016-07-06 华为技术有限公司 一种内存管理方法、装置及终端
CN106487574A (zh) * 2016-04-01 2017-03-08 国家计算机网络与信息安全管理中心 自动化运行维护监测系统
CN106685839A (zh) * 2016-11-17 2017-05-17 上海斐讯数据通信技术有限公司 路由器长连接服务监控方法及系统
WO2017096835A1 (zh) * 2015-12-09 2017-06-15 乐视控股(北京)有限公司 服务器群组的服务升级方法及系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140137131A1 (en) * 2012-11-15 2014-05-15 International Business Machines Corporation Framework for java based application memory management
CN104991849A (zh) * 2015-06-30 2015-10-21 浪潮软件股份有限公司 一种通过zabbix监控Linux进程占用系统资源的方法
WO2017096835A1 (zh) * 2015-12-09 2017-06-15 乐视控股(北京)有限公司 服务器群组的服务升级方法及系统
CN105740078A (zh) * 2016-01-29 2016-07-06 华为技术有限公司 一种内存管理方法、装置及终端
CN106487574A (zh) * 2016-04-01 2017-03-08 国家计算机网络与信息安全管理中心 自动化运行维护监测系统
CN106685839A (zh) * 2016-11-17 2017-05-17 上海斐讯数据通信技术有限公司 路由器长连接服务监控方法及系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111162965A (zh) * 2019-12-17 2020-05-15 杭州迪普科技股份有限公司 监控Buffer的方法和装置
CN114253457A (zh) * 2020-09-21 2022-03-29 华为技术有限公司 内存控制方法和装置

Similar Documents

Publication Publication Date Title
US8751623B2 (en) Reduction of alerts in information technology systems
CN109408210B (zh) 分布式定时任务管理方法及系统
EP2871577A1 (en) Complex event processing (CEP) based system for handling performance issues of a CEP system and corresponding method
CN107465575A (zh) 一种集群的监控方法及系统
CN106886485A (zh) 系统容量分析预测方法及装置
CN109684162A (zh) 设备状态预测方法、系统、终端及计算机可读存储介质
JP2008033852A (ja) リソース管理システム及びその方法
US10838791B1 (en) Robust event prediction
CN109670690A (zh) 数据信息中心监控预警方法、系统及设备
CN109743369A (zh) 一种基于车联网的实时数据的处理装置、方法及系统
CN110493146B (zh) 一种边缘智能网络感知平台及控制方法
CN115495231B (zh) 一种高并发任务复杂场景下的动态资源调度方法及系统
CN110716800B (zh) 任务调度方法及装置、存储介质及电子设备
CN109992471A (zh) 一种内存监控的方法及装置
CN113568756A (zh) 一种密码资源协同动态调度方法和系统
WO2024082861A1 (zh) 一种应用于视频监控中的云存储调度系统
CN109240863A (zh) 一种cpu故障定位方法、装置、设备及存储介质
CN103188103A (zh) 一种网管系统自监控方法
CN109634803A (zh) 一种上报设备异常的方法和装置
US8510273B2 (en) System, method, and computer-readable medium to facilitate application of arrival rate qualifications to missed throughput server level goals
US9519519B2 (en) System and method for managing workload performance on billed computer systems
WO2024169138A1 (zh) 一种资源调度方法、装置、设备及存储介质
CN113312235A (zh) 吞吐量优化的服务质量预警功率封顶系统
Zhang et al. PRMRAP: A proactive virtual resource management framework in cloud
CN111507819A (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
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20190709