CN112650599A - 一种日志处理方法、设备及存储介质 - Google Patents

Abstract

本申请提供一种日志处理方法、设备及计算机可读存储介质，其中，方法包括：获取各个目标设备发送的日志信息；将日志信息存储至分布式消息中间件的第一消息队列；调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息，并将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理；实现了数据可靠地导入联机分析处理平台，确保日志处理设备具有高吞吐量和高性能。

Description

一种日志处理方法、设备及存储介质

技术领域

本申请实施例涉及金融科技(Fintech)的日志管理技术领域，涉及但不限于一种日志处理方法、设备及计算机可读存储介质。

背景技术

随着计算机技术的发展，越来越多的技术应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，然而，由于金融行业的安全性、实时性要求，金融科技也对技术提出了更高的要求。

金融科技领域下，各种通信设备产生的数据越来越多，当通信设备产生大量日志信息时，目前采用Tranquility实现日志信息导入联机分析处理平台。Tranquility支持超文本传输协议(HyperText Transfer Protocol，Http)方式摄取数据，将日志信息从目标设备直接发至联机分析处理平台。然而，在日志信息量较大的情况下，将日志信息从目标设备直接发至联机分析处理平台时，上述方案至少存在日志处理设备发生崩溃的问题。

发明内容

本申请实施例提供一种日志处理方法、设备及计算机可读存储介质，解决了在日志信息量较大的情况下，将日志信息从目标设备直接发至联机分析处理平台时，相关技术中至少存在日志处理设备发生崩溃的问题；实现了高并发情况下数据的快速拉取，实现了数据可靠地导入联机分析处理平台，确保日志处理设备具有高吞吐量和高性能。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种日志处理方法，包括：

获取各个目标设备发送的日志信息；

将所述日志信息存储至分布式消息中间件的第一消息队列；

调用插件基于多线程并行拉取策略，从所述第一消息队列中拉取第一目标日志信息，并将所述第一目标日志信息存储至联机分析处理平台，以使得所述联机分析处理平台对所述第一目标日志信息进行分析处理。

本申请实施例提供一种日志处理装置，包括：

获取模块，用于获取各个目标设备发送的日志信息；

存储模块，用于将所述日志信息存储至分布式消息中间件的第一消息队列；

调用模块，用于调用插件基于多线程并行拉取策略，从所述第一消息队列中拉取第一目标日志信息，并将所述第一目标日志信息存储至联机分析处理平台，以使得所述联机分析处理平台对所述第一目标日志信息进行分析处理。

本申请实施例提供一种日志处理设备，包括：

存储器，用于存储可执行指令；处理器，用于执行存储器中存储的可执行指令时，实现上述的方法。

本申请实施例提供一种计算机可读存储介质，存储有可执行指令，用于引起处理器执行时，实现上述的方法。

本申请实施例具有以下有益效果：

通过获取各个目标设备发送的日志信息；将日志信息存储至分布式消息中间件的第一消息队列；调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息，并将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理；也就是说，获取到各个终端发送的日志信息后，将其存储在分布式消息中间件的第一消息队列中，即将大量的日志信息放在一个临时缓存区域，进而从临时缓存区域拉取日志信息，如此不仅避免在日志信息量较大的情况下，将日志信息从目标设备直接发至联机分析处理平台时，至少存在日志处理设备发生崩溃的现象，而且实现了高并发情况下数据的快速拉取，实现了数据可靠地导入联机分析处理平台，确保日志处理设备具有高吞吐量和高性能。

附图说明

图1是本申请实施例提供的服务器的一个可选的架构示意图；

图2是本申请实施例提供的日志处理方法的一个可选的流程示意图；

图3是本申请实施例提供的日志处理方法的一个可选的流程示意图；

图4是本申请实施例提供的日志处理方法的一个可选的流程示意图；

图5是本申请实施例提供的日志处理方法的一个可选的流程示意图；

图6是本申请实施例提供的日志处理方法的一个可选的流程示意图；

图7是本申请实施例提供的通过插件将数据传输至OLAP平台的示意图；

图8是本申请实施例提供的OLAP对各个目标设备发送的日志信息进行分析后得到的设备之间的联系的示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。除非另有定义，本申请实施例所使用的所有的技术和科学术语与属于本申请实施例的技术领域的技术人员通常理解的含义相同。本申请实施例所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

1)开源软件基金会(Apache)，它是全世界最大的开源软件基金会之一。

