CN111611138B - 日志数据抓取方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及一种日志数据抓取方法、装置、计算机设备和存储介质。所述方法包括：当客户端处于离线状态时，通过串行总线与所述客户端建立连接；扫描所述客户端端口配置参数，利用所述端口配置参数识别目标端口；通过所述目标端口连接所述客户端进行通信，发送配置文件到所述客户端；当向所述客户端发送日志数据抓取指令，将与所述配置文件对应的日志数据进行抓取时，断开串行总线与所述客户端的连接，并将所述日志数据存储到指定路径下。采用本方法能够在离线状态下，对日志数据进行实时准确的抓取，从而有效的提高了日志数据抓取的准确性，同时也提高了对客户端系统测试结果的准确性。

Description

日志数据抓取方法、装置、计算机设备和存储介质

技术领域

本申请涉及计算机技术领域，特别是涉及一种日志数据抓取方法、装置、计算机设备和存储介质。

背景技术

随着计算机技术的发展，个人计算机、智能手机等各种类型的电子设备越来越多，为人们的日常工作和生活带来了诸多便捷。在各种电子设备的日常运行过程中，通常需要将对应的日志信息记录下来并进行传输。特别是在对5G软件客户端进行系统测试时，通常会采用在线平台工具的方式对日志信息进行抓取。

然而，在目前常用的在线平台工具抓取日志信息的方式中，由于需要一直保持客户端和平台工具在线连接的状态，才能对客户端系统的日志数据进行有效抓取，因而会造成大量频繁的输入数据与输出数据的交互，对客户端系统测试的结果也会产生一定影响，由此使得无法得到准确的日志数据。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提高日志数据抓取准确性的日志数据抓取方法、装置、计算机设备和存储介质。

一种日志数据抓取方法，所述方法包括：

当客户端处于离线状态时，通过串行总线与所述客户端建立连接；

扫描所述客户端端口配置参数，利用所述端口配置参数识别目标端口；

通过所述目标端口连接所述客户端进行通信，发送配置文件到所述客户端；

当向所述客户端发送日志数据抓取指令，将与所述配置文件对应的日志数据进行抓取时，断开串行总线与所述客户端的连接，并将所述日志数据存储到指定路径下。

在其中一个实施例中，所述扫描所述客户端端口配置参数，利用所述端口配置参数识别目标端口之后，所述方法还包括：

当所述客户端中不存在与所述目标端口对应的配置参数时，将所述目标端口对应的配置参数加载至客户端本地；

利用客户端本地已加载的目标端口对应的配置参数，连接所述客户端进行通信。

在其中一个实施例中，所述将与所述配置文件对应的日志数据进行抓取时包括：

当对所述日志数据进行抓取时，对每个日志文件容量进行实时监测；

当监测到的日志文件容量大于预设阈值时，则自动将所述日志文件进行分割，得到对应的日志文件。

在其中一个实施例中，所述方法还包括：

当监测到所述日志文件的总容量达到预设阈值时，则自动停止日志数据的抓取或自动对已生成的日志文件进行覆盖。

在其中一个实施例中，所述方法还包括：

当需要读取日志数据时，通过串行总线与所述客户端建立通信连接；

向所述客户端发送停止日志数据抓取指令，获取客户端中已生成的日志数据；

通过触发操作将所述已生成的日志数据进行读取并储存。

在其中一个实施例中，所述当需要读取日志数据时，通过串行总线与所述客户端建立通信连接之后，所述方法还包括：

向所述客户端发送清除日志数据指令，将客户端中已生成的日志数据进行清除。

在其中一个实施例中，所述方法还包括：

当需要抓取日志数据或停止抓取日志数据时，通过串行总线与所述客户端建立通信连接，向所述客户端发送抓取日志数据或停止抓取日志数据指令；

否则，将串行总线与所述客户端的连接断开。

一种日志数据抓取装置，所述装置包括：

连接模块，用于当客户端处于离线状态时，通过串行总线与所述客户端建立连接；

识别模块，用于扫描所述客户端端口配置参数，利用所述端口配置参数识别目标端口；

发送模块，用于通过所述目标端口连接所述客户端进行通信，发送配置文件到所述客户端；

抓取模块，用于当向所述客户端发送日志数据抓取指令，将与所述配置文件对应的日志数据进行抓取时，断开串行总线与所述客户端的连接，并将所述日志数据存储到指定路径下。

