具体实施方式

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

图1为动态日志记录管理系统的组成结构示意图。本申请的动态日志记录管理系统的日志采集记录功能以模块的形式集成在分布式微服务系统的网关层，服务网关通常使用Spring Cloud Gateway，Zuul或其他基于Java Servlet的服务网关。日志记录拦截采用Web Fliter拦截器方式对调用请求进行拦截。

日志采集模块包括日志规则配置管理单元、日志规则配置存储单元、日志规则配置发布单元、日志拦截器、拦截规则判定器、日志记录缓存以及日志存储单元；

其中，日志规则配置管理单元所实现的功能属于应用服务管理功能，通过web管理端对日志规则进行配置。服务管理端可管理多组网关集群，每个网关集群均可配置独立的日志拦截记录规则。

创建日志采集匹配规则，所述日志采集匹配规则包括规则名、规则条件配置、规则优先级、生效日期、失效日期、记录明细以及启用状态。

日志采集匹配规则分为名单规则、正则规则和字段逻辑规则组三种形式。

所支持的名单规则用于字段因子的匹配，所述字段因子包括HTTP请求参数，HTTP请求头部参数，JSON Body报文字段参数，请求路径，返回响应时长，调用返回状态码，返回报文JSON Body报文结构；

所支持的字段逻辑规则组用于字段因子的逻辑条件匹配，逻辑条件匹配的表达形式为：type==’web’ && (status == 200 || status == 201) && (amount > 3000 ||amount < 20) && resonseTime > 2000。其中，type为请求url中参数标识渠道，status为http的返回response的状态值，amount为请求报文中JSON格式内的属性交易金额，responseTime为请求耗时时间。

例如，channel == “web” && path != “/usr/api”，可描述为api参数channel值为web，并且请求路径是/usr/api的记录则满足记录条件。

所述正则规则支持自定义正则表达式，若字段中的值匹配满足正则规则，则日志采集规则匹配记录；

所述正则表达式的规则用于通配匹配，例如：path==’/usr/list/[.]+’，匹配所有已’/usr/list’开头的请求路径。

名单匹配规则支持命中记录和不命中记录两种方式。通常用于对参数中用户标识，IP等字段做匹配计算，例如，IP地址包含在名单库中的请求记录日志，请求参数UUID在客户名单库中命中记录日志。规则中匹配的名单为了提升匹配效率，多将名单数据加载到内存中匹配使用，如果名单库规模较大，则使用Redis作为名单库存储，提升名单命中查询的效率。

同时本系统可以使用调用返回的结果作为规则因子字段，常用的有调用响应时间，返回状态码，或者具体的返回报文的字段值。例如，当调用响应时间大于200毫秒的结果进行日志记录，返回状态码不为200的请求进行记录，返回报文体中code字段值不为10000的请求进行记录。以控制返回记录的日志。

规则配置中的记录明细可选择日志记录的明细信息，默认记录信息包括：请求时间，返回时间，消耗时间，来源IP，请求路径，请求参数，请求报文大小，返回报文大小。可选择记录内容包括：请求Header的内容，请求Body报文体内容，返回报文体内容。其中，请求报文体和返回报文体的内容项较多。频繁的记录将对日志记录系统产生较大的存储压力，并发大的情况下，对服务器的性能也有一定的影响，因此是否记录请求报文体和返回报文体和具体的记录规则配置有关，以避免日志的过载记录。

日志记录的脱敏配置，当前服务网关集群中日志记录的配置项，用于配置当前日志记录中的字段对哪些内容进行脱敏处理，以保证日志中记录的信息不会有敏感信息外泄，用以保证数据安全。

日志规则配置存储，采用数据库和配置服务两种存储介质保存规则配置。其中数据库保存所有的编辑规则做管理使用，管理页面端对规则的编辑管理操作都直接操作数据中的配置数据，配置服务则通过API接口将启用或停用的规则与配置服务中的配置进行同步。未启用的配置记录只保存在数据中，不在配置服务中使用。

日志规则配置发布。服务网关通过配置服务监听网关日志规则的变化，更新每个服务网关的日志拦截规则，实现规则的动态更新。配置服务中存储的规则配置是通过配置服务的API接口发布至配置服务中，此规则配置文件将通过配置服务将直接应用于服务网关中，服务网关通过配置引用的方式监听规则配置的变化，当有规则在配置服务发生变化时，配置服务将同步通知所有引用此规则配置的服务更新服务端的配置信息，实现服务集群的同步配置刷新。在服务网关中，拦截规则管理器将更新维护规则的更新变化。

