基于session数的运维平台性能监控方法、装置及相关设备与流程

本发明涉及计算机技术领域，具体涉及一种基于session数的运维平台性能监控方法、装置及相关设备。

背景技术：

传统运维的管理模式由管理者人工监控系统的运行状况，对应用系统中出现的日常管理操作进行手工处理，成本高，效率低且缺乏实时性。已经不适用于大型应用系统。尤其是对于高度集群化的企业应用管理场景，自动化运维管理方式必不可少。

现今，采用监控系统采集和存储监控对象(如集群、主机、数据库等)的数据，通过分析、统计等处理得到相应的指标，再实时验证指标是否满足预期，如判定指标不满足预期(也即指标满足报警规则中的报警条件)时进行报警。例如报警规则规定主机的cpu使用率超过95％时进行报警，如果主机的cpu使用率达到98％，则判定该指标不符合预期或者说该指标满足报警规则中的报警条件而触发报警。

然而，监控系统通常只监控固定的几个指标，例如cpu使用率、网络流量、数据库连接数等等，并没有将活动session数结合起来进行监控，且也没有结合历史监控数据进行判断，因而报警规则相对简单，可能会造成误报进而影响管理者的工作计算。

技术实现要素：

鉴于以上内容，有必要提出一种基于session数的运维平台性能监控方法、装置及及相关，能够通过云监控及不同的报警方式，确定cpu使用率高是否由活动session数引起的，有助于运维管理者快速定位问题的根源，便于排查。

本发明的第一方面提供一种基于session数的运维平台性能监控方法，所述方法包括：

获取当前监控周期内的监控对象的cpu使用率；

当确定所述监控对象的cpu使用率满足第一报警条件时，获取所述当前监控周期内的所述监控对象的活动session数；

判断所述当前监控周期内的所述监控对象的活动session数是否满足第二报警条件；

当确定所述当前监控周期内的所述监控对象的活动session数不满足所述第二报警条件时，以预设第一报警方式对所述监控对象进行报警；

当确定所述当前监控周期内的所述监控对象的活动session数满足所述第二报警条件时，以预设第二报警方式对所述监控对象进行报警。

根据本发明的一个优选实施例，所述当前监控周期是根据历史监控周期内的cpu使用率进行设置的，包括：

获取历史监控周期对应的cpu使用率；

获取所述cpu使用率高于预设cpu使用率阈值的目标cpu使用率；

获取所述目标cpu使用率对应的监控时间段或者监控时间点；

将所述监控时间段或者监控时间点设置为当前监控周期。

根据本发明的一个优选实施例，在所述获取当前监控周期内的所述监控对象的活动session数之后，所述方法还包括：

判断所述当前监控周期内的监控对象的活动session数是否小于预设session数阈值；

当确定所述当前监控周期内的监控对象的活动session数小于所述预设session数阈值时，以预设第三报警方式对所述监控对象进行报警。

根据本发明的一个优选实施例，所述第二报警条件为：当前监控周期内的监控对象的活动session数大于上一个监控周期内的监控对象的活动session数的第一比例值且小于所述上一个监控周期内的监控对象的活动session数的第二比例值，其中，第一比例值小于1，第二比例值大于1。

根据本发明的一个优选实施例，当确定所述监控对象的cpu使用率不满足第一报警条件时，所述方法还包括：

获取下一个监控周期内的监控对象的cpu使用率。

根据本发明的一个优选实施例，所述预设第二报警方式为：生成监控信息展示界面，展示所述监控对象的活动session数及对应的活动sessionid。

根据本发明的一个优选实施例，所述获取当前监控周期内的监控对象的cpu使用率包括：

当系统处于可用状态时，获取监控对象当前运行的应用程序的进程信息；

根据所述进程信息的进程标识符，通过top命令调取rocketmq进程的资源信息；

从所述rocketmq进程的资源信息中获取所述当前监控周期内的监控对象的cpu使用率率。

本发明的第二方面提供一种基于session数的运维平台性能监控装置，所述装置包括：

第一获取模块，用于获取当前监控周期内的监控对象的cpu使用率；

第一判断模块，用于判断所述监控对象的cpu使用率是否满足第一报警条件；

第二获取模块，用于当所述第一判断模块确定所述监控对象的cpu使用率满足第一报警条件时，获取所述当前监控周期内的所述监控对象的活动session数；

第二判断模块，用于判断所述当前监控周期内的所述监控对象的活动session数是否满足第二报警条件；

第一报警模块，用于当所述第二判断模块确定所述当前监控周期内的所述监控对象的活动session数不满足所述第二报警条件时，以预设第一报警方式对所述监控对象进行报警；

