CN111371586B - 日志数据传输方法、装置和设备 - Google Patents

Abstract

本申请公开了日志数据处理方法、装置和设备。该方法包括：监听应用程序产生的日志数据；实时地将日志数据发送至Kafka消息队列的第一主题区域；在日志数据推送出现异常时，重试发送日志数据，如果重试成功，则停止发送日志数据至Kafka消息队列；如果重试未成功，则进一步确定日志数据被发送的次数是否达到阈值；如果达到所述阈值，则将日志数据发送到第二主题区域；如果未达到阈值，则重试将日志数据发送到第一主题区域，并进行计数统计，以统计日志数据被发送的次数。本申请实施例，在应用程序的日志数据发送出现异常时，通过确定日志数据的重新发送的结果来避免日志数据的发送错误，有效地提高日志数据传输的准确性。

Description

日志数据传输方法、装置和设备

技术领域

本申请一般涉及数据处理技术领域，尤其涉及日志数据处理方法、装置和设备。

背景技术

随着电子商务技术的发展，网络的后端服务器承载的压力也越来越大，同时需要处理的“数据”也呈几何级增长，实时准确的收集、传输、计算海量日志随之成为电子商务中的迫切要求。

现有技术中采集日志的工具，例如Flume、Scribe、Chukwa、ELK等，遵循传统的日志上报方式，即将日志数据先记录到文件系统，在通过采集Agent将日志的变化上报，可能是增量或全量地采集日志数据发送到消息队列。上述方式导致日志采集上报存在一定的延时，导致实时上报的效果不好。

同时，日志数据被采集上报给消息队列后，仅依靠消息队列自身的反馈机制，导致上报的日志数据存在错误性。

发明内容

鉴于现有技术中的上述缺陷或不足，期望提供一种日志数据传输方法、装置和设备来提高日志传输的准确性。

第一方面，本申请实施例提供了一种日志数据传输方法，该方法包括：

监听应用程序产生的日志数据；

实时地将日志数据发送至Kafka消息队列的第一主题区域；

在日志数据推送出现异常时，重试发送日志数据，

如果重试成功，则停止发送日志数据至Kafka消息队列；

如果重试未成功，则进一步确定日志数据被发送的次数是否达到阈值；

如果达到阈值，则将所述日志数据发送到第二主题区域；

如果未达到阈值，则重试将日志数据发送到第一主题区域，并进行计数统计，以统计日志数据被发送的次数。

第二方面，本申请实施例提供了一种日志数据传输装置，该装置包括：

监听单元，用于监听应用程序产生的日志数据；

消息发送单元，用于实时地将日志数据发送至Kafka消息队列的第一主题区域；

异常处理单元，用于在日志数据发送出现异常时，重试发送日志数据，

如果重试成功，则停止发送日志数据至Kafka消息队列；

如果重试未成功，则进一步确定日志数据被发送的次数是否达到阈值；

如果达到阈值，则将日志数据推送到第二主题区域；

如果未达到阈值，则重试将日志数据发送到第一主题区域，并触发计数单元执行加1；

计数单元，用于统计日志数据被发送的次数。

本申请实施例提供的日志数据传输方法和装置，其方法通过实时地监听应用程序产生的日志数据，并将日志数据发送至Kafka消息队列，当应用程序的日志数据的发送出现异常时，通过重试发送日志数据，然后确定重试结果是否成功，根据确定的结果对日志数据采取容错处理，有效地避免日志数据的发送错误，提高了日志数据传输的准确性。

进一步地，在日志数据发送正常时，可以通过配置Kafka的ACK响应消息，来确保日志数据被完整地传输。

进一步地，采用重发次数的检测来提高数据处理的效率。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1示出了本申请实施例提供的日志数据传输方法的流程示意图；

图2示出了本申请实施例提供的日志数据传输装置200的结构示意图；

图3示出了本申请实施例提供的异常处理单元203的示例性结构框图；

图4示出了适于用来实现本申请实施例的终端设备的计算机系统的结构示意图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

请参考图1，图1示出了本申请实施例提供的日志数据传输方法的流程示意图。该方法可以在终端设备执行。

如图1所示，该方法包括：

步骤110，监听应用程序产生的日志数据；

步骤120，实时地将日志数据推送至Kafka消息队列的第一主题区域。

在终端设备上安装有各种应用程序，应用程序在运行过程中产生应用日志数据。

终端设备例如可以是移动终端，优选的可以是具有操作系统的移动智能终端设备，也可以是电脑等终端设备。还可以是用作服务器的硬件终端设备。