2)Apache Druid:一种高性能的实时分析数据库。Apache Druid是一个开源的分布式的支持实时分析和实时摄入的数据存储系统。其中的每个Apache Druid进程都可以独立配置和扩展，在集群上提供最大的灵活性。这种设计还提供了增强的容错能力：一个组件的中断不会立即影响其他组件。Druid可以实现大数据量下的实时联机分析处理(Onlineanalytical Processing，OLAP)。联机分析处理是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。

3)分布式消息中间件，负责接收，保存和分发消息，在分布式场景下可扩展进程之间的通信，同时降低多个系统之间的耦合程度。分布式消息中间件包括RocketMQ。

4)Apache RocketMQ平台，是一种低延迟、高可靠、高性能、亿级容量、灵活扩展的分布式消息和数据流平台。

5)Apache计算引擎(Spark)：一种专为大规模数据处理而设计的快速通用的计算引擎。

6)Kafka，一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

7)实时数据流如Spark Streaming，是核心Spark API的一个扩展，支持可扩展、高吞吐、容错好的实时数据流处理。

8)发送数据流到Apache Druid的http客户端如Tranquility，Tranquil ity组件可以连接多种流式数据源，比如Spark Streaming。

9)主题(Topic)，表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。

10)消息队列(Message Queue)，消息逻辑存储单位，一个Topic下的消息，顺序保存多个消息队列中。

这里，对相关技术中的一种日志处理方法进行介绍，相关技术中，一般采用Spark-Streaming实时计算数据流，用于监控和数据分析；需要指出的是，采用Spark-Streaming做数据聚合计算，不支持实时的交互式查询，并且需求和配置偏向定制化，比如设定的统计时间间隔固定，修改后需要重启进程。

相关技术中的另一种日志处理方法，采用apache-druid实现联机分析处理OLAP，结合Kafka插件或tranquility实现数据摄入；需要指出的是，如果采用Tranquility的方案来做apache-druid的数据导入，基于Http方式摄取数据，将日志信息从目标设备直接发至联机分析处理平台，在日志信息量较大的情况下，日志处理设备发生崩溃。Tranquility是MetaMarket公司开源的项目，更新速度比较缓慢，而且缺失监控功能，我们不能监控到实例的运行状态，摄取速率等信息，不能满足自定义需求。如果采用Kafka插件做数据实时导入，依赖于Kafka数据平台，随着业务增长，Topic的数据增多，集群负载增大，性能会出现下降，在金融科技(Fintech)场景下对实时分布式业务并发的性能要求日益增加；同时Kafka插件仅使用单线程的方式做数据摄取并且没有消息位移自动复位功能，设计上存在风险点。

基于上述各个缺陷，本申请提供的日志处理方法，使用Apache-druid做实时数据分析并结合RocketMQ实时摄入数据流，实现了将RocketMQ数据直接导入Apache-druid的轻量级插件，保证了消息的高可靠和高并发，并且支持了亚秒响应的交互式查询。而且apache-druid支持亚秒级的交互式查询和灵活的配置提交，无需重启进程。

下面说明本申请实施例提供的日志处理设备的示例性应用，本申请实施例提供的日志处理设备可以实施为笔记本电脑，平板电脑，台式计算机，移动设备(例如，便携式音乐播放器，个人数字助理，专用消息设备)，智能机器人等终端，也可以实施为服务器。下面，将说明日志处理设备实施为服务器时的示例性应用。

参见图1，图1是本申请实施例提供的服务器100的结构示意图，图1所示的服务器100包括：至少一个处理器110、至少一个网络接口120、用户接口130和存储器150。服务器100中的各个组件通过总线系统140耦合在一起。可理解，总线系统140用于实现这些组件之间的连接通信。总线系统140除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图1中将各种总线都标为总线系统140。

处理器110可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(Digital Signal Processor，DSP)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口130包括使得能够呈现媒体内容的一个或多个输出装置131，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口130还包括一个或多个输入装置132，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器150可以是可移除的，不可移除的或其组合。示例性地硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器150可选地包括在物理位置上远离处理器110的一个或多个存储设备。存储器150包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(Read Only Memory，ROM)，易失性存储器可以是随机存取存储器(Random Access Memory，RAM)。本申请实施例描述的存储器150旨在包括任意适合类型的存储器。在一些实施例中，存储器150能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统151，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块152，用于经由一个或多个(有线或无线)网络接口120到达其他计算设备，示例性地网络接口120包括：蓝牙、无线相容性认证无线保真(Wireless Fidelity，WiFi)、和通用串行总线(Universal Serial Bus，USB)等；

