CN106055609B - nginx日志监控方法、装置、消息分布系统及信息处理的装置 - Google Patents

Abstract

本公开是关于一种nginx日志监控方法及装置，方法包括：获取与业务详情对应的第一分析代码；根据所述第一分析代码，替换nginx插件中已写入的第二分析代码；热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件；以及一种用于业务详情分析的消息分布系统。本公开的有益效果为：针对业务详情编写的分析代码及聚合模型，实现了在业务进行的过程中的动态实时调整，同时消息分布系统能够大幅提升日志内容的数据处理能力。

Description

nginx日志监控方法、装置、消息分布系统及信息处理的装置

技术领域

本公开涉及网络信息技术领域，尤其涉及一种用于业务详情分析的nginx日志监控方法、装置、消息分布系统及信息处理的装置。

背景技术

相关技术中，nginx一般作为业务的http请求的入口，并作为服务的代理，提供负载均衡，高可用的功能；nginx还能为业务服务提供缓存支持(如proxy cache，缓存代理)，使用缓存后，用户的请求经过nginx后会先在nginx缓存中去查询，如果命中，则直接返回，否则需要再向服务去请求。

当业务大量使用nginx缓存来提升业务性能后，业务相关的访问详情记录就只会存储在nginx的日志中，且这部分日志数据对我们监控业务用户的访问趋势，对用户行为进行分析，查看当前服务的请求质量等，都有价值。因此，如何提高nginx对这部分数据的实时整理分析能力，对进行业务详情分析至关重要。

相关方案中，对日志分布式采集分析方法利用相对固定的处理规则，当对某些关键信息进行监控时，在需要增加新的关键字时，则需要对代码逻辑进行重新调整与部署，这样也同时降低了节点的处理能力，对日志处理结果不能满足用户的需求。

发明内容

为克服相关技术中存在的问题，本公开提供一种nginx日志监控方法及装置，通过动态将分析代码替换到nginx插件中热重启的方式，提高了nginx日志分析的灵活性。

本公开还提供了一种消息分布系统，以提高日志内容整理分析的实时性，更加快速地展现业务的当前情况。

根据本公开实施例的第一方面，提供一种nginx日志监控方法，其具体技术方案包括：

获取与业务详情对应的第一分析代码；

根据所述第一分析代码，替换nginx插件中已写入的第二分析代码；

热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件。

本公开的实施例提供的技术方案可以包括以下有益效果：所述分析代码根据业务详情编写，并以nginx插件的方式进行调用，当需要作出调整时，只需要调整或替换nginx插件中已写入的分析代码，以及热重启操作即可完成新的nginx插件的装配，实现了动态地根据业务相关的访问详细纪录聚合模型，提高了灵活性。

在本公开示例性实施例的另一实施场景中，热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件之后，还包括：

获取关键字，所述关键字用于匹配日志内容，通过判断日志内容中是否有所述关键字实现对日志内容的监控。

本公开的实施例提供的技术方案可以包括以下有益效果：通过匹配关键字的方式实现对各所述日志内容的监控，效率高且节省资源。

在本公开示例性实施例的另一实施场景中，获取所述关键字时，还包括：

检测所述关键字是否保存在内存中；

在所述关键字未保存在内存时，在内存中建立一关键字数据库，并将所述关键字保存在该关键字数据库中。

本公开的实施例提供的技术方案可以包括以下有益效果：通过在内存中建立关键字数据的方式，使得在对待监控日志内容进行匹配关键字时，直接从内存的关键字数据库调用即可，使得匹配速度获得了极大的提升。

在本公开示例性实施例的另一实施场景中，所述获取与业务详情对应的第一分析代码之前，还包括：

对所述业务详情对应的聚合场景进行统计，以得到统计数据；

根据所述统计数据定制聚合模型；

其中，每一所述聚合模型包括有对应的第一分析代码。

本公开的实施例提供的技术方案可以包括以下有益效果：通过统计数据以及聚合模型得到第一分析代码，使得针对于各业务详情的分析代码可以通过聚合模型调取，无需临时编辑，可以提高在监控过程中的智能化程度。

在本公开示例性实施例的另一实施场景中，所述方法还包括：

检测所述业务详情对应的聚合场景是否发生变化；

当所述业务详情对应的聚合场景发生变化时，调用与变化后的聚合场景相对应的聚合模型；

对所述变化后的聚合场景相对应的聚合模型中包括的分析代码替换变化前的所述业务详情所使用的分析代码。

本公开的实施例提供的技术方案可以包括以下有益效果：智能检测聚合场景的变化，并动态装配相应的聚合模型，进行聚合模型中的分析代码的替换，使得nginx服务器实现无人值守。

根据本公开实施例的第二方面，提供一种nginx日志监控装置，所述装置包括：

获取模块，被配置用于获取与业务详情对应的第一分析代码；

替换模块，被配置用于根据所述第一分析代码，替换nginx插件中已写入的第二分析代码；

装配模块，被配置用于热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件。

在本公开示例性实施例的另一实施场景中，所述装置还包括：