一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现以下步骤：

当客户端处于离线状态时，通过串行总线与所述客户端建立连接；

扫描所述客户端端口配置参数，利用所述端口配置参数识别目标端口；

通过所述目标端口连接所述客户端进行通信，发送配置文件到所述客户端；

当向所述客户端发送日志数据抓取指令，将与所述配置文件对应的日志数据进行抓取时，断开串行总线与所述客户端的连接，并将所述日志数据存储到指定路径下。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现以下步骤：

当客户端处于离线状态时，通过串行总线与所述客户端建立连接；

扫描所述客户端端口配置参数，利用所述端口配置参数识别目标端口；

通过所述目标端口连接所述客户端进行通信，发送配置文件到所述客户端；

当向所述客户端发送日志数据抓取指令，将与所述配置文件对应的日志数据进行抓取时，断开串行总线与所述客户端的连接，并将所述日志数据存储到指定路径下。

上述日志数据抓取方法、装置、计算机设备和存储介质，当客户端处于离线状态时，通过串行总线与客户端建立连接，同时扫描客户端端口配置参数，利用端口配置参数识别目标端口。相对于传统的日志数据抓取方式，通过目标端口连接客户端进行通信，发送配置文件到客户端。向客户端发送日志数据抓取指令，将与配置文件对应的日志数据进行抓取时，断开串行总线与客户端的连接，并将日志数据存储到指定路径下，由此使得即使是断开连接时，即在离线的状态下，也能够将客户端与配置文件对应的日志数据进行抓取并储存到客户端指定路径下，有效的减少了大量频繁的输入数据与输出数据的交互，能够对日志数据进行实时准确的抓取，从而提高了日志数据抓取的准确性，同时也提高了对客户端系统测试结果的准确性。

附图说明

图1为一个实施例中日志数据抓取方法的应用环境图；

图2为一个实施例中日志数据抓取方法的流程示意图；

图3为一个实施例中读取日志数据步骤的流程示意图；

图4为另一个实施例中抓取日志数据或停止抓取日志数据步骤的流程示意图；

图5为一个实施例中日志数据抓取装置的结构框图；

图6为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的日志数据抓取方法，可以应用于如图1所示的应用环境中。其中，客户端102可以通过网络与服务器104通过网络进行通信。当客户端102处于离线状态时，服务器104通过串行总线与客户端102建立连接。服务器104扫描客户端102端口配置参数，利用客户端102端口配置参数识别目标端口。服务器104通过目标端口连接客户端102进行通信，并发送配置文件到客户端102。当服务器104向客户端102发送日志数据抓取指令，将与配置文件对应的日志数据进行抓取时，服务器断开串行总线与客户端102的连接，并将日志数据存储到指定路径下。其中，客户端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务器104可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种日志数据抓取方法，以该方法应用于图1中的服务器为例进行说明，包括以下步骤：

步骤202，当客户端处于离线状态时，通过串行总线与客户端建立连接。

客户端可以通过网络与服务器通过网络进行通信，通过网络通信连接保持在线状态。当客户端处于离线状态时，即客户端与服务器之间的网络通信连接断开时，服务器可以通过串行总线与客户端建立连接。其中，通用串行总线(Universal Serial Bus，USB)是连接外部设备的一个串口总线标准，在计算机上使用广泛，补充标准使其能够用于在便携设备之间直接交换数据。

步骤204，扫描客户端端口配置参数，利用端口配置参数识别目标端口。

当服务器通过串行总线与客户端建立连接时，服务器可以通过扫描客户端端口配置参数，利用端口配置参数识别目标端口。其中，客户端对应的端口配置参数可以包括端口的链路类型、发送信息的配置、接收信息的配置以及硬件识别号等。目标端口的配置参数可以包括端口配置的型号、波特率、停止位、校验位等。具体的，服务器获取通过串行总线连接到的客户端对应的设备参数，通过配置工具触发自动进行扫描，可以同时扫描多个已接入的客户端设备，通过扫描客户端端口配置参数，识别与目标端口对应的客户端端口配置参数，扫描识别到其中一个客户端设备后，将对应的客户端端口配置参数记录下来，然后进行下一个客户端设备参数的扫描识别，遍历完所有的客户端端口配置参数后，即扫描完成。服务器利用已扫描到的客户端端口参数识别目标端口，建立通信连接。例如，服务器可以通过串行总线连接到客户端设备，通过配置工具触发自动进行扫描，通过扫描客户端端口配置参数，识别与目标端口对应的客户端端口配置参数。其中，目标端口可以为ADB端口，ADB端口是安卓android系统里的一个工具，用这个工具可以直接操作管理android模拟器或者真实的andriod设备。

