一种用于Nginx日志实时处理分析的方法及终端与流程

本发明涉及数据处理技术领域，特别涉及一种用于nginx日志实时处理分析的方法及终端。

背景技术：

web软件nginx，因为其轻量级、高性能的优点，目前被普遍用作企业级网络服务的http(hypertexttransferprotocol，超文本传输协议)和反向代理服务器。作为企业所有网络服务的统一http请求入口，其运行期间所产生的nginx日志记录着所有http请求的详细信息。通过分析该日志可以用于分析外部用户的行为特点以及内部服务的运行状况，分析结果将对企业的产品运营和服务维护产生重要的价值。

目前，业界多使用开源的elkstack(简称elk)对nginx这样的网络服务日志进行采集、处理和分析。elk是三种不同日志处理工具(elasticsearch、logstash、kibana)的首字母缩写，它们三者分工各不相同，分别为：

elasticsearch是个分布式的搜索引擎，负责日志的存储和检索。

logstash主要负责对数据的采集和过滤。

kibana提供了一个友好的web界面，负责对日志的可视化分析和汇总。

三个工具相辅相成，常常被放在一起使用，作为网络日志统一采集、管理、分析处理的整体解决方案。

现有的采用elk工具对日志进行实时采集分析的方式存在以下缺点：对大规模数据的实时查询响应慢。elasticsearch作为一个分析处理日志的全文搜索引擎，它会存储下所有采集到的日志数据。当nginx日志规模非常庞大的情况下，以申请人所在公司为例，一天的nginx日志就有十几亿条，数据大小1tb左右，从一天十几亿的全量数据中进行检索会非常耗时。

技术实现要素：

本发明所要解决的技术问题是：提供一种用于nginx日志实时处理分析的方法及终端，以实现快速查询。

为了解决上述技术问题，本发明采用的技术方案为：

一种用于nginx日志实时处理分析的方法，包括步骤：

s1、实时采集并存储nginx日志；

s2、将所述nginx日志中满足预设参数的原文数据聚合压缩，得到并存储聚合后的查询数据至查询数据库；

s3、接收分析查询请求，从所述查询数据库中获取并返回与所述分析查询请求相对应的查询结果。

为了解决上述技术问题，本发明采用的另一种技术方案为：

一种用于nginx日志实时处理分析的终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述的一种用于nginx日志实时处理分析的方法。

本发明的有益效果在于：一种用于nginx日志实时处理分析的方法及终端，对于nginx日志中满足预设参数的原文数据聚合压缩，得到并存储聚合后的查询数据至查询数据库，使得后续进行分析查询的数据是聚合后的查询数据，由于原文数据聚合压缩后的数据减少，即减少了后续查询的数据量，从而提高了查询速度，以实现快速查询。

附图说明

图1为本发明实施例的一种用于nginx日志实时处理分析的方法的流程示意图；

图2为本发明实施例的一种用于nginx日志实时处理分析的方法与使用工具之间的对应流程示意图；

图3和图4为本发明实施例的一种用于nginx日志实时处理分析的方法在实际应用过程中的结果示意图；

图5为本发明实施例的一种用于nginx日志实时处理分析的终端的结构示意图；

图6为本发明实施例的一种用于nginx日志实时处理分析的终端的模块示意图。

标号说明：

1、一种用于nginx日志实时处理分析的终端；2、处理器；3、存储器。

具体实施方式

为详细说明本发明的技术内容、所实现目的及效果，以下结合实施方式并配合附图予以说明。

请参照图1至图4，一种用于nginx日志实时处理分析的方法，包括步骤：

s1、实时采集并存储nginx日志；

s2、将所述nginx日志中满足预设参数的原文数据聚合压缩，得到并存储聚合后的查询数据至查询数据库；

s3、接收分析查询请求，从所述查询数据库中获取并返回与所述分析查询请求相对应的查询结果。

