CN114281657A - 一种系统日志采集方法及装置 - Google Patents

Abstract

针对输出的日志准确率低、需要人工在源码中修改或添加日志输出控制块以反复采集日志、日志输出控制灵活性差等问题，本申请公开了一种系统日志采集方法及装置，该方法包括：获取系统的状态数据；根据状态数据识别系统的异常类型；根据异常类型采集系统的目标日志。实施本申请，能够实现系统日志的动态采集，提高了日志采集的灵活性，提高了系统日志采集的效率和准确率。

Description

一种系统日志采集方法及装置

技术领域

本申请涉及信息处理技术领域，尤其涉及一种系统日志采集方法及装置。

背景技术

Linux系统在运行程序时通常会把一些系统消息或者错误消息写入对应的系统日志中，例如，内核消息、系统程序消息、用户登录或者退出系统的相关消息、程序运行过程中的各种时间消息等。一旦系统出现问题，用户可以通过查看日志以定位系统问题，及时解决故障。

因此，Linux系统日志是定位和解决问题的重要手段。在实际的Linux系统的运维过程中，常通过配置文件或者人工设置控制块控制日志的输出，控制块的位置一旦设定，日志的输出位置也是固定的，无法动态改变，导致日志输出控制的灵活性差，且当输出的日志无法定位系统问题时，需要人工在源码中修改或添加控制块反复采集日志。

发明内容

本申请实施例公开了一种系统日志采集方法和装置，能够实现系统日志的动态采集，提高了日志采集的灵活性，提高了系统日志采集的效率和准确率。

第一方面，本申请提供了一种系统日志采集方法，应用于第一设备，该方法包括：获取系统的状态数据；根据状态数据识别系统的异常类型；根据异常类型采集系统的目标日志。

上述方法中，通过获取到的系统的状态数据确定系统的异常类型，再基于异常类型采集系统的目标日志，使得采集达到的系统的目标日志与系统的问题定位具有较高的关联度，提高了日志采集的准确率以及效率。

在第一方面的一种可能的实现方式中，根据异常类型采集系统的目标日志，包括：确定系统中与异常类型对应的目标函数；采集目标函数对应的系统的目标日志。

实施上述实现方式，通过确定导致系统为对应异常类型的目标函数，采集目标函数对应的系统的目标日志，有针对性地采集系统的目标日志，有利于提高了日志采集的准确率。

在第一方面的一种可能的实现方式中，采集目标函数对应的系统的目标日志是指：对目标函数进行插桩，以采集目标函数对应的系统的目标日志。

通过插桩的方式采集目标函数对应的系统的目标日志，目标函数运行时的上下文信息即为系统的目标日志，实现了目标日志的动态在线抓取，提高了系统的目标日志采集的灵活性，提高了日志采集的采集效率。

在第一方面的一种可能的实现方式中，确定系统中与异常类型对应的目标函数，包括：监控预设时间内系统内运行的应用进程或内核进程；确定应用进程或内核进程中与异常类型对应的目标函数。

对系统预设时间内的应用进程或内核进程进行监控，以判断应用进程或内核进程中与异常类型强相关的目标函数，不仅有利于提高日志的采集效率，还有利于提高采集的日志的准确率。

在第一方面的一种可能的实现方式中，根据异常类型采集系统的目标日志，包括：获取异常类型对应的日志采集模板；通过日志采集模板采集系统的目标日志。

实施上述实现方式，系统的异常类型有对应的日志采集模板，也就是说，系统的异常类型与日志采集模板的类型对应，基于日志采集模板可以直接获取系统的目标日志，无需人工修改或通过配置文件重新运行源码，可实现系统日志的在线式动态采集。

在第一方面的一种可能的实现方式中，获取异常类型对应的日志采集模板，包括：根据异常类型查找模板库，获得日志采集模板，模板库包括异常类型与日志采集模板的类型之间的映射关系。

实施上述实现方式，通过预先自定义各种类型的日志采集模板并存储至模板库中，且日志采集模板的类型与系统的异常类型一一对应，在确定系统的异常类型的情况下，根据异常类型和日志采集模板之间的映射关系可以查找到该异常类型对应的日志采集模板，由此获得的日志采集模板采集到的系统日志与系统问题定位具有较高的关联度，提高了系统日志的采集效率和准确率。

在第一方面的一种可能的实现方式中，获取系统的状态数据，包括：根据采集模型获取系统的状态数据，采集模型包括利用率-饱和度-错误(USE)模型、速率-错误-响应(RED)模型和延迟-流量-错误-饱和度(LETS)模型中的至少一种。

基于采集模型获取系统的状态数据，采集到的系统的状态数据能更好反映地系统的性能状态、更有针对性、代表性。另外，使用的采集模型的数量越多，采集到的系统的状态数据也就越详细，有助于提高后续识别系统的异常类型的准确率。

在第一方面的一种可能的实现方式中，获取系统的状态数据，包括：获取用户指定的采集指标；根据采集指标获取系统的状态数据。

用户可以指定采集指标，响应于用户的指定操作，第一设备根据用户指定的采集指标获取系统的状态数据，不仅使得采集到的系统的状态数据更有代表性，还增加了日志采集过程中的交互性。

第一方面的一种可能的实现方式中，异常类型包括CPU异常、内存异常和磁盘IO异常中的至少一种；日志采集模板的类型包括CPU类型、内存类型和磁盘IO类型中的至少一种。

识别出系统的异常类型的数量为至少一种，相应地，根据系统的异常类型获取对应的日志采集模板的数量也为至少一种。对系统的异常类型以及日志采集模板的类型进行分类，提高了系统日志的采集效率和准确率。

第一方面的一种可能的实现方式中，在根据异常类型采集系统的目标日志之后，还可以在显示器上显示系统的目标日志，或者，在显示器上显示系统的目标日志对应的提示信息。

在抓取到目标日志后，将目标日志或者目标日志对应的提示信息显示在显示器上，用户可以直观清楚地知晓与系统问题高度关联的信息，方便用户进一步定位系统问题。

第二方面，本申请提供了一种系统日志采集方法，应用于第二设备，该方法包括：接收第一设备发送的系统的状态数据；根据系统的状态数据识别系统的异常类型；向第一设备发送异常类型，以使第一设备根据异常类型采集系统的目标日志。

实施上述方法，接收来自第一设备的系统的状态数据，基于系统的状态数据识别系统的异常类型并将识别结果发送给第一设备，各个功能模块充分解耦，增加了识别功能模块部署方式的多样性，有利于提高系统日志的采集效率。

在第二方面的一种可能的实现方式中，根据系统的状态数据识别系统的异常类型，包括：根据人工智能AI识别模型分析系统的状态数据以确定系统的异常类型。

通过AI识别模型对系统的状态数据进行分析以识别系统的异常类型，提高了系统的异常类型的识别效率以及识别准确率，以使后续根据异常类型采集到的系统的目标日志与系统的问题具有较高的关联度，有助于发现系统的性能瓶颈以及定位系统的问题。

在第二方面的一种可能的实现方式中，系统的状态数据是第一设备基于用户指定的采集指标获取的。

系统的状态数据基于用户指定的采集指标获取，不仅使得采集到的系统的状态数据更有代表性，还增加了日志采集过程中的交互性。在第二方面的一种可能的实现方式中，系统的状态数据第一设备基于采集模型获取的，采集模型包括利用率-饱和度-错误(USE)模型、速率-错误-响应(RED)模型和延迟-流量-错误-饱和度(LETS)模型中的至少一种。

