具体实施方式

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

随着互联网信息技术的快速发展，业务系统在日常运行过程中所产生的日志文件也越来越多。现有的对于日志进行管理的技术方案大体上以ELK(Elasticsearch，logstash，kibana)和全链路监控为主。ELK主要用于实现分布式场景下日志收集和日志展示功能，而全链路监控方案主要实现分布式场景下一次请求的调用链的监控功能。

但ELK只是一个日志收集系统，不具备全链路监控功能，也不支持日志聚合，而目前的全链路监控方案都是通过追踪ID来聚合日志，因而只能保证对一次请求的日志根据追踪ID进行聚合，也即是局限于只能聚合一次请求的日志，对于多次请求都包含同一业务的情况，例如类似电商平台的订单流转，和基于工单调度场景的工单生命周期日志监控的场景，一个订单或工单会经历多次例如生产、调度、派单、审核等的流程请求节点，通过一个追踪ID只能看到其中某一个流程节点的日志，并不能查询全生命周期的所有日志，从而反映出：现有的日志聚合方式的聚合能力不够高，难以满足日志搜索查询需求的问题。

为解决上述技术问题，本发明通过预先配置关键字段，并在已注入追踪ID的日志信息包含关键字段时，建立关键字段和日志ID之间的索引，使得系统能够跨业务、跨请求，在时间维度和空间维度上支持更广的索引建立；通过对应的日志ID对包含有追踪ID的日志信息进行存储，使得在后续需要搜索查询时，既可根据日志ID直接查询日志信息，也可根据追踪ID查询相关的多条日志信息，同时系统还能够将关键字段与追踪ID之间通过日志ID关联起来，实现更高层次、更广维度的日志检索和展示，即便是在多个参与者针对同一业务进行多次请求的情景下，只要预先配置好适当的关键字段，使得分布式场景下的多次请求都关联上同样的关键字段，系统也能够基于此关键字段聚合显示出同一业务在多个流程节点上的相关日志信息，从而大大提升了日志聚合能力，解决了现有的日志聚合方式的聚合能力不够高，难以满足日志搜索查询需求的技术问题。

如图1所示，图1是本发明实施例方案涉及的硬件运行环境的设备结构示意图。

如图1所示，该日志聚合系统可以包括：处理器1001，例如CPU，用户接口1003，网络接口1004，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的设备结构并不构成对设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及日志聚合程序。

在图1所示的设备中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端(程序员端)，与客户端进行数据通信；而处理器1001可以用于调用存储器1005中存储的日志聚合程序，并执行下述日志聚合方法中的操作。

基于上述硬件结构，提出本发明日志聚合方法实施例。

参照图2，图2为本发明日志聚合方法第一实施例的流程示意图。所述日志聚合方法应用于日志聚合系统，所述日志聚合方法包括；

步骤S10，采集日志信息，并生成与所述日志信息对应的日志ID，其中，所述日志信息中已注入对应的追踪ID；

在本实施例中，通常业务平台每天都会产生大量的日志数据，日志信息指的是该日志聚合系统(以下简称系统)从一个或多个业务系统中收集到的业务系统日常产生的日志数据。对于日志信息可以通过各种方式进行采集，通常采用的是对原生业务系统无侵入式的采集方式。日志ID指的是与日志信息对应的身份标识，具体可以是每一日志信息唯一对应的身份标识，由系统在采集到日志信息之后针对每一日志信息生成。

日志ID的生成方式可以是生成一定长度的随机字符串，再将该随机字符串与当前时间戳相结合(随机字符串+当前时间戳)，或是将该随机字符串和对应日志信息的日志类型(日志类型具体可为请求类型、返回类型、异常类型等)相结合(随机字符串+日志类型)，又或是将该随机字符串与对应日志类型以及当前时间戳一并结合(随机字符串+日志类型+当前时间戳)，作为与该日志信息唯一对应的日志ID。

追踪ID也即是traceId，traceId一般由接收请求经过的第一个服务器产生，产生规则是：服务器IP+ID产生的时间+自增序列+当前进程号。需要说明的是，在对日志信息进行采集的过程中，系统需要先进行判断，判断当前线程中是否已存在traceId，如果当前线程已有traceId，则使用该已存在的traceId封装日志；如果当前线程没有traceId，系统则需生成一个traceId(具体可通过通用唯一识别码UUID生成)，并写入lagback(一个开源日志组件)的诊断上下文映射(MDC，Mapped Diagnostic Contexts)中，然后传递给当前线程，以保证分布式系统中每一次请求都有一个全局唯一的traceId来标记。