移动终端是指可以在移动中使用的设备，广义的讲包括手机、笔记本、平板电脑，甚至包括车载电脑。但是，大部分情况下是指手机或者具有多种应用功能的智能手机以及平板电脑。随着网络和技术朝着越来越宽带化的方向的发展，移动通信产业将走向真正的移动信息时代。随着集成电路技术的飞速发展，移动终端的处理能力已经拥有了强大的处理能力，移动终端正在从简单的通话工具变为一个综合信息处理平台。移动智能终端可以简称为智能终端，移动智能终端拥有接入互联网能力，通常搭载各种操作系统，可根据用户需求定制化各种功能。生活中常见的智能终端包括移动智能终端、车载智能终端、智能电视、可穿戴设备等。

本申请实施例中，通过在应用程序中预先注册自定义的KafkaAppender类，并通过该KafkaAppender类来对日志数据进行监听、发送及其异常处理。KafkaAppender类可以不断地监听应用程序产生的日志数据。示例代码，例如：private static final Logger log＝LoggerFactory.getLogger(KafkaAppender.class)。

在监听到应用程序产生日志数据之后，KafkaAppender类通过Formatter接口对日志数据进行解析，并通过append()函数调用Kafka生产者接口(API，ApplicationProgramming Interface，应用程序编程接口)来实现日志数据的自动推送。

实时地将日志数据推送至Kafka消息队列的第一主题区域，包括：

解析日志数据，并确定日志数据的目的地地址为Kafka消息队列的第一主题区域；

调用Kafka生产者接口将日志数据发送至第一主题区域。

解析日志数据时，可以根据日志数据的标识确定日志数据的目的地址，该标识例如可以是应用程序的名称。主题区域可以是日志数据发送的目的地，是一个逻辑上的概念。如果在磁盘上可以是一个分区的目录。分区的目录，可以有多个段落组合。例如，一个主题区域Topic可以对应多个分区partition[0，1，2，3]，一个分区可以对应多个段落segment组合。一个段落有默认的大小可以是1G。

步骤130，在应用程序的日志数据发送出现异常时，重试发送日志数据。

步骤131，确定重试发送日志数据是否成功；

如果重试成功，则进入步骤131a。如果重试未成功，则进入步骤131b。

步骤131a，停止发送日志数据至Kafka消息队列。

步骤131b，确定日志数据被发送的次数是否达到阈值。如果到达阈值，则进入步骤132。如果未达到阈值，则进入步骤133。

步骤132，将日志数据发送到第二主题区域。

步骤133，重试将日志数据发送到第一主题区域，并进行计数统计，以统计日志数据被发送的次数。

本申请实施例中，通过重试发送日志数据来对异常情况进行初步排查，然后，根据重试发送的结果来对日志数据进行容错处理，以提高日志数据的发送的准确率。

异常情况例如可以是网络中断、消息发送失败、网络超时、消息大小溢出等情况。在重试发送的过程中，上述异常情况可以通过有效时间段内进行重新发送，来确保日志数据的发送成功。为了进一步提高数据处理的效率，可以通过累计日志数据的发送次数来确保日志数据的完整性。还可以通过设置日志数据的重试标识，来确保日志数据的完整性。

本申请实施例中，通过在KafkaAppender类中增加了日志数据的容错处理机制，来确保日志数据传输的完整性。

本申请实施例中，通过在KafkaAppender中增加异常处理机制，来保证携带日志数据的Kafka消息的成功发送。

本申请实施例中，在Kafka消息队列中，通过调用Kafka生产者接口(Kafkaproducer)将Kafka消息根据指定的分区方法(默认round-robin、hash等)，将Kafka消息发布到指定的主题区域的指定分区，并将其持久化到硬盘，保留日志数据。例如可以指定存储时间长度等。生产者接口并不关注消息是否被消费。消费者接口可以根据需求从Kafka消息队列拉取数据。其中，Kafkaproducer是用于将消息数据发送到Kafka消息队列的接口。

应用程序的日志数据推送出现异常，可能是由于网络超时、消息大小溢出等原因导致的异常。

当出现异常时，异常处理程序重试发送日志数据的Kafka消息，如果重试发送成功，则停止发送携带日志数据的Kafka消息，如果重试未成功，则进一步确定日志数据被发送的次数是否达到阈值。该阈值可以根据经验设置，例如5-10次。该阈值的设置用于限制允许日志数据重发的次数，从而提升日志数据传输的效率。