系统的状态数据基于采集模型获取，使得采集到的系统的状态数据更有代表性。另外，使用的采集模型的数量越多，采集到的系统的状态数据也就越详细，有助于提高后续识别系统的异常类型的准确率。

第三方面，本申请提供了一种装置，该装置包括获取单元，用于获取系统的状态数据；识别单元，用于根据状态数据识别系统的异常类型；采集单元，用于根据异常类型采集系统的目标日志。

在第三方面的一种可能的实现方式中，采集单元，具体用于：确定系统中与异常类型对应的目标函数；采集目标函数对应的系统的目标日志。

在第三方面的一种可能的实现方式中，采集单元，具体用于：对目标函数进行插桩，以采集目标函数对应的系统的目标日志。

在第三方面的一种可能的实现方式中，采集单元，具体用于：监控预设时间内系统内运行的应用进程或内核进程；确定应用进程或内核进程中与异常类型对应的目标函数。

在第三方面的一种可能的实现方式中，采集单元，具体用于：获取异常类型对应的日志采集模板；通过日志采集模板采集系统的目标日志。

在第三方面的一种可能的实现方式中，采集单元，具体用于：根据异常类型查找模板库，获得日志采集模板，模板库包括异常类型与日志采集模板的类型之间的映射关系。

在第三方面的一种可能的实现方式中，获取单元，具体用于：根据采集模型获取系统的状态数据，采集模型包括利用率-饱和度-错误(USE)模型、速率-错误-响应(RED)模型和延迟-流量-错误-饱和度(LETS)模型中的至少一种。

在第三方面的一种可能的实现方式中，获取单元，具体用于：获取用户指定的采集指标；根据采集指标获取系统的状态数据。

在第三方面的一种可能的实现方式中，该装置还包括显示单元，用于显示系统的目标日志，或者，显示系统的目标日志对应的提示信息。

第四方面，本申请提供了一种装置，装置包括：接收单元，用于接收第一设备发送的系统的状态数据；识别单元，用于根据系统的状态数据识别系统的异常类型；发送单元，用于向第一设备发送异常类型，以使第一设备根据异常类型采集系统的目标日志。

在第四方面的一种可能的实现方式中，识别单元，具体用于：根据人工智能AI识别模型分析系统的状态数据以确定系统的异常类型。

在第四方面的一种可能的实现方式中，系统的状态数据是第一设备基于用户指定的采集指标获取的。

在第四方面的一种可能的实现方式中，系统的状态数据第一设备基于采集模型获取的，采集模型包括利用率-饱和度-错误(USE)模型、速率-错误-响应(RED)模型和延迟-流量-错误-饱和度(LETS)模型中的至少一种。

第五方面，本申请提供了一种装置，该装置包括处理器和存储器，处理器和存储器通过总线连接或者耦合在一起；其中，存储器用于存储程序指令；所述处理器调用所述存储器中的程序指令，以执行第一方面或者第一方面的任一可能的实现方式中的方法。

第六方面，本申请提供了一种装置，该装置包括处理器和存储器，处理器和存储器通过总线连接或者耦合在一起；其中，存储器用于存储程序指令；所述处理器调用所述存储器中的程序指令，以执行第二方面或者第二方面的任一可能的实现方式中的方法。

第七方面，本申请提供了一种计算机可读存储介质，所述计算机可读介质存储用于装置执行的程序代码，所述程序代码包括用于执行第一方面或者第一方面的任一可能的实现方式中的方法的指令。

第八方面，本申请提供了一种计算机可读存储介质，所述计算机可读介质存储用于装置执行的程序代码，所述程序代码包括用于执行第二方面或者第二方面的任一可能的实现方式中的方法的指令。

第九方面，本申请提供了一种计算机软件产品，该计算机程序软件产品包括程序指令，当该计算机软件产品被装置执行时，该装置执行前述第一方面或者第一方面的任一可能的实施例中的所述方法。该计算机软件产品可以为一个软件安装包，在需要使用前述第一方面的任一种可能的设计提供的方法的情况下，可以下载该计算机软件产品并在装置上执行该计算机软件产品，以实现第一方面或者第一方面的任一可能的实施例中的所述方法。

第十方面，本申请提供了一种计算机软件产品，该计算机程序软件产品包括程序指令，当该计算机软件产品被装置执行时，该装置执行前述第二方面或者第二方面的任一可能的实施例中的所述方法。该计算机软件产品可以为一个软件安装包，在需要使用前述第一方面的任一种可能的设计提供的方法的情况下，可以下载该计算机软件产品并在装置上执行该计算机软件产品，以实现第二方面或者第二方面的任一可能的实施例中的所述方法。

附图说明

为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是一种系统日志采集场景示意图；

图2A是本申请实施例提供的一种应用的系统架构；

图2B是本申请实施例提供的又一种应用的系统架构；

图3是本申请实施例提供的一种系统日志采集方法的流程图；

图4是本申请实施例提供的一种用户界面的示意图；

图5是本申请实施例提供的一种根据系统的异常类型采集系统日志的流程图；

图6是本申请实施例提供的一些采集系统的目标日志的流程示意图；

图7是本申请实施例提供的一种系统日志采集方法的流程图；

图8是本申请实施例提供的一种装置的功能结构示意图；

图9是本申请本实施例提供的又一种装置的功能结构示意图；

图10是本申请实施例提供的一种计算装置的结构示意图；

图11是本申请实施例提供的又一种计算装置的结构示意图。

具体实施方式

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。本申请实施例中的说明书和权利要求书中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

为了便于理解，下面先对本申请实施例可能涉及的相关术语等进行介绍。

(1)内核态和用户态

由于需要限制不同的程序之间的访问能力，防止它们获取别的程序的内存数据，或者获取外围设备的数据，并发送到网络，CPU划分出两个权限等级：用户态和内核态。其中，内核态中，CPU可以访问内存的所有数据，包括外围设备，例如硬盘、网卡，CPU也可以将自己从一个程序切换到另一个程序；而在用户态，只能受限的访问内存，且不允许访问外围设备，占用CPU的能力被剥夺，例如，运行在用户态下的程序不能直接访问操作系统内核数据结构和程序。

简单来说，用户态和内核态是应用程序运行的两种状态，当应用程序需要进行系统调用、中断等情况时，应用程序由用户态切换至内核态。

(2)扩展伯克利过滤机制eBPF

扩展伯克利过滤机制(extended Berkeley Packet Filter，eBPF)提供了内核的数据包过滤机制，其在内核提供了一个虚拟机，用户态将过滤规则以虚拟机指令的形式传递到内核，由内核根据这些指令来过滤数据包。eBPF技术是一种内核可编程技术，通过一种软件定义的方式提供并支持丰富的内核探针类型，通过探针机制，采集内核态或者用户态中程序的运行信息，而不需要修改内核和应用程序的代码，这种方式是一种非侵入式的更改。因此，开发者通过编写eBPF程序，eBPF利用自身的实现机制，即可实现监视系统以及提高在内核进行动态追踪的效率。

目前有两种使用方法，一种是基于python的软件开发工具包(SoftwareDevelopment Kit，SDK)，具有python的编程效率高、易使用等特点；另一种是基于bpftrace(命令行程序)的shell脚本，bpftrace是linux中基于eBPF的高级追踪语言，可以将基于eBPF的程序编译成脚本可供直接运行，而无需在内核中手动编译并加载。上述两种方式在本申请中都可应用。

(3)插桩

插桩技术是指在保证原有程序逻辑完整性的基础上在程序中插入探针，探针的本质即为进行信息采集的代码段，即在特定的位置插入代码段，通过探针的执行以采集代码中的信息(方法本身、方法参数值、返回值等)，从而收集程序运行时的动态上下文信息，以此实现探测的目的。