步骤S20，在所述日志信息中包含预配置的关键字段时，建立所述关键字段与所述日志ID之间的索引关系；

在本实施例中，关键字段指的是预先已配置好的字段，用户可以根据实际需求配置任意的关键字段，例如可将订单号、工单号定义为关键字段。关键字段可配置一个，也可配置多个，可基于一个维度进行配置，也可以基于多个不同的维度进行配置。索引关系指的是日志ID与关键字段之间的关联关系，一个日志ID可以关联一个或多个关键字段，一个关键字段也可以关联一个或多个不同的日志ID。

具体地，系统在采集到某一个日志信息后，对其进行解析，并调用预配置的一个或多个关键字段，以判断该日志信息中是否包含预配置的关键字段。例如关键字段为某一具体的工单号时，系统判断该日志信息中是否包含此工单号。若系统判定该日志信息中包含此工单号，说明该日志信息是与此工单号对应工单相关的日志信息，满足预设条件，则建立该工单号与此日志信息对应日志ID之间的关联关系，若是在此次请求之后的其他请求中还收集到其他包含此工单号的日志信息，也将其对应的其他日志ID一并与该工单号关联，从而使得一个工单号关联上同一工单的生成、调度、派单、退单、审核、完结等整个流程节点对应日志信息的日志ID。若是系统判定该日志信息中不包含此工单号，则说明该日志信息为与此工单无关的日志信息，则无需建立此日志信息对应ID与该工单号之间的对应关系，继续对下一日志进行判断。

步骤S30，基于所述追踪ID与所述日志信息之间的对应关系和/或所述索引关系，聚合显示所述日志信息。

在本实施例中，在系统对日志信息以及上述索引关系都进行保存后，用户可以通过日志ID、traceId或是关键字段来对日志信息进行检索。例如，用户若是输入某一具体的日志ID，则系统会根据此日志ID找到与此日志ID对应的日志信息作为检索结果；若是用户输入预配置的关键字段，则系统会根据关键字段与日志ID之间的索引关系，找到与用户当前输入关键字段关联的所有日志ID，然后再调用与此所有日志ID对应的日志信息作为检索结果；当然用户也可根据traceId来对同一线程的多个日志信息进行查找，只是由于traceId是与业务无关的标识，因此系统根据traceId得到的检索结果可能也包含与业务无关的日志信息。

需要说明的是，系统通过上述步骤能够建立关键字段与日志id之间的索引，扩展性强，占用存储空间少，能够提升日志检索效率，并且还将关键字段与traceId之间通过日志ID关联起来，从而得以实现更高层次更广维度的日志检索和展示，对研发、运维、运营、产品和测试来说都具备更好的用户体验和解决问题的能力。

本实施例提供一种日志聚合方法。所述日志聚合方法通过采集日志信息，并生成与所述日志信息对应的日志ID，其中，所述日志信息中已注入对应的追踪ID；在所述日志信息中包含预配置的关键字段时，建立所述关键字段与所述日志ID之间的索引关系；基于所述追踪ID与所述日志信息之间的对应关系和/或所述索引关系，聚合显示所述日志信息。本实施例通过预先配置关键字段，并在已注入追踪ID的日志信息包含关键字段时，建立关键字段和日志ID之间的索引，使得系统能够跨业务、跨请求，在时间维度和空间维度上支持更广的索引建立；通过对应的日志ID对包含有追踪ID的日志信息进行存储，使得在后续需要搜索查询时，既可根据日志ID直接查询日志信息，也可根据追踪ID查询相关的多条日志信息，同时系统还能够将关键字段与追踪ID之间通过日志ID关联起来，实现更高层次、更广维度的日志检索和展示，即便是在多个参与者针对同一业务进行多次请求的情景下，只要预先配置好适当的关键字段，使得分布式场景下的多次请求都关联上同样的关键字段，系统也能够基于此关键字段聚合显示出同一业务在多个流程节点上的相关日志信息，从而大大提升了日志聚合能力，解决了现有的日志聚合方式的聚合能力不够高，难以满足日志搜索查询需求的技术问题。

进一步地，基于上述图2所示的第一实施例，提出本发明日志聚合方法的第二实施例。在本实施例中，所述采集日志信息的步骤包括：

步骤S11，使用JAVA字节码增强方式，针对所述日志聚合系统对接的业务系统，拦截获取所述业务系统的节点请求和响应日志，其中，所述节点请求和响应日志基于全链路追踪ID埋点所生成；

