CN117194338A - 分布式日志数据的处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提供一种分布式日志数据的处理方法、装置、设备及存储介质，可用于计算机领域。在该方案中，包括应用程序客户端和日志平台。当应用程序客户端启动后，多线程监听日志产生情况获取日志数据，并根据预设日志格式生成日志对象，将其暂存本地日志队列，后续按照日志大小阈值以多线程方式批量传输日志至日志平台的消息队列。当日志平台接收到应用程序客户端发送的日志查看请求后，日志平台根据用户标识以及本地存储用户与项目空间的对应关系，获取与用户标识对应的目标项目空间，并从elasticsearch中获取目标项目空间对应的所有日志对象，返回应用程序客户端。本申请的分布式日志数据的处理方法能够实现日志查看流程的简单化，服务器资源使用的高效化。

Description

分布式日志数据的处理方法、装置、设备及存储介质

技术领域

本申请涉及计算机领域，尤其涉及一种分布式日志数据的处理方法、装置、设备及存储介质。

背景技术

随着计算机技术的飞速发展，多种应用系统产生的日志数据量急剧增长，高访问量高并发量的问题日益显著。因传统单体应用架构存在难以理解、难以维护以及开发效率低等缺点，微服务架构、分布式系统应运而生。然而，新技术在带来便利的同时也在产生一系列其它问题，比如各个应用系统的日志采集以及分析问题。

一般大型系统是一个分布式部署的架构，不同的服务模块会部署在不同的服务器上，当系统出现问题时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，因此建立集中式的日志采集系统，将所有服务节点上的日志统一采集和管理是常见的解决思路。当前Elasticsearch+Logstash+Kibana提供了一整套的解决方案，因涉及的三个软件均具开源性，相互之间能够配合使用，高效满足了很多场合的应用。

然而，在一些快速交付的项目场景下，日志采集系统的设计无需过于复杂，相对轻量级的日志采集解决方案即可。目前已有的Elasticsearch+Logstash+Kibana框架解决方案所涉及的中间件偏多，项目开发人员需对每部分有一定知识积累，同时应用系统在接入日志采集服务的过程中所需的配置工作也较为繁琐，若该框架应用于小型分布式系统场景下的日志采集过程，不可避免地会带来后续日志查看繁琐以及服务器资源浪费的问题。

发明内容

本申请提供一种分布式日志数据的处理方法、装置、设备及存储介质，用以解决现有技术中日志查看繁琐和服务器资源浪费的问题。

第一方面，本申请提供一种分布式日志数据的处理方法，应用于日志平台，所述方法包括：

接收用户的应用程序客户端发送的日志查看请求，所述日志查看请求中包括用户标识；

根据所述用户标识，以及本地存储的用户与项目空间之间的对应关系，获取与所述用户标识对应的目标项目空间；

根据所述目标项目空间，从elasticsearch中获取出所述目标项目空间对应的所有日志对象；其中，所述elasticsearch中存储有按照预设格式汇总的多个项目空间的所有日志对象；

将目标项目空间对应的所有日志对象返回所述应用程序客户端。

在第一方面的一种可能设计中，所述根据所述目标项目空间，从elasticsearch中获取出所述目标项目空间对应的所有日志对象之前，所述方法还包括：

针对每个应用程序客户端，通过多线程接收所述应用程序客户端上传的日志对象，并将所述日志对象放入消息队列；其中，同一个应用程序客户端的日志对象是以一定的时间间隔上传的；

基于分布式系统的至少一个节点，从所述消息队列中获取出每个项目空间对应的至少一个日志对象；

将所述至少一个日志对象按照预设格式汇总在所述elasticsearch上进行存储。

在第一方面的一种可能设计中，所述接收用户的应用程序客户端发送的日志查看请求之前，所述方法还包括：

接收所述应用程序客户端发送的登录申请，所述登录申请中包括用户的登录信息；

根据所述登录信息，以及本地存储的权限管理信息，确定所述用户是否具备登录日志系统查看日志的权限；

在确定出所述用户具备登录日志系统查看日志的权限时，授权所述用户访问日志系统，并向所述应用程序客户端发送登录认证通过消息。

在第一方面的一种可能设计中，所述用户与项目空间之间的对应关系中每个用户对应至少一个项目空间。

第二方面，本申请提供一种分布式日志数据的处理方法，应用于任一应用程序客户端，所述方法包括：

在所述应用程序客户端启动后，多线程监听日志产生情况获取日志数据，并根据预设的日志格式生成日志对象；

检测本地设置的日志队列是否已满；

若所述日志队列未满，则将所述日志对象放入所述日志队列；

判断所述日志队列的大小是否达到预设的日志大小阈值；

若所述日志队列达到所述日志大小阈值，则将所述日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

在第二方面的一种可能的设计中，所述方法还包括：

若所述日志队列未达到所述日志大小阈值，则确定上次上传日志的时刻到当前时刻的时间间隔是否达到预设时间间隔；

若上次上传日志的时刻到当前时刻的时间间隔达到预设时间间隔，则将所述日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

在第二方面的一种可能的设计中，所述在所述应用程序客户端启动后，所述方法还包括：

根据雪花算法生成所述应用程序客户端对应的贯穿全链路TID；

相应的，所述根据预设的日志格式生成日志对象，包括：

根据预设的日志格式生成所述日志对象，并将所述贯穿全链路TID加入到所述日志对象中的RpcContext对象中。

第三方面，本申请提供一种分布式日志数据的处理装置，包括：