第二报警模块，用于当所述第二判断模块确定所述当前监控周期内的所述监控对象的活动session数满足所述第二报警条件时，以预设第二报警方式对所述监控对象进行报警。

本发明的第三方面提供一种电子设备，所述电子设备包括处理器和存储器，所述处理器用于执行所述存储器中存储的计算机程序时实现所述的基于session数的运维平台性能监控方法。

本发明的第四方面提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现所述的基于session数的运维平台性能监控方法。

本发明实施例提供的基于session数的运维平台性能监控方法、装置、电子设备及存储介质，获取监控对象的监控指标，所述监控指标包括：cpu使用率、活动session数；在判断当前监控周期内监控对象的cpu使用率是否满足第一报警条件时，继续判断当前监控周期内的所述监控对象的活动session数是否满足第二报警条件；当确定当前监控周期内的所述监控对象的活动session数不满足第二报警条件时，通过第一报警方式报警提醒运维管理者cpu使用率较高；当确定当前监控周期内的所述监控对象的活动session数满足第二报警条件时，通过第二报警方式报警提醒运维管理者cpu使用率较高是由于不合理的活动session数引起的，进而提示管理者直接查看活动session数以排除故障原因，从而起到快速定位活动session的作用。因传统的运维并没有考虑活动session数不合理时也会引起cpu使用率高的问题，而在高并发的集群中，活动session数很容易出现异常，直接通过检测监控对象的活动session数能有助于运维管理者快速定位问题的根源，便于排查，提升系统运维的效率，降低人工排查的成本。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1是本发明实施例一提供的基于session数的运维平台性能监控方法的流程图。

图2是本发明实施例二提供的基于session数的运维平台性能监控装置的功能模块图。

图3是本发明实施例三提供的电子设备的示意图。

如下具体实施方式将结合上述附图进一步说明本发明。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施例对本发明进行详细描述。需要说明的是，在不冲突的情况下，本发明的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

除非另有定义，本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本发明。

本发明实施例的基于session数的运维平台性能监控方法应用在电子设备中，也可以应用在电子设备和通过网络与所述电子设备进行连接的服务器所构成的硬件环境中，由服务器和电子设备共同执行。网络包括但不限于：广域网、城域网或局域网。

所述电子设备可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算电子设备。

所述对于需要进行基于session数的运维平台性能监控方法的电子设备，可以直接在电子设备上集成本发明的方法所提供的基于session数的运维平台性能监控功能，或者安装用于实现本发明的方法的客户端。再如，本发明所提供的方法还可以以软件开发工具包(softwaredevelopmentkit，sdk)的形式运行在服务器等电子设备上，以sdk的形式提供基于session数的运维平台性能监控功能的接口，服务器或其他电子设备通过提供的接口即可实现基于session数的运维平台性能监控功能。

实施例一

图1是本发明实施例一提供的基于session数的运维平台性能监控方法的流程图。所述基于session数的运维平台性能监控方法对session数指标进行监控并根据监控的session数指标进行运维平台的维护。根据不同的需求，该流程图中的执行顺序可以改变，某些步骤可以省略。

101，获取当前监控周期内的监控对象的cpu使用率。

本实施例中，可以由监控系统监控周期内的监控对象的cpu使用率。监控系统可以是由多个云产品构成的大规模系统的监控系统，也可以是由少数几个机器构成的服务系统，还可以是单机系统。

监控对象可以是监控系统中的任何对象，例如，可以是物理实体如集群、系统、设备等，可以是软件实体如计算机操作系统、应用进程等，还可以是软硬件一起构成的逻辑实体如虚拟机等。

监控系统监控一个或多个监控对象的监控指标。所述监控指标也称之为监控项，是用于报警判定的指标。

监控系统可以同时检测多个监控对象的多个监控指标。

本实施例中，所述监控指标包括：活动session数、cpu使用率在其他实施例中，所述监控指标还可以同时包括内存使用率、数据库连接数等。

本实施例中，所述cpu使用率是指运行的程序占用的cpu的百分比，cpu使用率越高，说明同时运行的应用程序越多，cpu使用率越低，说明同时运行的应用程序越少。cpu使用率过高时会影响系统性能，导致系统运行缓慢，响应周期变长。

所述监控周期是指预先设定的监控时间段或者预先设定的监控时间点。

所述监控时间段是一个时间周期，例如，当天的上午10点-12点，或者当天的下午3点-5点，或者每隔两个小时。

所述监控时间点是一个具体的时间点，例如，当天的上午10点，或者当天晚上的10点，或者每一个整点，如1点，2点，3点等。