从上述描述可知，本发明的有益效果在于：对于nginx日志中满足预设参数的原文数据聚合压缩，得到并存储聚合后的查询数据至查询数据库，使得后续进行分析查询的数据是聚合后的查询数据，由于原文数据聚合压缩后的数据减少，即减少了后续查询的数据量，从而提高了查询速度，以实现快速查询。

进一步地，所述步骤s1具体包括以下步骤：

通过日志采集工具将各服务器上的nginx日志统一实时采集并按照预设格式存储到服务集群中，每条所述nginx日志的原文数据记录着来自外部的一个http请求的信息。

从上述描述可知，通过日志采集数据对外部每一个http请求的信息以一个原文数据进行对应采集和存储，以便于后续的统计。

进一步地，所述预设参数包括维度变量和指标变量，所述维度变量包括服务维度、时间维度、接口维度、产品维度和用户维度，所述指标变量包括总请求数、错误请求数、慢响应请求数；

所述步骤s2具体包括以下步骤：

将所述nginx日志中满足同一所述预设参数的原文数据聚合压缩成一条并统计对应所述原文数据的个数，得到并存储聚合后的查询数据至查询数据库。

进一步地，所述步骤s2具体包括以下步骤：

获取所述nginx日志的原文数据中的域名信息、原始时间戳、接口字段、产品id、已加密token字符串、状态码和响应时间，将所述域名信息通过映射关系转换为服务名称，将所述原始时间戳转换为所支持查询分析的时间级，得到时间信息，对所述接口字段替换成restful格式的接口信息，从mysql中的关联映射表中查询所述产品id所对应的产品名称，通过账号中心接口对所述token字符串进行解密得到用户id，根据所述状态码和所述响应时间对应统计到每一个所述指标变量上，得到包括所述服务名称、所述时间信息、所述接口信息、所述产品名称、所述用户id以及每一个所述指标变量的统计结果的中间过程数据；

将所述中间过程数据按照所述维度变量进行分组并按照分组对所述指标变量进行聚合统计，得到查询数据；

将所述查询数据存储至查询数据库。

从上述描述可知，通过上述的处理方式，相对于原先的elk查询工具来说，能够通过对原文数据的转换处理得到所需要的维度变量，并基于多个维度变量进行分组，从而实现了数据量的大幅度减少，即使得本发明能快速实现多种维度的查询，从而节省时间和人力成本，并且基于指标变量和维度变量的对应关系，在服务发送错误或响应太慢时，可以快速确定是由哪些维度变量所引起的，从而缩短故障处理时间，减少企业的经济损失。

进一步地，所述步骤s2中所述对所述接口字段替换成restful格式的接口信息具体包括以下步骤：

判断所述接口字段是否在接口管理工具中注册，若有注册，则从所述接口管理工具中获取restful格式的接口注册信息，将所述接口注册信息替换为正则表达式，通过所述正则表达式与所述接口字段进行匹配，若匹配成功，则使用所述接口注册信息作为接口信息；

若没有在接口管理工具中注册，则根据预设的转换规则将所述接口路径中的字符串替换成对应的占位符。

从上述描述可知，当对于已经在接口管理工具中注册的，可以使用正则表达式匹配，从而在匹配成功之后使用接口注册信息替换原先的接口字段，从而得到restful格式的接口信息；而对于没有注册的接口来说，采用预设的转换规则将字符串替换成对应的占位符，由于对应的参数都被替换成同样的占位符，从而使得可以对某个服务名下各个接口进行聚合统计。

进一步地，所述步骤s2中所述根据预设的转换规则将所述接口路径中的字符串替换成对应的占位符具体包括以下步骤：

将所述接口路径中的字符串中符合全数字、uuid格式、64位以上token字符串以及末尾有文件名后缀的分别替换成对应的占位符。

从上述描述可知，即将有影响同一个接口的参数进行统一化，以实现基于接口维度的聚合统计。

进一步地，所述步骤s2具体包括以下步骤：

