CN116800596A - 一种日志无损压缩分析方法和系统 - Google Patents

Abstract

本发明涉及一种日志无损压缩分析方法和系统。由压缩客户端从项目和功能两个维度对日志进行相似性压缩处理，产生日志记录；由日志压缩服务模块根据压缩时长要求分割日志记录、生成经压缩的日志并其保存到分布式存储服务中，并为每个经压缩的日志生成对应的元数据记录并将其保存到列式数据库中。其中，所述分布式存储服务和所述列式数据库存在于日志无损压缩分析服务端中。本发明既能直接输出运维、质量等工作需要的日志分析结果，又不损失任何原始日志信息，同时还能降低IT资源投入。

Description

一种日志无损压缩分析方法和系统

技术领域

本发明涉及IT与软件开发领域，尤其涉及一种日志无损压缩分析方法和系统。

背景技术

日志记录了与业务相关的所有用户每次访问的详细信息，能全面量化反映一个互联网服务的访问量、成功率、性能等的变化，有助于相关服务运行质量的保障和持续提升。

以Nginx日志为例，由于时刻都在更新，会产生数量巨大的日志数据，有些业务每天产生的日志量就达数十亿条，占用几十TB甚至更多的存储。如需长期保存数据，还需要不断增加服务器和存储资源。而且日志数据数量巨大还容易造成响应速度慢。

为应对海量日志处理分析的挑战，降低相关服务器资源的消耗，常见的做法包括：采用zip等方式压缩数据封存、只分析最近的部分日志或只分析经过一定的聚合或压缩后的结果数据。

例如，CN106354617A公开一种程序压缩性日志文件输出方法及装置，对于每条日志数据，将其中的日期字段与为本日志文件定义的起始时间字段的时间差值作为压缩后的日期字段表达式，采用预置的为各字段格式化串所分配的特定编号作为压缩后的字段名表达式；替换日志数据中存在的大量重复字段的格式化行信息。该方法虽然可以减少存储空间的占用，但一方面用户无法根据压缩后的日志文件方便快速地获取日志文件的主要价值，例如Nginx日志包含的一定时间内的访问量、性能和错误率等；另一方面，用户也无法从压缩后的日志文件中，搜索Nginx日志的各个字段的内容，无法集中综合分析、监控日志的变化。

再如，CN113312376A公开了一种用于Nginx日志实时处理分析的方法及终端，将Nginx日志中满足预设参数的原文数据聚合压缩，得到并存储聚合后的查询数据至查询数据库；后续进行分析查询的数据是聚合后的查询数据。然而，该方案聚合后会丢失一批重要数据，例如客户端agent或SSL协议的详细信息、TP99等不同百分位性能等，导致聚合后用户仍然无法删除原始日志，否则会彻底丢失部分原始数据，实际上无法节约存储；此外，该方案聚合后把所有业务字段都放在一个结果表中，随着业务字段数的增加，其维度的组成字段会越来越多，聚合后的记录数会呈指数级增长，与压缩的需求背离。

因此，亟须一种既能直接输出运维、质量等工作需要的日志分析结果，又不损失任何原始日志信息，同时还能降低IT资源投入的日志无损压缩分析方法和系统。

发明内容

为了降低日志记录的长度并方便搜索内容的目的，本发明针对压缩需要预处理原始日志，允许用户针对不同的项目自定义不同的压缩格式，支持采用广泛的分布式存储服务保存压缩后的文件，在压缩文件的命名中包含产品、项目、功能(可选)、机房、压缩时间段的信息。

根据Nginx日志分析的实际需求，支持从一定时长的压缩内容自动生成包括一系列重要指标的一条说明记录，作为压缩文件的元数据，用来描述压缩数据的主要特征，该元数据记录的具体字段包括开始和结束时间、访问量(压缩记录数)、最大性能和性能中位数、最大的前K(可设置)个性能、错误量等，支持在生成过程中自动判断具体生成哪些指标的数据，允许用户自定义配置需要生成哪些或不必生成哪些，允许对应多个压缩文件，再把结果数据和对应的压缩文件的存储路径、大小等信息组装为一条记录后保存到列式存储服务。

支持通过Grafana或自定义UI基于列式存储服务从项目、功能两个维度分析压缩后的数据。相比直接检索、分析原始Nginx日志，使得任何查询条件下都可以获得一样的输出，同时可以更块地获得更多类型的分析结果。