在一些实施例中，还可以预先设定多个监控时间段，例如，上午10点-12点，及当天的下午3点-5点，在每一个监控时间段内检测监控对象的cpu使用率。

在一些实施例中，还可以预先设定多个监控时间点，当天的上午10点，及当天晚上的10点，在每一个监控时间点时检测监控对象的cpu使用率。

在一些实施例中，所述监控周期还可以同时包括多个监控时间段及多个监控时间点。

本实施例中，所述当前监控周期是根据历史监控周期内的cpu使用率进行设置的。

具体的，所述根据历史监控周期内的cpu使用率设置当前监控周期包括：

获取历史监控周期对应的cpu使用率；

获取所述cpu使用率高于预设cpu使用率阈值的目标cpu使用率；

获取所述目标cpu使用率对应的监控时间段或者监控时间点；

将所述监控时间段或者监控时间点设置为当前的监控周期。

根据历史cpu使用率过高的监控时间段或者监控时间点设置多个监控时间段及多个监控时间点检测监控对象的cpu使用率，这些监控时间段或者监控时间点是用户应用比较频繁的时间段或者时间点，用户应用频繁时会使得cpu使用率过高，因而仅需检测所设定的监控时间段或监控时间点即可，而非实时处于监控状态检测监控对象的cpu使用率从而造成系统资源的浪费。

本实施例中，所述获取当前监控周期内的监控对象的cpu使用率包括：

1)当系统处于可用状态时，获取监控对象当前运行的应用程序的进程信息。

在本实施例中，所述系统包括可用状态及不可用状态。

所述可用状态是指系统处于运行状态。

所述不可用状态是指系统处于死机状态或者关机状态等。

当所述系统处于可用状态时，系统才需要在监控周期内对所述监控对象的cpu使用率进行监控。

在本实施例中，可以通过调用操作系统命令(例如ps命令)采集监控对象当前运行的应用程序的进程信息。

应用程序的进程信息可以包括应用程序进程的进程标识符(processidentifier，pid)。进程标识符用于区分各个进程。进程标识符可以用数字编号进行标识，如四位的数字编号标识进程标识符。

采集的应用程序的进程信息还可以包括应用程序进程所属的应用程序。一个应用程序包括一个应用程序进程。

可以从所有运行的进程中调取所述rocketmq的所有进程信息。

更进一步的，可以结合预先设定的关键字namesrvstartup和brokerstartup，从所述所有进程信息中获取所述rocketmq进程的pid。