将所述nginx日志中满足预设参数的原文数据聚合压缩，得到聚合后的查询数据；

将聚合后的所述查询数据存储在hive数据库，所述hive数据库中每一张hive表格中的每一个分区所对应的分区字段包括日期和小时。

从上述描述可知，采用日期和小时两个分区字段，使得当用户仅查询过去某个小时内某服务的访问详情时，因为数据有以小时作为分区，那么仅需读取出当前小时分区中的数据进行计算即可，相比于仅以日期作为分区，读出当天全部的数据再从中筛选出当前小时的数据进行同样计算来说其查询效率更高。

进一步地，所述步骤s2中所述将聚合后的所述查询数据存储在hive数据库具体包括以下步骤：

每当进入新的一个小时时，通过一合并程序将上一个小时分区中所存储的所有原有数据进行读取并合并成一个新的数据文件，将所述新的数据文件以覆盖的形式写回所述上一个小时分区中。

从上述描述可知，将一个小时内的所有小文件整合成一个按小时分区的大文件，避免了小文件过多会使得查询效率降低的问题。

进一步地，所述步骤s1具体包括以下步骤：

使用filebeat日志采集工具实时采集并存储nginx日志至kafka集群中；

所述步骤s2具体包括以下步骤：

使用sparkstreaming将所述kafka集群所存储的所述nginx日志中满足预设参数的原文数据聚合压缩，得到并存储聚合后的查询数据至hive数据库；

所述步骤s3具体包括以下步骤：

接收分析查询请求，基于presto数据查询引擎从所述hive数据库中获取并返回与所述分析查询请求相对应的查询结果。

从上述描述可知，将presto作为数据查询引擎其计算的全部过程都在内存中进行，查询效率要远远优于hive数据库自带的查询，从而提高查询速度。

请参照图5和图6，一种用于nginx日志实时处理分析的终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述的一种用于nginx日志实时处理分析的方法。

从上述描述可知，本发明的有益效果在于：对于nginx日志中满足预设参数的原文数据聚合压缩，得到并存储聚合后的查询数据至查询数据库，使得后续进行分析查询的数据是聚合后的查询数据，由于原文数据聚合压缩后的数据减少，即减少了后续查询的数据量，从而提高了查询速度，以实现快速查询。

请参照图1至图4，本发明的实施例一为：

一种用于nginx日志实时处理分析的方法，包括步骤：

s1、实时采集并存储nginx日志；

步骤s1具体包括以下步骤：

通过日志采集工具将各服务器上的nginx日志统一实时采集并按照预设格式存储到服务集群中，每条nginx日志的原文数据记录着来自外部的一个http请求的信息。

在本实施例中，使用filebeat作为日志采集工具。

s2、将nginx日志中满足预设参数的原文数据聚合压缩，得到并存储聚合后的查询数据至查询数据库；

其中，网络服务的开发者在日常运维分析过程中，一般仅关注当前服务的几个特殊运维指标，例如总请求数、5xx请求数(状态码以5开头的http请求，一般表示服务器内部错误)、4xx请求数(状态码以4开头的http请求，一般表示客户端导致的错误)、慢响应请求(一般响应时间大于1秒的http请求即可认为是慢请求)。其中，5xx请求数和4xx请求数可归类为错误请求。

除了在全局角度统计外，开发者有时候也需要从接口、产品、用户等不同维度来统计上述的运维指标。这个恰恰是现有的elk工具做不到的，譬如开发者想查看当前服务各个接口的访问量情况，由于elk中记录的是原始请求中的接口信息，路径当中和路径结尾含有不同的参数信息，无法对同类型的接口进行聚合统计。

基于以上场景，我们整理归纳了网络服务日常运维统计分析中常用的维度变量和指标变量，即预设参数包括维度变量和指标变量，维度变量包括服务维度、时间维度、接口维度、产品维度和用户维度，指标变量包括总请求数、错误请求数、慢响应请求数。