相关技术中，程序的运行有两种状态，即用户态和内核态，日志的采集也包括用户态采集和内核态采集。参见图1，图1是一种现有技术的日志采集场景示意图，应用程序的用户态调用printf函数以及内核态调用printk函数打印日志，输出到日志文件。在具体实现中，通常会在printf或printk之外增加一个控制块，控制日志的输出，控制块的实现有两种方式：第一种是采用宏#if defined(DEBUG)…#endif，这种控制块是编译阶段确定的，一旦在编译选项确定了，逻辑上是固定在代码上的，不能动态的改变；另外一种是采用if(DEBUG){}这种判断语句实现的，但同样也是，控制块的编写位置一旦确定，采集的日志的位置也是固定的，无法动态改变。若当前位置输出的日志无法定位问题，则需要重新修改源码(即增加或者改变printf或者printk的输出位置)。上述两种方式，整体上日志的采集控制灵活性差，无法适应现网环境复杂多变的情况，导致问题定位效率低。

下面描述本申请所应用的一种系统架构。参见图2A，图2A是本申请实施例提供的一种系统架构，该系统包括第一设备10和第二设备20，其中，第一设备10中包括数据收集模块和日志采集模块，第二设备20中部署有识别模块，第一设备10和第二设备20之间可以通过无线或者有线的方式进行通信。

在第一设备10中，数据收集模块用于获取系统的状态数据，例如，CPU的利用率、CPU的饱和度、内存利用率、磁盘的利用率等，并将获取到系统的状态数据发送给第二设备20，以使第二设备20的识别模块对系统的状态数据进行分析以识别系统的异常类型。第一设备10中的日志采集模块用于接收第二设备20发送的系统的异常类型，并根据异常类型采集系统的目标日志。可选地，数据收集模块还可以根据系统的运行环境的类型选择预设的采集模型对系统的状态数据进行收集。需要说明的是，第二设备20可以是云服务器或者其他计算设备。

在图2A所示的系统架构中，在一些可能的实施例中，第一设备10的数量有多个，在此情况下，第二设备20还可以与这多个第一设备进行无线通信，也就是说，部署在第二设备20上的识别模块可服务于多个第一设备，即第二设备20接收多个第一设备发送的系统的状态数据，并对每个系统的状态数据进行分析以识别每个系统的异常类型，并将识别出的每个系统的异常类型发送给对应的第一设备。

在一些可能的实施例中，参见图2B，图2B是本申请提供的另一种系统架构，如图2B所示，该系统包括第一设备10，且第一设备10中部署有数据收集模块、日志采集模块和识别模块。其中，数据收集模块用于收集系统的状态数据，例如，CPU的利用率、CPU的饱和度、内存利用率、磁盘的利用率等。识别模块对数据收集模块收集到系统的状态数据进行分析以识别系统的异常类型，最后，日志采集模块根据识别模块输出的系统的异常类型调用预设的日志采集模板采集系统的目标日志。

参见图3，基于上文所描述的系统架构，下面描述本申请实施例，参见图3，图3是本申请提供的一种系统日志采集方法，该方法包括但不限于以下步骤：

S101、第一设备获取系统的状态数据。

本申请实施例中，第一设备需要先获取系统的状态数据。一具体实施中，第一设备可以根据采集模型(或者为负载采集方法)获取系统的状态数据，采集模型可以是一种也可以是多种。另一具体实施中，第一设备也可以获取用户指定的采集指标，根据采集指标获取系统的状态数据。

本申请的一种实施例中，第一设备根据采集模型获取系统的状态数据，换句话说，采集模型确定了获取系统的状态数据的预设规则。采集模型包括利用率-饱和度-错误(Utilization,Saturation,and Errors，USE)模型、请求-错误-响应(Requests,Errors,and Duration，RED)模型和延迟-流量-错误-饱和度(Latency,Errors,Traffic andSaturation，LETS)模型中的至少一种。需要说明的是，上述三种模型为评估系统的性能提供了参考。

例如，采集模型可以是利用率-饱和度-错误(USE)模型，USE模型是Brenda Gregg提出的，Utilization(利用率)是指对系统诸如CPU，磁盘，内存等的利用情况，以CPU为例，CPU的利用率是指CPU执行非系统空闲进程的时间与CPU总的执行时间的比例；Saturation(饱和度)是系统等待处理的业务或者请求程度，一般为等待队列的长度，用于衡量是否超过了系统的最大承受能力；Errors(错误)错误是指系统在处理这些业务或者请求时报告的错误次数。

基于USE模型采集到的系统的状态数据可以是：获取CPU利用率(系统级均值)、CPU运行队列长度(也可称为分配队列长度)、CPU发生的错误事件数、磁盘的容量、磁盘的等待队列长度、磁盘发生的读写错误数、可用空间内存、内存的占用时间、内存错误数等。

例如，采集模型可以是速率-错误-响应(RED)模型，RED模型是Tom Wilkie提出的，Rate(速率)是指系统内每秒的请求数量；Errors(错误)是指系统内每秒请求失败的数量；Duration(响应时间)是指系统内请求所消耗的时间。

基于RED模型采集到的系统的状态数据可以是：获取系统单位时间内的请求数量、系统单位时间内请求失败的数量与请求数量的比率、系统内各请求的响应时间分布情况等。

例如，采集模型还可以是延迟-流量-错误-饱和度(LETS)模型，LETS模型是Google提出的，Latency(延迟)是指系统处理请求所消耗的时间，Errors(错误)是指系统发生的错误事件数；Traffic(流量)也称吞吐量，用于衡量系统的容量需求，即接收到的请求，例如，每秒的请求数；Saturation(饱和度)用于衡量服务器、网络等资源的负载，其最能影响系统服务状态的性能。

基于LETS模型采集到的系统的状态数据可以是：获取系统发送请求和接收响应所需的时间、请求成功以及请求失败的延迟、获取流经网络的请求数量(例如、对Web服务器或者API应用程序接口的http请求的数量)、系统发生的错误事件(例如，硬件错误、程序错误等)、CPU的利用率、内存使用率以及磁盘每秒读写数量等。

不妨以基于LETS模型和USE模型获得预设规则为例进行示例性阐述，LETS模型提供了四个衡量指标，分别为延迟、流量、错误和饱和度，USE模型提供了三个衡量指标，分别为利用率、饱和度和错误，综合这两种采集方法设定预设规则，去除重复或者相似的指标，则预设规则设定了利用率、饱和度、错误、延迟和流量五个指标，需要采集这五个指标相关的系统的状态数据，具体地，即采集系统中CPU、内存、磁盘等资源与上述五个指标相关的运行数据。

例如，以利用率这个指标为例进行示例性阐述，对于CPU来说，获取正在运行的线程数或者非空闲进程占用的时间(衡量利用率)；对于磁盘来说，磁盘因I/O需求消耗的CPU的百分比；对于内存来说，内存的空闲空间量与内存的空间总量的比值。以饱和度为例，对于CPU来说，获取CPU等待运行的队列长度；对于磁盘来说，获取磁盘的平均请求队列大小或者平均读和写的等待时间等。