接收模块，用于接收用户的应用程序客户端发送的日志查看请求，所述日志查看请求中包括用户标识；

处理模块，用于根据所述用户标识，以及本地存储的用户与项目空间之间的对应关系，获取与所述用户标识对应的目标项目空间；

所述处理模块还用于根据所述目标项目空间，从elasticsearch中获取出所述目标项目空间对应的所有日志对象；其中，所述elasticsearch中存储有按照预设格式汇总的多个项目空间的所有日志对象；

发送模块，用于将目标项目空间对应的所有日志对象返回所述应用程序客户端。

第四方面，本申请提供一种分布式日志数据的处理装置，包括：

获取模块，用于在所述应用程序客户端启动后，多线程监听日志产生情况获取日志数据，并根据预设的日志格式生成日志对象；

处理模块，用于检测本地设置的日志队列是否已满；

所述处理模块还用于若所述日志队列未满，则将所述日志对象放入所述日志队列；

所述处理模块还用于判断所述日志队列的大小是否达到预设的日志大小阈值；

发送模块，用于若所述日志队列达到所述日志大小阈值，则将所述日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

第五方面，本申请提供一种电子设备，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如第一至第二方面任一项所述的分布式日志数据的处理方法。

第六方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一至第二方面任一项所述的分布式日志数据的处理方法。

第七方面，本申请提供一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序被处理器执行时用于实现第一至第二方面任一项所述的分布式日志数据的处理方法。

本申请提供的分布式日志数据的处理方法、装置、设备及存储介质，该分布式日志数据的处理方法应用于应用程序客户端和日志平台。在应用程序客户端成功启动后，多线程监听日志的产生情况获取日志数据，并根据预设的日志格式生成日志对象，检测本地设置的日志队列是否已满，若日志队列未满，则将日志对象暂时放入日志队列，后续继续判断日志队列的大小是否达到预设的日志大小阈值，若日志队列达到预设的日志大小阈值，则将日志队列中的日志对象通过多线程上传至日志平台的消息队列。当用户有日志查看需求时，用户将通过应用程序客户端向日志平台发送日志查看请求。在日志平台接收到用户的应用程序客户端发送的日志查看请求时，日志平台根据用户标识，以及本地存储的用户与项目空间之间的对应关系，获取与用户标识对应的目标项目空间，并根据目标项目空间从elasticsearch中获取出目标项目空间对应的所有日志对象，将目标项目空间对应的所有日志对象返回应用程序客户端。通过应用上述分布式日志数据的处理方法，用户只需在日志平台可视化的界面上进行操作，即可便捷地查看与自己关联应用程序的日志情况，无需了解该日志平台的实际逻辑运转流程，简化了日志搜索查询的步骤，减少了服务器资源的不必要浪费。

附图说明

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

图1为本申请提供的分布式日志数据的处理方法的应用场景示意图；

图2为本申请提供的分布式日志数据的处理方法实施例一的流程示意图；

图3为本申请提供的分布式日志数据的处理方法实施例二的流程示意图；

图4为本申请提供的分布式日志数据的处理方法实施例三的流程示意图；

图5为本申请提供的分布式日志数据的处理方法实施例四的流程示意图；

图6为本申请提供的分布式日志数据的处理装置实施例一的结构示意图；

图7为本申请提供的分布式日志数据的处理装置实施例二的结构示意图；

图8为本申请提供的分布式日志数据的处理电子设备的结构示意图。

通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。

具体实施方式

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

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

图1为本申请提供的分布式日志数据的处理方法的应用场景示意图。如图1所示，本申请提供的方案的应用场景中包括应用程序客户端100和服务器101，其中服务器101用于部署日志平台1011，日志平台1011用于存储和可视化展示应用程序客户端100产生的日志数据。

应用程序客户端100主要提供用户登录日志平台1011查看自己关联应用程序日志情况的功能，同时提供维护用户个人信息、增加访问权限控制的功能，防止非研发人员访问到日志系统查看数据，造成日志数据泄露的问题。其中用户会关联具体的项目空间信息，不同用户间关联的应用程序以及同一用户关联的多个应用程序之间相互隔离。当用户想查看自己所属应用程序的日志数据情况时，便可通过应用程序客户端100登录部署在服务器101中的日志平台1011，根据关键词检索、时间范围查询等方法，选择对应的项目空间，即可查看该应用程序对应的系统日志情况。同时应用程序客户端100为用户提供本地服务的应用程序。在应用程序为用户提供服务的过程中，实时在产生大批量的日志数据。这部分日志数据先于本地日志队列中进行暂时存储，随后便传输至日志平台1011所提供的消息队列中。尽管图1中仅示出一个应用程序客户端100，但是应理解可以存在两个或更多的应用程序客户端100。应用程序客户端100通过通信网络与服务器101中的日志平台1011相连。

服务器101主要用于部署日志平台1011，日志平台1011提供日志数据存储和可视化展示的功能。当有接入该日志平台1011的应用程序客户端100启动时，日志平台1011中的Logstash便实时采集应用程序客户端100产生的日志数据，随后传输至Elasticsearch对其进行存储操作，当用户想要查看日志情况时，可通过Kibana实时展示。尽管图1中仅示出一个服务器101，但是应理解可以存在两个或更多的服务器101。服务器101通过通信网络与应用程序客户端100相连。

服务器101均为高性能计算机，拥有计算、存储和处理数据等功能。