步骤S12，将所述节点请求和响应日志封装为字符串格式以作为日志主体信息；

步骤S13，获取当前采集线程中的当前追踪ID以作为所述追踪ID，并获取所述日志主体信息的相关参数信息；

步骤S14，将所述日志主体信息、所述相关参数信息和所述追踪ID按照预设格式封装成所述日志信息，并将所述日志信息放入日志消息队列，以从所述日志消息队列中读取所述日志信息。

在本实施例中，系统完全兼容和涵盖了全链路日志监控的核心功能，相当于其超集和扩展，集成了全链路日志监控中无侵入式日志采集和traceId埋点的功能。作为一具体实施例，系统包含日志采集agent模块，实时监控模块、索引模块和存储模块。如图3所示，

日志采集agent模块使用java字节码增强技术实现，利用spring aop技术编写切面类。对业务系统接口和方法通过配置表达式进行拦截，获取接口和方法的输入参数与返回结果(也即是上述节点请求和响应日志)，封装成字符串格式作为日志主体信息，而无需日志复制过程。同时获取当前服务器IP地址、系统时间戳、接口URL、方法名、以及当前操作的类型作为上述相关参数信息，并附加一个traceId进行封装，组成json格式后编译成agent.jar文件。具体地，JSON格式如表1：

表1

日志采集agent模块将各个服务的成agent.jar文件异步发送到kafka(一个分布式、高吞吐量、高扩展性的消息队列系统)的消息队列中，以保证对原生业务系统性能影响最低。

实时监控模块从kafka消息队列中读取日志信息，并对其进行解析，解析出json格式的日志信息后，调用日志存储模块，以对日志信息进行存储，具体可存储于采用开源方案elasticsearch来实现，elasticsearch这一存储引擎支持分布式集群部署和根据id精确检索、全文检索等功能。通过具体日志id直接调用接口查询某条日志信息，也可以根据traceId查询相关的多条日志信息。存储时会先生成对应的日志id，然后根据配置的关键字段名来判断当前日志信息是否包含关键字段。如果包含则建立索引并将索引关系保存于Redis系统中，否则结束流程。

在接收到日志查询请求时，系统通过Redis这一key-value存储系统实现查询索引和返回索引，然后再根据索引查询全生命周期的日志信息，以聚合显示符合检索条件的日志信息。另外，系统还可包括离线分析统计模块Hive来实现日志信息的离线分析统计功能。Hive使用的是hadoop的分布式文件系统HDFS，hive数据仓库工具能将结构化的数据文件映射为一张数据库表，并提供SQL查询功能，能将SQL语句转变成MapReduce任务来执行。Hive的优点是学习成本低，可以通过类似SQL语句实现快速MapReduce统计。

需要说明的是，本发明对日志的收集不在网关层，而在具体的应用节点本地。

现有的方式中，无论是ELK还是全链路日志监控的大多数实现，都是对日志文件和系统日志进行收集，这里面包含了大量的无效日志。比如使用的开源框架spring的日志，javaEE的servlet日志，这些日志会占用业务系统大量的存储和计算资源。还有一个问题就是分布式环境下不同的模块开发者可能来自不同的团队，或者是一个团队中不同的开发者，这些人打印的日志格式和规范会有不同，会造成部分关键业务日志冗余或缺失。本实施例采用的是利用java字节码技术对接口与方法的请求和响应进行拦截，输出请求参数和响应文本作为主要日志(也即是日志来源是接口和方法的请求参数和响应信息)，并附加服务器IP，接口地址，方法名，时间戳和日志类型，而不是去修改或者读取应用系统日志。能够做到所有日志格式规范统一，信息收集针对性强，对计算和存储资源不浪费，而且请求和响应中包含了所有关键业务信息。

进一步地，步骤S20之前，还包括：

步骤A1，判断所述日志信息中是否包含所述关键字段，其中，所述关键字段为单一关键字段或对应不同维度的多个关键字段；

步骤A2，若是，则执行建立所述关键字段与所述日志ID之间的索引关系的步骤。

在本实施例中，上述关键字段可以指单一维度的关键字段，也可以指多个不同维度的多个关键字段。系统在采集到日志信息后，需要对日志信息进行解析，然后判断该日志信息中是否包含预配置的关键字段。若系统判定该日志信息中包含关键字段，则进一步执行后续建立索引的步骤；若系统判定该日志信息中不包含关键字段，则继续判断下一日志信息。