日志拦截器集成在服务网关中，以拦截器的形式体现。默认可拦截全部经过网关的请求，在拦截器配置中可配置不需要拦截的请求，例如，类似页面和静态资源等调用可配置不拦截记录。日志记录规则将对无需拦截的请求调用不在触发规则。只拦截有效的调用请求。

拦截规则判定器采用规则引擎作为规则判定识别功能。规则读取网关文件中的日志拦截规则，并监控规则的变化，将发生变化的规则进行动态编译并更新至日志规则判定管理器中。日志规则判定管理器为本系统的规则判断核心模块，此模块采用JAVA的JIT动态编译技术，可对规则条件做实时的动态编译，请求的规则匹配计算为直接使用编译完成后的规则字节码，此项技术保证了日志规则的逻辑判断耗时贴近原生代码执行效果，经测试在开发机上每毫秒可执行上万次级别的规则条件判断，因此具有良好到规则匹配执行性能。在规则的加载和判断上，当服务通过配置服务监听规则配置服务发生变更时，将先判断发生变更的规则，对失效的规则进行移除，对更新和新增的规则先行做加载以及预编译，编译通过后将编译通过的规则替换值规则管理中，实现规则的动态更新。

日志记录缓存采用内存队列和消息队列两种方式，异步的方式将需要记录的日志信息放在内存队列中，再有内存队列批量写入消息队列。提升日志处理的效率。异步的处理方式，不对当前业务请求调用产生阻塞影响。其中内存队列采用Disruptor高效内存队列做日志的内存队列缓存，消息队列采用Kafka作为日志队列缓存。两级队列的设计模式充分考虑到当前日志请求量过大时对写入线程池和并发的设计。

日志存储采用ElasticSearch对日志进行存储。ElasticSearch采用集群方式存储，ES有非常优秀的非结构化日志存储能力和高并发写入能力。特别是针对请求报文数据和返回报文数据，本模块对返回和请求的报文结构数据做文本化处理，不以结构化的方式将日志存储在ES中，提升ES的存储和查询效率。日志记录根据记录的日志规模按时段分组存储。也可以在规则配置中单独配置，将不同命中规则的日志分索引单独存储，以便于更加细分的对日志记录进行处理。

图2为规则配置流程的示意图。该规则配置流程包括如下步骤：

步骤1、在管理端创建日志记录规则，并填写日志记录规则信息；

所述日志记录规则信息包括规则名称、生效时间、失效时间、匹配规则类型选择名单、正则以及字段逻辑规则组；

步骤2、编写日志记录规则逻辑；

该步骤具体包括：

步骤201、选择需要判断字段因子所在位置，其中，所述需要判断字段包括Header头部、请求参数、路径、请求报文体、返回报文体、返回耗时以及状态码因子字段；

步骤202、配置规则优先级、配置是否记录请求报文体、配置是否记录返回报文体、配置是否需要单独额外的ES表存储，如果需要配置，则独立命名存储ES表名称；

步骤3、将已配置好的日志记录规则存储至规则数据库，并启用所述已配置好的日志记录规则；

步骤4、根据所述已配置好的日志记录规则生成规则文件，并通过配置服务的API将生成的所述规则文件存储至配置中心；

通过打开配置中心，以查看规则配置文件是否已更新。

步骤5、服务网关对所述配置中心中的所述规则文件进行监听，根据监听结果来判断配置规则动态更新是否完成；

步骤6、若配置规则动态更新完成，则结束；反之，继续执行步骤5。

所述根据监听结果来判断配置规则动态更新是否完成，具体包括：如果监听到所述规则文件发生变化，则在所述服务网关的日志中输出变化后的规则文件的结果，并根据所述变化后的规则文件的结果进行日志记录或者日志粒度记录；查看变化后的规则文件的结果输出，则配置规则动态更新完成。

根据所述变化后的规则文件的结果进行日志粒度记录，具体包括：

拦截器将拦截全部的外部请求，抽取所述外部请求中的明细字段，外部请求中的明细字段以格式化结构表示，包括JSON结构或XML结构，明细字段项和具体的业务数据有关；或者

在请求调用返回后执行异步拦截，抽取返回报文中的明细字段，或者按设定条件，全部保存外部请求和返回报文的内容；其中，所述设定条件为所述需要判断字段的逻辑条件匹配的表达式；

