CN106100868B - 一种项目运维管理装置、系统及方法 - Google Patents

Abstract

本发明公开了一种项目运维管理装置、系统及方法，所述装置包括：应用配置模块，用于分别为各实际项目创建对应的运维项目，并将各实际项目的应用服务器添加为对应的运维项目的待监控服务器；项目管理模块，用于通过监控服务器获取到各运维项目下待监控服务器的运维数据，并以运维项目为单位对其下的所述运维数据进行管理。其有益效果是实现以项目为单位对各实际项目的监控管理，让运维管理人员可以在排出其他项目干扰的情况下，清楚地了解该实际项目下各应用服务器的运行状况，这不仅使公司各项目的管理更方便，同时也减轻了运维管理人员的负担，有利于实现资源的优化配置。

Description

一种项目运维管理装置、系统及方法

技术领域

本发明涉及网络通信技术领域，更具体地说，涉及一种项目运维管理装置、系统及方法。

背景技术

随着公司项目的增多，用于部署各个系统的应用服务器也不断地增加。为了使这些承载不同业务的应用服务器进行管理，防止各个系统故障，从而带来巨大的经济损失，各个公司都专门开发了针对自己网络系统的运维监控系统，以对本公司的网络系统进行运维监控。

但是现在市面上主流的运维监控系统，都是以应用服务器的类型为监控单位，即根据应用服务器的类型配置监控服务器。例如，公司目前具有A、B、C三个项目，三个项目下的服务器部署情况请参见表1所示：

表1

根据现有监控系统的工作方式，会根据应用服务器的类型配置至少三台不同类型的监控服务器，这三台监控服务器分别用来监控项目A和C的数据库服务器、项目B和C的通用型服务器以及项目A和B的缓存服务器，整个监控系统的显示界面显示的也是所有服务器的列表信息。

这种运维监控方式不利于各个项目的单独监控，因为从实际管理来说，项目A、B、C是三个独立运维的项目，各个运维项目的运维管理人员并不相同，例如A项目的运维监控人员其实只需要了解A项目下的数据库服务器和缓存服务器的运行是否正常，对于其他类型的服务器或者其他项目下各服务器的运行情况并不关心。所以说，现有的运维监管方式单一的以应用服务器类型进行监控，不能对各个项目进行单独监控，不利于管理，加重了运营管理人员的负担，不利于资源的优化配置。

发明内容

本发明要解决的技术问题在于现有的运维监管方式单一的以应用服务器类型进行监控，不能以项目为监控单位对各个项目进行单独的监控，不利于项目管理。针对该技术问题，提供一种项目运维管理装置、系统及方法。

为解决上述技术问题，本发明提供一种项目运维管理装置，包括：

应用配置模块，用于分别为各实际项目创建对应的运维项目，并将各实际项目的应用服务器添加为对应的运维项目的待监控服务器；

项目管理模块，用于通过监控服务器获取到各运维项目下待监控服务器的运维数据，并以运维项目为单位对其下的所述运维数据进行管理。

进一步地，还包括：监控配置模块，用于为各所述运维项目下各类型的待监控服务器分配对应的监控服务器。

进一步地，还包括：项目查询模块，用于根据用户输入查询指令对相应运维项目的运维数据进行查询。

进一步地，所述项目管理模块用于通过监控服务器获取到各所述待监控服务器的运维数据，基于所述运维项目和各所述待监控服务器的类型，对采集到的所述运维数据进行处理。

进一步地，所述项目管理模块用于对采集到的各所述待监控服务器的运维数据进行聚合处理，得到聚合结果；

所述项目运维管理装置还包括结果显示模块，所述显示模块用于基于所述运维项目展示所述聚合结果。

进一步地，还包括：

阈值预设模块，用于为各所述待监控服务器下各类型的运维数据设置对应的告警阈值，所述运维数据包括以下几种中的至少一种：所述待监控服务器的吞吐量、并发量以及网络流量；

所述项目管理模块还用于将采集到的所述运维数据与所述运维数据对应的告警阈值进行比较，当所述运维数据与其对应的告警阈值不匹配，则提出告警。

本发明提供了一种项目运维管理系统，包括如上所述的项目运维管理装置。

本发明提供了一种项目运维管理方法，包括：

分别为各实际项目创建对应的运维项目，并将各实际项目的应用服务器添加为对应的运维项目的待监控服务器；

通过监控服务器获取到各运维项目下待监控服务器的运维数据，并以运维项目为单位对其下的所述运维数据进行管理。

进一步地，还包括根据用户输入查询指令对相应的运维项目的运维数据进行查询。

进一步地，所述通过监控服务器获取到各运维项目下待监控服务器的运维数据，并以运维项目为单位对其的所述运维数据进行管理包括：

通过监控服务器获取到各所述待监控服务器的运维数据；

基于所述运维项目和各所述待监控服务器的类型，对采集到的所述运维数据进行处理。

有益效果：本发明提供的项目运维管理装置、系统及方法，通过将各实际项目的应用服务器添加为对应的运维项目的待监控服务器，并利用监控服务器对各运维项目下的各待监控服务器进行监控管理，以项目为单位从各监控服务器获取各项目应用服务器的运维数据，实现以项目为单位对各实际项目的监控管理，让运维管理人员可以在排出其他项目干扰的情况下，清楚地了解该实际项目下各应用服务器的运行状况，这不仅使公司各项目的管理更方便，同时也减轻了运维管理人员的负担，有利于实现资源的优化配置。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1为实现本发明各个实施例的一个可选的服务器的结构示意图；

图2为本发明第一实施例提供的项目运维管理装置的一种结构示意图；

图3为本发明第一实施例提供的项目运维管理装置的另一种结构示意图；

图4为本发明第二实施例中部署项目运维管理装置的层次架构图；

图5为本发明第二实施例提供的项目运维管理装置的一种结构示意图；

图6为本发明第二实施例提供的项目运维管理装置的另一种结构示意图；

图7为本发明第二实施例提供的项目运维管理装置的又一种结构示意图；

图8为本发明第三实施例提供的项目运维管理方法的一种流程图；

图9为本发明第四实施例提供的项目运维管理方法的一种流程图；

图10为第四实施例中数据处理的一种流程图；

图11为第四实施例中对数据进行聚合处理的一种流程图；

图12为第四实施例中提供的项目查询一种流程图；