第二获取模块，被配置用于获取关键字，所述关键字用于匹配日志内容，通过判断日志内容中是否有所述关键字实现对日志内容的监控。

在本公开示例性实施例的另一实施场景中，所述第二获取模块还包括：

检测模块，被配置用于检测所述关键字是否保存在内存中；

建立模块，被配置用于在所述关键字未保存在内存时，在内存中建立一关键字数据库，并将所述关键字保存在该关键字数据库中。

在本公开示例性实施例的另一实施场景中，所述装置还包括：

统计模块，被配置用于对所述业务详情对应的聚合场景进行统计，以得到统计数据；

定制模块，根据所述统计数据定制聚合模型；其中，每一所述聚合模型包括有对应的第一分析代码。

在本公开示例性实施例的另一实施场景中，所述装置还包括：

第三检测模块，被配置用于检测所述业务详情对应的聚合场景是否发生变化；

调用模块，被配置用于当所述业务详情对应的聚合场景发生变化时，调用与变化后的聚合场景相对应的聚合模型；

替换模块，被配置用于对所述变化后的聚合场景相对应的聚合模型中包括的分析代码替换变化前的所述业务详情所使用的分析代码。

根据本公开实施例的第三方面，提供一种消息分布系统，所述系统包括：

中心节点，其提供有可操作接口，以获取与业务详情相对应的第一分析代码；

子节点，其具有数据接口，以接收对各子节点的第二分析代码；

所述中心节点与各所述子节点通过数据接口实现订阅关系，其中的中心节点将获取的第一分析代码下发至各所述子节点的数据接口，以使对各所述子节点用所述第一分析代码替换第二分析代码。

本公开的实施例提供的技术方案可以包括以下有益效果：通过分布式结构，实现对各待统计的子节点进行特定规则的聚合，并且对每一子节点上针对聚合模型对业务详情的聚合模型的，实现对各子节点的实时调整，提高了灵性性以及实时性。

在本公开示例性实施例的另一实施场景中，包括有数据仓储，用于记录所述中心节点与各所述子节点的消息量的数据输出；

其中，所述数据仓储与所述中心节点部署于同一nginx服务器。

本公开的实施例提供的技术方案可以包括以下有益效果：数据仓储能够存储数据处理过程中形成的消息量数据，也可单独部署，实现nginx服务器的轻量化。

在本公开示例性实施例的另一实施场景中，所述中心节点针对不同类型的业务详情聚合模型，该聚合模型包括有针对各所述子节点的聚合规则，聚合规则中包括与业务详情相对应的第一分析代码，所述中心节点向各所述子节点下发聚合模型时，各所述子节点接收所述聚合模型，用所述第一分析代码替换第二分析代码，并按照该聚合模型中包含的聚合规则对日志内容进行分析处理。

本公开的实施例提供的技术方案可以包括以下有益效果：通过中心节点对分布式结构中的各子节点进行聚合模型的替换与调整，使得通过上层控制快速达到下层，增强其数据处理能力。

在本公开示例性实施例的另一实施场景中，所述中心节点还包括有一评估模块，该评估模块被配置用于：

评估业务详情所包括的日志内容的总量；

在所述总量超过预设阈值时，通过网络设置新的子节点，并建立该新的子节点与中心节点的订阅关系，以使该新的子节点能够接收所述第一分析代码和/或所述聚合模型，以按照所述第一分析代码和/或所述聚合模型中包含的聚合规则对日志内容进行分析处理。

本公开的实施例提供的技术方案可以包括以下有益效果：可订阅新的子节点或者对现在的子节点进行调整，大幅提升了消息的处理能力，防止了消息的堵塞与堆积。

在本公开示例性实施例的另一实施场景中，所述系统还包括：

所述中心节点还配置有一脚本管理模块，

该脚本管理模块用于，根据各所述子节点接收到的聚合模型，调用配置信息管理脚本，并将各所述聚合模型写入各子节点的配置文件中，以将各所述子节点分析处理后的日志内容动态输出到各所述子节点以及所述中心节点中。

本公开的实施例提供的技术方案可以包括以下有益效果：通过脚本将需要的聚合模型写入子节点的配置文件，实现了对各所述子节点的业务详情的日志分析，降低了日志分析的成本，并且其灵活性更高。

本公开的第四方面，还涉及一种信息处理的装置，其包括：

处理器；

用于存储处理器可执行命令的存储器；

其中，所述处理器被配置为：

获取与业务详情对应的第一分析代码；

根据所述第一分析代码，替换nginx插件中已写入的第二分析代码；

热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件。

本公开的装置可以实现上述的方法所能达到的有益效果。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是根据一示例性实施例示出的一种nginx日志监控方法的流程图。

图2是根据一示例性实施例示出的局部步骤的流程图。

图3是根据一示例性实施例示出的另一实施方式的流程图。

图4是根据一示例性实施例示出的一种nginx日志监控装置的框图。

图5是根据一示例性实施例示出的一种nginx日志监控装置的另一种形式的框图。

图6是根据一示例性实施例示出的一种nginx日志监控装置的定制聚合模型时的框图。

图7是根据一示例性实施例示出的一种消息分布系统的示意图。