本发明涉及一种日志无损压缩分析系统，包括：压缩客户端，用于读取日志，从项目和功能两个维度对日志进行相似性压缩处理，产生日志记录；日志压缩服务模块，根据压缩时长要求分割日志记录、生成经压缩的日志并将经压缩的日志保存到分布式存储服务中，并为每个经压缩的日志生成对应的元数据记录并将元数据记录保存到列式数据库中；以及日志无损压缩分析服务端，用于接收和处理日志查询和分析请求，从列式数据库和分布式存储服务两者组合检索，并提供压缩配置管理。

本发明还涉及一种日志无损压缩分析方法，包括：由压缩客户端从项目和功能两个维度对日志进行相似性压缩处理，产生日志记录；由日志压缩服务模块根据压缩时长要求分割日志记录、生成经压缩的日志并将经压缩的日志保存到分布式存储服务中，并为每个经压缩的日志生成对应的元数据记录并将元数据记录保存到列式数据库中。

本发明相对于现有技术的优势在于：

■支持大幅无损压缩原始Nginx日志，降低海量日志对存储空间的要求，在搜索结果上不会丢失原始日志的任意记录和字段的内容，能在压缩的过程中自动生成压缩文件的元数据并保存到列式数据库服务，支持高性能分析压缩后的日志，能满足基于Nginx日志的运维监控、分析等工作的需求；

■综合列式数据库及分布式文件存储服务的主要特点在实现日志压缩的同时支持搜索压缩后的文件，可以根据实际日志分析需要确定需要针对压缩文件生成哪些元数据字段并存储到不同的列式数据库，也可以选用不同的压缩文件存储服务，具备比关系数据库更高的日志分析性能和并发能力，还能搜索压缩后的日志文件的内容；

■压缩过程中不会大量增加Nginx服务器的负载；在日志分析领域，相比常见的ELK架构、基于Hadoop的大数据架构，整个技术方案经济且方便实施，相同配置的集群分析、查询性能更高，有助于提高IT资源的效能、降低资源成本。

通过阅读下面的详细描述并参考相关联的附图，这些及其他特点和优点将变得显而易见。应该理解，前面的概括说明和下面的详细描述只是说明性的，不会对所要求保护的各方面形成限制。

附图说明

以下将通过参考附图中示出的具体实施例来对本发明进行更具体描述。

图1是根据本发明的一种日志无损压缩分析系统的示意框图；

图2是根据本发明的一种日志无损压缩分析方法的压缩客户端处理过程流程图；

图3是根据本发明的一种日志无损压缩分析方法的压缩服务处理过程流程图；

图4是根据本发明的一种日志无损压缩分析方法的服务端处理过程流程图；

图5是本发明技术方案相关业务表的设计示意。

附图中的流程图和框图显示了根据本申请的实施例的系统、方法可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。

具体实施方式

本申请基于日志各字段内容以及各日志记录之间的特点，针对分析、监控等实际工作的需要，采用压缩客户端、日志压缩服务和服务端，配合列式数据库和分布式文件存储服务，实现了对Nginx日志的无损、更好压缩效果，能在压缩过程中自动生成压缩文件的元数据，进一步支持针对元数据的高性能日志分析、监控和对压缩后文件的在线搜索，搜索结果与直接搜索原始日志文件一致。

具体而言，本发明采用下列方案实现Nginx日志的无损压缩、分析方案，支持对全部原始日志数据的高效查询、分析，降低存储占用：

1、双维度处理：针对Nginx日志各字段数据的特点，从项目、功能两个维度分别处理原始Nginx日志，再生成压缩文件并保存到分布式存储服务，实现对日志内容的无损压缩，降低日志的存储空间占用，支持根据选择的压缩时间段包含的数据量自动拆分压缩文件或选择不同的压缩模式。