例如：系统采用命令：pid＝`ps-fcjava|grep"$instances"|egrep"namesrvstartup|brokerstartup"|awk'{print$2}'，可以得到运行结果：[root@szc-l0075300rocketmq]#ps-fcjava|grep"rmq_lcloud-config-prd-ins5201"|egrep"namesrvstartup|brokerstartup"|awk'{print$2}'16056，因此，系统可以确定所述rocketmq进程的pid为16056。

2)根据所述进程信息，获取当前监控周期内的监控对象的cpu使用率。

本实施例中，所述根据所述进程信息，获取当前监控周期内的监控对象的cpu使用率包括：

根据所述进程信息的进程标识符，通过top命令调取所述rocketmq进程的资源信息；

从所述rocketmq进程的资源信息中获取当前监控周期内的监控对象的cpu使用率。

所述进程信息可以包括多个字段，每个字段对应一个进程信息，每个字段包括一个字段名，可以根据字段名获取所述进程标识符。例如，进程标识符在所述进程信息中的字段名为pid，则获取字段名为pid的字段，即得到所述进程标识符。

所述rocketmq进程的资源信息可以包括cpu使用率、内存使用率等。

102：判断所述监控对象的cpu使用率是否满足第一报警条件。

本实施例中，所述第一报警条件可以包括cpu使用率超过预设cpu使用率阈值。

所述判断所述监控对象的cpu使用率是否满足第一报警条件可以是判断所述监控对象的cpu使用率是否超过所述预设cpu使用率阈值。

预设cpu使用率阈值为预先设定的cpu使用率临界值(例如，80％)，该临界值表示所述监控对象运行的最佳状态。当所述监控对象的cpu使用率超过预先设定的cpu使用率阈值时，表明所述监控对象当前运行的应用程序较多，所述监控对象负荷较重，所述监控对象的cpu使用率满足第一报警条件；当所述监控对象的cpu使用率没有超过预先设定的cpu使用率阈值时，表明所述监控对象当前运行的应用程序较适中，所述监控对象运行状况较好，无需对所述监控对象的cpu使用率进行报警。

当确定所述监控对象的cpu使用率不满足第一报警条件时，执行103；否则，当确定所述监控对象的cpu使用率满足第一报警条件时，执行104。

103：获取下一个监控周期内的监控对象的cpu使用率。

当确定所述监控对象的cpu使用率不满足第一报警条件时，等待下一个监控周期，在下一个监控周期内获取监控对象的cpu使用率。

104：获取当前监控周期内的所述监控对象的活动session数。

活动session指一个终端用户与交互系统进行通信的时间间隔，通常指从注册入系统到注销系统之间所经过的时间以及如果需要的话，可能还有一定操作空间。session是解决http协议无状态问题的服务端解决方案，它能让客户端和服务端一系列交互动作变成一个完整的事务，能使网站变成一个真正意义上的软件。

由于市面的标准springboot产品通常不会对rocketmq的活动session数进行监控，不合理的使用活动session也会造成cpu使用率较高，而在传统的主机层面，cpu监控仅监控cpu使用率是否过高，并没有监控是否由于不合理的使用了活动session造成的cpu使用率高的问题。

可以通过springboot-monitor.jar包session方法获取当前监控周期内的监控对象的活动session，并统计活动session数。

105：判断当前监控周期内的所述监控对象的活动session数是否满足第二报警条件。

本实施例中，所述判断当前监控周期内的所述监控对象的活动session数是否满足第二报警条件包括：

根据上一个监控周期内的所述监控对象的活动session数，判断当前监控周期内的所述监控对象的活动session数是否满足第二报警条件。

检测每一个监控周期内监控对象的活动session数，并根据监控周期的时间顺序将所检测到的活动session数存储于数据库中，便于根据上一个监控周期检测到的监控对象的活动session数，预测当前监控周期内的监控对象的活动session，进一步的确定出报警条件。

具体的，所述第二报警条件可以为：当前监控周期内的监控对象的活动session数为上一个监控周期内的监控对象的活动session数的预设范围内。

所述监控对象的活动session数的预设范围为大于所述活动session数的第一比例值且小于所述活动session数的第二比例值，其中，第一比例值小于1，第二比例值大于1。

当所述当前监控周期内的监控对象的活动session数介于所述上一个监控周期内的监控对象的活动session数的第一比例值与第二比例值之间时，认为所述当前监控周期内的监控对象的活动session数符合预期，不满足第二报警条件；当所述当前监控周期内的监控对象的活动session数不介于所述上一个监控周期内的监控对象的活动session数的第一比例值与第二比例值之间时，即当所述当前监控周期内的监控对象的活动session数小于所述上一个监控周期内的监控对象的活动session数的第一比例值，或者大于所述上一个监控周期内的监控对象的活动session数的第二比例值时，认为所述当前监控周期内的监控对象的活动session数不符合预期，满足第二报警条件。

当确定当前监控周期内的所述监控对象的活动session数不满足第二报警条件时，执行106；当确定当前监控周期内的所述监控对象的活动session数满足第二报警条件时，执行107。

106：以预设第一报警方式对所述监控对象进行报警。

本实施例中，在当前监控周期内，所述监控对象的cpu使用率超过预设cpu使用率阈值，而该监控对象的活动session数在上一个监控周期内的活动session的预设范围内，表明当前监控周期内所述监控对象的cpu使用率过高，并不是由活动session数引起的，采用预设第一报警方式警报所述监控对象的cpu使用率过高。

所述预设第一报警方式可以是发出警报声、显示报警画面、发送报警消息、发送报警邮件等方式。

107：以预设第二报警方式对所述监控对象进行报警。

本实施例中，在当前监控周期内，所述监控对象的cpu使用率超过预设cpu使用率阈值，而该监控对象的活动session数也不在上一个监控周期内的活动session的预设范围内，表明当前监控周期内所述监控对象的cpu使用率过高，可能是由活动session数引起的，采用预设第二报警方式警报所述监控对象的cpu使用率过高。

所述预设第二报警方式可以是生成监控信息展示界面，在所述监控信息展示界面中展示所述监控对象的活动session数及对应的活动sessionid。

可以通过图表展示所述监控对象的活动session数及对应的活动sessionid。所述图表可以包括折线图、面积图、热力图、饼图、表格等。

在一具体实施例中，可以通过grafana展示所述监控对象的活动session数及对应的活动sessionid。可以通过grafana的采集agent，传送所述监控对象的活动session数及对应的活动sessionid到grafana平台展示。

grafana是一个可视化面板(dashboard)，支持各种图表和布局展示，支持graphite、zabbix、influxdb、prometheus和opentsdb作为数据源。grafana具有以下特性：灵活丰富的图形化选项；可以混合多种风格；支持白天和夜间模式；支持多个数据源。

或者，可以通过highcharts展示所述监控对象的活动session数及对应的活动sessionid。

highcharts是一个用纯javascript编写的一个图表库。highcharts能够很简单便捷的在web网站或是web应用程序添加有交互性的图表。highcharts支持监控平台的各种图例。

进一步的，在所述获取当前监控周期内的所述监控对象的活动session数之后，所述方法还可以包括：

判断当前监控周期内的监控对象的活动session数是否小于预设session数阈值；

当确定当前监控周期内的监控对象的活动session数小于预设session数阈值时，以预设第三报警方式对所述监控对象进行报警。

若当前监控周期内的所述监控对象的活动session数小于预设session数阈值时，认为满足了报警条件；若当前监控周期内的所述监控对象的活动session数大于或者等于预设session数阈值时，认为没有满足报警条件。

通过设先设置最低的session数临界值，在监控周期内的监控对象的活动session数低于最低的session数临界值，尤其是监控周期内的监控对象的活动session数趋于零的情况下，需对监控对象进行报警，避免活动session数过低有可能导致业务暂停或系统出现异常。

综上所述，根据上述基于session数的运维平台性能监控方法，获取监控对象的监控指标，所述监控指标包括：cpu使用率、活动session数；在判断当前监控周期内监控对象的cpu使用率是否满足第一报警条件时，继续判断当前监控周期内的所述监控对象的活动session数是否满足第二报警条件；当确定当前监控周期内的所述监控对象的活动session数不满足第二报警条件时，通过第一报警方式报警提醒运维管理者cpu使用率较高；当确定当前监控周期内的所述监控对象的活动session数满足第二报警条件时，通过第二报警方式报警提醒运维管理者cpu使用率较高是由于不合理的活动session数引起的，进而提示管理者直接查看活动session数以排除故障原因，从而起到快速定位活动session的作用。因传统的运维并没有考虑活动session数不合理时也会引起cpu使用率高的问题，而在高并发的集群中，活动session数很容易出现异常，直接通过检测监控对象的活动session数能有助于运维管理者快速定位问题的根源，便于排查，提升系统运维的效率，降低人工排查的成本。

以上所述，仅是本发明的具体实施方式，但本发明的保护范围并不局限于此，对于本领域的普通技术人员来说，在不脱离本发明创造构思的前提下，还可以做出改进，但这些均属于本发明的保护范围。

下面结合第2至3图，分别对实现上述基于session数的运维平台性能监控方法的电子设备的功能模块及硬件结构进行介绍。

实施例二

图2为本发明基于session数的运维平台性能监控装置较佳实施例中的功能模块图。

在一些实施例中，所述基于session数的运维平台性能监控装置20运行于电子设备中。所述基于session数的运维平台性能监控装置20对session数指标进行监控并根据监控的session数指标进行运维平台的维护。所述基于session数的运维平台性能监控装置20可以包括多个由程序代码段所组成的功能模块。所述基于session数的运维平台性能监控装置20中的各个程序段的程序代码可以存储于存储器中，并由至少一个处理器所执行。

本实施例中，所述基于session数的运维平台性能监控装置20根据其所执行的功能，可以被划分为多个功能模块。所述功能模块可以包括：第一获取模块201、设置模块202、第一判断模块203、第二获取模块204、第二判断模块205、第一报警模块206及第二报警模块207、第三判断模块208及第三警报模块209。本发明所称的模块是指一种能够被至少一个处理器所执行并且能够完成固定功能的一系列计算机程序段，其存储在存储器中。在一些实施例中，关于各模块的功能将在后续的实施例中详述。

第一获取模块201，用于获取当前监控周期内的监控对象的cpu使用率。

本实施例中，可以由监控系统监控周期内的监控对象的cpu使用率。监控系统可以是由多个云产品构成的大规模系统的监控系统，也可以是由少数几个机器构成的服务系统，还可以是单机系统。

监控对象可以是监控系统中的任何对象，例如，可以是物理实体如集群、系统、设备等，可以是软件实体如计算机操作系统、应用进程等，还可以是软硬件一起构成的逻辑实体如虚拟机等。

监控系统监控一个或多个监控对象的监控指标。所述监控指标也称之为监控项，是用于报警判定的指标。

监控系统可以同时检测多个监控对象的多个监控指标。

本实施例中，所述监控指标包括：活动session数、cpu使用率。在其他实施例中，所述监控指标还可以同时包括内存使用率、数据库连接数等。

本实施例中，所述cpu使用率是指运行的程序占用的cpu的百分比，cpu使用率越高，说明同时运行的应用程序越多，cpu使用率越低，说明同时运行的应用程序越少。cpu使用率过高时会影响系统性能，导致系统运行缓慢，响应周期变长。

所述监控周期是指预先设定的监控时间段或者预先设定的监控时间点。

所述监控时间段是一个时间周期，例如，当天的上午10点-12点，或者当天的下午3点-5点，或者每隔两个小时。

所述监控时间点是一个具体的时间点，例如，当天的上午10点，或者当天晚上的10点，或者每一个整点，如1点，2点，3点等。

在一些实施例中，还可以预先设定多个监控时间段，例如，上午10点-12点，及当天的下午3点-5点，在每一个监控时间段内检测监控对象的cpu使用率。

在一些实施例中，还可以预先设定多个监控时间点，当天的上午10点，及当天晚上的10点，在每一个监控时间点时检测监控对象的cpu使用率。

在一些实施例中，所述监控周期还可以同时包括多个监控时间段及多个监控时间点。

设置模块202，用于根据历史监控周期内的cpu使用率设置当前监控周期。

具体的，所述设置模块203根据历史监控周期内的cpu使用率设置当前监控周期包括：

获取历史监控周期对应的cpu使用率；

获取所述cpu使用率高于预设cpu使用率阈值的目标cpu使用率；

获取所述目标cpu使用率对应的监控时间段或者监控时间点；

将所述监控时间段或者监控时间点设置为当前的监控周期。

根据历史cpu使用率过高的监控时间段或者监控时间点设置多个监控时间段及多个监控时间点检测监控对象的cpu使用率，这些监控时间段过间断或者监控时间点是用户应用比较频繁的时间段或者时间点，用户应用频繁时会使得cpu使用率过高，因而仅需检测所设定的监控时间段或监控时间点即可，而非实时处于监控状态检测监控对象的cpu使用率从而造成系统资源的浪费。

本实施例中，所述获取当前监控周期内的监控对象的cpu使用率包括：

1)当系统处于可用状态时，获取监控对象当前运行的应用程序的进程信息。

在本实施例中，所述系统包括可用状态及不可用状态。

所述可用状态是指系统处于运行状态。

所述不可用状态是指系统处于死机状态或者关机状态等。

当所述系统处于可用状态时，系统才需要在监控周期内对所述监控对象的cpu使用率进行监控。

在本实施例中，可以通过调用操作系统命令(例如ps命令)采集监控对象当前运行的应用程序的进程信息。

应用程序的进程信息可以包括应用程序进程的进程标识符(processidentifier，pid)。进程标识符用于区分各个进程。进程标识符可以用数字编号进行标识，如四位的数字编号标识进程标识符。

采集的应用程序的进程信息还可以包括应用程序进程所属的应用程序。一个应用程序包括一个应用程序进程。

可以从所有运行的进程中调取所述rocketmq的所有进程信息。

更进一步的，可以结合预先设定的关键字namesrvstartup和brokerstartup，从所述所有进程信息中获取所述rocketmq进程的pid。

例如：系统采用命令：pid＝`ps-fcjava|grep"$instances"|egrep"namesrvstartup|brokerstartup"|awk'{print$2}'，可以得到运行结果：[root@szc-l0075300rocketmq]#ps-fcjava|grep"rmq_lcloud-config-prd-ins5201"|egrep"namesrvstartup|brokerstartup"|awk'{print$2}'16056，因此，系统可以确定所述rocketmq进程的pid为16056。