图13为第四实施例中项目运维管理系统的一种组件图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，为实现本发明各个实施例一个可选的服务器的结构示意图，该服务器至少包括：输入输出(IO)总线11、处理器12、存储器13、内存14和通信装置15。其中，

输入输出(IO)总线11分别与自身所属的服务器的其它部件(处理器12、存储器13、内存14和通信装置15)连接，并且为其它部件提供传送线路。

处理器12通常控制自身所属的服务器的总体操作。例如，处理器12执行计算和确认等操作。其中，处理器12可以是中央处理器(CPU)。

通信装置15，通常包括一个或多个组件，其允许自身所属的服务器与无线通信系统或网络之间的无线电通信。

存储器13存储处理器可读、处理器可执行的软件代码，其包含用于控制处理器12执行本文描述的功能的指令(即软件执行功能)。

其中，本发明提供项目运维管理装置中，实现应用配置模块、项目管理模块、监控配置模块、项目查询模块、阈值设置模块等功能的软件代码可存储在存储器13中，并由处理器12执行或编译后执行。毫无疑义的，上述模块可以处理器12中，也可以设置在该处理器12以外的其他器件上。而本发明一些实施例中提及的显示模块可以由显示器来实现，输入输出(IO)总线11将需要展示给用户的查询结果输出到显示器上，由显示器进行显示。

第一实施例

为了使本领域技术人员对本发明的优点和细节更清楚，下面将本发明提供的对项目运维管理装置进行详细说明，如图2：

项目运维管理装置20包括应用配置模块202和项目管理模块204。

假设现在公司新近运营了一个项目A，该项目A规格庞大，面向的用户群体大，一旦A项目的运营不正常，会给用户造成较大的麻烦，同时也会降低用户体验，给公司带来较大的经济损失。为了让该项目A保证正常运营，或者让开发人员在项目A出现异常的时候及时进行补救，需要对项目A进行管理。

在本实施例提供的项目运维管理装置20中，可以先创建一个与实际项目A对应的运维项目A1，创建运维项目A1的目的是为了对实际项目A进行监控。

应用配置模块202将实际项目的应用服务器添加为运维项目的待监控服务器。

实际项目A为了实现其运营目的会部署各种应用服务器，例如通用型服务器、缓存服务器、数据库连接池等。不同类型的应用服务器可能承载着不同的业务，如，缓存服务器能够使用户以更快的速度访问存储在其内部的对象。实际项目A是否能够正常运营，就在于这些应用服务器是否处于正常工作状态。为了监控实际项目A的应用服务器，应用配置模块202会将实际项目A下面的各应用服务器添加为待监控服务器，使这些应用服务器成为运维项目A1监控的对象。

然后项目管理模块204通过监控服务器获取到各运维项目下待监控服务器的运维数据，并以运维项目为单位对各运维项目下的运维数据进行管理。在本实施例中，项目管理模块204能够利用监控服务器获取到某一个运维项目下的各种运维数据，并基于运维项目对这些运维数据进行处理。项目管理模块204利用监控服务器对待监控服务器进行管理是为了实时掌握各待监控服务器的工作状态，例如在需要时，随时调用监控记录进行查看。

项目管理模块204对待监控服务器的管理方式可以包括多种，例如，采集各待监控服务器上的运维数据，并对这些运维数据进行处理分析，以便运维监控人员根据这些运维数据了解实际项目A下各应用服务器的工作状态，从而确定实际项目A是否处于正常运营状态。

在本实施例的一个示例当中，如图3所示，项目运维管理装置20中包括应用配置模块202和项目管理模块204以外，还包括监控配置模块203，监控配置模块203用于根据各待监控服务器的类型，为运维项目分配至少一个监控服务器。

由于现有的监控服务器只能实现对某种类型的应用服务器的监管，所以，在这里，监控配置模块203为运维项目A1配置监控服务器时，还需要考虑各待监控服务器的类型，根据待监控服务器的类型配置对应的监控服务器，如果运维项目A1下待监控服务器的类型有两种，所以就至少要配置至少两台监控服务器。进一步的，由于监控服务器的监控能力有限，所以如果运维项目A1下其中一种类型的待监控服务器的数量较大，一台监控服务器无法同时监控到这么多的待监控服务器，这种情况下，在同一个运维项目下，针对同一类型的待监控服务器可能也会设置多台监控服务器。

如果未来一种监控服务器能够同时监控多种类型的待监控服务器，那么监控配置模块203在为运维项目配置监控服务器时也不需要再考虑待监控服务器的类型了。

在上述示例当中，为各个待监控服务器分配监控服务器的原则是以项目为单位的，但是在本实施例的另外一种示例当中，可以不必单独为每一个运维项目分配监控服务器，也就是说一个类型的监控服务器可以同时监控多个运维项目的下的待监控服务器，例如监控服务器X专门用于对x类型的待监控服务器进行监控，那么监控服务器X可以同时对多个运维项目下的x类型待监控服务器进行监控。虽然这种监控服务器的部署方式类似于现有的部署方式，但是在后续对数据的管理方式上与现有技术中的存在较大的差别。在后续的监控管理过程中，监控服务器X在采集各个待监控服务器上的运维数据的时候，需要将不同运维项目下的运维数据进行分别存储。

为了更清楚地阐释该示例的细节，请参照表1，在表1当中，实际项目A、B、C下面分别部署有不同的应用服务器，对应这三个实际项目，有三个运维项目A1、B1、C1，运维项目A1中有两台待监控服务器，分别是数据库服务器和缓存服务器，运维项目B1中则有一台通用型服务器和一台缓存服务器，而对应的，运维项目C1中有一台数据库服务器和一台通用型服务器。由于监控服务器的监控能力可能会比较好，但是在该示例当中每个项目下，每个类型的待监控服务器的数量都很少，所以如果继续基于运维项目为各个待监控服务器配置对应的监控服务器，那就很容易造成资源浪费的情况。就拿缓存服务器来说，在运维项目A1和运维项目B1中都存在缓存服务器，所以如果基于运维项目进行分配，那么在该示例中，仅是监控缓存服务器的监控服务器就需要两台。而事实上，可能一台监控服务器就可以监控多台缓存服务器，因此，在这种情况下，如果再基于运维项目进行监控服务器的分配就增加了运维监控的成本，不利于资源的优化配置。