其中，本实施例使用sparkstreaming将kafka集群所存储的nginx日志中满足预设参数的原文数据聚合压缩，得到并存储聚合后的查询数据至hive数据库；其中，sparkstreaming是一套框架，sparkstreaming是spark核心api的一个扩展，可以实现高吞吐量的，具备容错机制的实时流数据处理。kafka是一个分布式的信息流式处理的工具。

其中，步骤s2具体包括以下步骤：

s21、获取nginx日志的原文数据中的域名信息、原始时间戳、接口字段、产品id(identitydocument，身份标识)、已加密token字符串、状态码和响应时间；

其中，token是计算机身份认证中的临时令牌。

s22、将域名信息通过映射关系转换为服务名称；

日志原文中仅存有所请求的域名信息，而一个服务名下可能有多个域名，所以我们需要将这里的域名信息转换成对应的服务信息。而在现有的elk工具中，由于它是通过事先设定好的配置文件对日志原文进行解析，所以除非日志原文中冗余存储了服务信息，否则无法实现上述域名到服务的映射转换。

s23、将原始时间戳转换为所支持查询分析的时间级，得到时间信息；

由于sparkstreaming是以数据的到达时间为间隔对数据进行切分然后按批次进行处理，假设本实施例所要支持是时间级是支持分钟级的查询，所以此处每1分钟处理一批数据，严格来说，这里是一种准实时的处理。

由于最后的查询分析基于分钟粒度，所以先将日志中的请求发生时间转化为以秒为单位的时间戳，然后除以60并向下取整作为该请求的发生时间，这样后续同一分钟内相同维度组合的请求便可以进行聚合统计，旨在减少最后留存在结果表中的数据量。

因为我们提供的是分钟级的统计结果查询。所以此处如果其他维度值都相同，那么同一分钟内的多次请求数据会被聚合为一条查询数据。举个例子，在其他维度变量(服务、接口、产品、用户)都相同的情况下，2021-04-2710:05:12(时间戳1619489112)有一条请求，2021-04-2710:05:46(时间戳1619489146)又有一条请求，那么这两条请求的时间戳都会处理成1619489100(2021-04-2710:05:00)，聚合后访问量会记作2，表示当前维度下在2021-04-2710:05:00～2021-04-2710:06:00这一分钟内有2条请求。这样原始记录下的2条记录就会被记为1条记录。

另外，由于个别日志有可能会延迟到达，下一批次数据处理的时候可能还有这一分钟内的另外三条请求记录，同理也会被合成一条记录。最后presto查询的时候按“时间(分钟)+服务+接口+产品+用户”聚合，访问量相加，就能得出该服务+接口+产品+用户在该分钟下的访问量为5。详见后续举例。

s24、对接口字段替换成restful格式的接口信息；

由于日志原文中的接口字段包含有参数信息，参数信息可能出现在接口路径中间，也有可能以“？”作为分隔符出现在接口路径后面。这样同一个接口会因为参数的不同而无法实现聚合统计，目前elk上便无法统计某个服务名下各个接口每天的访问量数据。

由此，在本实施例中，步骤s24中对接口字段替换成restful格式的接口信息具体包括以下步骤：

s241、判断接口字段是否在接口管理工具中注册，若有注册，则从接口管理工具中获取restful格式的接口注册信息，将接口注册信息替换为正则表达式，通过正则表达式与接口字段进行匹配，若匹配成功，则使用接口注册信息作为接口信息；

其中，restful是一种网络应用程序的设计风格和开发方式，基于http，可以使用xml格式定义或json格式定义。

其中，对接口字段替换成restful格式示例如下：

get/v0.1/users/123456？time＝1618392005＝》get/{version}/id/{user_id}。

在本实施例中，swagger作为一款开源的接口管理工具，将需要监测的服务在swagger上注册接口信息，从而从swagger获取服务的接口注册信息，而将其中{}占位符中的内容替换为正则表达式，如下：