2)根据所述进程信息，获取当前监控周期内的监控对象的cpu使用率。

本实施例中，所述根据所述进程信息，获取当前监控周期内的监控对象的cpu使用率包括：

根据所述进程信息的进程标识符，通过top命令调取所述rocketmq进程的资源信息；

从所述rocketmq进程的资源信息中获取当前监控周期内的监控对象的cpu使用率。

所述进程信息可以包括多个字段，每个字段对应一个进程信息，每个字段包括一个字段名，可以根据字段名获取所述进程标识符。例如，进程标识符在所述进程信息中的字段名为pid，则获取字段名为pid的字段，即得到所述进程标识符。

所述rocketmq进程的资源信息可以包括cpu使用率、内存使用率等。

第一判断模块203，用于判断所述监控对象的cpu使用率是否满足第一报警条件。

本实施例中，所述第一报警条件可以包括cpu使用率超过预设cpu使用率阈值。

所述判断所述监控对象的cpu使用率是否满足第一报警条件可以是判断所述监控对象的cpu使用率是否超过所述预设cpu使用率阈值。

预设cpu使用率阈值为预先设定的cpu使用率临界值(例如，80％)，该临界值表示所述监控对象运行的最佳状态。当所述监控对象的cpu使用率超过预先设定的cpu使用率阈值时，表明所述监控对象当前运行的应用程序较多，所述监控对象负荷较重，所述监控对象的cpu使用率满足第一报警条件；当所述监控对象的cpu使用率没有超过预先设定的cpu使用率阈值时，表明所述监控对象当前运行的应用程序较适中，所述监控对象运行状况较好，无需对所述监控对象的cpu使用率进行报警。

