CN105049270A - 信息处理方法、装置及系统 - Google Patents

Abstract

本申请提供了一种信息处理方法、装置及系统，通过获取当前存储的待处理报警信息后，将其与预设订阅规则进行匹配，并将匹配成功的待处理报警信息按照所属类型进行聚合，过滤了重复和无效的报警信息，避免了因发送大量重复报警通知，影响运维人员的休息和警惕性；由于该预设订阅规则是基于接收所述待处理报警信息的用户针对待处理报警信息的选择订阅及其通知方式的配置生成的，因而，本申请能够选择合适的通知方式，并向相应的运维人员发送该渲染后的待处理报警信息，避免运维人员对不感兴趣的报警信息接收，使其能够对每一条报警信息进行关注，能够在企业互联网发生故障时及时得到通知进行处理，从而保证了企业互联网的使用的安全性和可靠性。

Description

信息处理方法、装置及系统

技术领域

本申请主要涉及互联网的运维技术领域，更具体地说是涉及一种信息处理方法、装置及系统。

背景技术

目前，为了保证企业互联网的安全使用，通常都会有专业的运维人员对该互联网进行运维，而且，为了在互联网出现故障时能够及时发现及时处理，以确保企业互联网使用的安全性和稳定性，通常都会设置监控及报警设备，以便在企业互联网出现故障时，及时向相关运维人员发送运维通知，从而保证故障响应处理速度。

其中，运维通知的方式多种多样，如邮件、短信、即时通信等方式，然而，在企业会联网的实际运行中，由于一个服务可能部署在上百台机器上，每个服务又可能依赖多个子服务，因而，在其出现一个故障后，通常会向运维人员发送大量重复的报警通知，这将会影响运维人员的休息，降低运维人员的警惕性，使得运维人员不会对其一一关注，很容易导致重要报警信息被忽视，进而影响企业互联网的使用安全及其故障处理效率，增大了运维成本；而且，当该报警通知后包含一些该运维人员不感兴趣的报警信息时，还需要该运维人员与向其发送该报警通知的报警服务人员沟通，才能删除该类报警信息，非常麻烦。

发明内容

有鉴于此，本发明提供了一种信息处理方法、装置及系统，解决了现有技术中因发送大量重复报警信息，以及运维人员不感兴趣的报警信息，从而影响该运维人员的休息和警惕性，容易造成对重要报警信息的忽视，进而无法保证企业互联网使用过程中的安全性和稳定性的技术问题。

为了实现上述目的，本申请提供了以下技术方案：

一种信息处理方法，所述方法包括：

获取当前存储的待处理报警信息；

将所述待处理报警信息与预设订阅规则进行匹配，将匹配成功的待处理报警信息按照所属类型进行聚合，其中，所述预设订阅规则是基于接收所述待处理报警信息的用户针对所述待处理报警信息的选择订阅和通知方式的配置生成的；

对聚合后的待处理报警信息进行渲染，并将渲染后的待处理报警信息按照所述预设订阅规则输出。

优选的，在所述将渲染后的待处理报警信息按照所述预设订阅规则输出之前，所述方法还包括：

获取预存的所述用户的最新个人信息；

相应的，所述将渲染后的待处理报警信息按照所述预设订阅规则输出具体为：利用所述最新个人信息，将渲染后的待处理报警信息按照所述预设订阅规则输出。

优选的，所述对聚合后的待处理报警信息进行渲染，并将渲染后的待处理报警信息按照所述预设订阅规则输出包括：

通过django模板对聚合后的待处理报警信息进行渲染，确定每一个所述聚合后的待处理报警信息的输出方式；

根据预设规则选定所述聚合后的待处理报警信息的输出方式，并按照所述输出方式输出。

一种信息处理装置，所述装置包括：

第一获取模块，用于获取缓存的待处理报警信息；

匹配聚合模块，用于将所述待处理报警信息与预设订阅规则进行匹配，并对匹配成功的待处理报警信息按照所属类型进行聚合，其中，所述预设订阅规则是基于接收所述待处理报警信息的用户针对所述待处理报警信息的订阅和通知方式的配置生成的；

渲染输出模块，用于对聚合后的待处理报警信息进行渲染，并将渲染后生成的报警通知按照所述预设订阅规则输出。

优选的，所述装置还包括：