在这种情况下，可以针对运维项目A1和C1分配一台专门监管数据库服务器的监控服务器，而针对B1和C1通用型服务器，也可以分配一台对应的监控服务器，同理，也可以仅分配一台对应的监控服务器来监控运维项目A1和B1的缓存服务器。当监控数据库服务器的监控服务器在采集运维数据的时候，可以将运维项目A1的运维数据存储到第一路径下，将运维项目C1的运维数据存储到第三路径下。同理，另外两台监控服务器也可以采用这样的工作方式，这样，当需要对各实际项目进行统计管理的时候，可以分别在各个运维项目保存运维数据的路径下去获取数据并进行处理，展示给用户，让用户获取实际项目的运维情况。

在本实施例中，应用配置模块202的功能可以由图1中的处理器12来实现，处理器12还可以实现项目管理模块204的功能：当处理器12为各个待监控服务器分配监控服务器之后，处理器12可以通过通信装置15控制监控服务器，让监控服务器采集获取各个待监控服务器上的运维数据。当监控服务器将运维数据采集到以后，可以将数据存储到存储器13上。在后续的过程中，处理器12可以根据用户的需求，例如用户输入的查询指令对这些运维数据进行管理。

本实施例中的项目运维管理装置20，基于单独的实际项目创建对应的运维项目，将实际项目下的各个应用服务器作为运维项目的监控对象，并利用监控配置模块203根据运维项目下各待监控服务器的类型为该运维项目配置对应的监控服务器，使这些监控服务器仅对该运维项目下的待监控服务器进行管理，即仅对相应的实际项目下的各应用服务器进行监控，不会混杂其他实际项目的信息，能够有效的为本实际项目的运维监控人员排出其他项目带来的干扰信息，使该实际项目的运维监控人员能够很容易就获得符合其意愿的信息，进而提高工作效率，降低其工作负担，进一步实现资源的优化配置。

第二实施例

本实施例提供另一种项目运维管理装置，该项目运维管理装置的部署基于如图4所示的架构层次：

项目开发人员、系统维护人员在PC浏览器层401上通过浏览器客户端进行监控资源配置、监控报表查询等操作。

在本实施例中，SLB(Server Load Balancing，服务器负载均衡)层402采用阿里云提供的服务，当采用两台以上阿里云服务器时，即可使用SLB来做负载调度。SLB可以理解为是一台虚拟服务器，虚拟服务器代表的是多个真实服务器的群集，客户端向虚拟服务器发起连接时，通过某种复杂均衡算法，转发到真实服务器。

应用服务器403采用tomcat应用服务器，实现PC客户端与监控服务端交互。

业务管理层404是核心的后台运营管理平台，是管理和维护整个监控系统的控制中心，包括了项目管理、资源管理、监控报表查询、用户管理、权限管理和预警策略等模块。

监控任务中间件405通过定时收集任务实现从被监控的应用服务器上采集运维数据，存储到数据存储层406中NoSQL数据库下的MongoDB中，以便后续的数据监控查询、分析处理。同时当采集的数据达到配置的预警阈值时，会触发预警模块，及时通知相应系统负责人员进行处理。

值得注意的是，按照现有的架构，监控任务中间件405应当是被部署到业务管理层404内部的，但是在本实施例中，将监控任务中间件405和业务管理层404分开部署，这样的好处在于：现有的架构中，监控任务中间件405在业务管理层404内部，而监控任务中间件405的监控能力有限，所以整个业务管理层404能够管理监控的应用服务器的数量也具有最大上限，而在本实施例中，将监控任务中间件405分开部署，当待监控的应用服务器的数量超出一个监控任务中间件405的监控能力，只需要再添加一个新的监控任务中间件405即可，可以说，在这种新的部署下，监控应用服务器的数量几乎没有上限。

数据存储层406上采用阿里云的RDS来提供关系型数据库Mysql和NoSQL数据库，在NoSQL数据库下包括MongoDB。

操作系统407上的测试与生产环境都采用CentOS 7的64位版本的操作系统。

在本实施例中，如图5所示，项目运维管理装置20除了包括应用配置模块202、监控配置模块203和项目管理模块204以外，还包括人员分配模块201，人员分配模块201用于为运维项目配置关联人员。

一个运维项目会有对应的关联人员，这里的关联人员包括该运维项目对应的实际项目的开发人员，当创建运维项目后，可以选择录入对应实际项目的开发人员的信息，录入的信息一般包括姓名、联系电话、个人邮箱等。录入关联人员的信息主要是为了能够在运维项目对应的实际项目出现故障或异常的情况下，能够第一时间通知到这些开发人员，使他们抵达事故现场进行故障处理，避免损失扩大。

在创建与实际项目相对应的运维项目后，人员分配模块201为该运维项目分配运维管理人员，虽然一般运维管理人员都是从该运维项目的关联人员中选择出来的。但是运维管理人员与关联人员还是有区别的，运维管理人员具有登录查看并管理运维项目的权限，是在运维项目监控实际项目过程中的作业人员。而对于一个运维项目而言，关联人员是在对应的实际项目出现异常后必要的作业人员，而在运维监控过程中，关联人员并不需要承担很多的工作。

在本实施例中提供的一种较好的示例中，项目处理模块204还利用监控服务器采集各个待监控服务器上的数据，并将采集到的数据存储到本地数据库。项目处理模块204采集数据的方式可以是由运维监控人员在前端提出数据采集要求后，监控服务器根据具体要求进行采集。考虑到运维项目下待监控服务器的数量可能较多，各待监控服务器上的数据每时每刻都会发生变化，而每一个变化都可能会引起待监控服务器的异常，但运维监控人员不可能随时都发出采集数据的指令，所以这里提出一种较理想的实现方式，让项目处理模块204采用定时采集数据的方式，即预先设置定时时长，然后由监控服务器根据定时时长去自动采集各待监控服务器上的运维数据，例如，项目处理模块204需要利用监控服务器采集3台待监控服务器上的运维数据，监控服务器采集运维数据的定时时长被预先设置为5秒，则项目处理模块204会控制监控服务器每5秒去采集一次各缓存服务器的数据，并将采集到的数据存储到本地的数据库中。

可以理解的是，在上述示例中，所提到的“3台”“5秒”等都只是为了让本领域技术人员更容易理解本发明提供的项目运维管理装置，并非实现发明的必要限定。

项目处理模块204还能基于运维项目和各待监控服务器的类型，对采集到的运维数据进行处理。