第一获取模块201，还用于当所述第一判断模块203确定所述监控对象的cpu使用率不满足第一报警条件时，获取下一个监控周期内的监控对象的cpu使用率。

当确定所述监控对象的cpu使用率不满足第一报警条件时，等待下一个监控周期，在下一个监控周期内获取监控对象的cpu使用率。

第二获取模块204，用于当所述第一判断模块204确定所述监控对象的cpu使用率满足第一报警条件时，获取当前监控周期内的所述监控对象的活动session数。

活动session指一个终端用户与交互系统进行通信的时间间隔，通常指从注册入系统到注销系统之间所经过的时间以及如果需要的话，可能还有一定操作空间。session是解决http协议无状态问题的服务端解决方案，它能让客户端和服务端一系列交互动作变成一个完整的事务，能使网站变成一个真正意义上的软件。

由于市面的标准springboot产品通常不会对rocketmq的活动session数进行监控，不合理的使用活动session也会造成cpu使用率较高，而在传统的主机层面，cpu监控仅监控cpu使用率是否过高，并没有监控是否由于不合理的使用了活动session造成的cpu使用率高的问题。

可以通过springboot-monitor.jar包session方法获取当前监控周期内的监控对象的活动session，并统计活动session数。

第二判断模块205，用于判断当前监控周期内的所述监控对象的活动session数是否满足第二报警条件。