步骤206，通过目标端口连接客户端进行通信，发送配置文件到客户端。

当服务器通过配置工具扫描到对应的目标端口时，服务器通过目标端口连接客户端进行通信，发送配置文件到客户端。其中，配置文件可以是根据不同日志类型预先设置好的配置文件。日志类型很丰富有几千种具体的日志类型，日志数据可以包含客户端系统或设备的所有活动和行为的有序记录，一般为半结构化的数据，例如，单行日志信息、复杂的多行日志信息等。日志信息由低到高的等级类型可以包括：debug<info<warn<Error<Fatal，其中Fatal类型的日志，表示该日志错误问题相当严重，可以肯定这种错误已经无法修复，并且如果系统继续运行下去的话后果严重。在开发或生产环境中常见的日志类型可以包括：应用日志、Web和应用程序服务器日志、垃圾收集器日志以及系统日志。其中，应用日志包含应用程序编写的各种错误消息，警告或其他事件。该类型的日志消息可以提供与特定用例相关的逻辑高级信息，以便调试人员可以根据此类日志数据快速查找相关应用程序的故障问题所在。因而可以预先根据不同类型日志在服务器中设置日志数据的大小阈值、日志分类储存的类型以及自动获取客户端剩余日志数据储存空间等配置信息。

步骤208，当向客户端发送日志数据抓取指令，将与配置文件对应的日志数据进行抓取时，断开串行总线与客户端的连接，并将日志数据存储到指定路径下。

当客户端接收到服务器发送的配置文件之后，服务器可以向客户端发送日志数据抓取指令，将与配置文件对应的日志数据进行抓取时，断开串行总线与客户端的连接，并将日志数据存储到指定路径下。具体的，当服务器将预先配置好的配置文件发送到客户端后，服务器可以通过在界面程序中的触发操作，例如点击启动按钮，服务端向客户端发送日志数据抓取指令，启动客户端对应的应用程序将与配置文件对应的日志数据进行抓取时，可以断开串行总线与客户端的连接，应用程序将抓取到的日志数据存储到客户端的指定路径下。例如，可以按照日志文件生成的时间顺序进行分时间段的储存到指定路径下，便于后续查找日志数据使用。也可以按照日志文件对应的序列信息，例如IMEI序列号，对生成的日志文件进行分类储存，或者根据日志数据的等级类型进行分类储存，日志信息由低到高的等级类型可以包括：debug<info<warn<Error<Fatal，其中Fatal类型的日志，表示该日志错误问题相当严重，可以肯定这种错误已经无法修复，并且如果系统继续运行下去的话后果严重。服务器还可以按照不同日志的功能类型对日志文件进行分类储存，例如，根据在开发或生产环境中常见的日志类型，可以将日志数据按照应用日志、Web和应用程序服务器日志、垃圾收集器日志以及系统日志进行分类储存。

本实施例中，通过串行总线与客户端建立连接，同时扫描客户端端口配置参数，利用端口配置参数识别目标端口。相对于传统的日志数据抓取方式，通过目标端口连接客户端进行通信，发送配置文件到客户端。向客户端发送日志数据抓取指令，将与配置文件对应的日志数据进行抓取时，断开串行总线与客户端的连接，并将日志数据存储到指定路径下，由此使得即使是断开连接时，即在离线的状态下，也能够将客户端与配置文件对应的日志数据进行抓取并储存到客户端指定路径下，有效的减少了大量频繁的输入数据与输出数据的交互，能够对日志数据进行实时准确的抓取，从而提高了日志数据抓取的准确性，同时也提高了对客户端系统测试结果的准确性。

在一个实施例中，扫描客户端端口配置参数，利用端口配置参数识别目标端口之后，方法还包括：

当客户端中不存在与目标端口对应的配置参数时，将目标端口对应的配置参数加载至客户端本地。

利用客户端本地已加载的目标端口对应的配置参数，连接客户端进行通信。