get/{version}/id/{user_id}＝》get/[^/]+？/id/[^/]+？。

然后将该正则表达式与nginx日志的原文数据中的接口字段进行匹配，即舍弃掉路径“？”后面的参数，如果匹配成功则使用swagger中的restful格式接口对当前接口信息进行替换。

s242、若没有在接口管理工具中注册，则将接口路径中的字符串中符合全数字、uuid(universallyuniqueidentifier，通用唯一识别码)格式、64位以上token字符串以及末尾有文件名后缀的分别替换成对应的占位符。

如果有的服务没有在swagger中注册接口，则包括以下字符串和对应占位符如下：

(1)、全数字：/id/123456替换为/id/{num}。

(2)、uuid格式:/id/4ff99fbd-1a56-4a95-8682-dab52782e823替换为/id/{uuid}。

(3)、64位以上token字符串:/token/7f938b205f876fc3398a4d17a79f93c72bdbb410117be7aeee04b2a4988de1b48151a0d1deef882d04f855650a6fb6b1替换为/token/{token-string}。

(4)、末尾有文件名后缀:/file/tmp.txt替换为/file/{filename}。

(5)、15位以上全大写或全小写的字符串:/app/iejxidheuygeojdlf替换为/app/{id}。

s25、从mysql中的关联映射表中查询产品id所对应的产品名称，通过账号中心接口对token字符串进行解密得到用户id；

其中，凡是用户通过产品发送到服务端的请求都会在请求的头信息中带上产品id，这些信息会记录在nginx日志原文中。我们将日志原文的产品id提取出来，由于产品id与产品名称是一一对应的关系，因此可以从mysql(关系型数据库管理系统)中的关联映射表中查询得到，同理，表中的服务id与服务名称也是一一对应的关系。得到产品id对应的产品名称，一起存储在结果表中，后续可以按产品名称来展示当前服务被各产品访问的详情。

其中，出于对用户个人信息的保护以及网络安全的考虑，日志原文中不会明文记录用户的id和密码等信息。用户是以服务端提供的密钥在客户端本地进行加密后得到一个token字符串用于服务端进行身份认证和权限鉴别等操作。这个token字符串到期后会进行更新，所以一个用户可能对应多个token字符串。所以目前elk工具中也无法对用户维度的信息进行统计。

按照上述步骤s25即可以实现用户id获取，从而支持后续对用户进行统计分析。

s26、根据状态码和响应时间对应统计到每一个指标变量上，得到包括服务名称、时间信息、接口信息、产品名称、用户id以及每一个指标变量的统计结果的中间过程数据；

在对nginx日志中上述维度信息进行特殊处理后，结合nginx中已有的请求状态码和请求响应时间等信息，sparkstreaming以“服务+时间+接口+产品+用户”的维度组合对当前批次的数据进行聚合，计算出总请求数、5xx请求数、4xx请求数、大于1秒慢请求数、大于3秒慢请求数、大于5秒慢请求数、大于10秒慢请求数等指标。将聚合后的查询数据写入hive数据库的表格中。

经过这轮聚合压缩，每天10亿左右的nginx日志原文数据变为聚合后的1100多万条，日志规模变为原来的百分之一左右，为后续快速的即时查询提供了保障。

s27、将中间过程数据按照维度变量进行分组并按照分组对指标变量进行聚合统计，得到查询数据；

s28、将查询数据存储至查询数据库。

其中，聚合后的数据会写入hive数据库中，查询数据所对应结果表的表结构信息如下表1：

表1：表结构信息

其中，当前维度指表中所有维度变量的维度组合，本例中为“服务+时间+接口+产品+用户”，同一批次数据经处理后得到的查询数据里，这个维度组合是唯一的。详见上述数据举例。

s3、接收分析查询请求，从查询数据库中获取并返回与分析查询请求相对应的查询结果。