图8是根据一示例性实施例示出的一种nginx日志监控装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和方法的例子。

在更加详细地讨论示例性实施例之前应当提到的是，一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图中将各步骤描述成顺序的处理，但是其中的许多步骤可以并行地、并发地或者同时实施。此外，各步骤的顺序可以被重新安排，当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图内的其它步骤。处理处理可以对应于方法、函数、规程、子例程、子程序等。

本公开涉及一种用于业务详情分析的nginx日志监控方法及装置，运用于nginx对保存的日志的实时整理分析场景中，其基本思想是：通过nginx服务器获取与业务详细对应的第一分析代码以替换nginx插件中已写入的第二分析代码并进行热重启的方式，动态地装配nginx插件，使得nginx服务器在进行日志处理时，能够根据业务相关的访问详情动态地变换处理规则，配合从内存中匹配待监控日志内容的关键字，提高了nginx服务器对日志数据的实时整理分析能力。

图1是根据一示例性实施例示出的一种用于业务详情分析的nginx日志监控方法的流程图，如图1所示，本公开一种用于业务详情分析的nginx日志监控方法，适用于nginx服务器中，可以由nginx服务器或者其中心控制单元来执行，所述方法具体包括以下步骤：

在步骤110中，获取与业务详情对应的第一分析代码；

其中，所述第一分析代码指的是，根据业务详情编写对应的分析代码,该第一分析代码可由相应的工作人员进行现场即时编辑输入，也可以是保存于云端服务器的已编辑完成并进行封装的分析代码操作代码，以通过网络通道请求获取，在当前的nginx服务器需要时向云端服务器进行请求并下载以供使用。

业务详情是指与http请求相关的访问详情纪录，每一项业务可指一条对应的http请求，在使用nginx服务器作缓存时，其保存于nginx服务器的日志内容中。

在步骤120中，根据所述第一分析代码，替换nginx插件中已写入的第二分析代码；

所述nginx服务器支持插件的热插拔装配，并且具有灵活的插件开发模式。以nginx插件的方式将针对于业务详情分析的第一分析代码写入到nginx插件中并进行部署，保证服务器的工作效率。

获取所述第一分析代码后，将所述第一分析代码根据需要替换掉nginx插件中已写入的第二分析代码，其中的第二分析代码是指在所述nginx插件根据之前的业务写入的分析代码。

在步骤130中，热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件。

在nginx服务器处于工作模式下，通过对nginx插件的热重启，使得nginx服务器保持在工作状态中即可完成对分析代码的调整，以实现动态地替换并装配该nginx插件的效果。

本实施例提供的用于业务详情分析的nginx日志监控方法，在使用nginx服务器作为http业务请求的入口并将nginx服务器作为业务代理服务器时，由于其配置文件的简洁性，以及支持nginx插件的热插拨，使得nginx服务器在不重启的情况下实现针对业务详情的聚合模型的代码写入，同样也可以保证使服务器在任何复杂的业务请求中7*24小时不间断运行，从而大大提升了nginx服务器处理日志数据的能力。

如图2所示，本公开示例性实施例的可能出现的另一方式中，在所述步骤110之后，还包括：

在步骤111中，获取关键字，所述关键字用于匹配日志内容，通过判断日志内容中是否有所述关键字实现对日志内容的监控；

所述关键字监控方式作为对日志内容的一种监控方法，在对日志内容进行监控时，由于日志内容可能包含有多行代码、文字、字母以及数据的组合，因此日志内容所包含的信息量或较为庞大，通过检索日志内容的关键字的方式，使得对日志内容的监控更加简单，更易于执行。

在步骤111中，还可以根据所述nginx插件写入的所述第一分析代码所体现出来的聚合规则，在待监控日志内容中匹配所述关键字。

所述第一分析代码是根据业务详情有针对性地编写的，其包含了一定的聚合规则甚至聚合条件，能够对日志内容进行有规则、有条件的监控，而非盲目的监控。

在进行步骤111即获取所述关键字时，其可能的一种实施方式包括：

在步骤1111中，检测所述关键字是否保存在内存中；

在日志内容的监控过程中，虽然可以通过关键字来监控日志内容，然而在监控时如何调用该部分关键字，以及从何种路径调用关键字，对于日志内容的关键字匹配过程均有着不同的影响。

检测关键字是否保存在内存中，则可以直接检测出对关键字匹配时的效率。

在步骤1112中，在所述关键字未保存在内存时，在内存中建立一关键字数据库，并将所述关键字保存在该关键字数据库中。

在关键字未保存在内存时，则在nginx服务器的内存中建立关键字数据库，如SQL(结构化查询)、MYSQL(关系型数据存储)等，将对日志内容匹配时用到的所有关键字全部保存于该位于内存中的关键字数据库中，使得在对日志内容的监控过程中通过关键字匹配时，直接从内存中的关键字数据库调用，从而极大地提升匹配的效率，在日志内容越复杂、关键字个数越多的情况下，对于日志内容的监控与关键字匹配效率的提升也就越明显。

而当检测结果为关键字已保存在内存中时，可对该部分关键字不作处理。