第二获取模块，用于获取预存的所述用户最新的个人信息；

则所述渲染输出模块具体用于利用所述最新个人信息，将渲染后的待处理报警信息按照所述预设订阅规则输出。

优选的，所述渲染输出模块包括：

渲染单元，用于通过django模板对聚合后的待处理报警信息进行渲染，确定每一个所述聚合后的待处理报警信息的输出方式；

输出单元，用于按照预设规则选定所述聚合后的待处理报警信息的输出方式，并按照所述输出方式输出。

一种信息处理系统，所述系统包括：项目与类型装置、订阅管理装置、事件接收API装置以及如上所述的信息处理装置，其中：

所述项目与类型装置，用于按照预设分类标准，对监测到的报警信息进行分类；

所述订阅管理装置，用于根据用户针当前可处理的报警信息的类型的选择订阅及其通知方式的配置，生成订阅规则并存储；

所述事件接收API装置，用于根据预设的鉴权要求，推送报警通知，并对监测到的报警信息进行存储。

优选的，所述事件接收API装置包括http服务器，用于监测与所述http服务器连接的客户端的报警信息。

优选的，所示系统还可以包括：

用户信息管理装置，用于存储用户信息，所述用户信息包括个人信息和团队信息。

由此可见，与现有技术相比，本申请提供了一种信息处理方法、装置及系统，通过获取当前存储的待处理报警信息后，将其与预设订阅规则进行匹配，并将匹配成功的待处理报警信息按照所属类型进行聚合，从而避免了因重复报警信息相互独立，而发送大量重复报警通知，影响运维人员的休息和警惕性，进而造成对重要报警信息的忽视，并且降低了运维成本；其中，由于该预设订阅规则是基于接收所述待处理报警信息的用户(即运维人员)针对所述待处理报警信息的选择订阅及其通知方式的配置生成的，因而，本申请在对聚合后的待处理报警信息进行渲染，能够选择合适的通知方式，并向相应的运维人员发送该渲染后的待处理报警信息，从而避免了运维人员对不感兴趣的报警信息接收，使该运维人员能够对接收到的每一条报警信息进行关注，能够在企业互联网发生故障时及时得到通知进行处理，从而保证了企业互联网的使用的安全性和可靠性。

附图说明

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

图1为本发明提供的一种信息处理方法实施例的流程示意图；

图2为本发明提供的一种信息处理装置实施例的结构示意图；

图3为本发明提供的一种信息处理系统实施例的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请提供了一种信息处理方法、装置及系统，通过获取当前存储的待处理报警信息后，将其与预设订阅规则进行匹配，并将匹配成功的待处理报警信息按照所属类型进行聚合，从而避免了因重复报警信息相互独立，而发送大量重复报警通知，影响运维人员的休息和警惕性，进而造成对重要报警信息的忽视，并且降低了运维成本；其中，由于该预设订阅规则是基于接收所述待处理报警信息的用户(即运维人员)针对所述待处理报警信息的选择订阅及其通知方式的配置生成的，因而，本申请在对聚合后的待处理报警信息进行渲染，能够选择合适的通知方式，并向相应的运维人员发送该渲染后的待处理报警信息，从而避免了运维人员对不感兴趣的报警信息接收，使该运维人员能够对接收到的每一条报警信息进行关注，能够在企业互联网发生故障时及时得到通知进行处理，从而保证了企业互联网的使用的安全性和可靠性。

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。

如图1所示，为本发明提供的一种信息处理方法实施例的流程示意图，该方法可以包括：

步骤S110：获取当前存储的待处理报警信息。

在本实施例实际应用中，对于客户端推送的报警信息可先进行存储，从而避免了因推送的报警信息过多而造成发送超时，而且，本实施例在接收到一报警信息后，将其缓存等待一段时间，看是否还有相同类型的报警信息推送，当满足一定条件后才发送，而不是立即发送该报警信息，减少了信息发送次数，节省了通信费用，降低了运维成本。

其中，所要满足的一定条件可以根据预设订阅规则确定，本实施例对此不作具体限定。另外，需要说明的是，根据上述分析可知，本实施例中，上述待处理报警信息并不是指一条报警信息，而是多条报警信息，对其具体数量不做限定。

步骤S120：将所述待处理报警信息与预设订阅规则进行匹配，将匹配成功的待处理报警信息按照所属类型进行聚合。