由于项目处理模块204控制监控服务器采集数据是以待监控服务器为单位进行的，所以监控服务器采集到运维数据都是对应于每一台待监控服务器的，而在一个实际项目中，需要了解的并不是某一台应用服务器的状态，而是整个实际项目整体的运营情况，为了让运维监控人员随时都能了解一个运维项目的整体情况，在这里，推荐让项目处理模块204根据MapReduce算法对采集到的待监控服务器的运维数据进行聚合处理得到聚合结果。

MapReduce合并了两种经典函数，即映射(Mapping)与化简(Reducing)。映射对集合里的每个目标应用同一个操作，例如，当需要把表单里每个单元格乘以二，那么把这个函数单独地应用在每个单元格上的操作就属于Mapping。化简遍历集合中的元素来返回一个综合的结果，即，输出表单里一列数字的和这个任务属于Reducing。

项目处理模块204可以将采集到的各类型待监控服务器的运维数据进行汇总。在实际项目下，同一类型的子业务由同一类型的应用服务器承载着，对应的，一个运维项目下，仅是某种类型的待监控服务器就会有多台。所以，从实际管理层面来说，从同一类型的待监控服务器上采集到的数据应当被存储在一起，便于整体分析。因此，在MapReduce任务中，需要项目处理模块204将同一类型的待监控服务器的运维数据汇总到一起。

一般而言，MapReduce任务也是以定时的方式进行，相对定时数据采集任务而言，MapReduce任务的定时时长更长，例如数据采集的定时时长可能是5秒或10秒，而MapReduce任务则可能是每半个小时进行一次。在一次MapReduce任务中，汇总的运维数据包含了所有历史数据，而在此之前，例如半个小时以前，已经对半小时之前的数据进行过聚合处理了，故，本次聚合处理的对象主要为近30分钟内采集到的运维数据。了解上一次进行MapReduce任务的时间后就可以获知哪些运维数据是还未进行聚合处理的，即哪些运维数据是本次MapReduce任务的处理对象。

根据MapReduce算法进行处理，并得到聚合结果。MapReduce算法中有一个键值key，不同的键值key可以表征不同的监控管理要求，当进行MapReduce处理时，可以根据当前的监控要求确定出key值，然后利用MapReduce算法对数据进行处理，得到小时报表、日报表等。

将聚合结果存储到数据库中，并记录本次MapReduce处理的时间。为了便于运维监控人员获知其他关联人员在需要时查看运维项目的历史运维情况，这里将聚合结果存储到数据库中，数据库可以是MongoDB数据库。MongoDB数据库属于数据存储层中的NoSQL数据库，NoSQL泛指非关系型的数据库。为了使下一次进行MapReduce处理时，也能确定出哪些数据是没有进行过聚合处理的，所以在完成MapReduce处理后，还应该把本次进行MapReduce任务的时间记录下来。

在本实施例的另外一种示例当中，如图6所示，项目运维管理装置20包括应用配置模块202、项目管理模块204。

由于一个公司下可能有多个实际项目在同时运营，所以为了方便包括公司高层人员在内的用户能够随时查看某个实际项目下某个子业务的运营情况，这里项目运维管理装置20中还设置项目查询模块205。

项目查询模块205为用户提供查询服务，当用户需要使用项目查询功能时，启动后台的监控系统，然后从公司下面的多个实际项目中选择一个进行查询监控，并进入该实际项目相应的运维项目。若现在用户想要查询实际项目A，则选择进行入与实际项目A相应的运维项目A1中。进一步从运维项目A1中根据需要选择要查询的子目录，例如查询虚拟机运营情况、缓存服务器运营情况等。用户可以根据自己的需要自定义查询的时间区域。当用户不需要自定义查询时间区域时，也可以由项目运维管理装置返回默认的时间区域，并根据系统默认的查询时间进行，例如默认时间区域是近60分钟，当前时间为15：00，则当前默认的时间区域为14:00-15:00。项目查询模块按照指定的时间区域，选择相应的监控报表。并查询指定时间区域内该子目录下各运维数据。最后将原始数据进行封装，使用图表控件展示相应运维数据的内容。图表化的展示方式能够让用户更加直观的了解查询结果，在短时间内弄清楚子目录的运维情况，让用户避免了从大量运维数据中寻找有用信息的繁杂工作。同时，由处理器对数据进行处理也避免了人为因素带来的错误或其他误差。

项目查询模块205功能的实现可以通过图1中的输入输出(IO)总线11接收用户的指令，然后将用户指令输入到处理器12当中，处理器12解析用户的指令，并从存储器13中提取出相应的运维数据，然后对运维数据进行处理。在本实施例的一种示例当中，项目运维管理装置还可以包括显示模块，显示模块可以将结果展示给用户，显示模块展示查询结果的时候可以基于运维项目进行图表化的展示。不过本领域技术人员能够明白的是，除了图表化的展示方式以外，还可以对查询结果进行语音播报等方式的展示。

如图7所示，本实施例提供的项目运维管理装置20中，除了包括第一实施例中的人员分配模块201、应用配置模块202、监控配置模块203、项目管理模块204及项目查询模块205以外，还包括阈值预设模块206，阈值预设模块206用于为各待监控服务器下各类型的运维数据设置对应的告警阈值。