当服务器通过串行总线与客户端建立连接时，服务器可以通过扫描客户端端口配置参数，利用端口配置参数识别目标端口。具体的，当服务器通过配置工具扫描客户端端口配置参数时，服务器在客户端本地中没有查找到对应的目标端口配置参数时，即当客户端中不存在与目标端口对应的配置参数时，服务器可以利用配置工具，将目标端口对应的配置参数加载至客户端本地。进一步的，服务器可以利用客户端本地已加载的目标端口对应的配置参数，连接客户端进行通信。以目标端口为ADB端口举例说明。ADB端口的主要功能可以包括：运行设备的shell(命令行)；管理模拟器或设备的端口映射；可以实现计算机和设备之间上传或下载文件；将本地软件安装至模拟器或android设备。ADB是一个客户端-服务器端程序。当服务器通过配置工具扫描客户端端口的配置参数时，服务器在客户端本地中没有查找到ADB端口对应的配置参数时，即当客户端中不存在与ADB端口对应的配置参数时，服务器可以利用配置工具，将服务器中ADB端口对应的配置参数加载至客户端本地。进一步的，服务器可以利用客户端本地已加载的ADB端口对应的配置参数，连接客户端进行通信。例如，服务器可以通过触发操作启动或者停止应用程序，应运程序通过ADB端口发送启动或者停止抓取日志指令到客户端，由此使得能够实现服务器与客户端的快速通讯，操作便捷，也能够快速获取到准确的日志数据。

本实施例中，当客户端中不存在与目标端口对应的配置参数时，无需人工手动进行参数的配置，服务器通过自动扫描目标端口配置参数，利用配置工具将目标端口对应的配置参数加载至客户端本地，与客户端通过目标端口连接进行通信，简化了操作流程，实现了自动化识别客户端设备，从而能够快速准确的获取对应的日志数据。

在一个实施例中，将与配置文件对应的日志数据进行抓取时的步骤包括：

当对日志数据进行抓取时，对每个日志文件容量进行实时监测。

当监测到的日志文件容量大于预设阈值时，则自动将日志文件进行分割，得到对应的日志文件。

当服务器通过目标端口连接客户端进行通信之后，服务器可以通过目标端向客户端发送日志数据抓取指令，将与配置文件对应的日志数据进行抓取。当对日志数据进行抓取时，对每个日志文件容量进行实时监测。当监测到的日志文件容量大于预设阈值时，则自动将日志文件进行分割，得到对应的日志文件。具体的，当对客户端的日志数据进行抓取时，服务器根据预先配置好的配置文件，可以通过应用程序对每个日志文件容量进行实时监测，即实时监测生成日志文件的大小。当应用程序监测到日志文件容量大于预设阈值时，则自动将该日志文件进行分割，得到对应的新的日志文件。例如，可以预先在配置文件中设置日志数据的对应参数，可以将每个日志文件的容量阈值设为10MB，即当应用程序监测到日志文件容量大于10MB时，则自动将该日志文件进行分割，得到对应的多个新的日志文件，新的日志文件的容量均不大于10MB。进一步的，应用程序可以将实时生成的日志数据按照日志文件生成的时间间隔进行分类储存，也可以按照日志文件的等级类型分类储存到客户端本地的指定路径下。由此使得当服务器需要对客户端的日志数据进行抓取时，可以按照生成日志数据的时间或者不同类型的日志数据进行准确的分类储存，避免了由于日志文件容量过大而产生错误的数据，即使在离线状态下，也能够实现对日志数据进行快速准确的抓取并储存，从而有效的提高了日志数据抓取的准确性。

在其中一个实施例中，该方法还包括监测日志文件总容量的步骤，具体包括：

当监测到日志文件的总容量达到预设阈值时，则自动停止日志数据的抓取或自动对已生成的日志文件进行覆盖。