判断日志数据被发送的次数是否达到阈值，可以通过获取计数器的读取来判断。计数器，或称为计数单元，其用于对日志数据的发送次数进行统计。

进一步地，当应用程序正常运行时，其产生的日志数据被发送给Kafka消息队列，本申请实施例中可以通过Kafka消息队列的发送模式配置ACK响应消息，来确保日志数据被完整地传输。

其中，发送模式例如可以是同步模式，或者异步模式，通过ACK机制可以保证数据的不丢失。

进一步地，在判断日志数据的发送次数达到阈值时，还可以将日志数据记录到本地日志存储位置，以提高日志数据的准确性。

本申请实施例，通过在应用程序上预先注册KafkaAppender类，能够实时地监听应用程序产生的日志数据，将日志数据实时地推送到Kafka消息队列中，并通过在KafkaAppender中增加容错机制，有效地提升了日志数据传输的准确性。

应当注意，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

进一步参考图2，图2示出了根据本申请一个实施例的日志数据传输装置200的示例性结构框图。

如图2所示，该装置200包括：

监听单元201，用于监听应用程序产生的日志数据；

消息发送单元202，用于实时地将日志数据推送至Kafka消息队列的第一主题区域；

在终端设备上安装有各种应用程序，应用程序在运行过程中产生应用日志数据。

终端设备例如可以是移动终端，优选的可以是具有操作系统的移动智能终端设备，也可以是电脑等终端设备。还可以是用作服务器的硬件终端设备。

移动终端是指可以在移动中使用的设备，广义的讲包括手机、笔记本、平板电脑，甚至包括车载电脑。但是，大部分情况下是指手机或者具有多种应用功能的智能手机以及平板电脑。随着网络和技术朝着越来越宽带化的方向的发展，移动通信产业将走向真正的移动信息时代。随着集成电路技术的飞速发展，移动终端的处理能力已经拥有了强大的处理能力，移动终端正在从简单的通话工具变为一个综合信息处理平台。移动智能终端可以简称为智能终端，移动智能终端拥有接入互联网能力，通常搭载各种操作系统，可根据用户需求定制化各种功能。生活中常见的智能终端包括移动智能终端、车载智能终端、智能电视、可穿戴设备等。

本申请实施例中，通过在应用程序中预先注册自定义的KafkaAppender类，并通过该KafkaAppender类来对日志数据进行监听、发送及其异常处理。KafkaAppender类可以不断地监听应用程序产生的日志数据。示例代码，例如：private static final Logger log＝LoggerFactory.getLogger(KafkaAppender.class)。

在监听到应用程序产生日志数据之后，KafkaAppender类通过Formatter接口对日志数据进行解析，并通过append()函数调用Kafka生产者接口(API，ApplicationProgramming Interface，应用程序编程接口)来实现日志数据的自动推送。

其中，消息发送单元202，还可以包括：

解析子单元，用于解析日志数据，确定日志数据的目的地地址为Kafka消息队列的第一主题区域；

调用子单元，用于调用Kafka生产者接口将日志数据发送至第一主题区域。

解析日志数据时，可以根据日志数据的标识确定日志数据的目的地址，该标识例如可以是应用程序的名称。主题区域可以是日志数据发送的目的地，是一个逻辑上的概念。如果在磁盘上可以是一个分区的目录。分区的目录，可以有多个段落组合。例如，一个主题区域Topic可以对应多个分区partition[0，1，2，3]，一个分区可以对应多个段落segment组合。一个段落有默认的大小可以是1G。

异常处理单元203，用于在应用程序的日志数据发送出现异常时，重试发送日志数据，

如果重试成功，则停止发送日志数据至Kafka消息队列；

如果重试未成功，则进一步确定日志数据被发送的次数是否达到阈值；

如果达到阈值，则将日志数据发送到第二主题区域；

如果未达到阈值，则重试将日志数据发送到第一主题区域，并触发计数单元执行加1。

本申请实施例中，通过重试发送日志数据来对异常情况进行初步排查，然后根据重试发送的结果来对日志数据进行容错处理，以提高日志数据的发送的准确率。

异常情况例如可以是网络中断、消息发送失败、网络超时、消息大小溢出等情况。在重试发送的过程中，上述异常情况可以通过有效时间段内进行重新发送，来确保日志数据的发送成功。为了进一步提高数据处理的效率，可以通过累计日志数据的发送次数来确保日志数据的完整性。还可以通过设置日志数据的重试标识，来确保日志数据的完整性。本申请实施例中，通过在KafkaAppender类中增加了日志数据的容错处理机制，来确保日志数据传输的完整性。