在用户完成应用程序开发时，可接入服务器101中部署的日志平台1011，便于用户后续查看应用程序的日志产生情况。在应用程序的实际运行过程中，实时产生着大批量的日志数据，应用程序客户端100便可将这部分日志数据实时传输至服务器101中的日志平台1011。日志平台1011在接收到日志数据后，先对日志数据实施序列化处理操作，并在处理过后将日志数据进行存储。当有用户想查看自己所属应用程序的日志数据情况时，便可通过应用程序客户端100登录部署在服务器101中的日志平台1011，选择对应项目空间，查看对应的系统日志情况。通过为用户提供日志平台1011，可以帮助用户快速、高效地管理日志数据，从而实现对应用程序实际运行过程的监控和分析。

然而，随着数据时代的发展，高访问量高并发量越发常见，数据量趋于海量，传统的单体应用架构有着难以理解和维护、开发效率低等缺点，已经无法满足新时代的需求。为了更好地面对高并发海量数据的问题，微服务架构、分布式系统应运而生，但引入新的技术又会产生一系列其它问题，其中一个核心的问题点就是各个服务系统的日志收集及分析问题。在规模较大的场景中，服务节点多、链路长，面临的问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询等。

针对这种情况，目前常用的处理方法为建立集中式的日志收集系统，将所有节点上的日志统一收集和管理。一般大型系统是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。当前Elasticsearch+Logstash+Kibana框架提供了一整套解决方案，其中Elasticsearch是基于Lucene(一个全文检索引擎的架构)开发的分布式存储检索引擎，用来存储各类日志；Logstash作为数据收集引擎，支持动态地从各种数据源搜集数据，并对数据进行过滤、分析、丰富、统一格式等操作，然后存储到Elasticsearch；Kibana通常与Elasticsearch一起部署，提供图形化的web界面来浏览Elasticsearch存储的日志数据。同时Elasticsearch、Logstash以及Kibana都是开源软件，之间能够互相配合使用，高效满足了很多场合的应用。

然而，上述处理方案存在以下问题：在一些快速交付的项目场景下，目前已有的Elasticsearch+Logstash+Kibana框架存在缺陷。比如Elasticsearch+Logstash+Kibana框架的搭建偏向运维类，其涉及到的中间件较多，项目开发人员需对每部分均有一定知识积累，对项目开发人员友好性较差，同时该框架在接入日志收集需要大量配置工作，在一些小型分布式系统场景下，应用的日志系统过于复杂，不仅浪费服务器资源，还会给用户后续查看日志带来较为繁琐的流程和步骤，降低用户体验感。

针对上述问题，发明人在对分布式日志数据处理过程中服务器资源利用率低以及用户查看日志数据繁琐问题研究的过程中发现，在应用程序客户端产生日志数据后，便立即传输至日志平台，此时应用程序与日志平台实时在占用服务器资源，此外搭建的日志平台涉及的中间件偏多，体量较重，同一服务多个节点调用涉及的日志数据查询主要依据命令行方式，操作难度较大。据此发明人考虑是否可以在应用程序客户端预设日志大小阈值以及时间间隔两个参数，即应用程序客户端产生的日志数据先暂时存放在本地设置的日志队列中，当预设的日志大小阈值或时间间隔触发时，再将日志数据传输至日志平台，这样做能够尽量减少服务器资源的浪费，提高服务器资源的利用率。另外针对目前已有日志平台体量较重，同一服务多个节点调用涉及的日志数据查询操作难度较大的问题，发明人考虑提供一套轻量级的日志平台，基于java语言和SpringBoot框架研发，解决在某些分布式系统场景下查看日志困难繁琐的问题，开发人员只需要在日志平台可视化的界面上进行操作，即可便捷的查看系统日志，对上层屏蔽日志收集处理等一系列过程。

下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。

图2为本申请提供的分布式日志数据的处理方法实施例一的流程示意图。如图2所示，该分布式日志数据的处理方法的流程可以包括：

S201：在应用程序客户端启动后，多线程监听日志产生情况获取日志数据，并根据预设的日志格式生成日志对象。

在本步骤中，应用程序客户端是为用户提供本地服务的应用程序。在应用程序开发时，主要基于java语言和springBoot框架研发，日志采集过程借助logback的日志上报机制，其中logback是由log4j创始人设计的开源日志组件，它当前分为三个模块，即logback-core、logback-classic以及logback-access。

在应用程序客户端成功启动后，首先实施多项初始化操作。比如读取logback的配置，校验命名空间、配置等信息，根据预先配置的参数信息，确定后续产生的日志数据该被推送到哪个消息中间件，所涉及的消息中间件有高吞吐量的分布式发布订阅消息系统kafka、远程字典服务redis等，具体为应用程序配置哪个消息中间件，需根据具体的业务需求，灵活选配，同时会根据选用消息中间件的不同，初始化不同的Appender和Client，比如kafkaAppender、redisAppender以及对应的kafkaClient、redisClient等。在初始化消息中间件后，则初始化本地队列blockingQuenue，并开启监听日志情况。

应用程序客户端启动并各项初始化操作结束后，运行多个线程，进行多个任务，产生不同类型的日志数据。因日志数据类型多样，缺乏统一性，若不对其进行进一步处理，则会给后续日志数据的获取和分析带来繁琐步骤，降低执行效率，故依据预设的日志格式，将获取到的日志数据生成对应的日志对象，即logMessage对象，便于后续管理和查询。

常见的日志格式中对于每一条日志含有的信息包括日期、时间、日志级别、代码位置、日志内容、错误码等信息，具体如何设置以及设置哪些信息根据用户需求进行个性化定制。