本申请的另一种实施例中，第一设备获取用户指定的采集指标并根据采集指标获取系统的状态数据。例如，第一设备可以给用户提供一个用户界面，参见图4，图4是本申请实施例提供的一种用户界面的示例，并不限定用户界面仅为图4所示的样子，用户界面上罗列有各种采集指标，如：利用率、请求率、饱和度、错误率、延迟等，用户可通过触屏对用户界面上显示的采集指标中的部分或者全部进行选择。在一些可能的实施例中用户也可以通过键盘输入或者鼠标选择采集指标，本申请不做具体限定。响应于用户的上述操作，获取到的采集指标即为用户指定的采集指标，根据用户指定的采集指标获取系统的状态数据。需要说明的是，跟采集指标相关的系统的状态数据可参考上文中采集模型相关的描述，在此不再赘述。可以理解，获取系统的状态数据时采用的采集模型的数量越多或者用户指定的采集指标越多，采集到的系统的状态数据也就越丰富详细，有利于提高后续对系统的异常类型的识别准确率。需要说明的是，采集模型除了可以是上述USE模型、RED模型和LETS模型外，还可以是其他用于评价系统性能的模型，本申请不做具体限定。

在一些可能的实施例中，第一设备还可以根据系统的运行环境确定对应的采集模型以获取系统的状态数据。其中，系统的运行环境可以是物理机、容器和虚拟机等。例如，系统的运行环境为物理机时，基于USE模型采集系统的状态数据；系统的运行环境为容器时，基于RED模型采集系统的状态数据。在一些可能的实施例中，当系统有多种运行环境的情况下，也可以采用多种采集模型采集系统的状态数据。例如，若某台物理机中运行有容器，则检测到系统的运行环境有物理机和容器，物理机对应的采集模型为USE模型，容器对应的采集模型为RED模型，则可基于USE模型和RED模型采集系统的状态数据。除此之外，当系统的运行环境有多种的情况下，还可以在配置文件中设定运行环境的类型级别以确定一种采集模型，该采集模型为多种运行环境中类型级别最高的运行环境对应的采集模型。例如，假设检测到系统的运行环境为物理机和虚拟机，假设设置物理机的级别高于虚拟机的级别，则确定采集模型为物理机对应的采集模型(即USE模型)。

在采集系统的状态数据时，有些数据可以是通过命令获取，例如，可以使用top命令从/proc/stat中提取四个数据：用户模式、进程优先级别值、内核模式以及空闲的处理器时间，基于这四个数据进一步计算CPU执行非系统空闲进程的时间与CPU总的执行时间的比例(即CPU利用率)，当然，也可以由预先写好的脚本获取，还可以通过第三方工具(例如，Nagios)获取系统的状态数据，在一些可能的实施例中，系统的状态数据的采集可以通过上述至少一种方法实现，本申请不做具体限定。

可以看出，基于多种采集模型获取系统的状态数据或者根据用户指定的采集指标系统的状态数据，可使得采集到的系统的状态数据更加具有针对性和可靠性，过滤了其他不重要的数据，能较好地反映系统的性能状态。

S102、第一设备向第二设备发送系统的状态数据。

本申请实施例中，第一设备在获取到系统的状态数据后，第一设备向第二设备发送系统的状态数据，以使第二设备根据系统的状态数据识别系统的异常类型。相应地，第二设备接收第一设备发送的系统的状态数据。

S103、第二设备根据系统的状态数据识别系统的异常类型。

本申请实施例中，第二设备在接收到系统的状态数据后，对系统的状态数据进行分类分析以识别系统的异常类型。一具体实施中，第二设备接收到第一设备发送的系统的状态数据后，通过人工智能(Artificial Intelligence，AI)识别模型对将系统的状态数据进行分析以确定系统的异常类型，AI识别模型输出至少一种异常类型。

其中，异常类型包括CPU异常、内存异常和磁盘IO异常。CPU异常也可以称作CPU密集，是指系统的CPU性能差、表现尤为突出，即CPU异常型的系统具有的特点为CPU的利用率以及饱和度较高等；内存异常也可以称作内存密集，内存异常是指系统的内存性能差、表现尤为突出，即内存异常型的系统具有的特点为系统内存的空闲空间小、内存分配等待时间长等；磁盘IO异常也可以称作磁盘IO密集，磁盘IO异常是指系统的磁盘性能差、表现尤为突出，即磁盘IO异常型的系统具有的特点为读写排队时间长、存储空间小等。

需要说明的是，上述CPU异常、内存异常和磁盘IO异常这些分类只是本申请的一种示例。在一些可能的实施例中，系统的异常类型的分类并不是只包括上述CPU异常、内存异常和磁盘IO异常三种，还可以包括网络IO异常或其他类型，本申请不做具体限定。可以理解，若异常类型包括网络IO异常，相应地，采集到的系统的状态数据中也包括网络带宽的利用率、网络中向外发送的队列长度等与预设规则定义的指标相关的网络IO的数据。

AI识别模型是基于已知系统的状态数据以及已知系统的状态数据对应的已知异常类型训练得到的。举例来说，若欲使AI识别模型可以识别系统为CPU异常、内存异常或磁盘IO异常，则需要预先采集CPU异常型的系统的状态数据、内存异常型的系统的状态数据以及磁盘IO异常型的系统的状态数据，并对上述三种已知系统的异常类型进行标注，基于上述三种已知系统的状态数据以及已知系统对应的异常类型训练AI识别模型，即可使训练好的AI识别模型基于未知系统的状态数据能有效识别出该未知系统的异常类型。

需要说明的是，已知系统的状态数据的采集方式与待测数据(即本申请中的系统的状态数据)的采集方式是相同的，换句话说，若已知系统的状态数据的采集是基于USE模型和RED模型设定的预设规则进行的，那么待测数据的采集也是基于USE模型和RED模型设定的预设规则进行的，如此，可以保证AI识别模型能准确识别待测数据的异常类型。

AI识别模型可以是随机森林算法，随机森林(Random Forest，RF)中有多棵决策树，每棵决策树都是一个分类器，森林中的每棵决策树可以随机从样本数据集(即已知系统的状态数据)中采样一部分数据进行训练，例如，其中一棵决策树是基于已知系统的状态数据中利用率、饱和度这两个指标对应的数据以及已知异常类型训练分类的，另一棵决策树是基于已知系统的状态数据中延迟、利用率这两个指标对应的数据以及已知异常类型训练分类等，在每棵决策树训练完成后，即可将待测样本输入每棵决策树中，每棵决策树都对应有一个输出结果，将多棵决策树的输出结果进行整合以获得最终的输出结果。例如，将系统的状态数据包括的各个指标输入至随机森林的多个决策树中，每个决策树基于输入的数据判断系统的类型为CPU异常、内存异常还是磁盘IO异常，每个决策树都对应一种系统的分类结果，最后随机森林算法综合各个决策树的分类结果，采用众数法(即少数服从多数原则)确定出现次数最多的分类结果即为该系统对应的异常类型。除此之外，AI识别模型还可以是支持向量机(Support Vector Machine,SVM)模型、神经网络模型或者其他识别算法，本申请不做具体限定。

本申请的一种实施例中，AI识别模型在识别系统的状态数据对应的异常类型时，还可以给采集指标设置权重，且采集指标的权重在AI识别模型的训练过程中可以调整。采集指标的权重越大，则与该采集指标相关的系统的状态数据的重要程度越高。例如，若利用率和饱和度这两个采集指标对应的权重相较于其他采集指标的权重更大，则这两个采集指标对识别异常类型的贡献率也越大。识别模型通过对各指标进行加权操作对系统的状态数据计算综合值，根据该综合值确定系统的异常类型。例如，当综合值位于第一阈值范围内时，确定系统的异常类型为CPU异常；当综合值位于第二阈值范围内时，确定系统的异常类型为内存异常等。在一些可能的实施例中，第一阈值范围和第二阈值范围有交叉，在此情况下，当综合值既位于第一阈值范围又位于第二阈值范围时，确定系统的异常类型为CPU异常和内存异常。