当应用程序监测到日志文件的总容量达到预设阈值时，则自动停止日志数据的抓取或自动对已生成的日志文件进行覆盖。具体的，可以预先在配置文件中设置日志数据对应的参数，除了可以对每个日志文件的容量设置对应的阈值之外，还可以对日志文件的总容量设置对应的阈值。例如，针对5G客户端软件的内存较大时，可以将日志文件的总容量的阈值设为50MB，即当应用程序监测到日志文件的总容量达到50MB时，则弹出对应的选择框界面，可以根据调试人员的需求选择停止日志数据的抓取或对已生成的不必要的日志文件进行覆盖。也可以预先在配置文件中设置好对应的参数，当监测到日志文件的总容量达到50MB时，则自动停止日志数据的抓取，或者自动对已生成的日志文件进行覆盖。针对客户端软件的内存较小时，可以将日志文件的总容量的阈值设为30MB，即当应用程序监测到日志文件的总容量达到30MB时，则弹出对应的选择框界面，可以根据调试人员的需求选择停止日志数据的抓取或对已生成的不必要的日志文件进行覆盖。由此使得即使在离线状态下，也能实现自动化对日志数据的有效抓取，当日志数据总容量达到预设阈值时，按照预设配置参数，自动停止日志数据的抓取，或者自动对已生成的日志文件进行覆盖，避免了人工手动操作出现的错误数据，能够快速有效的对实时生成的日志数据进行有效的自动化管理和储存，减少了大量频繁的输入数据与输出数据的交互，从而提高了日志数据抓取的效率和准确性。

在一个实施例中，如图3所示，该方法还包括读取日志数据的步骤，具体包括：

步骤302，当需要读取日志数据时，通过串行总线与客户端建立通信连接。

步骤304，向客户端发送停止日志数据抓取指令，获取客户端中已生成的日志数据。

步骤306，通过触发操作将已生成的日志数据进行读取并储存。

当调试工作人员需要对某一时间段内的客户端进行故障排查时，需要读取对应的日志数据。具体的，当需要读取日志数据时，服务器通过串行总线与客户端建立通信连接。服务器通过目标端口向客户端发送停止日志数据抓取指令，并获取客户端中已生成的日志数据。服务器可以通过触发操作将已生成的日志数据进行读取并储存。例如，服务器可以通过点击读取日志数据按钮，将客户端中已生成的日志数据进行读取并储存，服务器也可以根据需求选择固定时间间隔内的日志数据进行读取，查找对应的故障信息。例如，服务器可以预先设置配置信息的固定时间间隔为24h，即每间隔24h应用程序就自动停止对日志数据的抓取，并将已生成的日志数据按照时间顺序保存在客户端本地指定的路径下。服务器也可以预先设置配置信息的固定时间间隔为4h，即每间隔4h应用程序就自动对已生成的日志数据进行覆盖，并将新生成的日志数据按照时间顺序保存在客户端本地指定的路径下。由此使得即使在离线状态下，通过应用程序启动客户端进行实时的日志数据抓取，只有当需要停止抓取日志数据或者读取日志数据时，才需要通过串行总线与客户端建立通信连接，拉取对应的日志数据，即使在离线状态下，也能够实现对客户端生成的日志数据进行实时的监测，避免了大量频繁的输入数据与输出数据的交互，从而能够获取到实时准确的日志数据。

在其中一个实施例中，当需要读取日志数据时，通过串行总线与客户端建立通信连接之后，该方法还包括清除日志数据的步骤，具体包括：

向客户端发送清除日志数据指令，将客户端中已生成的日志数据进行清除。

当需要读取日志数据时，通过串行总线与客户端建立通信连接之后，服务器还可以通过目标端口向客户端发送清除日志数据指令，将客户端中已生成的日志数据进行清除。具体的，当需要清除日志数据时，服务器可以通过串行总线与客户端建立通信连接，通过目标端口向客户端发送清除指令，将客户端中已生成的日志数据进行清除。其中，清除指令也可以是针对具体某一时间段内生成的日志数据进行清除，或者按照日志的不同类型，可以对某一具体的日志类型文件进行清除。例如，日志信息由低到高的等级类型可以包括：debug<info<warn<Error<Fatal，debug日志表示所有详细信息，用于调试。info日志表示一些关键跳转，证明软件正常运行的日志。warn日志表明发生了一些意外，软件无法处理，但是依然能正常运行。Error日志表示由于一些严重问题，软件不能正常执行一些功能，但是依然能运行。Fatal日志表示非常严重的错误，软件已经不能继续运行了。例如，由于目前客户端运行正常，服务器可以通过目标端口向客户端发送清除info类型的日志指令，将客户端中已生成的info类型的日志数据进行清除。由此使得可以定期对客户端的储存空间进行有效的清理，清除一些不必要的日志数据，避免由于储存空间不够而产生的日志数据无法储存或者错误覆盖的情况，简化了操作流程，极大的提高了日志数据管理的便利性，有效的避免了一些错误日志数据的产生，从而提高了获取日志数据的准确性。