S202：检测本地设置的日志队列是否已满。

在本步骤中，当步骤S201获取到日志数据并将其转换为日志对象后，将考虑其后续的存储位置。因应用程序在初始开发时，所应用的程序框架中包括本地日志队列，但本地日志队列有一定的大小空间，故需要首先检测本地设置的日志队列是否已满，根据判断结果决定后续日志对象的存储位置。

S203：若日志队列未满，则将日志对象放入日志队列。

在本步骤中，若检测到本地设置的日志队列未满，则将步骤S201中获取到的日志对象放入该本地设置的日志队列；若检测到本地设置的日志队列已满，则需等待本地队列空间的释放，否则将会产生应用程序阻塞问题的发生。

S204：判断日志队列的大小是否达到预设的日志大小阈值。

在本步骤中，当将日志对象暂时存放在本地设置的日志队列中后，需要考虑本地设置的日志队列的存储空间问题，故预设日志大小阈值，判断日志队列的大小是否达到预设的日志大小阈值，从而保证日志对象的可靠性、并发性以及应用程序运行的流畅性。

设置日志大小阈值参数，该日志大小参数为正整数，其与本地设置的日志队列大小关系为小于等于，比如本地设置的日志队列大小为100条，那么该日志大小参数的数值需要小于等于100条，比如80条、30条等符合条件的正整数数值。

S205：若日志队列达到日志大小阈值，则将日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

在本步骤中，当本地设置的日志队列中所存放的日志对象的大小达到预设的日志大小阈值后，则将日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

应用多线程操作的目的是提高日志对象上传的效率，保证日志对象的实时性。若采用单线程上传的方式，则不可避免会造成应用程序运行缓慢等问题。

S206：接收用户的应用程序客户端发送的日志查看请求，日志查看请求中包括用户标识。

在本步骤中，用户登录应用程序客户端后，日志平台将接收用户于应用程序客户端发送的日志查看请求。在日志查看请求中，包括用户标识，该用户标识能够唯一确定该用户是否有登录该日志平台的权限，日志平台则会根据该标识匹配平台内部已有的用户信息，在匹配结束后，回复应用程序客户端，从而告知发送日志查看请求的用户是否被允许登录日志平台。

S207：根据用户标识，以及本地存储的用户与项目空间之间的对应关系，获取与用户标识对应的目标项目空间。

在本步骤中，用户通过应用程序客户端成功登录至日志平台后，日志平台将根据用户的日志查看请求中的用户标识，以及日志平台于本地存储的用户与项目空间之间的对应关系，获取与用户标识对应的目标项目空间。目标项目空间中包括与该应用程序相关的所有日志数据信息，用户能够以可视化的方式于日志平台查看，同时该日志平台支持关键词检索、时间范围查询等功能，用户能够根据自己的需求实时查看与自己关联项目空间的日志产生情况。

S208：根据目标项目空间，从elasticsearch中获取出目标项目空间对应的所有日志对象；其中，elasticsearch中存储有按照预设格式汇总的多个项目空间的所有日志对象。

在本步骤中，elasticsearch是一个开源的高扩展的分布式全文检索引擎，它可以近乎实时的检索数据，本身扩展性较好，可以扩展到上百台服务器，处理PB级别的数据。elasticsearch使用Java开发，Lucene作为其核心来实现所有的索引和搜索的功能。

elasticsearch中的日志对象是从消息中间件中所获取，比如消息中间件是kafka，当应用程序客户端启动时，kafka消息队列的消费者和lasticsearch客户端也将同时初始化，之后循环监听kafka消息队列上指定主题下的消息，有日志对象产生时则快速进行异步消费，通过elasticsearch客户端程序将日志对象序列化后汇总到elasticsearch上进行存储。

根据步骤S207中得到的与用户标识对应的目标项目空间后，日志平台则根据目标项目空间，从elasticsearch中获取出目标项目空间对应的所有日志对象，其中elasticsearch中存储的日志对象均是按照预设的格式进行汇总，预设的格式主要是将从消息中间件中获取的日志对象进行序列化操作，序列化操作的目的是轻量化所有日志对象，解决空间资源浪费的问题。

S209：将目标项目空间对应的所有日志对象返回应用程序客户端。

在本步骤中，基于步骤S208中得到的目标空间对应的日志对象，日志平台将把日志对象返回应用程序客户端进行可视化展示。

本实施例提供的分布式日志数据的处理方法，主要涉及的程序有日志平台以及任一应用程序客户端。应用程序在开发过程中引入日志平台服务的相关依赖，并于logback中配置指定的appender信息后，说明该应用程序成功接入日志平台。在应用程序客户端成功启动后，应用程序产生的日志数据将被实时地多线程监听，同时根据预设日志格式生成对应日志对象，其中日志数据采集的过程借助logback的日志上报机制，首先日志数据根据预设日志格式生成对应日志对象后先被推到本地设置的日志消息队列做一级缓冲，随后采用对本地设置队列的大小判断机制，多线程传输日志消息至消息中间件，同时使用订阅发布机制，多线程收集以及处理日志对象，保证了保证日志消息的可靠性以及并发性。当用户有日志查看需求时，用户将通过应用程序客户端向日志平台发送日志查看请求。在日志平台接收到用户于应用程序客户端发送的日志查看请求后，根据请求中携带的用户标识以及本地存储的用户与项目空间之间的对应关系，日志平台获取目标项目空间并从elasticsearch中获取目标项目空间对应的所有日志对象，返回应用程序客户端，以可视化的方式将应用程序对应的日志情况呈现给用户，从而减少了用户查看日志情况的流程步骤，增强便捷性。该日志平台支持多应用程序的同时接入，接入操作实现也较为简单，提高了用户的体验感。此外该平台项目空间之间实现隔离化，基于logback配置及初始化中间件连接，进行日志收集以及处理，实现了日志平台的轻量化，提高了服务器资源的利用率，减少了系统资源的浪费。