Nginx日志各字段数据具有如下的特点：部分日志字段的值存在大量重复。因为，越是成熟的业务，具体的用户往往相对稳定，用户访问的业务功能、相关的客户端信息也不会频繁变化，后端的调用环境也不会频繁变化。复杂后台系统之间的调用的Nginx日志量往往比最终用户端的日志量多，访问量越大的业务，重复的内容就越多。具体到Nginx访问日志(以下简称Nginx日志)，包含重复数据的字段有(这些字段的名称都是Nginx内置的)：remote_addr、server_protocol、request_method、status(都是数字)、upstream_addr、http_user_agent、ssl_protocol、host和server_name，这些字段的值在不同记录之间不变；字段内容之间有部分重复的有：request_uri(对HTTP/HTTPS就是URL)、http_referer、请求参数args，导致字段值变化的原因在于参数值的不同，参数顺序不变；最长的字段是URL相关的及http_user_agent，其部分值都有按顺序固定的情况，也是最容易有全文检索需求的字段；真正随机变化的字段都是数字，包括time_local、客户端口(无应用场景)、请求和响应时长及字节数。

2、建立元数据记录：围绕实际工作中Nginx日志分析的需要，在压缩Nginx日志的过程中同步建立压缩文件的元数据记录，然后组合压缩文件的存储信息并保存到列式存储服务。

在压缩后日志的应用环节，基于实际的日志监控、分析工作侧重在访问量、性能、错误或流量等趋势的粗粒度分析的特点，可以结合Nginx日志在线监控、分析的需要，在压缩日志数据降低存储占用的过程中，为一批压缩后的日志记录自动生成描述其主要特征的元数据记录，包括访问量、前端及后端错误量、Top K性能等字段。在压缩完成一批日志记录后，把对应的元数据保存到列式存储服务(例如ClickHouse)，同时把压缩后的日志文件保存的分布式存储服务。然后可以由列式存储服务支撑常见日志分析需求，实现比关系数据库更好的日志查询、分析操作的性能，在需要搜索具体日志内容时再通过分布式存储服务查询压缩后的日志，从而既能减少存储空间占用，还能支撑全部日志查询需求。

针对不同类型项目Nginx日志分析的需要，列式存储服务支持方便地动态扩展新的字段来展示项目访问数据的更多特征，例如在业务系统不稳定时支持保存从压缩前的日志计算的错误分布、更多性能数据，对数据密集性项目保存其流量数据等。各个项目的具体特性可以由用户利用项目管理功能按需设置，有助于满足不同项目Nginx日志的个性化分析需求，挖掘相关项目日志数据的更多价值，提高实际日志分析工作的效率和体验。另外，由于日志数据生成后就不再变化，有利于针对压缩后日志内容的查询建立缓存，有助于提高对压缩内容的查询性能。

3、组合检索处理：面向实际的Nginx日志分析需求，从列式存储服务、压缩文件的分布式存储服务两部分组合检索、处理日志内容数据，实现高性能、支持全量Nginx日志内容的分析、统计服务。

图1是根据本发明的一种日志无损压缩分析系统的示意框图。

该系统由多个压缩客户端、日志压缩服务模块、日志无损压缩分析服务端(以下简称服务端)三部分组成。其中日志无损压缩分析服务端中进一步包括列式数据库(列式文件存储服务)和分布式文件存储服务，二者都可采用Go或Rust开发，列式数据库用于压缩元数据操作和分析，分布式文件存储服务用于压缩文件存储和搜索。日志无损压缩分析服务端中还包括，压缩元数据操作分析模块、压缩文件存储搜索服务模块、以及项目功能压缩配置管理模块。

各压缩客户端负责读取Nginx日志，对日志进行压缩处理后，传递给日志压缩服务模块。

日志压缩服务模块根据压缩时长要求分割日志记录、生成压缩文件并保存到分布式存储服务中，在这个过程中同时为每个压缩文件生成对应的元数据记录并保存到列式数据库中。

日志无损压缩分析服务端独立于列式数据库和分布式文件存储服务两部分运行，负责完成用户的日志查询和分析请求，同时提供必要的项目压缩配置管理功能。可以针对Grafana按其标准提供专门的插件和对应的服务端接口，从而方便地把Grafana支持的各种UI组件通过其Dashboard组装为对一个项目或一个Nginx实例监控、分析的UI模板，实际效果与Grafana上现存的一系列UI模板一致，实现基于Grafana的无损压缩日志内容的查询、分析。

图2是根据本发明的一种日志无损压缩分析方法的压缩客户端处理Nginx日志过程的流程图。