其中，由于hive查询是基于hadoop中的mapreduce进行计算的，这种计算框架会将中间数据缓存在磁盘中，由于磁盘的读写速度较慢，所以hive查询并不能满足即时查询的需求。由此采用presto作为本终端的数据查询引擎，presto与hive查询最大的不同在于其计算的全部过程都在内存中进行，查询效率要远远优于hive。

另外presto支持jdbc协议，可以通过jdbc连接hive查询，其查询语法与hive的语法有所差异，但是都是类sql语句，因此可以基于hive数据库使用presto进行数据查询。

以下是前端界面接入presto查询后可以通过不同维度来查询当前服务访问详情的效果如图5所示，其展示的是查看某个服务某段时间内不同接口的访问量详情。开发者可以快速便捷地知晓自己服务下各个接口的访问量、5xx错误数、慢请求数以及请求响应延时等指标，便于快速发现服务的线上质量问题，缩短故障处理时间，减少企业的经济损失。用户还可以通过切换维度下拉框中的维度，以产品或用户角度来展示请求详情，这种自由灵活的查询是通过elk工具做不到的，从而使开发和运维人员便捷地了解当前服务的运行状况，获知不同维度下的访问详情，节省时间和人力成本。同时，因为数据经过聚合压缩，借助presto查询引擎，上述的查询可以实现秒级响应，基本一秒内能返回查询结果。相比elk上基于日志全文动辄十几秒甚至几十秒的查询来的快许多。

我们不仅能在单一维度上进行查询，多个维度还能联合起来实现多层次的查询，类似于关系型数据库中的olap(联机分析处理)，具体参照图6。

其显示的当前服务的某个接口下各来源产品的分布详情，开发者可以清楚的知道哪个产品访问当前接口最频繁。同理，也可以切换到用户维度查看是哪些用户访问当前接口最频繁。

另外，本终端的维度和指标是可拓展的。由于hive表格是可以支持新增列的，如需新增新的统计维度和指标，仅需在hive表格中添加对应的维度和指标即可，同时在sparkstreaming计算程序中新增新维度或新指标的计算处理代码即可。同时，存储在数据仓库中的nginx日志结果表还可以与仓库中的其他外部数据进行多表关联查询。

由此，对于现有技术来说，如果同时间有多个用户在进行查询，会导致elasticsearch后台的内存资源消耗殆尽，导致服务不可用。而在本实施例中可以分担原先elk集群的查询压力，elk集群如果仅用来查询日志明细信息，便无需配置过多的计算资源，减少企业的硬件成本。

由上，为了便于理解本发明，对本实施例的步骤进行具体举例说明如下：

假设nginx日志中原文数据如下表2(仅举例与本实施例相关关键字段)：

表2-当前批次的原文数据

对原文数据按照步骤s21至步骤s27先做转换，得到中间过程数据，仅列举部分指标变量，得到表3：

表3-中间过程数据

上述请求都在10:05～10:06这一分钟里，时间信息都记为10:05的时间戳。

其中，时间为10位时间戳。

对上述转换后的中间过程数据按维度变量进行分组(groupby，每一个维度都要参与)，指标变量依据分组进行聚合统计(累加或取最大最小值)，得到查询数据写入hive表中，查询数据如下表4：

表4-中间过程数据

经过上述步骤，当前批次内5条数据便被压缩聚合为hive结果表中的3条数据。实际结果是每天10亿左右的nginx日志原文数据变为聚合后的1100多万条。这些聚合后的查询数据足以日常服务运维统计分析中的分钟级的多维度查询。无需从elk的日志原文数据中进行查询。

上述数据求某段时间内服务某接口的平均响应时间，只要将这个接口在这段时间内的sum(响应时间求和)/sum(请求数)即可求得，如果要求某接口的最大响应时间，只要求这个接口的max(最大响应时间)即可得到。

请参照图1至图4，本发明的实施例二为：