本实施例通过基于关键字段建立索引，而不是使用traceId这样一个与业务无关的标识去聚合日志，无需要考虑traceId的生成规则和使用规则，也避免了使用不当会造成将无关的业务日志聚合到一起，产生歧义，同时关键字段支持多个，也就能够支持多维度索引的建立，对具体业务的贡献就是支持多维度搜索日志。

进一步地，所述步骤A1包括：

步骤A11，使用字符串匹配方式判断所述日志主体信息中是否包含至少一个所述关键字段；

步骤A12，若所述日志主体信息中包含至少一个所述关键字段，则判定所述日志信息中包含所述关键字段；

步骤A13，若所述日志主体信息中不包含任一所述关键字段，则判定所述日志信息中不包含所述关键字段。

在本实施例中，系统针对日志信息中的日志详情以字符串匹配的方式进行关键字段匹配。以关键字段为多个字段为例，系统判断当前日志信息中是否包含多个字段中的一个或是多个；若该日志信息包含上述多个字段中的一个或是多个，则系统判定该日志信息中包含关键字段，进而建立所包含的关键字段与该日志信息对应日志ID之间的关联关系；若该日志信息中不包含上述多个字段中的任一字段，则系统判定该日志信息不包含关键字段。

本实施例针对格式化日志中的日志详情通过字符串匹配的方式来实现，匹配方式较之基于正则表达式等的其他方式更加简便易行。

进一步地，所述采集日志信息的步骤之后，还包括：

步骤B1，判断所述相关参数信息中的信息类型是否为异常类型；

步骤B2，若是，则将所述日志信息确定为异常信息，并基于所述异常信息生成异常告警，以将所述异常告警推送至对应处理人终端；

步骤B3，若否，则执行生成与所述日志信息对应的日志ID的步骤。

在本实施例中，系统在对日志主体进行进行字符串匹配的同时，还可针对日志信息中的日志类型字段进行检查，以判别其日志信息类型是否为异常类型(例如检测到type＝3则表示该日志信息为异常类型)。若系统判定当前日志信息为异常类型，则可调用邮件功能或者短信功能通知接口人进行处理；若系统判定当前日志信息不为异常类型，则继续执行后续步骤。

本实施例通过设置实时报警功能，使得系统能够及时将异常类型的日志信息通知给相应处理人员，以供处理人员及时处理。

进一步地，基于上述图2所示的第一实施例，提出本发明日志聚合方法的第三实施例。在本实施例中，步骤S30之前，还包括：

步骤C1，在接收到日志检索指令时，基于所述日志检索指令确定检索词，其中，所述检索词包括所述关键字段、所述日志ID和/或所述追踪ID；

当所述检索词为所述关键字段时，步骤S40包括：

步骤S31，根据所述索引关系，确定在所述关键字段对应业务的全生命周期范围内与所述关键字段关联的所有日志ID；

步骤S32，获取所述关键字段关联的所有日志ID对应的日志信息，以将所述所有日志ID对应的日志信息进行聚合显示。

在本实施例中，在用户通过系统进行日志检索时，通常需要先输入检索词。检索词可以是关键字段、日志ID以及追踪ID中的一项或是多项。若是输入关键字段，则系统可基于上述索引关系聚合显示出与此关键字段相关联的一个或多个日志信息；若是输入traceId，则系统可查找并显示出与此traceId相关的多条日志信息；若是输入日志ID，则系统可直接确定到与此日志ID对应的日志信息；若是输入关键字段和traceId，则系统可从traceId关联的多个日志信息中确定出包含关键字段的一个或多个日志信息，作为最终的检索结果展示给用户。

本实施例通过对关键字段进行聚合，而不只是增加一个追踪id。追踪id只能对一次请求的日志进行追踪，而关键字段可以对不同时间、不同空间的日志进行索引，也即是这个聚合可以跨越时间与空间维度，不限制是一次请求，还是多次请求。

进一步地，所述建立所述关键字段与所述日志ID之间的索引关系的步骤包括：

步骤S21，根据所述关键字段建立索引，并按照键值对的数据结构将所述关键字段和所述日志ID之间的关联关系保存至数据库中。

在本实施例中，系统对于关键字段和日志ID的关联关系，是采用键值对的结构进行保存的，其中key是关键字段，value是日志id按照时间升序排序的数组。也即是最后聚合出来的数据结构是key-value形式的键值对。由于关键字段与日志id之间的索引的扩展性强，占用存储空间少，因此能够进一步提升日志检索效率。通常系统会将键值对数据存储在Redis数据库中。

进一步地，步骤S30之前，还包括：

将所述日志信息按照所述日志ID存储至指定的存储引擎。