压缩客户端负责根据Nginx日志记录之间对应字段内容上的相似性压缩相同或相似的内容，然后传递到日志压缩服务模块生成最终的压缩结果并保存。它以守护进程的方式运行在Nginx进程所在的服务器上，也可以把一个项目的所有日志文件汇总到一个服务器上，再用运行该工具。主要处理步骤如附图2所示：

在步骤21：用户配置要处理的日志文件路径、对应的Nginx服务使用的log_format配置，根据申请人的另一项专利CN110262926B(服务器的元数据修复方法、装置、系统和计算机设备)中公开的方法自动找出现网部署了哪些项目、每个项目有哪些实例及配置，确定一个项目有哪些Nginx实例，进一步可以配置Nginx日志的所属项目编号，启动客户端工具；

在步骤22：读取并解析用户配置的log_format值，根据Nginx内置的日志各个字段的名称确定Nginx服务为其log_format指定了哪些字段、从左到右每个字段的序号、各字段之间的分隔符号；

接着压缩JSON格式的日志。首先，在步骤23：判断日志格式是否是JSON，包括获取日志每个字段的值分别属于Nginx内置的哪些字段，先判断日志内容是否以字符“{”开头、以“}”结尾，如果是，即日志格式是JSON，则流程前进到步骤24，将JSON日志压缩为普通格式，包括尝试把每一行的日志转换为JSON对象，然后获取该对象所有的key值，把每个key对应的值按log_format配置的原有字段顺序采用逗号依次连接，生成不包含key值的对应日志记录，并前进到步骤25；如果不是，即日志格式不是JSON，则使用上一步得到一系列字段和序号，直接前进到步骤25；

在步骤25：依次压缩处理每一行日志，对任意文件都逐行读取Nginx日志文件的内容，然后执行以下子步骤：

在步骤251，为每一行日志建立对应的对象，包括利用分隔符切割当前行的日志得到所有字段，结合上面得到的字段名、项目编号、Nginx所在的host建立对应的数据对象；

在步骤252，提取并压缩日志中值固定不变的字段及其值，降低这些字

段的空间占用，这里分两种情况：

i.检查是否在日志配置中记录ssl_protocol、server_protocol、

server_name，这些字段的值在所有记录中都相同，如果配置了则全局记录每个字段的日志值并清空当前日志行中对应序号的内容；如果日志中server_name的值发生了变化，则记录变化时间；

ii.request_method、upstream_addr、host的值总是属于由一些固定的值构成的集合，当后端系统之间经过Nginx转发调用时remote_addr也是一些固定的内网而不是公网IP，因此可以对这四个字段分别固定编号，再把每个值的编号替换到当前日志行中对应序号的字段值；

在步骤253，压缩agent、URL相关的字段，降低http_user_agent、URL的空间占用，具体处理的字段包括request_uri、http_referer、args，具体处理

方式包括以下四个步骤：

步骤2531，压缩相邻行：检查当前日志的上一行日志的request_uri和http_user_agent是否相同，如果相同则把当前行的这两个字段置空，否则继续按下面的方式处理；

步骤2532，压缩URL字段：如果URL中包含参数，则把URL和第一个参数替换为一个编号，其余的参数名也逐一编号替换，但是都在日志中保留参数值；

步骤2533，压缩agent字段：对http_user_agent按操作系统或客户端库及其版本-终端厂商名(如果有)-build号的方式编号后替换原来的值；

步骤2534，压缩args字段：压缩对args中每个参数的值也逐一扫描对比，如果发现不同日志的参数值中间总是存在相同字符串，也提取出来替换为对应的编号；

其中，步骤2532、2533、2545在图中虽然以顺序方式示出，但本领域技术人员可以理解，它们是可以并行的。

在步骤26，搜集处理结果(替换后的日志数据对象)，批量发送到日志压缩服务模块。根据日志压缩服务的具体方案，既可以通过消息队列，有助于保持原始日志记录顺序，也可以通过RPC发送数据；

在步骤27，发现新的压缩配置则发送到日志压缩分析服务保存，包括搜集步骤25中新创建的压缩项、相关编号、对应的值、项目编号、项目的日志格式配置信息，发现新的值时，在上一步批量发送压缩结果时异步地把新发现的值发送到服务端保存到内容压缩编号表。

图3是根据本发明的一种日志无损压缩分析方法的压缩服务处理过程流程图，示出项目日志最终的压缩、生成元数据及存储的过程。