输入处理模块153，用于对一个或多个来自一个或多个输入装置132之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的装置可以采用软件方式实现，图1示出了存储在存储器150中的一种日志处理装置154，该日志处理装置154可以是服务器100中的日志处理装置，其可以是程序和插件等形式的软件，包括以下软件模块：获取模块1541、存储模块1542、调用模块1543、处理模块1544，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分。将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的装置可以采用硬件方式实现，作为示例，本申请实施例提供的装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的日志处理方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(Application Specific Integrated Circuit，ASIC)、DSP、可编程逻辑器件(Programmable Logic Device，PLD)、复杂可编程逻辑器件(Complex ProgrammableLogic Device，CPLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或其他电子元件。

下面将结合本申请实施例提供的服务器100的示例性应用和实施，说明本申请实施例提供的日志处理方法。

参见图2，图2是本申请实施例提供的日志处理方法的一个可选的流程示意图，将结合图2示出的步骤进行说明；

步骤S201，获取各个目标设备发送的日志信息。

本申请实施例中，目标设备支持各种应用程序(Application，APP)和小程序，例如以下中的一个或多个：金融服务APP，保险服务APP，商城小程序，城市服务APP，智能生活小程序，绿色出行小程序，金融小程序，云音乐服务APP，游戏APP，证券服务APP，客户服务APP，直播APP，云会议服务APP等。目标设备上的各种应用和金融交易都会产生大量的后台流水和日志信息。

步骤S202，将日志信息存储至分布式消息中间件的第一消息队列。

其中，分布式消息中间件包括RocketMQ。分布式消息中间件建立消息队列来订阅消息。第一消息队列可以是包括一个Topic下的多个消息队列；第一消息队列也可以是包括至少两个Topic下的多个消息队列。

本申请实施例中，日志处理设备获取到各个目标设备发送的日志信息后，首先将获取的日志信息按照异步处理策略存储至分布式消息中间件的第一消息队列，即将大量的日志信息放在一个临时缓存区域，以便于后续从临时缓存区域异步拉取日志信息。也就是说，本申请采用异步处理的方式将应用运行时产生的数据存储到消息系统RocketMQ的第一消息队列中，该以便于后续基于第一消息队列，快速向联机分析处理平台写入数据，提高了数据的写入效率，并且，由于RocketMQ的高吞吐量和可扩展性，有效地避免了日志数据量大且并发性高导致业务运行受到影响的问题。

步骤S203，调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息，并将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理。

其中，插件的使用也非常便捷，具体的，先单独编译一个rocketmq插件服务，然后将单独编译好的rocketmq插件服务的jar包放到插件文件夹中，并在加载列表(loadList)中增加配置“druid-rocketmq-indexing-service”插件，使得Apache Druid的管理子进程在启动初始化的时候自动从文件路径加载该插件，以通过该插件实现数据的导入，从而执行后续的日志处理过程。

其中，联机分析处理平台包括OLAP平台，Apache Druid实现OLAP平台大数据量下的实时联机分析处理。

本申请实施例中，设计上述插件之后，为了实现日志处理的实时性，将上述插件与分布式消息中间件进行无缝连接。具体的，覆写了实时导入数据的底层接口代码，生成新的消息并调取对象即上述插件，从而实现插件与分布式消息中间件进行无缝连接，该插件即上述的druid-rocketmq-indexing-service，实现数据的实时导入。而且，本实施例中，不仅实现插件与分布式消息中间件的无缝连接，插件druid-rocketmq-indexing-service还采用多线程的方式从分布式消息中间件的topic上拉取消息，实现从临时缓存区域异步拉取日志信息，提高了拉取效率，同时实现了日志信息的实时导入。

可见，本申请提供的日志处理方法至少具有如下有益效果：设计和实现了与RocketMQ中间件平台无缝连接的rocketmq-indexing-service插件，将线上实时数据流导入OLAP平台的Apache Druid；结合Apache druid和RocketMQ做实时大数据分析和聚合查询；现有数据导入方式相比，支持更可靠，更高并发的互联网金融服务场景。

本申请提供的日志处理方法，通过获取各个目标设备发送的日志信息；将日志信息存储至分布式消息中间件的第一消息队列；调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息，并将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理；也就是说，获取到各个应用APP和小程序发送的日志信息后，将其存储在分布式消息中间件的第一消息队列中，即将大量的日志信息放在一个临时缓存区域，进而从临时缓存区域拉取日志信息，如此不仅避免在日志信息量较大的情况下，将日志信息从目标设备直接发至联机分析处理平台时，至少存在日志处理设备发生崩溃的现象，而且实现了高并发情况下数据的快速拉取，实现了数据可靠地导入联机分析处理平台，确保日志处理设备具有高吞吐量和高性能。

参见图3，图3是本申请实施例提供的日志处理方法的一个可选的流程示意图，将结合图3示出的步骤进行说明；

步骤S301，获取各个目标应用发送的日志信息。

步骤S302，将日志信息存储至分布式消息中间件的第一消息队列。

步骤S303，获取分布式消息中间件记录的第一消息队列中的最大偏移位置。

本申请实施例中，日志处理设备将基于异步处理策略将日志信息，存储至分布式消息中间件的第一消息队列之后，消费者consumer集群可以从第一消息队列中取出日志信息并进行处理，在对取出的日志信息进行处理的过程中，可以根据取出的日志信息的处理情况记录消息处理状态信息。该消息处理状态信息能够体现出消费者consumer对取出的日志信息的处理完成情况，即能够指示已经处理完成的日志消息。日志处理设备可以基于消息处理状态确定第一消息队列的最大偏移量。

日志处理设备获取分布式消息中间件记录的第一消息队列中的最大偏移位置，这里，最大偏移位置表示在第一消息队列中上述最大偏移量对应的位置之前的日志信息均已被处理完成。

步骤S304，调用插件基于多线程并行拉取策略，以最大偏移位置为起始位置，从第一消息队列中拉取第一目标日志信息。

这里，第一消息队列包括一个Topic或至少两个Topic下的多个消息队列，第一目标日志信息包括第一消息队列中的多个消息。这里，日志处理设备可以根据第一消息队列包含的消息队列的数量，确定当前拉取消息的多线程的线程数量。示例性的，日志处理设备确定第一消息队列包括N个消息队列，进而确定当前拉取消息的多线程的线程数量为M，其中，N≤M，且M-N的差值在差值范围内，如此，在日志处理设备获取到分布式消息中间件记录的第一消息队列中的最大偏移位置后，调用插件基于多线程并行拉取策略，以最大偏移位置为起始位置，从第一消息队列中采用多线程拉取第一目标日志信息即拉取多个消息，如此，实现有序、精确、并行快速地拉取待处理对象。

步骤S305，确定第一消息队列中的当前偏移位置。

步骤S306，将当前偏移位置落盘。

本申请实施例中，日志处理设备调用插件基于多线程并行拉取策略，以最大偏移位置为起始位置，从第一消息队列中拉取第一目标日志信息后，确定第一消息队列中的当前偏移位置即消息拉取到哪个位置了，并且将当前偏移位置异步定时落盘，将当前偏移位置写入磁盘，后续重新进行日志处理时，从该落盘的当前偏移位置开始，以防止异常重启导致的内存数据丢失。

需要说明的是，kafka插件采用单线程的方式拉取数据，并且未对数据进行限流和安全保护，在高并发压测场景下可能出现数据丢失或重复；而tranquility模式在数据并发量很大的场景下会出现进程崩溃和数据丢失。而本申请中采用RocketMQ保障了数据的可靠性，发往中间件的消息在没有被确认(ack)前都会保留在消息队列中，同时通过定时落盘当前偏移位置可以防止异常重启导致的内存数据丢失。

步骤S307，将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理。

本申请其他实施例中，在步骤S306将当前偏移位置落盘之后，还可以执行如图4所示的步骤：

步骤S3061，若日志处理设备发生异常重启事件，调用进程管理程序查询第一消息队列和当前偏移位置之间的第一映射表。

其中，进程管理程序包括supervisor。

本申请实施例中，日志处理设备确定发生异常重启事件，则调用进程管理程序查询第一消息队列和当前偏移位置之间的第一映射表,其中，第一映射表是预先生成的；日志处理设备引导索引任务supervisor在启动后记录并维护一个第一消息队列和当前偏移位置之间的第一映射表，在任务异常重启后如果打开了自动位移校正开关，则根据第一映射表对默认偏移位置进行校正。

步骤S3062，确定日志处理设备重启后的默认偏移位置。

步骤S3063，若默认偏移位置小于当前偏移位置，基于第一映射表确定第一消息队列中大于当前偏移位置的下一偏移位置。

本申请实施例中，日志处理设备确定发生异常重启事件，并且重启之后，确定默认偏移位置小于当前偏移位置，则基于第一映射表确定第一消息队列中大于当前偏移位置的下一偏移位置；也就是说，比较默认偏移位置是否小于第一映射表中记录的当前偏移位置，如果是，则需要跳过这部分已经消费的无效内容，从最新的位置开始消费，以确保消费的真确性，即在任务异常重启后支持消息偏移位的自动调整，防止了读取非法位置和大量重复读取，提升了系统性能。

步骤S3064，调用插件基于多线程并行拉取策略，以下一偏移位置为起始位置，从第一消息队列中拉取第二目标日志信息。

步骤S3065，将第二目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第二目标日志信息进行分析处理。

需要说明的是，本实施例中与其它实施例中相同步骤和相同内容的说明，可以参照其它实施例中的描述，此处不再赘述。

参见图5，图5是本申请实施例提供的日志处理方法的一个可选的流程示意图，将结合图5示出的步骤进行说明；

步骤S401，获取各个目标设备发送的日志信息。

步骤S402，将日志信息存储至分布式消息中间件的第一消息队列。

步骤S403，获取插件的配置文件中的第一消息队列的队列数量。

本申请实施例中，日志处理设备可以对插件进行预先配置或者实时配置，并将配置数据存储在该插件的配置文件中，配置数据用于控制同时访问资源的线程数量，元数据存储介质，文件存储介质，计算缓存大小和线程数量。

步骤S404，基于队列数量设置多线程的线程数量。

本申请实施例中，日志处理设备从配置文件中查找到队列数量后，基于队列数量设置多线程的线程数量。这里，日志处理设备可以设置多线程的线程数量等于消息队列数；或者，日志处理设备可以设置多线程的线程数量大于消息队列数，且多线程的线程数量与消息队列数的差值在差值范围内。日志处理设备后续在等待所有线程执行完成后返回批量消息，提供给异步持久化的任务。

步骤S405，接收消费者集群发送的拉取指令。

本申请实施例中，日志处理设备调用插件进行多线程拉取，是由消费者集群主动拉取的。这里，在RocketMQ插件的开发过程中本申请人测试对比了单线程模式和多线程模式的最大支撑TPS，可以相差十倍，并确定采用了多线程Pull模式可以实现较好的性能，因此，提出消费者集群主动拉取(pull consume r)，即消费者集群主动从指定topic上拉取消息，只要任务(task)在运行(RUNNING)的状态就会持续地获取消息。这里没有使用主动推给消费者(push consumer)，是因为当消费能力不够的时候如果push的速度过快时，消费端容易出现数据丢失；使用pull consumer，消费者主动去服务端拉取消息，主动权在消费端可控性好。此外，还使用了锁控制最大并发线程数，一般设置为等于消息队列数；为了防止进程异常，对拉取的消息进行流量控制，这样即使在压测和大促活动期间也保障了服务的安全。

步骤S406，响应拉取指令，调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息。

步骤S407，将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理。

需要说明的是，本实施例中与其它实施例中相同步骤和相同内容的说明，可以参照其它实施例中的描述，此处不再赘述。

参见图6，图6是本申请实施例提供的日志处理方法的一个可选的流程示意图，将结合图6示出的步骤进行说明；

步骤S501，获取各个目标设备发送的日志信息。

步骤S502，将日志信息存储至分布式消息中间件的第一消息队列。

步骤S503，通过运行实时计算任务消费第一消息队列中的日志信息，得到消费消息。

其中，实时计算包括spark-streaming或flink。示例性的，spark-streaming可以从RocketMQ的topic上消费消息，实现消息的初步聚合统计。

步骤S504，将消费消息存储至分布式消息中间件的第二消息队列。

第二消息队列可以是包括一个Topic下的多个消息队列；第二消息队列也可以是包括至少两个Topic下的多个消息队列。

这里本申请实施例中，在spark-streaming从RocketMQ的topic上消费消息后，可以将消费消息发往RocketMQ的另一指定topic即存储至第二消息队列，进而可以将第二消息队列提供给apache-druid导入和持久化，通过这种异步的方式耦合在一起，结合了各大开源产品的优势，在资源有限的场景下最大限度地提升计算性能。

步骤S505，调用插件基于多线程并行拉取策略，从第二消息队列中拉取消费消息，并将消费消息存储至联机分析处理平台，以使得联机分析处理平台对消费消息进行分析处理。

这里，插件druid-rocketmq-indexing-service同时支持将spark-streaming或flink的计算结果导入联机分析处理平台的apache-druid进行交互式实时查询。

步骤S506，调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息，并将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理。

本申请实施例中，联机分析处理平台的apache druid提供的实时摄取消息的抽象类，设计维护了一个自定义消息队列类型到它的整型哈希值的第二映射表，把复杂类型转化成了基本数据类型。如此，日志处理设备将第一目标日志信息存储至联机分析处理平台的过程中，可以基于第二映射表将消息队列中的数据的类型转换成联机分析处理平台的apache druid所能够处理的类型，避免了jackson对fastjson的自定义类数据类型无法解析的问题。

这里，日志处理设备从第一消息队列中拉取第一目标日志信息后，对于第一目标日志信息又称为消息进行解析时，支持定制或通用消息格式，实现了对消息字段的填充或切割的预处理，将消息预解析成apache-druid能够解析的不包含自定义类型嵌套的JSON格式，最终写入到时序数据库中，提高了写入效率。

本申请其他实施例中，结合图7对步骤S506中将第一目标日志信息存储至联机分析处理平台的过程中进行进一步地说明，这里，先对联机分析处理平台的架构进行简要说明，联机分析处理平台包括如下节点，

统治节点(Overload)管理数据写入任务的生成和分配。

管理节点(Middle Manager)负责接收Overload分配的索引任务，创建启动工人节点Peon实例来执行索引任务，一个Middle Manager可以运行多个Peon实例。

历史节点(Historical)的职责主要是对历史的数据进行存储和查询，历史节点从深存储区(Deep Storage)下载Segment文件，然后响应Broker对于Segment的查询将查询结果返回给Broker节点，它们通过zookeeper来声明自己存储的节点，同时也通过zookeeper来监听加载或删除Segment的信号。

协调节点(Coordinator)监测一组历史节点来保证数据的可用和冗余。协调节点读取元数据存储来确定哪些Segment需要load到集群中，通过zookeeper来感知Historical节点的存在，通过在Zookeeper上创建entry来和Historical节点通信来告诉他们加载或者删除Segment。

查询节点(Broker)接收外部客户端的查询，并且将查询路由到历史节点和实时节点。当Broker收到返回的结果的时候，它将结果merge起来然后返回给调用者。Broker通过Zookeeper来感知实时节点和历史节点的存在。

元数据存储节点(metadata storage)，元数据都存储在该节点的存储设备上。

步骤S506中将第一目标日志信息存储至联机分析处理平台时，第一目标日志信息作为待存储的数据，经由日志处理设备调用druid-rocketmq-indexing-service插件提交任务的方式，经过Overlord、zookeeper以及Middle Manager最终提交给工人节点Peon进程执行，Historical进程负责数据块的生成和持久化，可见，druid-rocketmq-indexing-service插件起到了关键的数据引导作用。

本申请其他实施例中，结合图8对步骤S506中将第一目标日志信息和消费消息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息和消费消息进行分析处理的结果进行进一步地说明，本申请利用apache druid具有的亚秒级聚合查询能力，调用http接口输出计算结果，并结合Netflix/vizceral做数据可视化，绘制整个应用服务的地图网格，如图8所示，通过该地图网格，可以观测出不同目标设备之间的联系，这种联系是联机分析处理平台对第一目标日志信息和消费消息进行分析处理的结果的直观表达，其中，不同的圆圈代表不同的目标设备，以目标设备包括设备1至设备11为例，各个圆圈之间的连线代表不同设备之间的联系，如此，实时观测调用关系、数据流量，并进行错误预警。

在查询的过程中，还可以使用tranquility基于HTTP协议将RocketMQ消息导入apache-druid进行实时聚合查询，能够降低吞吐量，提升整体性能。

需要说明的是，本实施例中与其它实施例中相同步骤和相同内容的说明，可以参照其它实施例中的描述，此处不再赘述。

下面继续说明本申请实施例提供的日志处理装置154实施为软件模块的示例性结构，在一些实施例中，如图1所示，存储在存储器150的日志处理装置154中的软件模块可以是服务器100中的日志处理装置，包括：

获取模块1541，用于获取各个目标设备发送的日志信息。

存储模块1542，用于将日志信息存储至分布式消息中间件的第一消息队列。

调用模块1543，用于调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息，并将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理。

本申请其他实施例中，获取模块1541，还用于获取分布式消息中间件记录的第一消息队列中的最大偏移位置；

调用模块1543，还用于调用插件基于多线程并行拉取策略，以最大偏移位置为起始位置，从第一消息队列中拉取第一目标日志信息。

本申请其他实施例中，日志处理装置154还包括：

处理模块1544，用于确定第一消息队列中的当前偏移位置；将当前偏移位置落盘。

本申请其他实施例中，调用模块1543，还用于若日志处理设备发生异常重启事件，调用进程管理程序查询第一消息队列和当前偏移位置之间的第一映射表；

处理模块1544，还用于确定日志处理设备重启后的默认偏移位置；

处理模块1544，还用于若默认偏移位置小于当前偏移位置，基于第一映射表确定第一消息队列中大于当前偏移位置的下一偏移位置；

调用模块1543，还用于调用插件基于多线程并行拉取策略，以下一偏移位置为起始位置，从第一消息队列中拉取第二目标日志信息。

存储模块1542，还用于将第二目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第二目标日志信息进行分析处理。

本申请其他实施例中，获取模块1541，还用于获取插件的配置文件中的第一消息队列的队列数量；

处理模块1544，还用于基于队列数量设置多线程的线程数量。

本申请其他实施例中，获取模块1541，还用于接收消费者集群发送的拉取指令；

调用模块1543，还用于响应拉取指令，调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息。

处理模块1544，还用于通过运行实时计算任务消费第一消息队列中的日志信息，得到消费消息；

存储模块1542，还用于将消费消息存储至分布式消息中间件的第二消息队列；

调用模块1543，还用于调用插件基于多线程并行拉取策略，从第二消息队列中拉取消费消息，并将消费消息存储至联机分析处理平台，以使得联机分析处理平台对消费消息进行分析处理。

本申请提供的日志处理装置，通过获取各个目标设备发送的日志信息；将日志信息存储至分布式消息中间件的第一消息队列；调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息，并将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理；也就是说，获取到各个终端发送的日志信息后，将其存储在分布式消息中间件的第一消息队列中，即将大量的日志信息放在一个临时缓存区域，进而从临时缓存区域异步拉取日志信息，如此不仅避免在日志信息量较大的情况下，将日志信息从目标设备直接发至联机分析处理平台时，至少存在日志处理设备发生崩溃的现象，而且实现了高并发情况下数据的快速拉取，实现了数据可靠地导入联机分析处理平台，确保日志处理设备具有高吞吐量和高性能。

需要说明的是，本申请实施例装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，因此不做赘述。对于本装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

本申请实施例提供一种存储有可执行指令的存储介质，其中存储有可执行指令，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，以实现以下步骤：

获取各个目标设备发送的日志信息；

将日志信息存储至分布式消息中间件的第一消息队列；

调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息，并将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理。

本申请其他实施例中，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，还可以实现以下步骤：

获取分布式消息中间件记录的第一消息队列中的最大偏移位置；

调用插件基于多线程并行拉取策略，以最大偏移位置为起始位置，从第一消息队列中拉取第一目标日志信息。

本申请其他实施例中，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，还可以实现以下步骤：

确定第一消息队列中的当前偏移位置；

将当前偏移位置落盘。

本申请其他实施例中，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，还可以实现以下步骤：

若日志处理设备发生异常重启事件，调用进程管理程序查询第一消息队列和当前偏移位置之间的第一映射表；

确定日志处理设备重启后的默认偏移位置；

若默认偏移位置小于当前偏移位置，基于第一映射表确定第一消息队列中大于当前偏移位置的下一偏移位置；

调用插件基于多线程并行拉取策略，以下一偏移位置为起始位置，从第一消息队列中拉取第二目标日志信息；

将第二目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第二目标日志信息进行分析处理。

本申请其他实施例中，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，还可以实现以下步骤：

获取插件的配置文件中的第一消息队列的队列数量；

基于队列数量设置多线程的线程数量。

本申请其他实施例中，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，还可以实现以下步骤：

接收消费者集群发送的拉取指令；

响应拉取指令，调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息。

本申请其他实施例中，当可执行指令被处理器执行时，将引起处理器执行本申请实施例提供的方法，还可以实现以下步骤：

通过运行实时计算任务消费第一消息队列中的日志信息，得到消费消息；

将消费消息存储至分布式消息中间件的第二消息队列；

调用插件基于多线程并行拉取策略，从第二消息队列中拉取消费消息，并将消费消息存储至联机分析处理平台，以使得联机分析处理平台对消费消息进行分析处理。

本申请提供的存储介质，通过获取各个目标设备发送的日志信息；将日志信息存储至分布式消息中间件的第一消息队列；调用插件基于多线程并行拉取策略，从第一消息队列中拉取第一目标日志信息，并将第一目标日志信息存储至联机分析处理平台，以使得联机分析处理平台对第一目标日志信息进行分析处理；也就是说，获取到各个终端发送的日志信息后，将其存储在分布式消息中间件的第一消息队列中，即将大量的日志信息放在一个临时缓存区域，进而从临时缓存区域异步拉取日志信息，如此不仅避免在日志信息量较大的情况下，将日志信息从目标设备直接发至联机分析处理平台时，至少存在日志处理设备发生崩溃的现象，而且实现了高并发情况下数据的快速拉取，实现了数据可靠地导入联机分析处理平台，确保日志处理设备具有高吞吐量和高性能。

在一些实施例中，存储介质可以是计算机可读存储介质，例如，铁电存储器(Ferromagnetic Random Access Memory，FRAM)、ROM、可编程只读存储器(ProgrammableRead Only Memory，PROM)、可擦除可编程只读存储器(Erasable Programmable Read OnlyMemory，EPROM)、带电可擦可编程只读存储器(Electrically Erasable ProgrammableRead Only Memory，EEPROM)、闪存、磁表面存储器、光盘、或光盘只读存储器(CompactDisk-Read Only Memory,CD-ROM)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(Hyper Text MarkupLanguage，HTML)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

以上，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (10)

1.一种日志处理方法，其特征在于，包括：

获取各个目标设备发送的日志信息；

将所述日志信息存储至分布式消息中间件的第一消息队列；

调用插件基于多线程并行拉取策略，从所述第一消息队列中拉取第一目标日志信息，并将所述第一目标日志信息存储至联机分析处理平台，以使得所述联机分析处理平台对所述第一目标日志信息进行分析处理。

2.根据权利要求1中所述的方法，其特征在于，所述调用插件基于多线程并行拉取策略，从所述第一消息队列中拉取第一目标日志信息，包括：

获取所述分布式消息中间件记录的所述第一消息队列中的最大偏移位置；

调用所述插件基于多线程并行拉取策略，以所述最大偏移位置为起始位置，从所述第一消息队列中拉取所述第一目标日志信息。

3.根据权利要求2中所述的方法，其特征在于，所述调用所述插件基于多线程并行拉取策略，以所述最大偏移位置为起始位置，从所述第一消息队列中拉取所述第一目标日志信息之后，包括：

确定所述第一消息队列中的当前偏移位置；

将所述当前偏移位置落盘。

4.根据权利要求3中所述的方法，其特征在于，所述将所述当前偏移位置落盘之后，包括：

若日志处理设备发生异常重启事件，调用进程管理程序查询所述第一消息队列和所述当前偏移位置之间的第一映射表；

确定所述日志处理设备重启后的默认偏移位置；

若所述默认偏移位置小于所述当前偏移位置，基于所述第一映射表确定所述第一消息队列中大于所述当前偏移位置的下一偏移位置；

调用所述插件基于多线程并行拉取策略，以所述下一偏移位置为起始位置，从所述第一消息队列中拉取第二目标日志信息；

将所述第二目标日志信息存储至所述联机分析处理平台，以使得所述联机分析处理平台对所述第二目标日志信息进行分析处理。

5.根据权利要求1中所述的方法，其特征在于，所述调用插件基于多线程并行拉取策略，从所述第一消息队列中拉取第一目标日志信息之前，包括：

获取所述插件的配置文件中的所述第一消息队列的队列数量；

基于所述队列数量设置所述多线程的线程数量。

6.根据权利要求1中所述的方法，其特征在于，所述调用插件基于多线程并行拉取策略，从所述第一消息队列中拉取第一目标日志信息，包括：

接收消费者集群发送的拉取指令；

响应所述拉取指令，调用插件基于多线程并行拉取策略，从所述第一消息队列中拉取第一目标日志信息。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述将所述日志信息存储至分布式消息中间件的第一消息队列之后，包括：

通过运行实时计算任务消费所述第一消息队列中的所述日志信息，得到消费消息；

将所述消费消息存储至所述分布式消息中间件的第二消息队列；

调用所述插件基于多线程并行拉取策略，从所述第二消息队列中拉取所述消费消息，并将所述消费消息存储至所述联机分析处理平台，以使得所述联机分析处理平台对所述消费消息进行分析处理。

8.一种日志处理装置，其特征在于，所述日志处理装置，包括：

获取模块，用于获取各个目标设备发送的日志信息；

存储模块，用于将所述日志信息存储至分布式消息中间件的第一消息队列；

调用模块，用于调用插件基于多线程并行拉取策略，从所述第一消息队列中拉取第一目标日志信息，并将所述第一目标日志信息存储至联机分析处理平台，以使得所述联机分析处理平台对所述第一目标日志信息进行分析处理。

9.一种日志处理设备，其特征在于，包括：

存储器，用于存储可执行指令；处理器，用于执行所述存储器中存储的可执行指令时，实现权利要求1至7任一项所述的方法。

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

Images