内存为nginx服务器提供的物理性内存，如颗粒性闪存flash、pcle等，也可以为例如proxy cache(代理缓存)，通过该nginx服务器的内存数据库作为缓存，利用ramdisk(内存硬盘化)技术在nginx服务器的内存中形成一个文件系统，该文件系统用于保存所述关键字数据库，对关键字数据库中的所有数据的读取与写入均在该内存中进行，使得效率大大提升。

与业务相关的请求与设置等均保存在缓存中以供查询，与http请求相关的访问详情纪录则存储于nginx服务器的日志内容中。

而当不提供关键字匹配的情况下进行的日志内容的监控时，则需要根据日志内容所包括的全部信息量进行分析、检测、判断，工作量大大增加。

结合图3所示，在本公开示例性实施例的另一场景中，在所述步骤110之前，还包括聚合模型的过程，其具体如下：

在步骤101中，对所述业务详情对应的聚合场景进行统计，以得到统计数据；

业务详情即在nginx服务器作为业务的http请求的入口并提供缓存支持时，与各业务相关的访问详情纪录，该部分数据存储于nginx的日志中；

聚合场景可对不同类型的业务详情进行分析，以得到统计数据，该统计数据可包括有业务详情类型的数据。

在步骤102中，根据所述统计数据定制聚合模型；

其中，每一所述聚合模型包括有对应的第一分析代码。

另一实施方式中，聚合场景发生变化时可通过以下步骤实现分析代码的替换过程：

检测所述业务详情对应的聚合场景是否发生变化；

动态地根据业务请求相关的访问详情纪录聚合模型，可通过编写或者调用与该业务详情相关的分析代码，生成聚合模型并封存，封存的方式可通过一定的路径保存于nginx服务器的物理性存储介质中，也可以通过网络通道保存于虚拟服务器中进行存储。

在检测到业务详情所对应的聚合场景发生变化时，例如可通过nginx服务器的可扩展的态势感知框架进行检测，根据变化后的聚合场景信息，获取与该聚合场景相对应的聚合模型，同时，也即获取该聚合模型内所包含的第一分析代码。

当所述业务详情对应的聚合场景发生变化时，调用与变化后的聚合场景相对应的聚合模型；

聚合场景为具体的业务请求发生变化，或者需要对该类型的业务请求进行监控(对业务的http请求的限制或者禁止)时，nginx服务器根据一定的策略(或态势感知)而进行的对业务访问详细所作出的日志纪录上的变更。

通过本公开示例性实施例的方法，使得nginx服务器在检测到聚合场景发生变化时，可以快速地调用已封装好的聚合模型来应对突然发生的聚合场景变化，进而使nginx服务器能够快速响应各类型不同的聚合场景，而当调用后的聚合模型内所包含的第一分析代码并不能完全适应当前业务详情时(即当聚合场景可能再次发生变化的情况下)，则可再次进行步骤110～130，以及步骤111，再次获取编写后的第一分析代码以对封装的聚合模型中的分析代码进行替换，即对所述变化后的聚合场景相对应的聚合模型中包括的分析代码替换变化前的所述业务详情所使用的分析代码，以更好地适应业务详情所对应的聚合场景变化。

如图4所示，在本公开示例性实施例的另一方面，本公开提供一种用于业务详情分析的nginx日志监控装置，所述装置主要包括有获取模块410、替换模块420以及装配模块430：

其中的获取模块410，被配置用于获取与业务详情对应的第一分析代码；

其中的替换模块420，被配置用于根据所述第一分析代码，替换nginx插件中已写入的第二分析代码；

其中的装配模块430，被配置用于热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件。

所述替换模块420能够接收所述获取模块410的第一分析代码，并实现接收的第一分析代码对nginx插件中已写入的第二分析代码的替换，因此，二者之间通讯连接，所述装配模块430则在检测到所述替换模块420的替换过程完成之后，发出热重启信号，使所述nginx服务器实现热重启，完成替换第一分析代码后的nginx插件的装配，因此，所述装配模块430至少与所述nginx服务器(或其中心控制模块)保持通讯连接，同时，至少与所述替换模块420保持单向通讯，以获取所述替换模块420的替换工作是否完成。

进一步地，在本公开示例性实施例可能的一种方式中，如图5所示，所述装置还包括：

第二获取模块510，被配置用于获取关键字，所述关键字用于匹配日志内容，通过判断日志内容中是否有所述关键字实现对日志内容的监控。

通过本公开示例性实施例的第二获取模块510，可以实现通过匹配关键字的方式对日志内容进行监控。

在可能的一种实施方式中，所述第二获取模块510还包括：

检测模块511，被配置用于检测所述关键字是否保存在内存中；

建立模块512，被配置用于在所述关键字未保存在内存时，在内存中建立一关键字数据库，并将所述关键字保存在该关键字数据库中。

在本公开示例性实施例的另一实施场景中，如图6所示，所述装置还包括：

统计模块610，被配置用于对所述业务详情对应的聚合场景进行统计，以得到统计数据；

定制模块620，根据所述统计数据定制聚合模型；其中，每一所述聚合模型包括有对应的第一分析代码。