将请求HttpRequest和HttpResponse在拦截器中传入规则判定器中进行判断，按日志匹配规则优先级依次匹配执行；优先级越大的则越优先匹配，如果匹配到此规则，则后续规则不再进行匹配，按此规则中的规则因子抽取因子变量，在规则判定器中匹配执行，判定是否匹配规则，如果匹配规则，则将所需记录信息封装日志粒度报文体，发送至内存队列。

图3为日志记录的流程示意图。在步骤5中，根据所述变化后的规则文件的结果进行日志记录，具体包括如下步骤：

步骤301、拦截器将拦截全部的外部请求，请求优先判断拦截器中忽略记录请求的路径配置，如果匹配属于忽略请求配置，则直接跳过不做日志规则匹配；

步骤302、在请求调用返回后执行异步拦截，将请求HttpRequest和HttpResponse在拦截器中传入规则判定器中进行判断，按日志匹配规则优先级依次匹配执行，优先级越大的则越优先匹配，如果匹配到此规则，则后续规则不再进行匹配，按此规则中的规则因子抽取因子变量，在规则判定器中匹配执行，判定是否匹配规则，如果匹配规则，则将所需记录信息封装日志记录报文体，发送至内存队列；

步骤303、内存队列中的消费端线程将监控内存中是否有日志记录数据需要存储，如果需要，则按批量日志记录的方式将日志记录写入至Kafka消息队列中；

步骤304、Kafka消息队列的消费端启动消费线程，消费Kafka消息队列中的日志记录，将日志数据批量写入ElasticSearch中，完成日志记录，在管理端通过查询页面可基于不同条件查询筛选符合记录要求的日志记录。

综上所述，本申请给出了一套基于服务网关的动态服务日志记录的方法。通过在在请求的网关层基于规则引擎动态匹配需要记录的日志记录。按匹配规则记录日志，可基于不同的规则组将日志区分记录分开存储。可通过管理端动态修改匹配规则，实时生效。可配置记录请求的明细，包括请求的报文和返回的报文。本发明主要解决分布式系统下多系统的日志记录可视化规则配置，定制存储和记录粒度的配置化控制，实现日志记录动态管控。日志记录配置项采用规则引擎动态编译技术，使得日志的判断识别对业务调用主流程的性能不产生影响，日志记录采用异步消息内存队列方式，不影响业务调用。在本申请的技术方案中，外部的请求统一通过服务网关进行业务请求调用，在网关层的日志采用动态可配置性拦截，可针对不同的报文属性，协议头属性，名单，IP地址，请求参数，响应状态码，响应时间等信息通过管理平台可视化配置拦截日志记录条件。

本系统的采集服务部署在微服务架构下的服务网关层拦截请求。拦截日志参数条件包括并不限于参数，协议头头，IP，响应码。同时重点是针对调用返回的结果做拦截记录。不仅仅面向访问记录的拦截，同时针对返回的结果做日志拦截包含了响应时间，响应报文的内容条件，以及请求报文的条件，拦截判断条件项。

拦截记录的日志项粒度是可配置，同时最重要的是，日志可拦截记录请求报文体和返回报文体，并且已json结构保存。日志拦截器采用Filter方式拦截，区别于AOP的实现拦截方式，对全部请求进行拦截，并提供忽略的拦截跳出配置，可直接忽略不拦截请求。采用基于微服务的配置中心的方式更新拦截规则动态变化，采用配置中心配置变更的方式实现拦截规则的动态更新。

拦截规则不限于规则表达式的判断，同时还支持名单，正则表达式的拦截判断。在网关层的请求日志拦截可配置选择拦截的应用服务，以及应用服务具体的path路径。拦截规则在管理端配置管理，可配置规则的有效期，优先级，以及拦截内容。管理端可配置多套不同网关集群的拦截记录规则。日志拦截存储采用ElasticSearch做日志存储，规则存储采用关系型数据库并不局限于特定数据库。规则的动态配置保存在配置中心，动态变更通知所有的网关服务集群。

在一些实施例中，计算机程序的部分或者全部可以经由ROM而被载入和/或安装到设备上。当计算机程序加载并被执行时，可以执行上文描述的方法的一个或多个步骤。

本申请中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：场可编程门阵列（FPGA）、专用集成电路（ASIC）、专用标准产品（ASSP）、芯片上系统的系统（SOC）、负载可编程逻辑设备（CPLD）等等。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器（RAM）、只读存储器（ROM）、可擦除可编程只读存储器（EPROM或快闪存储器）、光纤、便捷式紧凑盘只读存储器（CD-ROM）、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。