日志压缩服务负责根据用户对项目的配置压缩客户端发送的所有Nginx日志数据、生成压缩文件并保存相关元数据。当压缩服务存在多个实例时，要保证一个项目所有Nginx实例的数据能被一个压缩服务实例访问。主要处理步骤包括：

步骤31，从服务端读取项目的压缩配置，按下述方式处理后缓存：

·如果项目配置要区分各个Nginx实例的日志，则根据项目配置获取其各个Nginx实例的地址，然后按日志对象的host属性区分不同实例的日志，在下面2)步根据host把日志记录分组后再执行压缩；

·根据设置的压缩时间粒度，则从每天0时刻起依次确定相同时长的压缩时间段；

接着顺序读取客户端发送的数据，按下列步骤依次压缩处理每一行日志，先收到日志先处理：

在步骤32，获取已保存的压缩完成的最后一个时间段的开始时间，没有

值则为空；

在步骤33，根据当前日志的时间戳字段确定当前日志所属的压缩时间段，如果该时间段的开始时间小于上一步得到的时间则立即处理下一条日志，否则通过在步骤34搜集每一行要处理的日志对象后继续。

接着，在步骤35，判断是否是压缩时间段第一条日志。

如果该日志是时间段的第一个日志，则立即在步骤36为当前时间段的压缩操作创建元数据对象，对象的基础公共属性选择各个项目的Nginx日志分析工作中普遍需要的字段，包括访问量、前段及后端错误量、最大性能、压缩文件存储路径，从而可以快速、方便地支持常见的日志分析、统计等需求。还可以根据项目的不同特点或分类扩展出不同类型的子对象以支持更多对日志的分析指标，例如对云存储服务或每次调用的数据量较大的服务，支持分析输入和输出流量的变化。

如果该日志不是时间段的第一个日志，则前进到步骤37，跨字段压缩重复的日志内容：在每个压缩时间段，从左到右逐个字段、逐个字符对比每秒内当前行和之前所有行的日志记录的内容，如果发现从开头第一个字符或从一个不同的字符开始，当前行与之前某一行日志有多个字段的内容都相同，则继续向右逐个字符对比直到找到两行日志中出现不同的字符为止，然后记录存在内容重复的第一行的行号，如果这个行号已存在则读取使用，同时记录可压缩的字段数F、字符数C以及对照压缩的行号L，然后把当前行日志中与第L行相同的各个字段及其后续分隔符都置空，再把F、C、L的值以一定的格式组合记录到置空后的位置，紧邻后面不为空而且有变化的内容。在另一个实施例中，这一步还可以放到压缩客户端执行。

继续处理剩余日志记录，把日志的时间戳作为该压缩时间段的开始时间并置空时间戳字段，接下来在步骤38异步地生成并存储上一个压缩时间段的结果，这里通过事务或检查、确认机制保障下面两步操作总是成功，每次成功压缩一个时间段后立即记录及开始时间。具体包括：

i.采用项目配置的压缩格式，把上个时间段的所有处理后的日志记录按原始顺序(即该项目Nginx实例的log_format配置的字段顺序)写到一个压缩文件中，把文件命名为：项目编号-压缩开始时间-最后一条日志的时间戳-host实例IP-性能放大倍数.扩展名，扩展名由具体选择的压缩格式决定，host和性能放大倍数可选，如果压缩过程中二者的任意一项没有值则省略；如果项目配置按最小时间粒度拆分压缩文件，则按配置的时间粒度长度分别生成对应的压缩文件，再把所有压缩文件合并为一个结果压缩文件；

这里支持选择的压缩格式包括但不限于zip、gz、bz2和parquet，对于zip、gz、bz2这三种格式按现有技术压缩即可，支持在一个压缩文件中压缩多个时间段的处理后的日志文件；对于parquet格式的压缩文件可以保存到兼容S3协议的存储服务，例如MinIO，写入时可以结合实际日志量选择把多个压缩时间段的日志记录写入到一个parquet文件中；保存为parquet格式的压缩文件时，默认采用snappy格式压缩，允许用户针对不同的项目指定压缩格式的具体要求。

还可以在这里扩展支持更多压缩格式，新的压缩格式需要在从压缩文件中查询数据时提供配套的解决方案。

ii.保存压缩文件到分布式存储服务；