在本实施例中，可采用开源方案elasticsearch来实现日志信息的存储，系统将日志信息按照日志ID存储至elasticsearch这一存储引擎，elasticsearch支持分布式集群部署和根据id精确检索、全文检索等功能。用户可以通过具体日志ID直接调用接口查询某条日志信息，也可以根据traceId查询相关的多条日志信息。

如图4所示，本发明还提供一种日志聚合系统，所述日志聚合系统包括：

日志信息采集模块10，用于采集日志信息，并生成与所述日志信息对应的日志ID，其中，所述日志信息中已注入对应的追踪ID；

索引关系建立模块20，用于在所述日志信息中包含预配置的关键字段时，建立所述关键字段与所述日志ID之间的索引关系；

日志聚合显示模块30，用于基于所述追踪ID与所述日志信息之间的对应关系和/或所述索引关系，聚合显示所述日志信息。

可选地，所述日志信息采集模块10包括：

业务系统拦截单元，用于使用JAVA字节码增强方式，针对所述日志聚合系统对接的业务系统，拦截获取所述业务系统的节点请求和响应日志，其中，所述节点请求和响应日志基于全链路追踪ID埋点所生成；

主体信息获取单元，用于将所述节点请求和响应日志封装为字符串格式以作为日志主体信息；

ID参数获取单元，用于获取当前采集线程中的当前追踪ID以作为所述追踪ID，并获取所述日志主体信息的相关参数信息；

日志信息读取单元，用于将所述日志主体信息、所述相关参数信息和所述追踪ID按照预设格式封装成所述日志信息，并将所述日志信息放入日志消息队列，以从所述日志消息队列中读取所述日志信息。

可选地，所述日志聚合系统还包括：

关键字段判断单元，用于判断所述日志信息中是否包含所述关键字段，其中，所述关键字段为单一关键字段或对应不同维度的多个关键字段；

关键字段判定单元，用于若是，则执行建立所述关键字段与所述日志ID之间的索引关系的步骤。

可选地，所述关键字段判断单元还用于：

使用字符串匹配方式判断所述日志主体信息中是否包含至少一个所述关键字段；

若所述日志主体信息中包含至少一个所述关键字段，则判定所述日志信息中包含所述关键字段；

若所述日志主体信息中不包含任一所述关键字段，则判定所述日志信息中不包含所述关键字段。

可选地，所述日志聚合系统还包括：

异常类型判断模块，用于判断所述相关参数信息中的信息类型是否为异常类型；

异常告警推送模块，用于若是，则将所述日志信息确定为异常信息，并基于所述异常信息生成异常告警，以将所述异常告警推送至对应处理人终端；

异常类型排除模块，用于若否，则执行生成与所述日志信息对应的日志ID的步骤。

可选地，所述日志聚合系统还包括：

日志检索确定模块，用于在接收到日志检索指令时，基于所述日志检索指令确定检索词，其中，所述检索词包括所述关键字段、所述日志ID和/或所述追踪ID；

当所述检索词为所述关键字段时，所述日志聚合显示模块30包括：

日志ID确定单元，用于根据所述索引关系，确定在所述关键字段对应业务的全生命周期范围内与所述关键字段关联的所有日志ID；

日志聚合显示单元，用于获取所述关键字段关联的所有日志ID对应的日志信息，以将所述所有日志ID对应的日志信息进行聚合显示。

可选地，所述索引关系建立模块20包括：

索引建立保存单元，用于根据所述关键字段建立索引，并按照键值对的数据结构将所述关键字段和所述日志ID之间的关联关系保存至数据库中。

可选地，所述日志聚合系统还包括：

日志信息存储模块，用于将所述日志信息按照所述日志ID存储至指定的存储引擎。

本发明还提供一种日志聚合设备。

所述日志聚合设备包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的日志聚合程序，其中所述日志聚合程序被所述处理器执行时，实现如上所述的日志聚合方法的步骤。

其中，所述日志聚合程序被执行时所实现的方法可参照本发明日志聚合方法的各个实施例，此处不再赘述。

本发明还提供一种计算机可读存储介质。

本发明计算机可读存储介质上存储有日志聚合程序，所述日志聚合程序被处理器执行时实现如上所述的日志聚合方法的步骤。

其中，所述日志聚合程序被执行时所实现的方法可参照本发明日志聚合方法各个实施例，此处不再赘述。

本发明还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上述的日志聚合方法的步骤。

其中，所述计算机程序被执行时所实现的方法可参照本发明日志聚合方法各个实施例，此处不再赘述。

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

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

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

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