本申请的一种实施例中，AI识别模型根据输入的系统的状态数据输出一种异常类型。例如，AI识别模型接收到输入的系统的状态数据，对系统的状态数据进行综合分析，比较该系统的状态数据与多种已知异常类型(即CPU异常、内存异常和磁盘IO异常)的系统的状态数据之间的差异，假设由差异量得出该系统为CPU异常、内存异常和磁盘IO异常的概率分别为0.7、0.2和0.1，CPU异常对应的分类概率最高，若AI识别模型仅输出一种异常类型，易知AI识别模型输出的系统的异常类型为CPU异常。

本申请的另一种实施例中，AI识别模型根据输入的系统的状态数据输出多种异常类型，即并不限定系统对应的异常类型的数量只有一种。例如，AI识别模型接收到输入的系统的状态数据，对系统的状态数据进行综合分析，比较该系统的状态数据与多种已知异常类型的系统的状态数据之间的差异，假设由差异量得出该系统为CPU异常、内存异常和磁盘IO异常的概率分别为0.5、0.4和0.1，即CPU异常和内存异常对应的概率均超过预设阈值(假设为0.33)，故AI识别模型输出的系统的异常类型为CPU异常和内存异常。又例如，AI识别模型对输入的系统的状态数据进行分析比较，得到该系统为CPU异常和内存异常的概率分别为0.6和0.4，则输出该系统对应的异常类型为CPU异常和内存异常。

可以看到，基于识别模型实现对系统的异常类型的自动识别，提高了系统的异常类型的识别效率，有助于定位系统问题的大致方向，且识别出的系统的异常类型与后续系统问题的定位具有较高的关联度，有助于提高后续采集的系统的目标日志与系统问题的关联度，使得采集的日志的准确率更高。

S104、第二设备向第一设备发送系统的异常类型。

本申请实施例中，第二设备根据系统的状态数据识别出系统的异常类型后，将识别出的系统的异常类型发送给第一设备。相应地，第一设备接收第二设备发送的系统的异常类型。

需要说明的是，第二设备识别出的第一设备的系统的异常类型的数量可以是一种，也可以是多种，本申请不做具体限定。

在一可能的实施例中，在有多个第一设备的情况下，第二设备在识别出每个第一设备对应的系统的异常类型后，向第一设备发送识别结果，识别结果中包括第一设备的设备标识以及该设备表示对应的系统的异常类型。可以看到，由第二设备可服务于多个第一设备，实现多个第一设备上系统的异常类型的识别，第二设备可以是云服务器，加速了识别效率，有助于提高系统的目标日志的采集效率。

S105、第一设备根据系统的异常类型采集系统的目标日志。

本申请实施例中，第一设备在接收到系统的异常类型后，根据系统的异常类型采集系统的目标日志。一具体实施中，第一设备可以根据系统的异常类型获取该异常类型对应的日志采集模板，并运行日志采集模板以采集系统的目标日志。另一具体实施中，第一设备可以先确定系统中与异常类型对应的目标函数，然后采集目标函数对应的系统的目标日志。

参见图5，图5示例性地提供了一种基于系统的异常类型对应的日志采集模板采集系统的目标日志的方法，图5是对S105的细化，该方法包括但不限于以下步骤：

S1051、获取异常类型对应的日志采集模板。

具体地，第一设备根据异常类型查找模板库，获得日志采集模板，模板库包括异常类型和日志采集模板的类型之间的映射关系。模板库中包括多种类型的日志采集模板。需要说明的是，日志采集模板可以是脚本。

需要说明的是，模板库中日志采集模板的类型的数量是大于等于异常类型的类别数，对于任意一种异常类型，总能在模板库中查找到该异常类型对应的日志采集模板。

示例性地，异常类型包括CPU异常、内存异常和磁盘IO异常，日志采集模板的类型包括CPU类型、内存类型和磁盘IO类型。可以理解，异常类型和日志采集模板的类型之间的映射关系具体为：在异常类型为CPU异常时，与CPU异常对应的日志采集模板为CPU类型的日志采集模板；在异常类型为内存异常时，与内存异常对应的日志采集模板为内存类型的日志采集模板；在异常类型为磁盘IO异常时，与磁盘IO异常对应的日志采集模板为磁盘IO类型的日志采集模板。

在一些可能的实施例中，第一设备对应的异常类型的数量为多种，在此情况下，第一设备获取到的日志采集模板的数量也为多种，且第一设备对应的异常类型的数量与第一设备获取到的日志采集模板的数量相同。例如，第一设备对应的异常类型为CPU异常和内存异常，则第一设备根据异常类型查找模板库获取的日志采集模板有CPU类型的日志采集模板和内存类型的日志采集模板。

S1052、运行日志采集模板以采集系统的目标日志。

具体地，运行日志采集模板以确定与系统的异常类型对应的目标函数以及采集目标函数对应的系统的目标日志。一具体实施中，日志采集模板包括第一采集模板和第二采集模板，所谓运行日志采集模板以采集系统的目标日志是指：运行第一采集模板以确定导致系统为上述异常类型的目标函数，该目标函数可以是用户态的目标函数或内核态的目标函数；运行第二采集模板，即可采集目标函数对应的目标日志。

由于日志采集模型的类型有CPU类型、内存类型和磁盘IO类型，每种类型的日志采集模板都包括第一采集模板和第二采集模板，其中，第一采集模板用于确定导致系统为对应异常类型的目标函数，目标函数也可以称之为热点函数或关键函数。该目标函数可能是用户进程的热点函数，也可能是内核进程的热点函数，本申请不做具体限定；第二采集模板用于获取用户态的目标函数或内核态的目标函数运行的上下文信息，该上下文信息即为系统的目标日志。

具体地，运行第一采集模板，以确定导致系统为对应异常类型的目标进程，目标进程包括应用进程或内核进程，获取目标进程对应的进程识别号(Process Identification，PID)，进一步在目标进程中抓取导致系统为对应异常类型的目标函数。在目标进程为应用进程时，确定该目标进程对应的用户态的目标函数。在一些可能的实施例中，在目标进程为应用进程时，确定该目标进程对应的用户态的目标函数和该目标进程对应的内核态的目标函数。在目标进程为内核进程时，确定该目标进程在内核态的目标函数。在确定导致系统为对应异常类型的目标函数后，运行第二采集模板，以获取目标函数对应的目标日志，例如，第二采集模板在用户态或内核态中的目标函数的入口以及出口处插桩，获得目标函数运行的上下文信息。

在一些可能的实施例中，第二采集模块采集的目标日志的范围也可以稍大些，即采集目标函数对应的应用的子模块的目标日志或者目标函数对应的内核的子模块的目标日志，其中，应用的子模块包括管理模块、数据交换模块、业务逻辑控制模块等；内核的子模块包括内存管理模块、进程调度模块、网络接口模块、进程间通信模块等。例如，目标函数为内核进程中的内存分配函数(例如，kmalloc函数)，而kmalloc函数是被内存管理模块调用的，则该kmalloc函数对应的内核的子模块为内存管理模块。