在本公开示例性实施例的另一实施场景中，所述装置还包括：

第三检测模块，被配置用于检测所述业务详情对应的聚合场景是否发生变化；

调用模块，被配置用于当所述业务详情对应的聚合场景发生变化时，调用与变化后的聚合场景相对应的聚合模型；

替换模块，被配置用于对所述变化后的聚合场景相对应的聚合模型中包括的分析代码替换变化前的所述业务详情所使用的分析代码。

上述实施例中提供的用于业务详情分析的nginx日志监控装置可执行本发明中任意实施例中所提供的用于业务详情分析的nginx日志监控方法，具备执行该方法相应的功能模块和有益效果，未在上述实施例中详细描述的技术细节，可参见本发明任意实施例中所提供的用于业务详情分析的nginx日志监控方法。

如图7所示，本公开还提供一种用于业务详情分析的消息分布系统，其采用动态聚合模型以及分布式结构的特点，使得nginx服务器对日志消息的处理能力大幅提升，降低了当业务大量使用nginx作为缓存时的故障率，结合图示，所述系统主要包括中心节点以及若干子节点，其中的中心节点与多个子节点采用分布式结构进行存储，在一种可能的实施方式中，该系统还包括有数据仓储，数据仓储可与所述中心节点一同部署，也可单独部署。

本公开的消息分布系统，部署于nginx代理服务器，以nginx作为代理服务器时，可将多个http请求并在一个子节点处理，并由部署的中心节点来进行中心控制协调。

其中的中心节点，其提供有可操作接口，以获取与业务详情相对应的第一分析代码；

中心节点对外提供可编程接口，例如通用的IO、API接口等，以实时接收通过该可编程接口获得的操作代码以及操作参数等，也可以连接PLC远程接收通过网络传输的分析代码。

其中的子节点，其具有数据接口，以接收对各子节点的第二分析代码；各子节点的数据接口能够接收中心节点指定的聚合模型以及配置参数等，以对该子节点的日志内容进行聚合处理。

各个子节点均具有一个数据接口，通过其数据接口能够与中心节点实现通讯，以接收中心节点下发的操作指令、参数，在本公开示例性实施例中，可用于接收中心节点的第一分析代码、聚合模型等。

每一子节点可处理该子节点上累积的日志内容。在该子节点上保存对应的业务http在通过该nginx代理服务器进行数据请求时的日志缓存，各子节点将其对应的日志缓存内容发送至中心节点进行集中存储。

所述中心节点与各子节点之间均通讯连接。

其中的数据仓储，能够记录所述中心节点与各所述子节点的数据输出，以供查询。

针对各子节点以及中心节点的信息量，数据仓储可单独部署，也可同中心节点、各子节点一同部署，同样地，数据仓储既可部署于nginx代理服务器内，也可部署于nginx服务器之外。

所述中心节点能够动态地调用各所述子节点的数据接口，完成各子节点与中心节点之间建立的订阅关系，以实现中心节点对各所述子节点进行配置，决定是否根据所述第一分析代码替换nginx插件中已写入的第二分析代码，以及替换分析代码后的子节点的热重启。

所述中心节点接收到外部输入或者获取的获取与业务详情相对应的聚合模型或者第一分析代码时，能够及时将该聚合模型或者第一分析代码发送到分布式结构的各子节点，以迅速完成中心节点对各子节点的分析代码的动态调整，进而完成针对业务详情的日志内容数据存储的需求。

本公开的实施例提供的技术方案可以包括以下有益效果：在nginx代理服务器中搭建分布式结构，以中心节点作为中心，各子节点作为分支，在中心节点接收到分析代码时，能够快速地将分析代码发送至各子节点，实现对各待统计的子节点进行特定规则的聚合，并且对每一子节点上针对聚合模型对业务详情的聚合模型的，实现了对各子节点的实时调整，提高了灵活性以及实时性。

进一步地，所述中心节点针对不同类型的业务详情聚合模型。

该聚合规则中可包括与业务详情相对应的第一分析代码，所述中心节点向各所述子节点下发聚合模型时，各所述子节点接收所述聚合模型，用所述聚合模型包括的第一分析代码替换各所述子节点的第二分析代码后，各所述子节点根据所述第一分析代码所体现出来的聚合规则对日志内容进行分析处理。

分析代码中的代码部分体现出了对日志处理的聚合规则，不同的分析代码，如第一分析代码和第二分析代码对应地采用不同的聚合规则和聚合方式对日志内容进行分析处理。

通过中心节点对子节点的综合配置，不仅提高了判断的正确率，还提高了判断的效率。

通过本公开示例性实施例的分布式消息系统，各所述子节点的代码替换过程包括：

所述中心子节点通过分析代码替换各子节点中已写入的第二分析代码，可在同时根据业务详情生成一聚合模型。

所述中心子节点向各所述子节点发布生成的聚合模型，各所述子节点在接收到替换后的聚合模型后，或者根据中心节点的发送情况，在接收第一分析代码后，直接进行聚合模型的替换与装配，以通过该替换后的聚合模型所体现的聚合规则、处理逻辑对日志内容进行分析处理。