iii.在步骤39，把压缩文件的元数据对象以及上面压缩文件的存储地址保存到列式存储服务；

如果当前日志不是其所属时间段的第一个日志，则计算当前日志的时间戳与该时间段的开始时间的秒值差，如果差大于0则用差值替换时间戳字段，如果差值为0，则置空时间戳字段的值；

接下来在步骤310，计算Top K性能：通过一个K个元素的集合计算、保存当前压缩时间段的最大的前K个request_time，如果当前的request_time大于集合中某元素e，即先从集合中清除e，然后再把request_time加入到集合；

在步骤311，压缩性能数据，如果Top K性能数据中有低于0.01的，则把所有性能数据都乘以1000，同时记录这个倍数并放到压缩文件命名中；

在步骤312，压缩状态码，把所有的状态码200对应的字段的值全部置空，其他状态码值不变；

在步骤313，计算、更新压缩文件的元数据对象：通过累计当前时间段的日志数量计算其访问量，通过判断状态码是否属于[400,500)、[500,600)

两个区间分别累计前端和后台错误量；当项目配置要计算错误分布时，分别计算每一个实际发生了的错误码的错误量；当项目配置要分析流量时，分别累计输入和输出流量的值；还可以根据项目是否可能存在安全性风险启用针对访问日志的安全性分析并在元数据中保存分析结果；

在步骤314，在要压缩功能(某些URL)的日志时，但是把URL字段的内容置空，同时把URL放到压缩文件名中，其余按上述相同方式处理即可，

可以对不同功能设置不同的日志压缩时间段长度。

图4是根据本发明的一种日志无损压缩分析方法的服务端对压缩后日志内容的分析、搜索过程的流程图。

服务端负责接收用户端通过UI发送的日志分析、统计请求的参数，处理后返回给前端提供各种类型的展示结果数据。

日志监控、分析页面基本都是查询、计算某个项目或几个项目一段时间内的一系列运行质量指标，用户还可能输入类似模糊查询的匹配条件，例如利用通配符*查询符合条件的一系列URL或http_user_agent记录。常见的实现方式是通过一个个的小UI组件组成一个大的看板，每个小组件分别异步地向服务端查询一个运行质量指标的数据再渲染为折线图、柱状图、表格等不同形式的效果，把这些运行质量指标与上面保存到列式存储服务的列关联起来，在海量数据的情况下总是可以获得比OLTP服务更好的性能，能为Nginx日志分析工作带来稳定、良好的体验。

对于zip、gz或bz2格式的压缩文件，可以参照zgrep和bzgrep工具的实现二次开发搜索压缩文件内部文件内容的功能，即通过添加下列两部分的功能支持搜索按这里的方案压缩后的Nginx日志：

·支持搜索一个压缩文件中的多个文件，逐行输出找到的验收的日志记录；

·根据上面的压缩原理，在找到一行日志记录后，支持搜索随后的被压缩处理的日志：当在压缩后的文件中根据搜索条件找到一行日志记录后，立即检查紧邻的下一行日志，如果下一行日志记录中搜索条件对应的自动内容为空，说明是压缩处理后的结果，也把下一行记录添加到搜索结果集中。

下面的过程具体处理一个质量指标数据的查询、计算，主要包括以下步骤：

步骤41，服务端解析用户通过前端UI提交的日志分析请求，包括需要分析的项目、分析时间段，大部分UI面板上的小组件往往都已经包含了指定的质量指标，这种情况下的查询条件；用户也可能是输入的自定义查询内容；

步骤42，根据用输入的查询条件查询内容压缩编号表中指定项目的压缩配置数据，得到查询条件对应压缩项以及该项目Nginx日志的格式配置；

步骤43，根据要查询的指标数据的存储位置，服务端采用不同的方式搜索包含用户指定的查询条件和上一步获得的压缩项的数据记录：

a)当要查询的指标数据保存在分布式列式存储服务时，直接调用该服务的客户端工具库查询所有需要的列的数据，这部分往往可以通过SQL语句方便地得到指定时间段要分析的项目的各个指标的值及相关计算结果；

b)如果要查询数据只存在于压缩文件中，先根据查询条件从列式存储服务获取所有的压缩文件在分布式存储服务的存储路径，从中可知压缩文件的格式，然后根据分布式存储服务是否支持搜索压缩文件、压缩文件的格式分别采取对应的查询方案从压缩文件中查询数据：