这里所说的运维数据的类型包括待监控服务器的吞吐量、并发量以及网络流量等。应用服务器的吞吐量即其承压能力，吞吐量与请求request对CPU的消耗、外部接口、I/O((Input/Output，输入/输出)等紧密关联。应用服务器的并发量是指同一时间访问的人数，人数越多，瞬间带宽要求更高。一般应用服务器都限制了瞬时最高流量，因此，一个待监控服务器在某一时刻能够接受访问的人次是基本固定的，这便是该待监控服务器的最高并发量，一旦在某一时刻出现访问量激增、瞬时并发量超过该待监控服务器所能承受的最高并发量，就有可能引起应用服务器崩溃。因此，阈值预设模块206为并发量设置的告警阈值可能会比该待监控服务器所能承受的最高并发量稍微低一点，以保证在待监控服务器崩溃之前就让运维监控人员了解情况，并做出相应的调控，避免该待监控服务器崩溃。阈值预设模块206为各个待监控服务器设置对应的告警阈值后，当待监控服务器的某一运维数据超出对应的告警阈值之后，系统可以自动地可以向该运维项目对应的运维监控人员发出告警，而不需要运维管理人员实时地对所有运维数据进行人工比对分析，这样能够有效地节约人力成本。

毫无疑义的是，阈值预设模块206并不需要为所有待监控服务器的全部运维数据都设置告警阈值，例如，有的待监控服务器并没有限定瞬时最高流量，在这种情况下就不需要为并发量设置最高阈值。所以在一些场景下，阈值预设模块206为待监控服务器的运维数据设置告警阈值时，可以只是选择其中部分运维数据进行设置，例如仅设置吞吐量和并发量两种。

在图7所示的项目运维管理装置20中，项目处理模块204还用于判断采集到的运维数据与阈值预设模块206预设的对应告警阈值是否匹配。

项目处理模块204采集到待监控服务器的运维数据之后，需要确定该运维数据的值表征的是待监控服务器下哪种参数类型的当前情况。例如该运维数据是该待监控服务器的吞吐量还是并发量。进一步地，由于为待监控服务器的运维数据设置告警阈值的时候，并没有要求为所有的所有类型的运维数据都设置告警阈值，因此可能有部分运维数据并没有告警阈值，所以在确定运维数据对应的类型后还要进一步判断该类型的运维数据是否设置了对应的告警阈值。当对采集到的运维数据设置了数据告警阈值时，项目处理模块204需要根据该告警阈值判断判断运维数据与告警阈值是否匹配。这里所说的匹配是指运维数据的值在告警阈值所限定的范围内，若并发量的告警阈值所限定的范围是小于或等于1000，当前采集到的并发量的运维数据为1150，那么很显然该运维数据与告警阈值并不匹配。

若当前采集到的运维数据与对应的告警阈值不匹配，那么项目处理模块204需要向运维监控人员提出告警，提示运维监控人员对当前状态做出调整，避免对应的待监控服务器因承载压力过大而崩溃。若是采集到的运维数据不仅是与对应的告警阈值不匹配，而是显示出该待监控服务器已经崩溃了，这时候的告警对象也应当有所调整，因为这时候需要该运维项目的关联人员，即实际项目的开发人员，到现场对已故障的待监控服务器进行处理。

可以理解的是，上述告警处理流程和查询流程可以同时存在，当待监控服务器的运维数据与告警阈值不匹配时，运维监控人员能够第一时间获知消息，其他时间内，运维监控人员或其他用户可以方便地对运维项目进行查询管理，根据图表化展示的信息了解实际项目的运营状况，预测实际项目的发展趋势，提早进行规划部署。

第三实施例

本实施例提供一种项目运维管理方法，请参考图8：

假设现在公司新近运营了一个项目A，该项目A规格庞大，面向的用户群体大，一旦A项目的运营不正常，会给用户造成较大的麻烦，同时也会降低用户体验，给公司带来较大的经济损失。为了让该项目A保证正常运营，或者让开发人员在项目A出现异常的时候及时进行补救，所以现在需要对项目A进行管理。

根据本实施例提供的项目运维管理方法，首先创建一个与该项目A对应的运维项目A1，运维项目A1与实际项目A对应，创建运维项目A1的目的即是为了对实际项目A进行监控。

S802、分别为各实际项目创建对应的运维项目，并将各实际项目的应用服务器添加为对应的运维项目的待监控服务器。

实际项目A为了实现其运营目的会部署各种应用服务器，例如通用型服务器、缓存服务器、数据库连接池等。不同类型的应用服务器可能承载着不同的业务，如，缓存服务器能够使用户以更快的速度访问存储在其内部的对象。实际项目A是否能够正常运营，就在于这些应用服务器是否处于正常工作状态。运维项目A1为了监控实际项目A的应用服务器，会将实际项目A下面的各应用服务器添加为待监控服务器，使这些应用服务器成为其监控的对象。

S804、通过监控服务器获取到各运维项目下待监控服务器的运维数据，并以运维项目为单位对其下的运维数据进行管理。

监控服务器对待监控服务器的管理是为了实时掌握各待监控服务器的工作状态，还可以在需要时，随时调用监控记录进行查看。

监控服务器对待监控服务器的管理动作可以包括多种，例如，采集各待监控服务器上的运维数据，并对这些运维数据进行处理分析，以便运维监控人员根据这些运维数据了解实际项目A下各应用服务器的工作状态，从而确定实际项目A是否处于正常运营状态。

在本实施例的一个示例当中，在利用监控服务器对各运维项目下的各待监控服务器进行监控管理之前，还包括为各运维项目下各类型的待监控服务器分配对应的监控服务器。

由于现有的监控服务器只能实现对某种类型的应用服务器的监管，所以，在这里，为运维项目A1配置监控服务器时，还需要考虑各待监控服务器的类型，根据待监控服务器的类型配置对应的监控服务器，如果运维项目A1下待监控服务器的类型有两种，所以就至少要配置至少两台监控服务器。进一步的，由于监控服务器的监控能力有限，所以如果运维项目A1下其中一种类型的待监控服务器的数量较大，一台监控服务器无法同时监控到这么多的待监控服务器，这种情况下，在同一个运维项目下，针对同一类型的待监控服务器可能也会设置多台监控服务器。

如果未来一种监控服务器能够同时监控多种类型的待监控服务器，那么在为运维项目配置监控服务器时也不需要再考虑待监控服务器的类型了。

在上述示例当中，为各个待监控服务器分配监控服务器的原则是以项目为单位的，但是在本实施例的另外一种示例当中，可以不必单独为每一个运维项目分配监控服务器，也就是说一个类型的监控服务器可以同时监控多个运维项目的下的待监控服务器，例如监控服务器X专门用于对x类型的待监控服务器进行监控，那么监控服务器X可以同时对多个运维项目下的x类型待监控服务器进行监控。虽然这种监控服务器的部署方式类似于现有的部署方式，但是在后续对数据的管理方式上与现有技术中的存在较大的差别。在后续的监控管理过程中，监控服务器X在采集各个待监控服务器上的运维数据的时候，需要将不同运维项目下的运维数据进行分别存储。

为了更清楚地阐释该示例的细节，请参照表1，在表1当中，实际项目A、B、C下面分别部署有不同的应用服务器，对应这三个实际项目，有三个运维项目A1、B1、C1，运维项目A1中有两台待监控服务器，分别是数据库服务器和缓存服务器，运维项目B1中则有一台通用型服务器和一台缓存服务器，而对应的，运维项目C1中有一台数据库服务器和一台通用型服务器。由于监控服务器的监控能力可能会比较好，但是在该示例当中每个项目下，每个类型的待监控服务器的数量都很少，所以如果继续基于运维项目为各个待监控服务器配置对应的监控服务器，那就很容易造成资源浪费的情况。就拿缓存服务器来说，在运维项目A1和运维项目B1中都存在缓存服务器，所以如果基于运维项目进行分配，那么在该示例中，仅是监控缓存服务器的监控服务器就需要两台。而事实上，可能一台监控服务器就可以监控多台缓存服务器，因此，在这种情况下，如果再基于运维项目进行监控服务器的分配就增加了运维监控的成本，不利于资源的优化配置。

在这种情况下，可以针对运维项目A1和C1分配一台专门监管数据库服务器的监控服务器，而针对B1和C1通用型服务器，也可以分配一台对应的监控服务器，同理，也可以仅分配一台对应的监控服务器来监控运维项目A1和B1的缓存服务器。当监控数据库服务器的监控服务器在采集运维数据的时候，可以将运维项目A1的运维数据存储到第一路径下，将运维项目C1的运维数据存储到第三路径下。同理，另外两台监控服务器也可以采用这样的工作方式，这样，当需要对各实际项目进行统计管理的时候，可以分别在各个运维项目保存运维数据的路径下去获取数据并进行处理，展示给用户，让用户获取实际项目的运维情况。

本实施例中的项目运维管理方法，基于单独的实际项目创建对应的运维项目，将实际项目下的各个应用服务器作为运维项目的监控对象，并根据运维项目下各待监控服务器的类型为该运维项目配置对应的监控服务器，使这些监控服务器仅对该运维项目下的待监控服务器进行管理，即仅对相应实际项目下的各应用服务器进行监控，不会混杂其他实际项目的信息，能够有效的为本实际项目的运维监控人员排出其他实际项目带来的干扰信息，使的运维监控人员能够很容易就获得符合其意愿的信息，进而提高工作效率，降低其工作负担，进一步实现资源的优化配置。

第四实施例

为了使本领域技术人员对本发明的优点和细节更清楚，下面将对项目运维管理方法做进一步说明，如图9所示：

S901、创建运维项目。

假设现在公司新近运营了一个项目A，该项目A规格庞大，面向的用户群体大，一旦A项目的运营不正常，会给用户造成较大的麻烦，同时也会降低用户体验，给公司带来较大的经济损失。为了让该项目A保证正常运营，或者让开发人员在项目A出现异常的时候及时进行补救，所以现在需要对项目A进行管理。

根据本实施例提供的项目运维管理方法，首先创建一个与该项目A对应的运维项目A1，运维项目A1与实际项目A对应，创建运维项目A1的目的即是为了对实际项目A进行监控。

S902、为运维项目配置关联人员。

一个运维项目会有对应的关联人员，这里的关联人员包括该运维项目对应的实际项目的开发人员，当创建运维项目后，可以选择录入对应实际项目的开发人员的信息，录入的信息一般包括姓名、联系电话、个人邮箱等。录入关联人员的信息主要是为了能够在运维项目对应的实际项目出现故障或异常的情况下，能够第一时间通知到这些开发人员，使他们抵达事故现场进行故障处理，避免损失扩大。

在创建与实际项目相对应的运维项目后还包括为该运维项目分配运维管理人员，虽然一般运维管理人员都是由超级管理员从该运维项目的关联人员中选择出来的。但是运维管理人员与关联人员还是有区别的，运维管理人员具有登录查看并管理运维项目的权限，是在运维项目监控实际项目过程中的作业人员。而对于一个运维项目而言，关联人员是在对应的实际项目出现异常后必要的作业人员，在运维监控过程中，关联人员并不需要承担很多的工作。

S903、创建子目录，并为各子目录添加对应的待监控服务器。

一个实际项目下可能会部署多种子业务，如缓存业务、数据库业务，这些子业务需要对应的应用服务器来支持，例如缓存业务需要缓存服务器的支持。在运维项目中，对应这些子业务会创建相应的子目录，子目录实现对实际项目中子业务下各应用服务器的监控，支持各子业务的应用服务器就是在各子目录下的待监控服务器。

S904、为各待监控服务器下各类型的运维数据设置对应的告警阈值。

这里所说的运维数据的类型包括待监控服务器的吞吐量、并发量以及网络流量等。应用服务器的吞吐量即其承压能力，吞吐量与请求request对CPU的消耗、外部接口、I/O((Input/Output，输入/输出)等紧密关联。应用服务器的并发量是指同一时间访问的人数，人数越多，瞬间带宽要求更高。一般应用服务器都限制了瞬时最高流量，因此，一个待监控服务器在某一时刻能够接受访问的人次是基本固定的，这便是该待监控服务器的最高并发量，一旦在某一时刻出现访问量激增、瞬时并发量超过该待监控服务器所能承受的最高并发量，就有可能引起应用服务器崩溃。因此，为并发量设置的告警阈值可能会比该待监控服务器所能承受的最高并发量稍微低一点，以保证在待监控服务器崩溃之前就让运维监控人员了解情况，并做出相应的调控，避免该待监控服务器崩溃。各个待监控服务器设置对应的告警阈值后，当待监控服务器的某一运维数据超出对应的告警阈值之后，系统可以自动地可以向该运维项目对应的运维监控人员发出告警，而不需要运维管理人员实时地对所有运维数据进行人工比对分析，这样能够有效地节约人力成本。

毫无疑义的是，并不是所有待监控服务器都必须设置上述全部的运维数据，例如，有的待监控服务器并没有限定瞬时最高流量，在这种情况下就不需要为并发量设置最高阈值。所以在一些场景下，为待监控服务器的运维数据设置告警阈值时，可以只是选择其中部分运维数据进行设置，例如仅设置吞吐量和并发量两种。

S905、根据各个待监控服务器的类型为运维项目配置监控服务器。

由于现有的监控服务器只能实现对某种类型的应用服务器的监管，所以，在这里，为运维项目配置监控服务器时，还需要考虑各待监控服务器的类型，根据待监控服务器的类型配置对应的监控服务器，如果运维项目下待监控服务器的类型有两种，所有就至少要配置至少两台监控服务器。进一步的，由于监控服务器的监控能力有限，所以如果运维项目下其中一种类型的待监控服务器的数量较大，一台监控服务器无法同时监控到这么多的待监控服务器，这种情况下，在同一个运维项目下，针对同一类型的待监控服务器可能也会设置多台监控服务器。

如果未来一种监控服务器能够同时监控多种类型的待监控服务器，那么在为运维项目配置监控服务器时也不需要再考虑待监控服务器的类型了。

S906、使用监控服务器对运维项目下各待监控服务器进行管理。

监控服务器对各待监控服务器的管理可以包括多个方面，例如采集各个待监控服务器上的数据，并将采集到的数据存储到本地数据库。采集数据的方式可以是由运维监控人员在前台提出数据采集要求之后，监控服务器才根据具体要求进行采集。考虑到运维项目下待监控服务器的数量可能较多，各待监控服务器上的数据每时每刻都会发生变化，而每一个变化都可能会引起待监控服务器的异常，但运维监控人员不可能随时都发出采集数据的指令，所以这里提出一种较理想的实现方式，采用定时采集数据的方式，及预先设置定时时长，然后由监控服务器根据定时时长去采集其监控的各待监控服务器上的数据，例如，第一监控服务器用于监控管理运维项目A1下的3台缓存服务器，将第一监控服务器采集数据的定时时长预先设置为5秒，则第一监控服务器会每5秒去采集一次各缓存服务器的数据，并将采集到的数据存储到本地的数据库中。

可以理解的是，在上述示例中，所提到的“3台”、“5秒”等都只是为了让本领域技术人员更容易理解本发明提供的项目运维管理方法，并非实现发明的必要限定。

在采集到各待监控服务器上的数据之后，可以对数据进行一定的处理，下面提出两种处理方式。

第一种，判断采集到的运维数据与预设的对应告警阈值是否匹配。请参考图10：

S1001、确定获取到的运维数据属于哪种类型。

监控服务器采集到待监控服务器的运维数据之后，需要确定该运维数据是的值表征的是哪种类型的运维数据的当前情况。例如该运维数据是该待监控服务器的吞吐量还是并发量。

S1002、判断是否对该类型的运维数据设置了告警阈值。

由于在S904中为待监控服务器的运维数据设置告警阈值的时候，并没有要求为所有的运维数据都设置告警阈值，因此可能有部分运维数据对应的运维数据并没有告警阈值，所以在确定运维数据的类型后还要进一步判断该运维数据是否设置了对应的告警阈值。若判断结果为是，则执行S1003，否则跳转至S1004。

S1003、获取运维数据对应的告警阈值，判断获取到的运维数据与告警阈值是否匹配。若判断结果为是，则执行S1004，否则执行S1005。

这里所说的匹配是指运维数据的值在告警阈值所限定的范围内，若并发量的告警阈值所限定的范围是小于或等于1000，当前采集到的并发量的运维数据为1150，那么很显然该运维数据与告警阈值并不匹配。

S1004、将运维数据存储到本地数据库。

将运维数据存储到数据库是为了对数据进行进一步处理分析，或者方便让运维监控人员直接查看，了解与该运维项目对应的实际项目在这一时刻的运转状态。

S1005、向运维监控人员提出告警。

若当前采集到的运维数据与对应的告警阈值不匹配，那么需要向运维监控人员提出告警，提示运维监控人员对当前状态做出调整，避免对应的待监控服务器因承载压力过大而崩溃。若是采集到的运维数据不仅是与对应的告警阈值不匹配，而是显示出该待监控服务器已经崩溃了，这时候的告警对象也应当有所调整，因为这时候需要该运维项目的关联人员，即实际项目的开发人员到现场对故障的待监控服务器进行处理。

对采集到的数据进行第二种方式的处理：

由于数据采集是以待监控服务器为单位进行的，也就是说，采集到数据都是对应于每一台待监控服务器的，而在一个实际项目中，需要了解的并不是某一台应用服务器的状态，而是整个实际项目整体的运营情况，为了运维监控人员随时都能了解一个运维项目的整体情况，在这里，推荐使用MapReduce算法对采集到的待监控服务器的运维数据进行聚合处理得到聚合结果。

MapReduce合并了两种经典函数，即映射(Mapping)与化简(Reducing)。映射对集合里的每个目标应用同一个操作，例如，当需要把表单里每个单元格乘以二，那么把这个函数单独地应用在每个单元格上的操作就属于Mapping。化简遍历集合中的元素来返回一个综合的结果，即，输出表单里一列数字的和这个任务属于Reducing。在本实施例中，对采集到的各待监控服务器的运维数据进行MapReduce处理的流程图请参考图11：

S1101、将采集到的各类型待监控服务器的运维数据进行汇总。

在实际项目下，同一类型的业务由同一类型的应用服务器承载着，对应的一个运维项目下，仅是某种类型的待监控服务器就会有多台。所以，从实际管理层面来说，从同一类型的待监控服务器上采集到的数据应当被存储在一起，便于整体分析。因此，在MapReduce任务中，需要将同一类型的待监控服务器的运维数据汇总到一起。

S1102、根据获取上次进行MapReduce处理的时间确定本次需要进行MapReduce处理的数据。

一般而言，MapReduce任务也是以定时的方式进行，相对定时数据采集任务而言，MapReduce任务的定时时长更长，例如数据采集的定时时长可能是5秒或10秒，而MapReduce任务则可能是每半个小时进行一次。在一次MapReduce任务中，汇总的运维数据包含了所有历史数据，而在此之前，例如半个小时以前，已经对半小时之前的数据进行过聚合处理了，因此，本次聚合处理的对象主要为对近30分钟内采集到的运维数据。所以根据上一次进行MapReduce任务的时间就可以获知哪些数据是还未进行聚合处理的，也就是哪些数据是本次MapReduce任务的处理对象。

S1103、根据MapReduce算法进行处理，并得到聚合结果。

MapReduce算法中有一个键值key，不同的键值key可以表征不同的监控管理要求，当进行MapReduce处理时，可以根据当前的监控要求确定出key值，然后利用MapReduce算法对数据进行处理，得到小时报表、日报表等。

S1104、将聚合结果存储到数据库中，并记录本次MapReduce处理的时间。

为了便于运维监控人员获知其他关联人员在需要时查看运维项目的历史运维情况，这里将聚合结果存储到数据库中，数据库可以是MongoDB数据库。MongoDB数据库属于数据存储层中的NoSQL数据库，NoSQL，泛指非关系型的数据库。为了让下一次进行MapReduce处理时，还能确定出哪些数据是没有进行过聚合处理的，所以在完成MapReduce处理后，还应该把本次进行MapReduce任务的时间记录下来。

一个公司下可能有多个实际项目在同时运营，为了方便包括公司高层人员在内的用户能够随时查看某个实际项目下某个子业务的运营情况，本实施例提供的项目运维管理方法还提供一种项目查询流程，用于根据用户输入查询指令对相应运维项目的运维数据进行查询。如图12所示：

S1201、启动后台监控系统。

当用户需要使用项目查询功能时，启动后台的监控系统，

S1202、选择要进行查询的运维项目。

从公司下面的多个实际项目中选择一个进行查询监控，并进入该实际项目相应的运维项目。若现在用户想要查询实际项目A，则选择进行入与实际项目A相应的运维项目A1中。

S1203、选择要查询的子目录。

进入运维项目后，需要根据需要选择要查询的子目录，即实际项目的子应用。例如查询虚拟机运营情况、缓存服务器运营情况等、

S1204、判断用户是否选择自定义查询时间区域。

若是，则执行S1205，若否，则执行S1206。

S1205、用户自定义时间区域。

若用户选择自定义查询的时间区域，则直接弹出供用户进行输入的窗口。

S1206、返回默认的时间区域。

用户需要自定义查询时间区域时，则根据系统默认的查询时间进行，例如默认时间区域是近60分钟，当前时间为15：00，则当前默认的时间区域为14:00-15:00。

S1207、按照指定的时间区域，选择相应的监控报表。

监控报表，根据MapReduce任务的定时时长，监控报表可以分为不同类型的，例如小时报表、日报表、周报表等，若用户选择了的时间区域的起始点与完结点都是整点，则选择对应的小时报表。若用户选择的时间区域包含非整点，则可能需要选择时长更短的报表。

S1208、查询指定时间区域内该子目录下各类型的运维数据。

运维数据的类型即是实际项目中各子业务的指标信息，包含吞吐量、并发量等信息。

S1209、封装原始数据，使用图表控件展示相应运维数据的内容。

图表化的展示方式能够让用户更加直观的了解查询结果，在短时间内弄清楚子目录的运维情况，让用户避免了从大量运维数据中寻找有用信息的繁杂工作。同时，由装置或系统的处理器对数据进行处理也避免了人为因素带来的错误或其他误差。

本发明还提供一种项目运维管理系统，该项目运维管理系统可以部署在图4所示框架上。在该系统中，可以包括实施例一或第二实施例种的任意一种项目运维管理装置。在实际应用中，其可以依赖如图13所示的各组件来实现：

组件图中可以分为前端组件1301、通用组件1302以及后台组件1303三部分，前端组件1301和后台组件1303分别基于通用组件1302实现各自的功能，通用组件中包括平台框架、辅助工具、以及MongoDB客户端，前端组件1301主要用于用户对运维项目的查询，其将用户从UI页面输入的参数传入相应查询接口，通过通用组件1302进行查询算法处理、资源管理处理，从而返回页面所需的结果集。后台组件1303主要通过定时任务，如定时数据采集任务或者定时MapReduce任务等对运维项目的运维数据进行采集，然后通过MapReduce算法进行聚合处理获得聚合结果，以便用户通过前端进行查询。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。

Claims (9)

1.一种项目运维管理装置，其特征在于，包括：

应用配置模块，用于分别为各实际项目创建对应的运维项目，并将各实际项目的应用服务器添加为对应的运维项目的待监控服务器；

项目管理模块，用于通过监控服务器获取到各运维项目下待监控服务器的运维数据，并以运维项目为单位对其下的所述运维数据进行管理；

监控配置模块，用于为待监控服务器分配监控服务器；

所述为各待监控服务器分配监控服务器包括：

根据待监控服务器的类型为各待监控服务器分配监控服务器，其中，所述监控服务器将采集的待监控服务器的运维数据以运维项目为单位进行分别存储；

或，

以运维项目为单位为各待监控服务器分配监控服务器。

2.如权利要求1所述的项目运维管理装置，其特征在于，还包括：项目查询模块，用于根据用户输入查询指令对相应运维项目下的运维数据进行查询。

3.如权利要求1-2任一项所述的项目运维管理装置，其特征在于，所述项目管理模块用于通过监控服务器获取到各所述待监控服务器的运维数据，基于所述运维项目和各所述待监控服务器的类型，对采集到的所述运维数据进行处理。

4.如权利要求3所述的项目运维管理装置，其特征在于，所述项目管理模块用于对采集到的各所述待监控服务器的运维数据进行聚合处理，得到聚合结果；

所述项目运维管理装置还包括结果显示模块，所述显示模块用于基于所述运维项目展示所述聚合结果。

5.如权利要求1-2任一项所述的项目运维管理装置，其特征在于，还包括：

阈值预设模块，用于为各所述待监控服务器下各类型的运维数据设置对应的告警阈值，所述运维数据包括以下几种中的至少一种：所述待监控服务器的吞吐量、并发量以及网络流量；

所述项目管理模块还用于将采集到的所述运维数据与所述运维数据对应的告警阈值进行比较，当所述运维数据与其对应的告警阈值不匹配，则提出告警。

6.一种项目运维管理系统，其特征在于，包括如权利要求1-5任一项所述的项目运维管理装置。

7.一种项目运维管理方法，其特征在于，包括：

分别为各实际项目创建对应的运维项目，并将各实际项目的应用服务器添加为对应的运维项目的待监控服务器；

为各待监控服务器分配监控服务器；

通过监控服务器获取到各运维项目下待监控服务器的运维数据，并以运维项目为单位对其下的所述运维数据进行管理；

所述为各待监控服务器分配监控服务器包括：

根据待监控服务器的类型为各待监控服务器分配监控服务器，其中，所述监控服务器将采集的待监控服务器的运维数据以运维项目为单位进行分别存储；

或，

以运维项目为单位为各待监控服务器分配监控服务器。

8.如权利要求7所述的项目运维管理方法，其特征在于，还包括根据用户输入查询指令对相应的运维项目的运维数据进行查询。

9.如权利要求7或8所述的项目运维管理方法，其特征在于，所述通过监控服务器获取到各运维项目下待监控服务器的运维数据，并以运维项目为单位对其下的所述运维数据进行管理包括：

通过监控服务器获取到各所述待监控服务器的运维数据；

基于所述运维项目和各所述待监控服务器的类型，对采集到的所述运维数据进行处理。