在当前的各子节点已具有一聚合模型时，在接收到中心节点的发布的第一分析代码或者另一聚合模型时，可直接进行替换步骤，无需进行热重启操作，即可使各子节点按照最新的聚合规则、代码逻辑对日志内容进行处理。

在可能的一种实施方式中，所述中心节点还包括有一评估模块，该评估模块可以评估已有的子节点是否不能应对当前的业务详情，并在出于防止日志内容堆积的目的而增加新的子节点。

具体的所述评估模块被配置用于：

评估业务详情所包括的日志内容的总量；

此过程中可通过检测当前的业务详情在nginx代理服务器请求的入口的数量进行判断。

当当前的业务详情在nginx代理服务器请求的入口的数量可被视为业务详情所包括的日志内容的总量，并作为日志内容问题的判断标准。

同时，所述评估模块可设置一预设阈值，该预设阈值可用于判断日志内容的问题是否超过现有的所有子节点的处理能力。

在所述总量超过预设阈值时，通过网络设置新的子节点，并建立该新的子节点与中心节点的订阅，以使该新的子节点能够接收替换后的聚合模型。

在所述问题小于所述预设阈值时，则可关闭该评估模块，或者通过nginx代理服务器中的既定策略使该评估模块每隔一单位时间打开一次，以保证当前的各子节点能够处理当前的业务详情。

通过评估模块可实现针对业务需求对性能、业务吞吐量及数据一致性，通过中心节点分配新的子节点，同时完成与新的子节点的数据接口之间的订阅关系，实现中心节点与各子节点之间的订阅、通讯以及配置，最大限度地防止日志内容信息的堆积，进一步地提升对日志内容的处理分析能力。

在可能的一种实施方式中，该系统中还包括有信息展示模块，以提取各子节点在对业务详情的日志内容进行分析聚合处理后的关键数据，并在该信息展示模块上进行展示。

信息展示模块可以为一实体的显示装置，例如通过有线或者无线连接的一显示器，该信息展示模块能够提取数据，以进行展示供用户察看。

在本公开示例性实施例的另一种方式中，所述系统还包括有：脚本管理模块，该脚本管理模块用于，根据各所述子节点接收到的聚合模型，调用配置信息管理脚本，并将各所述聚合模型写入各子节点的配置文件中，以将各所述子节点分析处理后的日志内容动态输出到各所述子节点以及所述中心节点中。

Nginx的配置信息管理脚本可以包括有启动脚本、停止脚本、重启脚本、配置转换脚本以及配置模板文件脚本等，通过对其中的脚本管理模块的调用，使得各所述子节点在接收到中心节点的聚合模型后，使该聚合模型形成各子节点的标准配置信息管理脚本，通过执行形成的标准配置信息管理脚本，实现各子节点对收到的聚合模型的快速配置，增强了各子节点对中心节点的执行能力，同时，也使得本公开的分布式系统的易用性提到了极大的提升。

本公开的实施例提供的技术方案可以包括以下有益效果：通过脚本将需要的聚合模型写入子节点的配置文件，实现了对各所述子节点的业务详情的日志分析，降低了日志分析的成本，并且其灵活性更高。

本公开示例性实施例中，还涉及一种信息处理的装置，其用于对nginx服务器中的日志内容进行处理，所述装置至少包括：

处理器；

用于存储处理器可执行命令的存储器；

其中，所述处理器被配置为：

获取与业务详情对应的第一分析代码；

根据所述第一分析代码，替换nginx插件中已写入的第二分析代码；

热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件。

所述装置可位于nginx服务器中，也可为一独立的装置并与nginx服务器通讯连接，并可以通过其中的处理器来执行本公开上述实施例中包含的方法。

其中的第一分析代码所体现出的聚合规则，在获取到待监控日志内容的关键字时，可通过匹配关键字的方式对日志内容进行监控，其动态调整及监控的效率大大提升。

将意识到的是，本发明也扩展到适合于将本发明付诸实践的计算机程序，特别是载体上或者载体中的计算机程序。程序可以以源代码、目标代码、代码中间源和诸如部分编译的形式的目标代码的形式，或者以任何其它适合在按照本发明的方法的实现中使用的形式。也将注意的是，这样的程序可能具有许多不同的构架设计。例如，实现按照本发明的方法或者系统的功能性的程序代码可能被再分为一个或者多个子例程。

用于在这些子例程中间分布功能性的许多不同方式将对技术人员而言是明显的。子例程可以一起存储在一个可执行文件中，从而形成自含式的程序。这样的可执行文件可以包括计算机可执行指令，例如处理器指令和/或解释器指令(例如，Java解释器指令)。可替换地，子例程的一个或者多个或者所有子例程都可以存储在至少一个外部库文件中，并且与主程序静态地或者动态地(例如在运行时间)链接。主程序含有对子例程中的至少一个的至少一个调用。子例程也可以包括对彼此的函数调用。涉及计算机程序产品的实施例包括对应于所阐明方法中至少一种方法的处理步骤的每一步骤的计算机可执行指令。这些指令可以被再分成子例程和/或被存储在一个或者多个可能静态或者动态链接的文件中。