i.如果分布式存储服务支持搜索压缩后的文件，则可以检查压缩文件被分别存储到哪些服务器上，然后根据用户输入的查询条件和对应的压缩项，在所有相关服务器上并行分别搜索压缩文件的块，再合并每个块的搜索结果为最终的搜索结果；

ii.如果分布式存储服务不支持搜索压缩文件并且压缩文件的格式为zip、gz或bz2，先检查本地是否存在对应的压缩文件，如果不存在先下载到本地，接下来采用上述支持搜索这些格式压缩文件的工具搜索本地文件，读取搜索结果，然后循环检查每个搜索结果记录的下一行记录是否符合上述压缩规则，把所有符合记录都加入到返回结果；

iii.如果压缩文件的格式为parquet，根据用户查询条件和对应的压缩项组装查询用的SQL语句，然后采用apache的arrow-datafusion从parquet文件中搜索要查询的内容，接下来搜索压缩文件中每一个找到的记录的下一个记录，判断下一个记录是否被压缩处理，如果是则继续判断下一条记录，知道不满足压缩条件，合并所有符合条件的压缩记录；

步骤44，服务端汇总查询结果列表数据后返回到前端UI；

步骤45，在前端UI上对应的小组件把查询结果集展示为要求的分析效果图，例如折线图、饼图、柱状图、表格或部分组合的联动形式。

多个UI小组件并行异步执行上述步骤，即可向用户展示形式丰富的完整的Nginx日志分析、监控效果的面板。

图5是本发明技术方案相关业务表的设计示意，虚线表示逻辑上的依赖关系，数据类型仅供参考，Set类型表示集合对象，所有的数据都可以保存在列式数据库中。包括以下两类：

1)业务对象压缩、分析配置表

用于支持用户根据不同项目的访问量、请求及响应的数据量、稳定性等实际情况自定义日志无损压缩、分析和监控过程需要的信息，包括项目以及要分析的项目URL(功能)的编号、相关产品(业务)、Nginx组成实例、项目名、压缩结果的存储位置，还有关于日志压缩、分析上对不同项目的阈值、压缩项及其替换值、其它配置的可用状态、使用时间和应用范围，供日志压缩阶段和之后分析压缩文件时使用。

2)压缩结果文件的元数据表

具体有项目及其功能日志的压缩元数据表，这里应涵盖日志分析、监控工作中主要的常见指标，例如访问量、错误量、错误量、性能、流量以及相关项目，还保存相关压缩后日志文件所在的时间段、在分布式文件存储服务上的保存路径，这两个表中的一个记录对应至少一个压缩文件。

本发明从Nginx实际作用决定的其访问日志各个字段内容上的特点、Nginx日志记录之间的关系出发针对性地压缩其日志，在压缩过程中自动生成日志监控、分析工作所需的元数据并同步分别存储，实现了对Nginx日志内容的无损压缩及压缩后的高性能分析，降低了日志的存储空间需求。

本发明采用与压缩日志内容相反的逻辑，支持从压缩后的文件中搜索出全部符合查询条件的内容，使搜索结果等同于直接搜索原始Nginx日志，同时支持异步并行搜索相关元数据记录。

本发明从Nginx单实例到项目全部Nginx实例日志的两级压缩过程，能避免因处理压缩日志大量增加Nginx所在服务器的负载；支持根据实际的Nginx日志监控、分析需求灵活调整压缩后日志文件元数据的内容、支持选用不同的压缩格式、压缩算法、存储服务，方便实施而且IT资源投入可控。

综上，本发明的方案能方便地根据业务需求扩展、订制，在部署上不依赖任何商业软件，可以快速地在少量服务器上搭建完成，适合轻量级地快速采集、分析原始日志，并且可以灵活订制是否存储(保存或不保存哪些)压缩后的日志文件。本发明的方案通过压缩原始日志文件大量减少了存储空间需求，相比gzip、tar压缩比更高，还可以对压缩后的日志文件输出搜索原始日志文件一致的输出，同时保存压缩文件元数据的列式存储服务可以对绝大部分运维监控等需求提供较好的分析性能，能够支持对全量Nginx日志的查询、统计、趋势和关联分析等操作。