本实施例中，所述第二判断模块205判断当前监控周期内的所述监控对象的活动session数是否满足第二报警条件包括：

根据上一个监控周期内的所述监控对象的活动session数，判断当前监控周期内的所述监控对象的活动session数是否满足第二报警条件。

检测每一个监控周期内监控对象的活动session数，并根据监控周期的时间顺序将所检测到的活动session数存储于数据库中，便于根据上一个监控周期检测到的监控对象的活动session数，预测当前监控周期内的监控对象的活动session，进一步的确定出报警条件。

具体的，所述第二报警条件可以为：当前监控周期内的监控对象的活动session数为上一个监控周期内的监控对象的活动session数的预设范围内。

所述监控对象的活动session数的预设范围为大于所述活动session数的第一比例值且小于所述活动session数的第二比例值，其中，第一比例值小于1，第二比例值大于1。

当所述当前监控周期内的监控对象的活动session数介于所述上一个监控周期内的监控对象的活动session数的第一比例值与第二比例值之间时，认为所述当前监控周期内的监控对象的活动session数符合预期，不满足第二报警条件；当所述当前监控周期内的监控对象的活动session数不介于所述上一个监控周期内的监控对象的活动session数的第一比例值与第二比例值之间时，即当所述当前监控周期内的监控对象的活动session数小于所述上一个监控周期内的监控对象的活动session数的第一比例值，或者大于所述上一个监控周期内的监控对象的活动session数的第二比例值时，认为所述当前监控周期内的监控对象的活动session数不符合预期，满足第二报警条件。

第一报警模块206，用于当所述第二判断模块205确定当前监控周期内的所述监控对象的活动session数不满足第二报警条件时，以预设第一报警方式对所述监控对象进行报警。

本实施例中，在当前监控周期内，所述监控对象的cpu使用率超过预设cpu使用率阈值，而该监控对象的活动session数在上一个监控周期内的活动session的预设范围内，表明当前监控周期内所述监控对象的cpu使用率过高，并不是由活动session数引起的，采用预设第一报警方式警报所述监控对象的cpu使用率过高。

所述预设第一报警方式可以是发出警报声、显示报警画面、发送报警消息、发送报警邮件等方式。

第二报警模块207，用于当所述第二判断模块205确定当前监控周期内的所述监控对象的活动session数满足第二报警条件时，以预设第二报警方式对所述监控对象进行报警。

本实施例中，在当前监控周期内，所述监控对象的cpu使用率超过预设cpu使用率阈值，而该监控对象的活动session数也不在上一个监控周期内的活动session的预设范围内，表明当前监控周期内所述监控对象的cpu使用率过高，可能是由活动session数引起的，采用预设第二报警方式警报所述监控对象的cpu使用率过高。

所述预设第二报警方式可以是生成监控信息展示界面，在所述监控信息展示界面中展示所述监控对象的活动session数及对应的活动sessionid。

可以通过图表展示所述监控对象的活动session数及对应的活动sessionid。所述图表可以包括折线图、面积图、热力图、饼图、表格等。