参见图6，图6提供了一些采集系统的目标日志的流程示意图，参见图6中的(1)，假设某系统的异常类型为A，触发系统获取类型A对应的日志采集模板，其包括A对应的第一采集模板和A对应的第二采集模板，运行A对应的第一采集模板获得导致系统为异常类型A的目标进程为应用进程，以及获取该应用进程在用户态的目标函数，或者，用户态的目标函数和内核态的目标函数，根据用户态的目标函数确定该目标函数对应的应用的子模块，根据内核态的目标函数确定该目标函数对应的内核的子模块。然后运行A对应的第二采集模板以采集应用的子模块对应的日志以及内核的子模块对应的日志。参见图6中的(2)，假设某系统的异常类型为A，触发系统获取类型A对应的日志采集模板，其包括A对应的第一采集模板和A对应的第二采集模板，运行A对应的第一采集模板获得导致系统为异常类型A的目标进程为内核进程，以及获取该内核进程在内核态的目标函数，根据内核态的目标函数确定该目标函数对应的内核的子模块，然后运行A对应的第二采集模板以采集内核的子模块对应的日志。在一些可能的实施例中，也有可能存在应用进程和内核进程共同导致系统为上述异常类型A，在此情况下，可以结合上述图6中的(1)和图6中的(2)所述的方法进行相应日志的采集。

需要说明的是，日志采集模板可以是基于扩展伯克利过滤机制eBPF的python或shell脚本，有关扩展伯克利过滤机制eBPF的介绍可参考上述相关描述。日志采集模板可以直接调用运行以获取系统的相关信息，因此，第一采集模板和第二采集模板也可以直接运行。

示例性地，日志采集模板可以是基于bpftrace的shell脚本，bpftrace是基于伯克利过滤机制(Berkeley Packet Filter，BPF)和伯克利过滤机制编译器集合(BPF CompilerCollection，BCC)构建的开源跟踪程序，日志采集模板通过插入探针(或称插桩)的方式分别在系统中的应用进程或内核进程中设置标记或中断，当应用进程或内核进程运行到该标记时，会执行附加到这个探测点处的日志采集模板对应的程序代码，然后恢复正常的流程，从而日志采集模板可以获取应用进程对应的目标函数或内核进程对应的目标函数的运行信息。

Linux系统的内核主要支持两种探针，即kprobe和kretprobe，这两种类型的探针都是针对内核函数的调用，其中，kprobe类型的探针通常在内核函数执行前插入探测程序(即本申请中的日志采集模板)，而kretprobe类型的探针是在内核函数执行完毕且返回之后再插入探测程序(即本申请中的日志采集模板)。因此，内核中两种类型的探针的区别在于探测程序被插入的位置不同。除此之外，对于用户态来说，Linux系统支持uprobe和uretprobe两种类型的探针，其中，uprobe类型的探针用于用户态的函数调用，uretprobe类型的探针用于用户态的函数的返回。因此，在需要对应用进程或者内核进程的用户态和/或内核态的目标函数进行监测时，即可将上述这些探针挂接至对应内核态或用户态的hook函数，即可实现探测程序(即日志采集模板)的动态插入，以此实现系统的目标日志的智能动态采集，无需人工或通过配置文件修改源码即可实现日志的动态输出，且输出的目标日志与系统的问题定位具有较高的关联度。

在一些可能的实施例中，识别模型输出的系统的异常类型的数量为多种，相应地，依据上述方法依次调用每种异常类型对应的日志采集模板以采集系统的目标日志并输出。例如，若识别模型输出的系统的异常类型为内存异常和CPU异常，则触发系统调用内存类型的日志采集模板和CPU类型的日志采集模板以采集系统的目标日志。一具体实施中，可以先运行内存类型的日志采集模板后运行CPU类型的日志采集模板进行系统的目标日志的采集，当然，也可以先运行CPU类型的日志采集模板后运行内存类型的日志采集模板进行系统的目标日志的采集，本申请不做具体限定。

本申请的另一种实施例中，第一设备在接收到自身系统的异常类型后，第一设备确定系统中与异常类型对应的目标函数，并采集目标函数对应的系统的目标日志。例如，可对目标函数进行插桩，以采集系统的目标日志。具体地，可以监控预设时间内系统内运行的应用进程或内核进程，确定应用进程或内核进程中与异常类型对应的目标函数。在确定目标函数后，采集目标函数对应的系统的目标日志。

其中，若某应用进程导致系统为对应的异常类型时，则该应用进程中存在与异常类型对应的目标函数，且该目标函数包括该应用进程对应的用户态的目标函数。在一些可能的实施例中，若该应用进程运行时还涉及到系统调用，即需要调用内核态中的相关函数，在此情况下，该目标函数不仅包括该应用进程对应的用户态的目标函数，还包括该应用进程对应的内核态的目标函数。若某内核进程导致系统为对应的异常类型时，则该内核进程中存在与异常类型对应的目标函数，且该目标函数为该内核进程对应的内核态的目标函数。在一些可能的实施例中，也可能出现某应用进程和某内核进程共同导致系统为对应的异常类型，此时确定的目标函数可参考前述两种情况，在此不再赘述。

在确定目标函数后，可以直接对目标函数进行插桩获取目标日志。在一些可能的实施例中，在确定目标函数后，进一步确定该目标函数对应的应用的子模块或者内核的子模块，并采集该目标函数对应的应用的子模块或者内核的子模块的目标日志。例如，对于用户态的目标函数，可对该目标函数对应的应用的子模块进行插桩，以获取目标日志；对于内核态的目标函数，可对该目标函数对应的内核的子模块进行插桩，以获取目标日志。其中，应用的子模块包括管理模块、数据交换模块、业务逻辑控制模块等；内核的子模块包括内存管理模块、进程调度模块、网络接口模块、进程间通信模块等。

例如，假设某系统经识别模型分析后输出系统的异常类型为内存异常，且该系统在一小时前性能良好。例如，监控系统在两小时内运行的应用进程和内核进程，获取各进程(包括应用进程和内核进程)的内存分配等待时间的分布数据，确定内存分配等待时间最长的进程的进程识别号(Process Identification，PID)为23，且该进程为应用进程A，进一步地，确定PID为23的应用进程A对应的用户态的目标函数或者内核态的目标函数，获取应用进程A在用户态中调用频率最高或者运行时间最长的函数作为该应用进程A在用户态的目标函数，判断该应用进程A的运行过程中是否有关联的系统调用执行，若没有关联的系统调用执行，则可直接对该应用进程A对应的用户态的目标函数进行插桩，以采集系统的目标日志；若有关联的系统调用执行，还需获取内核态中调用频率最高或者运行时间最长的函数作为该应用进程A在内核态的目标函数，在此情况下，需分别对用户态的目标函数和内核态的目标函数进行插桩，以采集系统的目标日志。目标函数是导致该系统的异常类型为内存异常的根因所在，由此实现了与系统问题具有高关联度的目标函数的定位。除此之外，还可以在用户态调用printf函数以及在内核态调用printk函数将获取到的目标日志输出至指定的文件或控制台界面等位置，由此即完成了系统日志的动态采集与输出。

例如，假设某系统经识别模型分析后输出系统的异常类型为CPU异常，监控系统在发生CPU异常的一小时内运行的应用进程和内核进程，获取各进程(包括应用进程和内核进程)的CPU利用率分布数据，确定CPU利用率最高的进程的PID为122874，且该进程为内核进程B，进一步地，确定PID为122874的内核进程B与系统的异常类型对应的目标函数，获取内核态中调用频率最高或者运行时间最长的函数作为该内核进程B在内核态的目标函数(例如，调度函数schedule函数)，在确定目标函数后，可以直接对内核态的目标函数进行插桩，获取该内核态的目标函数运行时的上下文信息，该上下文信息即为采集到的系统的目标日志。在一些可能的实施例中，在确定内核态的目标函数后，例如调度函数schedule函数，为了获取更详细的日志系信息，可以在调度函数schedule函数对应内核的进程调度模块处插桩，以采集系统的目标日志。