以上各实施例仅用以说明本申请的技术方案，而非对其限制。可以理解，以上虽然以Nginx日志为例具体说明了怎样实现无损压缩分析，但这里的完整方案及其各个主要部分的应用范围广泛，还能方便地应用于Apache HTTP Server、Tomcat、K8S的ingress等服务器的日志的无损压缩分析。

本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围，其均应涵盖在本申请的权利要求和说明书的范围当中。

Claims (10)

1.一种日志无损压缩分析系统，包括：

压缩客户端，用于读取日志，从项目和功能两个维度对所述日志进行相似性压缩处理，产生日志记录；

日志压缩服务模块，用于根据压缩时长要求分割所述日志记录、生成经压缩的日志并将所述经压缩的日志保存到分布式存储服务中，并为每个经压缩的日志生成对应的元数据记录并将所述元数据记录保存到列式数据库中；以及

日志无损压缩分析服务端，用于接收和处理日志查询和分析请求，从所述列式数据库和所述分布式存储服务两者组合检索，并提供压缩配置管理。

2.如权利要求1所述的系统，其特征在于，所述分布式存储服务和所述列式数据库存在于所述日志无损压缩分析服务端中，所述日志无损压缩分析服务端独立于所述列式数据库和所述分布式文件存储服务运行。

3.如权利要求1所述的系统，其特征在于，所述元数据记录，包括访问量、前端及后端错误量、Top K性能。

4.如权利要求1所述的系统，其特征在于，所述压缩配置管理包括针对不同类型项目日志分析的需求设置所述列式数据库所支持的动态扩展的新字段来展示项目访问数据的更多特征，所述列式数据库中包括业务对象压缩分析配置表和元数据表。

5.一种日志无损压缩分析方法，包括：

由压缩客户端从项目和功能两个维度对日志进行相似性压缩处理，产生日志记录；

由日志压缩服务模块根据压缩时长要求分割所述日志记录、生成经压缩的日志并将所述经压缩的日志保存到分布式存储服务中，并为每个经压缩的日志生成对应的元数据记录并将所述元数据记录保存到列式数据库中。

6.如权利要求5所述的方法，其特征在于，进一步包括，由日志无损压缩分析服务端接收和处理日志查询和分析请求，从所述列式数据库和所述分布式存储服务两者组合检索，并提供压缩配置管理。

7.如权利要求5所述的方法，其特征在于，由压缩客户端从项目和功能两个维度对日志进行相似性压缩处理进一步包括：

读取并解析用户配置的log_format值；

判断日志格式是否是JSON，如果是则将所述日志压缩为普通格式；

依次压缩处理每一行日志，为所述每一行日志建立对应的对象，压缩值不变的字段，压缩agent、URL相关字段；

搜集处理结果，批量发送到所述日志压缩服务模块。

8.如权利要求5所述的方法，其特征在于，压缩agent、URL相关字段进一步包括：压缩相邻行、压缩URL字段、压缩agent字段、压缩args字段。

9.如权利要求5所述的方法，其特征在于，由日志压缩服务模块根据压缩时长要求分割所述日志记录、生成经压缩的日志并将所述经压缩的日志保存到分布式存储服务中，并为每个经压缩的日志生成对应的元数据记录并将所述元数据记录保存到列式数据库中，进一步包括：

从日志无损压缩分析服务端读取项目的压缩配置，处理后缓存；以及

顺序读取由所述压缩客户端发送的数据，依次压缩处理每一行日志，包括：

获取已保存的压缩完成的最后一个时间段的开始时间；

根据当前日志的时间戳字段确定当前日志所属的压缩时间段；

判断是否是所述压缩时间段第一条日志，若是，则为当前时间段的压缩操作创建元数据，若否则跨字段压缩重复的日志内容、计算Top K性能、压缩性能数据、压缩状态码、计算并更新元数据；

异步地生成并存储上一个压缩时间段的结果；以及

将所述元数据异步保存到所述列式数据库。

10.如权利要求6所述的方法，其特征在于，由日志无损压缩分析服务端接收和处理日志查询和分析请求，从所述列式数据库和所述分布式存储服务两者组合检索，并提供压缩配置管理进一步包括：

解析来自用户的日志分析请求；

根据所述用户的查询条件查询压缩配置数据；

搜索包含所述查询条件的数据记录；

汇总查询结果列表数据；以及

展示查询结果。