其中，所述预设订阅规则是基于接收所述待处理报警信息的用户针对所述待处理报警信息的选择订阅和通知方式的配置生成的。

具体的，在实际应用中，用户登录系统后，该系统会将对该用户开放的报警信息类型呈现出来，也就是说，每一个用户登录系统后只能够看到其有权处理的报警信息的类型，此时，用户可从中选择感兴趣或按照规则要求选择相应的报警信息的类型，即订阅该用户将要处理的报警信息类型，同时，还可以按照自身需求对其进行详细配置。

例如，对某些类型的报警信息只选择短信通知，对某些类型的报警信息选择短信和邮件通知，对某个时段的通知进行忽略，对某个类型的报警信息的报警频率上限加以控制，也就是说，当其报警率达到一定阈值将直接控制对应的客户端停止运行等，本实施例对此不作具体限定，当然，用户还可以进行其他配置，只要不是本领域技术人员付出创造性劳动确定的，均属于本发明保护范围，本实施例不再一一说明。

其中，对应上述配置信息可全部存储在数据库中，而且，根据实际需要，还可以通过后台管理界面进行修改。

另外，需要说明的是，对于同属于一个类型的报警信息的聚合过程属于本领域现有技术，本实施在此不再详述。

步骤S130：对聚合后的待处理报警信息进行渲染，并将渲染后的待处理报警按照所述预设订阅规则输出。

可选的，在本实施例中，可通过模板来渲染报警信息，具体可通过django模板来渲染聚合后的待处理报警信息，具体渲染过程属于本领域现有技术，如使用开源的引擎实现等等，本申请对此不作具体限定。

例如，一个报警信息的类型为“视频转码生产状况”，可以配置短信模板：“视频转码任务-积压{{cluster}}积压数量为{{count}}”；可以配置邮件模板为：“视频转码任务积压{{cluster}}，积压数量为{{count}}，积压的任务为{{tasks}}。推送的数据为JSON数据格式：比如{“cluster”:”集群1”,”count”:1000,“tasks”:[task1,task2...]”}。这样，同一个报警信息，发出的报警内容可以不同，短信的内容尽量精简，邮件的内容尽尽量详细，运维人员可根据实际情况选择查看报警信息的方式，灵活且实用。

作为本发明另一个实施例，为了避免运维人员或其联系方式的更改，本申请还可以在输出上述渲染后的待处理报警信息之前，获取预存的该运维人员的最新个人信息，这样，即可利用该最新个人信息将渲染后的待处理报警信息按照所述预设订阅规则输出，从而确保相应的运维人员能够收到正确的报警信息。

综上所述，在本实施例中，通过获取当前存储的待处理报警信息后，将其与预设订阅规则进行匹配，并将匹配成功的待处理报警信息按照所属类型进行聚合，从而避免了因重复报警信息相互独立，而发送大量重复报警通知，影响运维人员的休息和警惕性，进而造成对重要报警信息的忽视，并且降低了运维成本；其中，由于该预设订阅规则是基于接收所述待处理报警信息的用户(即运维人员)针对所述待处理报警信息的选择订阅及其通知方式的配置生成的，因而，本申请在对聚合后的待处理报警信息进行渲染，能够选择合适的通知方式，并向相应的运维人员发送该渲染后的待处理报警信息，从而避免了运维人员对不感兴趣的报警信息接收，使该运维人员能够对接收到的每一条报警信息进行关注，能够在企业互联网发生故障时及时得到通知进行处理，从而保证了企业互联网的使用的安全性和可靠性。

如图2所示，为本发明提供的一种信息处理装置实施例的结构示意图，该装置可以包括：

第一获取模块210，用于获取缓存的待处理报警信息；

匹配聚合模块220，用于将所述待处理报警信息与预设订阅规则进行匹配，并对匹配成功的待处理报警信息按照所属类型进行聚合，其中，所述预设订阅规则是基于接收所述待处理报警信息的用户针对所述待处理报警信息的订阅和通知方式的配置生成的；

渲染输出模块230，用于对聚合后的待处理报警信息进行渲染，并将渲染后生成的报警通知按照所述预设订阅规则输出。

作为本发明另一实施例，在上述实施例的基础上，该装置还可以包括：

第二获取模块，用于获取预存的所述用户最新的个人信息；