需要说明的是，通过上述方法采集到系统的目标日志后，还可以在第一设备的显示器上显示采集到的系统的目标日志，以供用户知晓与系统问题高度关联的函数的执行结果，从而根据该执行结果进行进一步分析。具体地，在用户态调用printf函数将采集到的用户态对应的日志信息输出至显示器上，在内核态调用printk函数将获取到内核态对应的日志信息目标日志输出至显示器上。在一些可能的实施例中，也可以通过printf函数或printk函数将对应的目标日志输出至指定的文件或控制台界面等位置，由此即完成了系统日志的动态采集与输出。在一些可能的实施例中，也可以在显示器上显示系统的目标日志对应的提示信息，提示信息指示了系统异常的根因。

可以看到，实施本申请实施例，基于至少一种负载采集方法采集系统的状态数据，借助于AI识别模型分析系统的状态数据以识别系统的异常类型，提高了系统数据采集的效率和准确度，有利于提高AI识别模型的识别准确率。根据系统的异常类型采集系统的目标日志，不仅实现了与系统问题高度关系的系统日志的动态采集，提高了系统日志的采集效率，还有助于快速定位系统问题以提升系统的运维效率。

参见图7，图7是本申请实施例提供的一种系统日志采集方法的流程图，与图3实施例不同的是，图7实施例所描述的方法可以在一台设备(例如，第一设备)内完成，而图3实施例所描述的方法需要两台设备参于完成。图7实施例可以独立于图3实施例。该方法包括但不限于以下步骤：

S201、第一设备获取系统的状态数据。该步骤具体可参考图3实施例中S101的相关描述，在此不再赘述。

S202、第一设备根据系统的状态数据识别系统的异常类型。

该步骤具体可参考图3实施例中的S103，需要说明的是，与S103不同的是，两者的执行主体不同，在S103中系统的异常类型的识别过程是在第二设备执行的，而S202中系统的异常类型的识别过程是在第一设备执行的，除此之外，二者采用的具体的识别方法是相同的，因此，该步骤具体可参考图3实施例中的S103，在此不再赘述。

S203、第一设备获取系统的异常类型对应的日志采集模板。该步骤具体可参考图5实施例中的S1051，在此不在赘述。

S204、第一设备运行日志采集模板以采集系统的目标日志。该步骤具体可参考图5实施例中的S1052，在此不在赘述。

可以看到，实施本申请实施例，基于至少一种负载采集方法采集系统的状态数据，借助于AI识别模型分析系统的状态数据以识别系统的异常类型，提高了系统数据采集的效率和准确度，有利于提高AI识别模型的识别准确率。根据系统的异常类型采集系统的目标日志，不仅实现了与系统问题高度关系的系统日志的动态采集，提高了系统日志的采集效率，还有助于快速定位系统问题以提升系统的运维效率。

参见图8，图8是本申请实施例提供的一种装置的功能结构示意图，装置41包括获取单元410、收发单元411和采集单元412。可选地，在一些可能的实施例中，装置41还包括识别单元413。该装置41可以通过硬件、软件或者软硬件结合的方式来实现。

其中，获取单元410用于获取系统的状态数据，收发单元411用于向第二设备发送系统的状态数据，收发单元411还用于接收第二设备发送的系统的异常类型，系统的异常类型是第二设备根据系统的状态数据识别获得的，采集单元412用于根据系统的异常类型采集系统的目标日志。

该装置41的各功能模块可用于实现图3实施例所描述的第一设备侧的方法。在图3实施例中，获取单元410可用于执行S101，收发单元411可用于执行S102和S104，采集单元412可用于执行S105。进一步地，采集单元412可用于执行图5实施例中的S1051和S1052。

在一些可能的实施例中，装置41还包括识别单元413，识别单元413用于根据系统的状态数据识别系统的异常类型。该装置41的各功能模块可用于实现图7实施例所描述的方法，在图7实施中，获取单元410可用于执行S201，识别单元413可用于执行S202，采集单元412可用于执行S203和S204。

参见图9，图9是本申请实施例提供的另一种装置的功能结构示意图，装置51包括接收单元510、识别单元511和发送单元512。该装置51可以通过硬件、软件或者软硬件结合的方式来实现。

其中，接收单元510用于接收第一设备发送的系统的状态数据，识别单元511用于根据系统的状态数据识别系统的异常类型，发送单元512用于向第一设备发送识别出的系统的异常类型。

该装置51的各个功能模块可用于实现图3实施例所描述的第二设备侧的方法。在图3实施例中，接收单元510可用于执行S102，识别单元511可用于执行S103，发送单元512用于执行S104。

参见图10，图10是本申请实施例提供的一种计算装置的结构示意图。

如图10所示，计算装置30包括处理器301、辅助存储器302、系统内存303、通信接口304和总线300。其中，辅助存储器302、系统内存303、通信接口304分别通过总线300与处理器301连接。计算装置30可为图2A中的第一设备。

总线300用于计算装置30的各部件之间传递信息，总线300可以使用有线的连接方式或者采用无线的连接方式，本申请并不对此进行限定。

处理器301执行各操作的具体实现可参考上述方法实施例中采集系统的状态数据、获取日志采集模板、采集系统的目标日志等具体操作。处理器301可以是中央处理器(Central Processing Unit，CPU)，现场可编程门阵列(Field Programmable Gate Array，FPGA)，或数字信号处理器(Digital Signal Processor，DSP)等计算逻辑或以上任意计算逻辑的组合。处理器301可以为单核处理器或多核处理器。

系统内存303可以包括一些软件，例如，操作系统(例如Darwin、RTXC、LINUX、UNIX、OS X、WINDOWS或嵌入式操作系统(例如Vxworks))，应用程序等。

辅助存储器302一般也称为外存，辅助存储器302的存储介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如光盘)、或者半导体介质(例如固态硬盘(Solid StateDisk，SSD))等。辅助存储器302可以存储程序以及数据，其中，存储的程序包括：数据采集程序、采集模型、日志采集程序或模板等，存储的数据包括：系统的状态数据、系统的异常类型、系统的异常类型和日志采集模板的类型之间的映射关系等。

在一些可能的实施例中，计算装置30还包括输入/输出接口305和输入/输出设备306，输入/输出接口305与输入/输出设备306连接，用于接收输入的信息，输出操作结果。输入/输出设备可以为鼠标、键盘、显示器、或者光驱等。

通信接口304使用例如但不限于收发器一类的收发装置，来实现与图11所示计算装置40之间的通信，通信接口304可以通过有线或者无线的形式与计算装置40互连，可用于向计算装置40发送系统的状态数据以及接收计算装置40发送的系统的异常类型。

此外，图10仅仅是一个计算装置30的例子，计算装置30可能包含相比于图10展示的更多或者更少的组件，或者有不同的组件配置方式。同时，图10中展示的各种组件可以用硬件、软件或者硬件与软件的结合方式实施。

本申请实施例中，计算装置30用于实现上述图3实施例中第一设备侧的方法和图5实施例所描述的方法。

参见图11，图11是本申请实施例提供的一种计算装置的结构示意图。

计算装置40包括处理器401、辅助存储器402、系统内存403、通信接口404和总线400。其中，辅助存储器402、系统内存403、通信接口404分别通过总线400与处理器401连接。计算装置40可为图2A中的第二设备。