在一个实施例中，如图4所示，该方法还包括抓取日志数据或停止抓取日志数据的步骤，具体包括：

步骤402，当需要抓取日志数据或停止抓取日志数据时，通过串行总线与客户端建立通信连接，向客户端发送抓取日志数据或停止抓取日志数据指令。

步骤404，否则，将串行总线与客户端的连接断开。

当客户端处于离线状态时，服务器可以通过串行总线与客户端建立通信连接，通过目标端口对客户端发送抓取日志数据或停止抓取日志数据指令，将对应的日志数据进行抓取或者停止抓取。具体的，当需要抓取日志数据或停止抓取日志数据时，服务器可以通过串行总线与客户端建立通信连接，向客户端发送抓取日志数据或停止抓取日志数据指令。否则，服务器将串行总线与客户端的连接断开。例如，当客户端能正常运行时，但客户端的某些功能不能正常执行，比如某个应用程序无法正常打开时，服务器可以通过串行总线与客户端建立通信连接，向客户端发送停止抓取日志数据指令，同时服务器获取对应的warn类型日志数据，因为warn类型日志数据表明发生了一些意外，软件无法处理，但是依然能正常运行。服务器通过目标端口将客户端本地已生成的所有warn类型日志数据储存到服务器中的指定路径下，便于查找对应的故障信息。当故障信息查找到并处理完毕后，服务器可以通过串行总线与客户端建立通信连接，通过目标端口对客户端发送继续抓取日志数据指令，对客户端中实时生成的日志数据继续进行抓取。此外，服务器也可以通过串行总线与客户端建立通信连接，向客户端发送停止抓取日志数据指令，同时服务器获取对应的应用日志类型的日志数据，因为应用日志数据包含应用程序编写的各种错误消息，警告或其他事件。该类型的日志数据可以提供与特定用例相关的逻辑高级信息，以便调试人员可以根据此类日志数据快速查找到相关应用程序的故障问题。因此服务器可以通过读取不同类型的日志数据，全方面的快速查找到故障问题所在。

本实施例中，只有当需要开启日志抓取数据或者停止日志抓取数据时，才需要通过串行总线与客户端进行连接通信。在串行总线与客户端的连接断开时，即离线状态下，通过应用程序仍然能够对客户端产生的日志数据进行实时抓取，相对于传统的在线平台工具抓取日志的方式，无需人工手动操作，也无需繁琐的设置流程，可以适应多种环境情况下，对客户端的日志数据进行实时准确的抓取，同时也避免了大量频繁的输入数据与输出数据的交互，极大的提高了日志数据抓取的准确性与便捷性。同时服务器可以通过读取不同类型的实时日志数据，全方面的快速查找到故障问题所在。

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

在一个实施例中，如图5所示，提供了一种日志数据抓取装置，包括：连接模块502、识别模块504、发送模块506和抓取模块508，其中：

连接模块502，用于当客户端处于离线状态时，通过串行总线与客户端建立连接。

识别模块504，用于扫描客户端端口配置参数，利用端口配置参数识别目标端口。

发送模块506，用于通过目标端口连接客户端进行通信，发送配置文件到客户端。

抓取模块508，用于当向客户端发送日志数据抓取指令，将与配置文件对应的日志数据进行抓取时，断开串行总线与客户端的连接，并将日志数据存储到指定路径下。

在一个实施例中，该装置还包括：加载模块。

加载模块用于当客户端中不存在与目标端口对应的配置参数时，将目标端口对应的配置参数加载至客户端本地。连接模块502还用于利用客户端本地已加载的目标端口对应的配置参数，连接客户端进行通信。

在一个实施例中，该装置还包括：监测模块和分割模块。

监测模块用于当对日志数据进行抓取时，对每个日志文件容量进行实时监测。分割模块用于当监测到的日志文件容量大于预设阈值时，则自动将日志文件进行分割，得到对应的日志文件。

在一个实施例中，监测模块还用于当监测到日志文件的总容量达到预设阈值时，则自动停止日志数据的抓取或自动对已生成的日志文件进行覆盖。