图3为本申请提供的分布式日志数据的处理方法实施例二的流程示意图。如图3所示，在上述图2所示的实施例的基础上，根据目标项目空间，从elasticsearch中获取出目标项目空间对应的所有日志对象之前，该分布式日志数据的处理方法还包括以下步骤：

S301：针对每个应用程序客户端，通过多线程接收应用程序客户端上传的日志对象，并将日志对象放入消息队列；其中，同一个应用程序客户端的日志对象是以一定的时间间隔上传的。

在本步骤中，每个应用程序客户端在实际运行过程中所产生的日志对象先被推到本地设置的日志消息队列做一级缓冲，随后应用定时检查和队列大小检查的双重处理机制将日志对象放入消息队列，比如RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ以及Pulsar等。

同一个应用程序客户端的日志对象是以预先设置的时间间隔上传的，从而保证网络资源的高效率使用，避免造成网络资源浪费。

S302：基于分布式系统的至少一个节点，从消息队列中获取出每个项目空间对应的至少一个日志对象。

在本步骤中，分布式系统是其组件分布在联通的计算机上，组件之间通过消息传递进行通信和动作协调的系统。在分布式系统启动后，其中涉及的多个节点会相应产生日志数据，这些日志数据在被统一格式化处理为日志对象后，存储在消息队列中。日志平台中的消息队列消费者将从消息队列中获取出每个项目空间对应的至少一个日志对象，进行后续的存储操作。

S303：将至少一个日志对象按照预设格式汇总在elasticsearch上进行存储。

在本步骤中，基于步骤S302中得到的至少一个日志对象，日志平台将对该日志对象进行序列化处理，最后汇总在elasticsearch上进行存储。序列化处理即预设格式，实现日志对象格式的统一化和轻量化，节省存储空间。

本实施例提供的分布式日志数据的处理方法，主要涉及日志平台从elasticsearch中获取目标项目空间对应的所有日志对象之前进行的一系列操作。elasticsearch中日志对象的获取来源是消息中间件，当消息队列的消费者监听到消息中间件中有日志对象时，则快速进行异步消费，并按照预设的格式对获取到的日志对象做序列化处理，减少空间占比，降低资源浪费。在序列化处理后，elasticsearch客户端程序便将日志对象汇总到elasticsearch上进行最后的存储，从而避免日志数据的丢失。

图4为本申请提供的分布式日志数据的处理方法实施例三的流程示意图。如图4所示，本实施例在上述实施例的基础上，接收用户的应用程序客户端发送的日志查看请求之前，该分布式日志数据的处理方法还包括以下步骤：

S401：接收应用程序客户端发送的登录申请，登录申请中包括用户的登录信息。

在本步骤中，用户根据应用程序客户端的要求填写信息后，应用程序客户端将登录请求发送至日志平台，日志平台便接收到应用程序客户端发送的登录申请，在该申请中，包括用户在登录时填写的用户登录信息，该登录信息将作为用户是否有权限于日志平台查看日志情况的依据。

S402：根据登录信息，以及本地存储的权限管理信息，确定用户是否具备登录日志系统查看日志的权限。

在本步骤中，根据步骤S401获得的登录信息，以及日志平台于本地存储的权限管理信息，确定用户是否具备登录日志系统查看日志的权限。其中，登录信息中包括用户的个人基本信息，比如用户标识，日志平台于本地存储的权限管理信息包括各个用户的基本信息、各个用户与自己关联的应用程序的关系、各个应用程序关联的日志情况等。

日志平台将把应用程序客户端发送过来的用户信息中涉及的用户标识与本地存储的权限管理信息进行比对，在比对过程中，若发现该用户确实属于日志平台维护的相关用户，则确定该用户具备登录日志系统查看日志的权限，相反则不具备。

S403：在确定出用户具备登录日志系统查看日志的权限时，授权用户访问日志系统，并向应用程序客户端发送登录认证通过消息。

在本步骤中，基于步骤S402确定出用户具备登录日志系统查看日志的权限时，日志平台将授权用户访问日志系统，同时向应用程序客户端发送登录认证通过的消息，后续用户便可根据自己的需求查看对应应用程序的日志产生情况；若步骤S402确定出用户不具备登录日志系统查看日志的权限，则日志平台不会授权用户访问日志系统，同时向应用程序客户端发送登录认证不通过的消息，从而保证日志平台的安全性。

本实施例提供的分布式日志数据的处理方法，主要为日志平台接收用户的应用程序客户端发送的日志查看请求之前所涉及的流程步骤。在用户于应用程序客户端按要求填写信息结束后，应用程序客户端将会把用户的登录请求发送至日志平台，日志平台则会根据用户登录请求中包含的用户标识与本地存储的管理权限信息进行精准匹配。根据匹配的结果，日志平台将会执行用户能否授权访问日志系统的操作，并向应用程序客户端发送登录认证是否通过的消息，从而给用户及时的登录反馈，保证日志平台内关联用户以及应用程序的安全性，降低用户隐私泄露的问题，同时给用户提供便捷查看应用程序日志情况的平台，减少日志查看繁琐的流程，提高用户体验感。