则所述渲染输出模块230具体用于利用所述最新个人信息，将渲染后的待处理报警信息按照所述预设订阅规则输出。

可选的，上述渲染输出模块230可以包括渲染单元，用于通过django模板对聚合后的待处理报警信息进行渲染，确定每一个所述聚合后的待处理报警信息的输出方式；

输出单元，用于按照预设规则选定所述聚合后的待处理报警信息的输出方式，并按照所述输出方式输出。

结合上述分析可知，在本实施例中，所监测到的报警信息通过类型发送方式，方便运维人员快速查看同一类报警信息，以便快速且准确排出故障；而且，运维人员提前对报警信息进行了选择订阅和配置，从而使其能够有选择性接收报警信息，而不知接收所有报警信息，减少了对不感兴趣和不在职责范围内的报警信息的接收；另外，本实施例对同一类型的报警信息按照所属类型进行聚合，过滤了重复报警信息和无效报警信息，提高了报警信息的有效性，同时避免了因重复报警信息相互独立，而发送大量重复报警通知，影响运维人员的休息和警惕性，进而造成对重要报警信息的忽视，并且降低了运维成本；此外，本实施例对报警信息还进行了模板渲染，使得其不同输出方式能够具有不同报警内容，充分发挥各输出方式的优势，此时，运维人员可根据实际需要进行选择查看，确保其能够获得充足的报警信息，以便快速且准确排除问题。

如图3所示，为本发明提供的一种信息处理系统实施例的结构示意图，该系统可以包括：项目与类型装置310、订阅管理装置320、事件接收API装置330以及信息处理装置340，其中：

所述项目与类型装置310，用于按照预设分类标准，对监测到的报警信息进行分类。

在实际应用中，所有的报警信息必须要有一个报警类型，相当于“主题”，一个报警类型，是属于一个项目及团队，其可以设定该报警类型的公开模式，可公开的报警信息类型及其报警信息对所有用户可见，而不可公开的报警信息类型及其报警信息支队该项目及团队内的成员可见，从而确保重要报警信息不泄露。

所述订阅管理装置320，用于根据用户针当前可处理的报警信息的类型的选择订阅及其通知方式的配置，生成订阅规则并存储。

其中，该订阅管理装置获得订阅规则的过程可参照上述方法实施例对应部分的描述，本实施例在此不再详述。

结合上述分析可知，本实施例中运维人员采用选择订阅方式接收报警信息，排出了不感兴趣以及不在其职责范围内的报警信息等，即减少了对无用报警信息的接收，降低了通信成本。

所述事件接收API装置330，用于根据预设的鉴权要求，推送报警通知，并对监测到的报警信息进行存储。

在本实施例中，该事件接收API装置330可包括一个http服务器，用于监测与所述http服务器连接的客户端的报警信息，调用者(即发送报警信息的一方)可根据自己所在项目的秘钥进行鉴权，可规定只有该项目团队内部的人员才可以推送该类型的报警信息。

而且，该报警信息的响应方式采用异步方式，即报警信息推送过来的时候，不会立即进行发送信息，而是先存储在缓存模块，缓存模块中的数据，只有达到一定的条件时才会进行处理，具体过程可参照上述方法实施例对应部分的描述，本实施例在此不再详述。

另外，需要说明的是，该信息处理装置330具体组成结构及其功能与上述装置实施例记载的信息处理装置相同，本实施在此不再赘述。

可选的，在上述实施例的基础上，该装置还可以包括：

用户信息管理装置，用于存储用户信息，所述用户信息包括个人信息和团队信息。

其中，个人信息可以包括用户的手机号、邮箱、即时通信的账号等等。本实施例对此不作限定，在实际应用中，用户与团队之间可以是多对多关系，一个用户可以隶属于多个团队，本申请对此不作具体限定。

在实际应用中，可以通过该用户信息管理装置统一收集用户联系方式，并保证该联系方式是该用户的最新联系方式，从而保证报警信息能够准确及时发送到该用户的电子设备。