另一个涉及计算机程序产品的实施例包括对应于所阐明的系统和/或产品中至少一个的装置中每个装置的计算机可执行指令。这些指令可以被再分成子例程和/或被存储在一个或者多个可能静态或者动态链接的文件中。

计算机程序的载体可以是能够运载程序的任何实体或者设备。例如，载体可以包含存储介质，诸如(ROM例如CDROM或者半导体ROM)或者磁记录介质(例如软盘或者硬盘)。进一步地，载体可以是可传输的载体，诸如电学或者光学信号，其可以经由电缆或者光缆，或者通过无线电或者其它手段传递。当程序具体化为这样的信号时，载体可以由这样的线缆或者其它设备或者装置组成。可替换地，载体可以是其中嵌入有程序的集成电路，所述集成电路适合于执行相关方法，或者供相关方法的执行所用。

应该留意的是，上文提到的实施例是举例说明本发明，而不是限制本发明，并且本领域的技术人员将能够设计许多可替换的实施例，而不会偏离所附权利要求的范围。在权利要求中，任何放置在圆括号之间的参考符号不应被解读为是对权利要求的限制。动词“包括”和其词形变化的使用不排除除了在权利要求中记载的那些之外的元素或者步骤的存在。在元素之前的冠词“一”或者“一个”不排除复数个这样的元素的存在。本发明可以通过包括几个明显不同的元件的硬件，以及通过适当编程的计算机而实现。在列举几种装置的设备权利要求中，这些装置中的几种可以通过硬件的同一项来体现。在相互不同的从属权利要求中陈述某些措施的单纯事实并不表明这些措施的组合不能被用来获益。

如果期望的话，这里所讨论的不同功能可以以不同顺序执行和/或彼此同时执行。此外，如果期望的话，以上所描述的一个或多个功能可以是可选的或者可以进行组合。

如果期望的话，上文所讨论的各步骤并不限于各实施例中的执行顺序，不同步骤可以以不同顺序执行和/或彼此同时执行。此外，在其他实施例中，以上所描述的一个或多个步骤可以是可选的或者可以进行组合。

虽然本发明的各个方面在独立权利要求中给出，但是本发明的其它方面包括来自所描述实施方式的特征和/或具有独立权利要求的特征的从属权利要求的组合，而并非仅是权利要求中所明确给出的组合。

这里所要注意的是，虽然以上描述了本发明的示例实施方式，但是这些描述并不应当以限制的含义进行理解。相反，可以进行若干种变化和修改而并不背离如所附权利要求中所限定的本发明的范围。

本领域普通技术人员应该明白，本发明实施例的装置中的各单元可以用通用的计算装置来实现，各单元可以集中在单个计算装置或者计算装置组成的网络组中，本发明实施例中的装置对应于前述实施例中的方法，其可以通过可执行的程序代码实现，也可以通过集成电路组合的方式来实现，因此本发明并不局限于特定的硬件或者软件及其结合。

本领域普通技术人员应该明白，本发明实施例的装置中的各单元可以用通用的移动终端来实现，各单元可以集中在单个移动终端或者移动终端组成的设备组合中，本发明实施例中的装置对应于前述实施例中的方法，其可以通过编辑可执行的程序代码实现，也可以通过集成电路组合的方式来实现，因此本发明并不局限于特定的硬件或者软件及其结合。

图8是根据一示例性实施例示出的一种用于业务详情分析的nginx日志监控方法的装置1900的框图。例如，装置1900可以被提供为一服务器。参照图8，装置1900包括处理组件1922，其进一步包括一个或多个处理器，以及由存储器1932所代表的存储器资源，用于存储可由处理部件1922的执行的指令，例如应用程序。存储器1932中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1922被配置为执行指令，以执行上述方法。

装置1900还可以包括一个电源组件1926被配置为执行装置1900的电源管理，一个有线或无线网络接口1950被配置为将装置1900连接到网络，和一个输入输出(I/O)接口1958。装置1900可以操作基于存储在存储器1932的操作系统，例如Windows Server TM，MacOSX TM，Unix TM,Linux TM，Free BSD TM或类似。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。

Claims (12)

1.一种nginx日志监控方法，其特征在于，所述方法包括：

获取与业务详情对应的第一分析代码；

根据所述第一分析代码，替换nginx插件中已写入的第二分析代码；

热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件；

所述获取与业务详情对应的第一分析代码之前，还包括：

对所述业务详情对应的聚合场景进行统计，以得到统计数据；

根据所述统计数据定制聚合模型；

其中，每一所述聚合模型包括有对应的第一分析代码；

所述方法还包括：

检测所述业务详情对应的聚合场景是否发生变化；

当所述业务详情对应的聚合场景发生变化时，调用与变化后的聚合场景相对应的聚合模型；

对所述变化后的聚合场景相对应的聚合模型中包括的分析代码替换变化前的所述业务详情所使用的分析代码。

2.根据权利要求1所述的监控方法，其特征在于，热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件之后，还包括：