本申请实施例中，通过在KafkaAppender中增加异常处理机制，来保证携带日志数据的Kafka消息的成功发送。其异常处理机制可以描述为图3。图3示出了本申请实施例提供的异常处理单元203的示例性结构框图。

如图3所示，该异常处理单元203包括：

重试确定子单元3031，用于确定重试发送日志数据是否成功。

如果成功发送，则进入停止单元3031a。如果未成功发送，则进入阈值确定单元3031b。

停止单元3031a，用于停止发送日志数据至Kafka消息队列。

阈值确定单元3031b，用于确定日志数据被发送的次数是否达到阈值。如果到达阈值，则进入发送变更单元3032。如果未达到阈值，则进入消息重试单元3033。

发送变更单元3032，用于将日志数据发送到第二主题区域。

消息重试单元3033，用于将日志数据重新发送到第一主题区域，并触发计数单元执行加1。

该装置还可以包括：

计数单元，用于统计日志数据被发送的次数。

本申请实施例中，在Kafka消息队列中，通过调用Kafka生产者接口(Kafkaproducer)将Kafka消息根据指定的分区方法(默认round-robin、hash等)，将Kafka消息发布到指定的主题区域的指定分区，并将其持久化到硬盘，保留日志数据。例如可以指定存储时间长度等。生产者接口并不关注消息是否被消费。消费者接口可以根据需求从Kafka消息队列拉取数据。其中，Kafkaproducer是用于将消息数据发送到Kafka消息队列的接口。

应用程序的日志数据推送出现异常，可能是由于网络超时、消息大小溢出等原因导致的异常。

当出现异常时，异常处理程序重试发送日志数据的Kafka消息，如果重试发送成功，则停止发送携带日志数据的Kafka消息，如果重试未成功，则进一步确定日志数据被发送的次数是否达到阈值。该阈值可以根据经验设置，例如5-10次。该阈值的设置用于限制允许日志数据重发的次数，从而提升日志数据传输的效率。

判断日志数据被发送的次数是否达到阈值，可以通过获取计数器的读取来判断。计数器用于对日志数据的发送次数进行统计。进一步地，该装置还可以包括：

配置单元，用于在应用程序的日志数据推送正常时，按照kafka消息队列的发送模式配置响应确认消息。

当应用程序正常运行时，其产生的日志数据被发送给Kafka消息队列，本申请实施例中可以通过Kafka消息队列的发送模式配置ACK响应消息，来确保日志数据被完整地传输。

其中，发送模式例如可以是同步模式，或者异步模式，通过ACK机制可以保证数据的不丢失。

进一步地，该装置还可以包括：

记录单元，用于如果达到阈值，将日志数据记录到本地日志存储位置。

在判断日志数据的发送次数达到阈值时，可以将日志数据记录到本地日志存储位置，以提高日志数据的准确性。

本申请实施例，通过在应用程序上预先注册KafkaAppender类，能够实时地监听应用程序产生的日志数据，将日志数据实时地推送到Kafka消息队列中，并通过在KafkaAppender中增加容错机制，有效地提升了日志数据传输的准确性。

应当理解，装置200中记载的诸单元或模块与参考图1描述的方法中的各个步骤相对应。由此，上文针对方法描述的操作和特征同样适用于装置200及其中包含的单元，在此不再赘述。

装置200可以预先实现在电子设备的浏览器或其他安全应用中，也可以通过下载等方式而加载到电子设备的浏览器或其安全应用中。装置200中的相应单元可以与电子设备中的单元相互配合以实现本申请实施例的方案。

下面参考图4，其示出了适于用来实现本申请实施例的终端设备计算机系统400的结构示意图。

如图4所示，计算机系统400包括中央处理单元(CPU)401，其可以根据存储在只读存储器(ROM)402中的程序或者从存储部分408加载到随机访问存储器(RAM)403中的程序而执行各种适当的动作和处理。在RAM 403中，还存储有系统500操作所需的各种程序和数据。CPU 401、ROM 402以及RAM 403通过总线404彼此相连。输入/输出(I/O)接口405也连接至总线404。

以下部件连接至I/O接口405：包括键盘、鼠标等的输入部分406；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分407；包括硬盘等的存储部分408；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分409。通信部分409经由诸如因特网的网络执行通信处理。驱动器410也根据需要连接至I/O接口405。可拆卸介质411，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器410上，以便于从其上读出的计算机程序根据需要被安装入存储部分408。