作为一种可选实施方式，本实施例提供的分布式日志数据的处理方法，在上述任意一个实施例的基础上，该分布式日志数据的处理方法还包括以下步骤：

用户与项目空间之间的对应关系中每个用户对应至少一个项目空间。

在本步骤中，用户与项目空间的对应关系中每个用户对应至少一个项目空间，也可以是多个项目空间，比如有的用户参与研发的应用程序有多个，同时这多个研发完成的应用程序已经成功接入日志平台，日志平台将会把这几个应用程序与该用户进行关联，应用程序之间是以隔离的方式进行存放，从而保证不同应用程序之间日志数据不存在交叉性，为用户提供清晰的日志情况。

本实施例提供的分布式日志数据的处理方法，主要涉及用户与项目空间之间对应关系的限制。当业务系统成功接入日志平台后，日志平台将会把对应的用户与该业务系统关联起来，在后续用户通过应用程序客户端于日志平台查看自己应用程序的日志情况时，日志平台将准确地将应用程序有关情况清晰地呈现在用户面前，减少了现阶段日志查看繁琐的流程，同时用户只需在日志平台可视化的界面上进行操作，便可查看自己对应应用程序的日志情况，便捷性高，操作较为简单。

图5为本申请提供的分布式日志数据的处理方法实施例四的流程示意图。如图5所示，该分布式日志数据的处理方法的步骤基本与图2中一致，与图2所示的分布式日志数据的处理方法不同的步骤为：

S506：若日志队列未达到日志大小阈值，则确定上次上传日志的时刻到当前时刻的时间间隔是否达到预设时间间隔。

在本步骤中，若日志队列未达到日志大小阈值，则需要确定上次上传日志的时刻到当前时刻的时间间隔是否达到预设的时间间隔。若不预设时间间隔，出现的情况会有获取到的日志对象存放在本地设置的日志队列，仅依靠预设的日志大小阈值决定是否将日志对象传输至消息队列，或等本地设置的队列完全被填满后再进行日志对象的传输操作，则会在一定程度上降低日志对象的实时性。

预设时间间隔的大小根据具体的业务需求进行设定，针对实时性较强的应用程序，设置的预设时间间隔应简短一些，比如1小时或者更短，而针对实时性要求不高的应用程序而言，设置的预设时间间隔可以稍微延长，比如2小时等，具体时间间隔的长短需要相对而言。

S507：若上次上传日志的时刻到当前时刻的时间间隔达到预设时间间隔，则将日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

在本步骤中，若上次上传日志的时刻到当前时刻的时间间隔达到预设时间间隔，则将日志队列中的日志对象通过多线程上传至日志平台中的消息队列，保证了日志对象上传的实时性。比如预设的时间间隔为1小时，上次上传日志的时刻为本日的上午9时，而当前时刻为上午10时，此时需要将日志队列中的日志对象通过多线程上传至日志平台中的消息队列；若当前时刻为上午9时45分，那么本地设置的日志队列中的日志对象则暂时存放。

本实施例提供的分布式日志数据的处理方法，主要涉及对本地队列中日志对象定时检查的处理机制。当本地设置的日志队列未满或者本地设置的日志队列中已存在的日志大小小于预设的日志大小阈值时，应用程序客户端将启动定时检查的处理机制。该机制通过预设时间间隔，计算当前时刻至上次上传日志时刻的时间间隔，若计算所得的时间间隔达到预设的时间间隔，则应用程序客户端将以批量方式把本地设置的日志队列中存在的日志对象上传至消息中间件，从而保证日志对象上传的实时性，减少日志数据丢失问题的出现。

作为一种可选实施方式，本实施例提供的分布式日志数据的处理方法，在上述任意一个实施例的基础上，在应用程序客户端启动后，该分布式日志数据的处理方法还包括以下步骤：

根据雪花算法生成应用程序客户端对应的贯穿全链路TID；

相应的，根据预设的日志格式生成日志对象，包括：

根据预设的日志格式生成日志对象，并将贯穿全链路TID加入到日志对象中的RpcContext对象中。

在本步骤中，雪花算法是一种生成唯一贯穿全链路TID的算法，主要应用于分布式系统中，它可以在不依赖于数据库等其他存储设施的情况下，生成全局唯一的贯穿全链路TID。

在分布式系统中，会存在多个系统之间的相互调用，比如系统之间的http调用、系统之间的MQ消费以及系统与数据库之间的调用。一个请求包含很多组件，需要调用的应用程序涉及多个，整个链路很长，为了后续方便根据日志排查故障需要依据雪花算法生成贯穿全链路TID。

在应用程序客户端启动后，贯穿全链路TID在入口WEB服务处生成，后续的服务间调用会一直进行传递。如在dubbo的微服务治理架构下，可将此贯穿全链路TID标识在服务通信时加入到日志对象的RpcContext对象中进行传递，其中RpcContext对象是dubbo微服务治理框架所特有的属性，能够隐式传递对应参数。

关于贯穿全链路TID在进入每个服务节点自动打印的解决方案，采用自定义注解加切面的方式进行拦截。如果全局对象中没有贯穿全链路TID，则在切的逻辑中进行生成，根据雪花算法生成，从而保证全局的唯一性；如果有TID，则直接将TID信息在前置通知的处理中进行打印。关于在应用程序方法中自己增加的日志，其贯穿全链路TID自动打印可借助映射诊断上下文MDC机制解决，MDC主要用在做日志链路追踪时，动态配置用户自定义的一些信息，比如requestId、sessionId等，MDC使用的容器支持多线程操作，满足线程安全。