在一个实施例中，该装置还包括：获取模块和读取模块。

连接模块502还用于当需要读取日志数据时，通过串行总线与客户端建立通信连接。获取模块用于向客户端发送停止日志数据抓取指令，获取客户端中已生成的日志数据。读取模块用于通过触发操作将已生成的日志数据进行读取并储存。

在一个实施例中，该装置还包括：清除模块。

清除模块用于向客户端发送清除日志数据指令，将客户端中已生成的日志数据进行清除。

在一个实施例中，连接模块502还用于当需要抓取日志数据或停止抓取日志数据时，通过串行总线与客户端建立通信连接，向客户端发送抓取日志数据或停止抓取日志数据指令；否则，将串行总线与客户端的连接断开。

关于日志数据抓取装置的具体限定可以参见上文中对于日志数据抓取方法的限定，在此不再赘述。上述日志数据抓取装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储日志抓取数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种日志数据抓取方法。

本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述各个方法实施例的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

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

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种日志数据抓取方法，所述方法包括：

当客户端处于离线状态时，通过串行总线与所述客户端建立连接；

扫描所述客户端端口配置参数，利用所述端口配置参数识别目标端口；

通过所述目标端口连接所述客户端；

当所述客户端中不存在与所述目标端口对应的配置参数时，利用配置工具，将所述目标端口对应的配置参数加载至客户端本地；利用客户端本地已加载的目标端口对应的配置参数，连接所述客户端；

基于与所述客户端之间的连接发送配置文件到所述客户端；所述配置文件是根据不同日志类型预先设置好的，用于指示抓取的日志数据；

当向所述客户端发送日志数据抓取指令，将与所述配置文件对应的日志数据进行抓取时，断开串行总线与所述客户端的连接，并指示所述客户端将所述日志数据存储到所述客户端的指定路径下。

2.根据权利要求1所述的方法，其特征在于，所述端口配置参数包括端口的链路类型、发送信息的配置、接收信息的配置以及硬件识别号。

3.根据权利要求1所述的方法，其特征在于，所述将与所述配置文件对应的日志数据进行抓取时包括：

当对所述日志数据进行抓取时，对每个日志文件容量进行实时监测；所述日志数据包括日志文件；

当监测到的日志文件容量大于预设阈值时，则自动将所述日志文件进行分割，得到对应的多个新日志文件。

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

当监测到所述日志文件的总容量达到预设阈值时，则自动停止日志数据的抓取或自动对已生成的日志文件进行覆盖。

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

当需要读取日志数据时，通过串行总线与所述客户端建立通信连接；

向所述客户端发送停止日志数据抓取指令，获取客户端中已生成的日志数据；

通过触发操作将所述已生成的日志数据进行读取并储存。

6.根据权利要求5所述的方法，其特征在于，所述当需要读取日志数据时，通过串行总线与所述客户端建立通信连接之后，所述方法还包括：

向所述客户端发送清除日志数据指令，将客户端中已生成的日志数据进行清除。

7.根据权利要求1至3、5、6任意一项所述的方法，其特征在于，所述方法还包括：

当需要抓取日志数据或停止抓取日志数据时，通过串行总线与所述客户端建立通信连接，向所述客户端发送抓取日志数据或停止抓取日志数据指令；

否则，将串行总线与所述客户端的连接断开。

8.一种日志数据抓取装置，其特征在于，所述装置包括：

连接模块，用于当客户端处于离线状态时，通过串行总线与所述客户端建立连接；

识别模块，用于扫描所述客户端端口配置参数，利用所述端口配置参数识别目标端口以使得所述连接模块通过所述目标端口连接所述客户端；

加载模块，用于当所述客户端中不存在与所述目标端口对应的配置参数时，利用配置工具，将所述目标端口对应的配置参数加载至客户端本地，以使得所述连接模块利用客户端本地已加载的目标端口对应的配置参数，连接所述客户端；

发送模块，用于基于与所述客户端之间的连接发送配置文件到所述客户端；所述配置文件是根据不同日志类型预先设置好的，用于指示抓取的日志数据；

抓取模块，用于当向所述客户端发送日志数据抓取指令，将与所述配置文件对应的日志数据进行抓取时，断开串行总线与所述客户端的连接，并指示所述客户端将所述日志数据存储到所述客户端的指定路径下。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

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