特别地，根据本公开的实施例，上文参考流程图图1描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在机器可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分409从网络上被下载和安装，和/或从可拆卸介质411被安装。在该计算机程序被中央处理单元(CPU)401执行时，执行本申请的系统中限定的上述功能。

需要说明的是，本发明所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本发明中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本发明中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本发明各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，前述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现，也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中，例如，可以描述为：一种处理器包括监听单元、第一推送单元、第一判断单元、停止单元、第二判断单元、第二推送单元以及重新发送单元。其中，这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定，例如，监听单元还可以被描述为“用于监听到应用程序产生的日志数据的单元”。

例如，上述电子设备可以实施如图1所示的：

步骤110，监听应用程序产生的日志数据；

步骤120，实时地将日志数据推送至Kafka消息队列的第一主题区域。

步骤131，确定重试发送日志数据是否成功；

如果重试成功，则进入步骤131a。如果重试未成功，则进入步骤131b。

步骤131a，停止发送日志数据至Kafka消息队列。

步骤131b，确定日志数据被发送的次数是否达到阈值。如果到达阈值，则进入步骤140。如果未达到阈值，则进入步骤150。

步骤132，将日志数据发送到第二主题区域。

步骤133，重试将日志数据发送到第一主题区域，并进行计数统计，以统计日志数据被发送的次数。作为另一方面，本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中的。上述计算机可读存储介质存储有一个或者多个程序，当上述前述程序被一个或者一个以上的处理器用来执行描述于本申请的日志数据传输方法。

以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本申请中所涉及的发明范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离前述发明构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (8)

1.一种日志数据传输方法，其特征在于，该方法包括：

监听应用程序产生的日志数据；

实时地将所述日志数据发送至Kafka消息队列的第一主题区域；

在所述日志数据推送出现异常时，重试发送所述日志数据，

如果重试成功，则停止发送所述日志数据至所述Kafka消息队列；

如果重试未成功，则进一步确定所述日志数据被发送的次数是否达到阈值；

如果达到所述阈值，则将所述日志数据发送到第二主题区域；

如果未达到所述阈值，则重试将所述日志数据发送到所述第一主题区域，并进行计数统计，以统计所述日志数据被发送的次数；

其中，所述实时地将所述日志数据推送至Kafka消息队列的第一主题区域，包括：

通过Formatter接口解析所述日志数据，并确定所述日志数据的目的地地址为所述Kafka消息队列的第一主题区域；

调用Kafka生产者接口将所述日志数据发送至所述第一主题区域。

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

如果达到阈值，将所述日志数据记录到本地日志存储位置。

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

在所述日志数据发送正常时，按照所述Kafka消息队列的发送模式配置ACK响应消息。

4.根据权利要求1所述的方法，其特征在于，在监听到应用程序产生的日志数据之前，该方法还包括：

在所述应用程序中预先注册自定义的KafkaAppender类，通过所述KafkaAppender类来对所述日志数据进行监听、发送及异常处理。

5.一种日志数据传输装置，其特征在于，该装置包括：

监听单元，用于监听应用程序产生的日志数据；

消息发送单元，用于实时地将所述日志数据发送至Kafka消息队列的第一主题区域；

异常处理单元，用于在所述日志数据发送出现异常时，重试发送所述日志数据，

如果重试成功，则停止发送所述日志数据至Kafka消息队列；

如果重试未成功，则进一步确定所述日志数据被发送的次数是否达到阈值；

如果达到所述阈值，则将所述日志数据推送到第二主题区域；

如果未达到所述阈值，则重试将所述日志数据发送到第一主题区域，并触发计数单元执行加1；

所述计数单元，用于统计所述日志数据被发送的次数；

其中，所述消息发送单元包括：

解析子单元，用于通过Formatter接口解析所述日志数据，并确定所述日志数据的目的地地址为所述Kafka消息队列的第一主题区域；

调用子单元，用于调用Kafka生产者接口将所述日志数据发送至所述第一主题区域。

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

记录单元，用于如果达到阈值，将所述日志数据记录到本地日志存储位置。

7.根据权利要求5-6任一项所述的装置，其特征在于，该装置还包括：

配置单元，用于在所述日志数据发送正常时，按照所述Kafka消息队列的发送模式配置ACK响应消息。

8.一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1-4中任一项所述的方法。

Images