本实施例提供的分布式日志数据的处理方法，主要涉及设计一个贯穿全链路TID的流程。若项目的架构是微服务体系，如dubbo治理下的微服务架构，此时一次请求的整体调用，日志可能会跨多个服务节点，此时根据自定义注解加切面的方式以及雪花算法，实现全局链路追踪TID的生成传递和自动打印的策略。在后续排查分布式系统对应项目的故障问题时，依据该TID能够较为快速定位到具体故障位置，实现故障的快速清除以及项目的正常运转。在应用程序项目接入日志平台的过程中，如果需要生成全局TID，可在对应的类、方法上加上自定义注解，不需要TID则直接忽略，此日志平台设计对接入的应用程序项目侵入性交底、使用简单。

图6为本申请提供的分布式日志数据的处理装置实施例一的结构示意图。如图6所示，该分布式日志数据的处理装置600包括：

接收模块601，用于接收用户的应用程序客户端发送的日志查看请求，日志查看请求中包括用户标识；

处理模块602，用于根据用户标识，以及本地存储的用户与项目空间之间的对应关系，获取与用户标识对应的目标项目空间；

处理模块602还用于根据目标项目空间，从elasticsearch中获取出目标项目空间对应的所有日志对象；其中，elasticsearch中存储有按照预设格式汇总的多个项目空间的所有日志对象；

发送模块603，用于将目标项目空间对应的所有日志对象返回应用程序客户端。

可选地，处理模块602还用于：

针对每个应用程序客户端，通过多线程接收应用程序客户端上传的日志对象，并将日志对象放入消息队列；其中，同一个应用程序客户端的日志对象是以一定的时间间隔上传的；

基于分布式系统的至少一个节点，从消息队列中获取出每个项目空间对应的至少一个日志对象；

将至少一个日志对象按照预设格式汇总在elasticsearch上进行存储。

可选地，接收模块601还用于：

接收应用程序客户端发送的登录申请，登录申请中包括用户的登录信息；

根据登录信息，以及本地存储的权限管理信息，确定用户是否具备登录日志系统查看日志的权限；

在确定出用户具备登录日志系统查看日志的权限时，授权用户访问日志系统，并向应用程序客户端发送登录认证通过消息。

可选地，处理模块602还用于：

用户与项目空间之间的对应关系中每个用户对应至少一个项目空间。

前述各实施例提供的分布式日志数据的处理装置，可以用于执行前述任一方法实施例中分布式日志数据的处理方法，其实现原理和技术效果类似，该分布式日志数据的处理装置维护用户信息，增加访问权限控制，防止非研发人员访问到日志平台查看数据，造成数据泄露的问题。同时，该分布式日志数据的处理装置中用户关联具体的项目空间信息，一个用户支持多项目空间的关联，各项目空间之间相互隔离，给后续用户查看日志情况提供清晰流程。在用户查看日志时，以可视化的方式呈现给用户，无需了解该日志平台实际的逻辑运行过程，解决日志查看繁琐的问题。

图7为本申请提供的分布式日志数据的处理装置实施例二的结构示意图。如图7所示，该分布式日志数据的处理装置700包括：

获取模块701，用于在应用程序客户端启动后，多线程监听日志产生情况获取日志数据，并根据预设的日志格式生成日志对象；

处理模块702，用于检测本地设置的日志队列是否已满；

处理模块702还用于若日志队列未满，则将日志对象放入日志队列；

处理模块702还用于判断日志队列的大小是否达到预设的日志大小阈值；

发送模块703，用于若日志队列达到日志大小阈值，则将日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

可选地，发送模块703还用于：

若日志队列未达到日志大小阈值，则确定上次上传日志的时刻到当前时刻的时间间隔是否达到预设时间间隔；

若上次上传日志的时刻到当前时刻的时间间隔达到预设时间间隔，则将日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

可选地，发送模块703还用于：

根据雪花算法生成应用程序客户端对应的贯穿全链路TID；

相应的，根据预设的日志格式生成日志对象，包括：

根据预设的日志格式生成日志对象，并将贯穿全链路TID加入到日志对象中的RpcContext对象中。

本实施例提供的分布式日志数据的处理装置，可以用于执行前述任一方法实施例中分布式日志数据的处理方法，其实现原理和技术效果类似，在此不再赘述。

图8为本申请提供的分布式日志数据的处理电子设备的结构示意图。如图8所示，该电子设备具体可以包括接收器800、发送器801、处理器802以及存储器803。其中，上述接收器800和发送器801用于实现电子设备与应用程序客户端之间的数据传输，上述存储器803存储计算机执行指令；上述处理器802执行上述存储器803存储的计算机执行指令，以实现上述实施例中的分布式日志数据的处理方法。

本实施例提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机执行指令，计算机执行指令被处理器执行时用于实现上述实施例中的分布式日志数据的处理方法。

本申请实施例还提供一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时实现上述任意一个实施例提供的分布式日志数据的处理方法。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本申请所必须的。

进一步需要说明的是，虽然流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

应该理解，上述的装置实施例仅是示意性的，本申请的装置还可通过其它的方式实现。例如，上述实施例中单元/模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。例如，多个单元、模块或组件可以结合，或者可以集成到另一个系统，或一些特征可以忽略或不执行。