综上所述，本实施例通过获取当前存储的待处理报警信息后，将其与预设订阅规则进行匹配，并将匹配成功的待处理报警信息按照所属类型进行聚合，从而避免了因重复报警信息相互独立，而发送大量重复报警通知，影响运维人员的休息和警惕性，进而造成对重要报警信息的忽视，并且降低了运维成本；其中，由于该预设订阅规则是基于接收所述待处理报警信息的用户(即运维人员)针对所述待处理报警信息的选择订阅及其通知方式的配置生成的，因而，本申请在对聚合后的待处理报警信息进行渲染，能够选择合适的通知方式，并向相应的运维人员发送该渲染后的待处理报警信息，从而避免了运维人员对不感兴趣的报警信息接收，使该运维人员能够对接收到的每一条报警信息进行关注，能够在企业互联网发生故障时及时得到通知进行处理，从而保证了企业互联网的使用的安全性和可靠性。

最后，需要说明的是，在上述各实施例中，诸如第一、第二等之类的关系术语仅仅用来将一个操作、单元或模块与另一个操作、单元或模块区分开来，而不一定要求或者暗示这些单元、操作或模块之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法或者系统中还存在另外的相同要素。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置和系统而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (9)

1.一种信息处理方法，其特征在于，所述方法包括：

获取当前存储的待处理报警信息；

将所述待处理报警信息与预设订阅规则进行匹配，将匹配成功的待处理报警信息按照所属类型进行聚合，其中，所述预设订阅规则是基于接收所述待处理报警信息的用户针对所述待处理报警信息的选择订阅和通知方式的配置生成的；

对聚合后的待处理报警信息进行渲染，并将渲染后的待处理报警信息按照所述预设订阅规则输出。

2.根据权利要求1所述的方法，其特征在于，在所述将渲染后的待处理报警信息按照所述预设订阅规则输出之前，所述方法还包括：

获取预存的所述用户的最新个人信息；

相应的，所述将渲染后的待处理报警信息按照所述预设订阅规则输出具体为：利用所述最新个人信息，将渲染后的待处理报警信息按照所述预设订阅规则输出。

3.根据权利要求1或2所述的方法，其特征在于，所述对聚合后的待处理报警信息进行渲染，并将渲染后的待处理报警信息按照所述预设订阅规则输出包括：

通过django模板对聚合后的待处理报警信息进行渲染，确定每一个所述聚合后的待处理报警信息的输出方式；

根据预设规则选定所述聚合后的待处理报警信息的输出方式，并按照所述输出方式输出。

4.一种信息处理装置，其特征在于，所述装置包括：

第一获取模块，用于获取缓存的待处理报警信息；

匹配聚合模块，用于将所述待处理报警信息与预设订阅规则进行匹配，并对匹配成功的待处理报警信息按照所属类型进行聚合，其中，所述预设订阅规则是基于接收所述待处理报警信息的用户针对所述待处理报警信息的订阅和通知方式的配置生成的；

渲染输出模块，用于对聚合后的待处理报警信息进行渲染，并将渲染后生成的报警通知按照所述预设订阅规则输出。

5.根据权利要求4所述的装置，其特征在于，所述装置还包括：

第二获取模块，用于获取预存的所述用户最新的个人信息；

则所述渲染输出模块具体用于利用所述最新个人信息，将渲染后的待处理报警信息按照所述预设订阅规则输出。

6.根据权利要求4或5所述的装置，其特征在于，所述渲染输出模块包括：

渲染单元，用于通过django模板对聚合后的待处理报警信息进行渲染，确定每一个所述聚合后的待处理报警信息的输出方式；

输出单元，用于按照预设规则选定所述聚合后的待处理报警信息的输出方式，并按照所述输出方式输出。

7.一种信息处理系统，其特征在于，所述系统包括：项目与类型装置、订阅管理装置、事件接收API装置以及如权利要求4-6任意一项所述的信息处理装置，其中：

所述项目与类型装置，用于按照预设分类标准，对监测到的报警信息进行分类；

所述订阅管理装置，用于根据用户针当前可处理的报警信息的类型的选择订阅及其通知方式的配置，生成订阅规则并存储；

所述事件接收API装置，用于根据预设的鉴权要求，推送报警通知，并对监测到的报警信息进行存储。

8.根据权利要求7所述的系统，其特征在于，所述事件接收API装置包括http服务器，用于监测与所述http服务器连接的客户端的报警信息。

9.根据权利要求7所示的系统，其特征在于，所示系统还可以包括：

用户信息管理装置，用于存储用户信息，所述用户信息包括个人信息和团队信息。