获取关键字，所述关键字用于匹配日志内容，通过判断日志内容中是否有所述关键字实现对日志内容的监控。

3.根据权利要求2所述的监控方法，其特征在于，所述获取关键字时，包括：

检测所述关键字是否保存在内存中；

在所述关键字未保存在内存时，在内存中建立一关键字数据库，并将所述关键字保存在该关键字数据库中。

4.一种nginx日志监控装置，其特征在于，所述装置包括：

获取模块，被配置用于获取与业务详情对应的第一分析代码；

替换模块，被配置用于根据所述第一分析代码，替换nginx插件中已写入的第二分析代码；

装配模块，被配置用于热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件；

所述装置还包括：

统计模块，被配置用于对所述业务详情对应的聚合场景进行统计，以得到统计数据；

定制模块，根据所述统计数据定制聚合模型；其中，每一所述聚合模型包括有对应的第一分析代码；

所述装置还包括：

第三检测模块，被配置用于检测所述业务详情对应的聚合场景是否发生变化；

调用模块，被配置用于当所述业务详情对应的聚合场景发生变化时，调用与变化后的聚合场景相对应的聚合模型；

替换模块，被配置用于对所述变化后的聚合场景相对应的聚合模型中包括的分析代码替换变化前的所述业务详情所使用的分析代码。

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

第二获取模块，被配置用于获取关键字，所述关键字用于匹配日志内容，通过判断日志内容中是否有所述关键字实现对日志内容的监控。

6.根据权利要求5所述的监控装置，其特征在于，所述第二获取模块还包括：

检测模块，被配置用于检测所述关键字是否保存在内存中；

建立模块，被配置用于在所述关键字未保存在内存时，在内存中建立一关键字数据库，并将所述关键字保存在该关键字数据库中。

7.一种消息分布系统，其特征在于，所述系统包括：

中心节点，其提供有可操作接口，以获取与业务详情相对应的第一分析代码；

子节点，其具有数据接口，所述数据接口被配置用于接收对各子节点的第二分析代码；

所述中心节点与各所述子节点通过数据接口实现订阅关系，其中的中心节点将获取的第一分析代码下发至各所述子节点的数据接口，以使对各所述子节点用所述第一分析代码替换第二分析代码；

所述中心节点针对不同类型的业务详情定制聚合模型，所述聚合模型中包括有与业务详情相对应的第一分析代码，所述中心节点向各所述子节点下发聚合模型时，各所述子节点接收所述聚合模型，用所述聚合模型包括的第一分析代码替换各所述子节点的第二分析代码后，根据所述第一分析代码所体现出来的聚合规则对日志内容进行分析处理；

所述中心节点检测所述业务详情对应的聚合场景是否发生变化；当所述业务详情对应的聚合场景发生变化时，调用与变化后的聚合场景相对应的聚合模型；对所述变化后的聚合场景相对应的聚合模型中包括的分析代码替换变化前的所述业务详情所使用的分析代码。

8.根据权利要求7所述的消息分布系统，其特征在于，还包括有数据仓储，用于记录所述中心节点与各所述子节点的消息量的数据输出；

其中，所述数据仓储与所述中心节点部署于同一nginx服务器。

9.根据权利要求7所述的消息分布系统，其特征在于，所述中心节点还包括有一评估模块，该评估模块被配置用于：

评估业务详情所包括的日志内容的总量；

在所述总量超过预设阈值时，通过网络设置新的子节点，并建立该新的子节点与中心节点的订阅关系，以使该新的子节点能够接收所述第一分析代码和/或所述聚合模型，以按照所述第一分析代码和/或所述聚合模型中包含的聚合规则对日志内容进行分析处理。

10.根据权利要求7所述的消息分布系统，其特征在于，所述中心节点还配置有一脚本管理模块，

该脚本管理模块用于，根据各所述子节点接收到的聚合模型，调用配置信息管理脚本，并将各所述聚合模型写入各子节点的配置文件中，以将各所述子节点分析处理后的日志内容动态输出到各所述子节点以及所述中心节点中。

11.一种信息处理的装置，其特征在于，包括：

处理器；

用于存储处理器可执行命令的存储器；

其中，所述处理器被配置为：

获取与业务详情对应的第一分析代码；

根据所述第一分析代码，替换nginx插件中已写入的第二分析代码；

热重启所述nginx插件，以动态装配写入所述第一分析代码的nginx插件；

所述获取与业务详情对应的第一分析代码之前，所述处理器还被配置为：

对所述业务详情对应的聚合场景进行统计，以得到统计数据；

根据所述统计数据定制聚合模型；

其中，每一所述聚合模型包括有对应的第一分析代码；

所述处理器还被配置为：

检测所述业务详情对应的聚合场景是否发生变化；

当所述业务详情对应的聚合场景发生变化时，调用与变化后的聚合场景相对应的聚合模型；

对所述变化后的聚合场景相对应的聚合模型中包括的分析代码替换变化前的所述业务详情所使用的分析代码。

12.一种计算机可读存储介质，其上存储有计算机指令，其特征在于，该指令被处理器执行时实现上述权利要求1-3中任一项所述方法的步骤。