一种用于nginx日志实时处理分析的方法，在上述实施例一的基础上，步骤s2具体包括以下步骤：

将nginx日志中满足预设参数的原文数据聚合压缩，得到聚合后的查询数据；

将聚合后的查询数据存储在hive数据库，hive数据库中每一张hive表格中的每一个分区所对应的分区字段包括日期和小时。

其中，步骤s2中将聚合后的查询数据存储在hive数据库具体包括以下步骤：

每当进入新的一个小时时，通过一合并程序将上一个小时分区中所存储的所有原有数据进行读取并合并成一个新的数据文件，将新的数据文件以覆盖的形式写回上一个小时分区中。

即在本实施例中，在hive数据库存储中采用了两个旨在优化查询效率。

(1)hive表分区设置

这里采用日期和小时两个分区字段，目的是为了提高查询效率。hive作为hadoop生态系统中的一员，hive的底层存储是依赖于hdfs分布式文件存储系统。每张hive表格对应hdfs中的一个目录，hive表中的分区则对应该目录下的子目录。在hive的类sql查询语句中使用分区变量作为过滤条件，能将查询限制在所需分区数据中读入并计算，避免对全表数据进行读取，以此来提升查询效率。在本终端中，当用户仅查询过去某个小时内某服务的访问详情时，因为数据有以小时作为分区，那么仅需读取出当前小时分区中的数据进行计算即可，相比于仅以日期作为分区，读出当天全部的数据再从中筛选出当前小时的数据进行同样计算来说其效率更高。

(2)hive小文件合并

然而，分区的粒度并非分的越细越好。此处并未以分钟作为分区，原因是分区过细会导致hive表在底层hdfs中出现过多用于存储数据的小文件。如果以分钟作为分区，每个分区中以最少一个文件计，那么一天至少会有24*60＝1440个小文件。小文件过多会使得hive查询效率降低。一个原因是因为过多的元数据信息会消耗查询时主节点的内存，另外一个原因是hive查询时会为每一个小文件开启一个jvm进程进行计算，这么多任务的初始化、启动、执行会消耗大量的计算资源。所以，我们采取以小时作为结果表里最小的分区粒度。

由于sparkstreaming每分钟都会往hive中写入数据，一批数据会在hdfs形成一份小文件，所以为了控制小文件数量，我们会启动另外一个轻量级的sparkstreaming程序定时对小文件进行合并。具体策略为：当进入一个新的小时的时候，轻量级的sparkstreaming程序会将刚过去的上一个小时分区的数据读取出来合并成一个大文件，然后再写回这个小时分区中并将原有的数据覆盖。

请参照图5和图6，本发明的实施例三为：

一种用于nginx日志实时处理分析的终端1，包括存储器3、处理器2及存储在存储器3上并可在处理器2上运行的计算机程序，处理器2执行计算机程序时实现上述实施例一或二的步骤。

如图6所示，若将一种用于nginx日志实时处理分析的终端1表示为功能模块连接组成，则由依次连接的数据采集模块、数据实时处理模块、数据存储模块和数据查询模块。

综上所述，本发明提供的一种用于nginx日志实时处理分析的方法及终端，对于nginx日志中基于多个维度变量进行分组，从而大幅度减少了后续查询的数据量；得到并存储聚合后的查询数据至查询数据库，采用日期和小时两个分区字段，并将一个小时内的所有小文件整合成一个按小时分区的大文件；并将presto作为数据查询引擎，以大幅度提高查询速度，从而实现快速查询。同时，基于多个维度变量，本发明能快速实现多种维度的查询，从而节省时间和人力成本，并且基于指标变量和维度变量的对应关系，在服务发送错误或响应太慢时，可以快速确定是由哪些维度变量所引起的，从而缩短故障处理时间，减少企业的经济损失。

以上所述仅为本发明的实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等同变换，或直接或间接运用在相关的技术领域，均同理包括在本发明的专利保护范围内。