总线400用于计算装置40的各部件之间传递信息，总线400可以使用有线的连接方式或者采用无线的连接方式，本申请并不对此进行限定。

处理器401执行各操作的具体实现可参考上述方法实施例中根据系统的状态数据识别系统的异常类型等具体操作。处理器401可以是中央处理器(Central ProcessingUnit，CPU)，现场可编程门阵列(Field Programmable Gate Array，FPGA)，或数字信号处理器(Digital Signal Processor，DSP)等计算逻辑或以上任意计算逻辑的组合。处理器401可以为单核处理器或多核处理器。

系统内存403可以包括一些软件，例如，操作系统(例如Darwin、RTXC、LINUX、UNIX、OS X、WINDOWS或嵌入式操作系统(例如Vxworks))，应用程序等。

辅助存储器402一般也称为外存，辅助存储器402的存储介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如光盘)、或者半导体介质(例如固态硬盘(solid statedisk，SSD))等。辅助存储器402可以存储程序以及数据，其中，存储的程序包括：AI识别模型等，存储的数据包括：系统的状态数据、系统的异常类型等。

通信接口404使用例如但不限于收发器一类的收发装置，来实现与图10所示计算装置30之间的通信，通信接口404可以通过有线或者无线的形式与计算装置30互连，可用于接收计算装置30发送的系统的状态数据以及向计算装置30发送系统的异常类型。

此外，图11仅仅是一个计算装置40的例子，计算装置40可能包含相比于图11展示的更多或者更少的组件，或者有不同的组件配置方式。同时，图11中展示的各种组件可以用硬件、软件或者硬件与软件的结合方式实施。

本申请实施例中，计算装置40用于实现上述图3实施例中第二设备侧的方法。

在一些可能的实施例中，计算装置40的功能也可以集成于计算装置30内部，在此情况下，计算装置30可为图2B中的第二设备，计算装置30的处理器301还用于对计算装置30内获取到的系统的状态数据进行分析以识别系统的异常类型，计算装置30的辅助存储器302中存储的程序还包括AI识别模型，计算装置30用于实现上述图7实施例所描述的方法。

在本文上述的实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述的部分，可以参见其他实施例的相关描述。

需要说明的是，本领域普通技术人员可以看到上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质包括只读存储器(Read-Only Memory，ROM)、随机存储器(Random AccessMemory，RAM)、可编程只读存储器(Programmable Read-only Memory，PROM)、可擦除可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、一次可编程只读存储器(One-time Programmable Read-Only Memory，OTPROM)、电子抹除式可复写只读存储(Electrically-Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(CompactDisc Read-Only Memory，CD-ROM)或其他光盘存储器、磁盘存储器、磁带存储器、或者能够用于携带或存储数据的计算机可读的任何其他介质。

本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是个人计算机，服务器，或者网络设备、机器人、单片机、芯片、机器人等)执行本申请各个实施例所述方法的全部或部分步骤。

Claims (21)

1.一种系统日志采集方法，应用于第一设备，其特征在于，所述方法包括：

获取系统的状态数据；

根据所述状态数据识别所述系统的异常类型；

根据所述异常类型采集所述系统的目标日志。

2.根据权利要求1所述的方法，其特征在于，所述根据所述异常类型采集所述系统的目标日志，包括：

确定所述系统中与所述异常类型对应的目标函数；

采集所述目标函数对应的所述系统的目标日志。

3.根据权利要求2所述的方法，其特征在于，所述确定所述系统中与所述异常类型对应的目标函数，包括：

监控预设时间内所述系统内运行的应用进程或内核进程；

确定所述应用进程或所述内核进程中与所述异常类型对应的所述目标函数。

4.根据权利要求1所述的方法，其特征在于，所述根据所述异常类型采集所述系统的目标日志，包括：

获取所述异常类型对应的日志采集模板；

通过所述日志采集模板采集所述系统的目标日志。

5.根据权利要求4所述的方法，其特征在于，所述获取所述异常类型对应的日志采集模板，包括：

根据所述异常类型查找模板库，获得所述日志采集模板，所述模板库包括所述异常类型与所述日志采集模板的类型之间的映射关系。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述获取系统的状态数据，包括：

根据采集模型获取所述系统的状态数据，所述采集模型包括利用率-饱和度-错误USE模型、速率-错误-响应RED模型和延迟-流量-错误-饱和度LETS模型中的至少一种。

7.根据权利要求1-5任一项所述的方法，其特征在于，所述获取系统的状态数据，包括：

获取用户指定的采集指标；

根据所述采集指标获取系统的状态数据。

8.一种系统日志采集方法，应用于第二设备，其特征在于，所述方法包括：

接收第一设备发送的系统的状态数据；

根据所述系统的状态数据识别所述系统的异常类型；

向所述第一设备发送所述异常类型，以使所述第一设备根据所述异常类型采集所述系统的目标日志。

9.根据权利要求8所述的方法，其特征在于，所述根据所述系统的状态数据识别所述系统的异常类型，包括：

根据人工智能AI识别模型分析所述系统的状态数据以确定所述系统的异常类型。

10.根据权利要求8或9所述的方法，其特征在于，所述系统的状态数据是所述第一设备基于用户指定的采集指标获取的。

11.一种用于日志采集的装置，其特征在于，所述装置包括：

获取单元，用于获取系统的状态数据；

识别单元，用于根据所述状态数据识别所述系统的异常类型；

采集单元，用于根据所述异常类型采集所述系统的目标日志。

12.根据权利要求11所述的装置，其特征在于，所述采集单元，具体用于：

确定所述系统中与所述异常类型对应的目标函数；

采集所述目标函数对应的所述系统的目标日志。

13.根据权利要求12所述的装置，其特征在于，所述采集单元，具体用于：

监控预设时间内所述系统内运行的应用进程或内核进程；

确定所述应用进程或所述内核进程中与所述异常类型对应的所述目标函数。

14.根据权利要求11所述的装置，其特征在于，所述采集单元，具体用于：

获取所述异常类型对应的日志采集模板；

通过所述日志采集模板采集所述系统的目标日志。

15.根据权利要求14所述的装置，其特征在于，所述采集单元，具体用于：

根据所述异常类型查找模板库，获得所述日志采集模板，所述模板库包括所述异常类型与所述日志采集模板的类型之间的映射关系。

16.根据权利要求11-15任一项所述的装置，其特征在于，所述获取单元，具体用于：

根据采集模型获取所述系统的状态数据，所述采集模型包括利用率-饱和度-错误USE模型、速率-错误-响应RED模型和延迟-流量-错误-饱和度LETS模型中的至少一种。

17.根据权利要求11-15任一项所述的装置，其特征在于，所述获取单元，具体用于：

获取用户指定的采集指标；

根据所述采集指标获取系统的状态数据。

18.一种装置，其特征在于，所述装置包括：

接收单元，用于接收第一设备发送的系统的状态数据；

识别单元，用于根据所述系统的状态数据识别所述系统的异常类型；

发送单元，用于向所述第一设备发送所述异常类型，以使所述第一设备根据所述异常类型采集所述系统的目标日志。

19.根据权利要求18所述的装置，其特征在于，所述识别单元，具体用于：

根据人工智能AI识别模型分析所述系统的状态数据以确定所述系统的异常类型。

20.根据权利要求18或19所述的装置，其特征在于，所述系统的状态数据是所述第一设备基于用户指定的采集指标获取的。

21.一种计算设备，其特征在于，所述计算设备包括处理器和存储器；

所述处理器用于执行所述存储器中存储的指令，以使得所述计算设备执行如权利要求1至10中任一项所述的方法。

Images