另外，若无特别说明，在本申请各个实施例中的各功能单元/模块可以集成在一个单元/模块中，也可以是各个单元/模块单独物理存在，也可以两个或两个以上单元/模块集成在一起。上述集成的单元/模块既可以采用硬件的形式实现，也可以采用软件程序模块的形式实现。

集成的单元/模块如果以硬件的形式实现时，该硬件可以是数字电路，模拟电路等等。硬件结构的物理实现包括但不局限于晶体管，忆阻器等等。若无特别说明，处理器可以是任何适当的硬件处理器，比如CPU、GPU、FPGA、DSP和ASIC等等。若无特别说明，存储单元可以是任何适当的磁存储介质或者磁光存储介质，比如，阻变式存储器RRAM(ResistiveRandom Access Memory)、动态随机存取存储器DRAM(Dynamic Random Access Memory)、静态随机存取存储器SRAM(Static Random-Access Memory)、增强动态随机存取存储器EDRAM(Enhanced Dynamic Random Access Memory)、高带宽内存HBM(High-Bandwidth Memory)、混合存储立方HMC(Hybrid Memory Cube)等等。

集成的单元/模块如果以软件程序模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储器中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储器中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储器包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。上述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围

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

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

Claims (11)

1.一种分布式日志数据的处理方法，其特征在于，应用于日志平台，所述方法包括：

接收用户的应用程序客户端发送的日志查看请求，所述日志查看请求中包括用户标识；

根据所述用户标识，以及本地存储的用户与项目空间之间的对应关系，获取与所述用户标识对应的目标项目空间；

根据所述目标项目空间，从elasticsearch中获取出所述目标项目空间对应的所有日志对象；其中，所述elasticsearch中存储有按照预设格式汇总的多个项目空间的所有日志对象；

将目标项目空间对应的所有日志对象返回所述应用程序客户端。

2.根据权利要求1所述的方法，其特征在于，所述根据所述目标项目空间，从elasticsearch中获取出所述目标项目空间对应的所有日志对象之前，所述方法还包括：

针对每个应用程序客户端，通过多线程接收所述应用程序客户端上传的日志对象，并将所述日志对象放入消息队列；其中，同一个应用程序客户端的日志对象是以一定的时间间隔上传的；

基于分布式系统的至少一个节点，从所述消息队列中获取出每个项目空间对应的至少一个日志对象；

将所述至少一个日志对象按照预设格式汇总在所述elasticsearch上进行存储。

3.根据权利要求1或2所述的方法，其特征在于，所述接收用户的应用程序客户端发送的日志查看请求之前，所述方法还包括：

接收所述应用程序客户端发送的登录申请，所述登录申请中包括用户的登录信息；

根据所述登录信息，以及本地存储的权限管理信息，确定所述用户是否具备登录日志系统查看日志的权限；

在确定出所述用户具备登录日志系统查看日志的权限时，授权所述用户访问日志系统，并向所述应用程序客户端发送登录认证通过消息。

4.根据权利要求1或2所述的方法，其特征在于，所述用户与项目空间之间的对应关系中每个用户对应至少一个项目空间。

5.一种分布式日志数据的处理方法，其特征在于，应用于任一应用程序客户端，所述方法包括：

在所述应用程序客户端启动后，多线程监听日志产生情况获取日志数据，并根据预设的日志格式生成日志对象；

检测本地设置的日志队列是否已满；

若所述日志队列未满，则将所述日志对象放入所述日志队列；

判断所述日志队列的大小是否达到预设的日志大小阈值；

若所述日志队列达到所述日志大小阈值，则将所述日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

6.根据权利要求5所述的方法，其特征在于，所述方法还包括：

若所述日志队列未达到所述日志大小阈值，则确定上次上传日志的时刻到当前时刻的时间间隔是否达到预设时间间隔；

若上次上传日志的时刻到当前时刻的时间间隔达到预设时间间隔，则将所述日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

7.根据权利要求5或6所述的方法，其特征在于，所述在所述应用程序客户端启动后，所述方法还包括：

根据雪花算法生成所述应用程序客户端对应的贯穿全链路TID；

相应的，所述根据预设的日志格式生成日志对象，包括：

根据预设的日志格式生成所述日志对象，并将所述贯穿全链路TID加入到所述日志对象中的RpcContext对象中。

8.一种分布式日志数据的处理装置，其特征在于，包括：

接收模块，用于接收用户的应用程序客户端发送的日志查看请求，所述日志查看请求中包括用户标识；

处理模块，用于根据所述用户标识，以及本地存储的用户与项目空间之间的对应关系，获取与所述用户标识对应的目标项目空间；

所述处理模块还用于根据所述目标项目空间，从elasticsearch中获取出所述目标项目空间对应的所有日志对象；其中，所述elasticsearch中存储有按照预设格式汇总的多个项目空间的所有日志对象；

发送模块，用于将目标项目空间对应的所有日志对象返回所述应用程序客户端。

9.一种分布式日志数据的处理装置，其特征在于，包括：

获取模块，用于在所述应用程序客户端启动后，多线程监听日志产生情况获取日志数据，并根据预设的日志格式生成日志对象；

处理模块，用于检测本地设置的日志队列是否已满；

所述处理模块还用于若所述日志队列未满，则将所述日志对象放入所述日志队列；

所述处理模块还用于判断所述日志队列的大小是否达到预设的日志大小阈值；

发送模块，用于若所述日志队列达到所述日志大小阈值，则将所述日志队列中的日志对象通过多线程上传至日志平台中的消息队列。

10.一种电子设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；

所述存储器存储计算机执行指令；

所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1至7任一项所述的方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至7任一项所述的方法。