在一具体实施例中，可以通过grafana展示所述监控对象的活动session数及对应的活动sessionid。可以通过grafana的采集agent，传送所述监控对象的活动session数及对应的活动sessionid到grafana平台展示。

grafana是一个可视化面板(dashboard)，支持各种图表和布局展示，支持graphite、zabbix、influxdb、prometheus和opentsdb作为数据源。grafana具有以下特性：灵活丰富的图形化选项；可以混合多种风格；支持白天和夜间模式；支持多个数据源。

或者，可以通过highcharts展示所述监控对象的活动session数及对应的活动sessionid。

highcharts是一个用纯javascript编写的一个图表库。highcharts能够很简单便捷的在web网站或是web应用程序添加有交互性的图表。highcharts支持监控平台的各种图例。

进一步的，所述基于session数的运维平台性能监控装置还可以包括：第三判断模块208，用于判断当前监控周期内的监控对象的活动session数是否小于预设session数阈值；第三报警模块209，用于当第三判断模块208确定当前监控周期内的监控对象的活动session数小于预设session数阈值时，以预设第三报警方式对所述监控对象进行报警。

若当前监控周期内的所述监控对象的活动session数小于预设session数阈值时，认为满足了报警条件；若当前监控周期内的所述监控对象的活动session数大于或者等于预设session数阈值时，认为没有满足报警条件。

通过设先设置最低的session数临界值，在监控周期内的监控对象的活动session数低于最低的session数临界值，尤其是监控周期内的监控对象的活动session数趋于零的情况下，需对监控对象进行报警，避免活动session数过低有可能导致业务暂停或系统出现异常。

综上所述，根据上述基于session数的运维平台性能监控装置，获取监控对象的监控指标，所述监控指标包括：cpu使用率、活动session数；在判断当前监控周期内监控对象的cpu使用率是否满足第一报警条件时，继续判断当前监控周期内的所述监控对象的活动session数是否满足第二报警条件；当确定当前监控周期内的所述监控对象的活动session数不满足第二报警条件时，通过第一报警方式报警提醒运维管理者cpu使用率较高；当确定当前监控周期内的所述监控对象的活动session数满足第二报警条件时，通过第二报警方式报警提醒运维管理者cpu使用率较高是由于不合理的活动session数引起的，进而提示管理者直接查看活动session数以排除故障原因，从而起到快速定位活动session的作用。因传统的运维并没有考虑活动session数不合理时也会引起cpu使用率高的问题，而在高并发的集群中，活动session数很容易出现异常，直接通过检测监控对象的活动session数能有助于运维管理者快速定位问题的根源，便于排查，提升系统运维的效率，降低人工排查的成本。

上述以软件功能模块的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机电子设备(可以是个人计算机，双屏电子设备，或者网络电子设备等)或处理器(processor)执行本发明各个实施例所述方法的部分。

实施例三

图3为本发明实施例三提供的电子设备的示意图。

所述电子设备3包括：存储器31、至少一个处理器32、存储在所述存储器31中并可在所述至少一个处理器32上运行的计算机程序33及至少一条通讯总线34。

所述至少一个处理器32执行所述计算机程序33时实现上述基于session数的运维平台性能监控方法实施例中的步骤。

示例性的，所述计算机程序33可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器31中，并由所述至少一个处理器32执行。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序33在所述电子设备3中的执行过程。

所述电子设备3可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算电子设备。本领域技术人员可以理解，所述示意图3仅仅是电子设备3的示例，并不构成对电子设备3的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述电子设备3还可以包括输入输出电子设备、网络接入电子设备、总线等。

所述至少一个处理器32可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。该处理器32可以是微处理器或者该处理器32也可以是任何常规的处理器等，所述处理器32是所述电子设备3的控制中心，利用各种接口和线路连接整个电子设备3的各个部分。

所述存储器31可用于存储所述计算机程序33和/或模块/单元，所述处理器32通过运行或执行存储在所述存储器31内的计算机程序和/或模块/单元，以及调用存储在存储器31内的数据，实现所述电子设备3的各种功能。所述存储器31可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据电子设备3的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器31可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(smartmediacard，smc)，安全数字(securedigital，sd)卡，闪存卡(flashcard)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

所述电子设备3集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

在本发明所提供的几个实施例中，应该理解到，所揭露的服务器和方法，可以通过其它的方式实现。例如，以上所描述的服务器实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

另外，在本发明各个实施例中的各功能单元可以集成在相同处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在相同单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能模块的形式实现。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或，单数不排除复数。系统权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

最后应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或等同替换，而不脱离本发明技术方案的精神范围。