数据采集方法、装置、系统、电子设备及存储介质

技术领域

本申请属于远程调用技术领域，具体涉及一种数据采集方法、装置、系统、电子设备及存储介质。

背景技术

云原生，微服务等技术的发展，为应用程序的开发和部署，尤其是分布式系统的开发和部署带来了更多的优势，可以实现应用程序的弹性扩展、自动化管理和高可用性，也能实现应用程序更高的灵活性和可维护性。但是，能够实现这些复杂功能的同时，也需要系统具有更高的稳定性和可靠性。如此，对系统的可观测需求便日益增加，软件开发和运维过程中需要收集远程调用程序的链路(Trace)数据，指标(Metric)数据以及日志(Log)数据等，以能够观测系统的状态、性能、健康状况以及行为特征，从而能够对系统进行观测、诊断、优化以及故障处理等。

在实际应用中，由于链路数据规模取决于用户服务接收的请求数量，因此一般情况下链路数据的数据规模要远大于Metric数据，因此在上报至服务端过程中会造成更多的通信开销和性能开销。

发明内容

本申请提出一种数据采集方法、装置、系统、电子设备及存储介质，能够对链路数据进行压缩，有效减少链路数据传输过程中的通信开销和性能开销。

本申请第一方面实施例提出了一种数据采集方法，包括：

获取应用程序节点远程调用应用程序生成的链路数据；所述链路数据至少包括远程调用过程中请求的服务端接口名称、应用程序节点的用户许可标识、调用的应用程序的标识以及涉及的标签信息；

对所述服务端接口名称进行压缩，得到压缩数据；

对所述用户许可标识、所述应用程序的标识及所述标签信息进行编码，得到编码字符串和所述编码字符串与原文的映射关系；

将所述压缩数据、所述编码字符串以及所述映射关系上传至数据收集设备。

在本申请一些实施例中，所述对所述服务端接口名称进行压缩，得到压缩数据，包括：

从所述链路数据中获取各次远程调用过程中应用程序节点请求的服务端接口名称；

对各所述服务端接口名称中相同的字符进行合并，基于进行合并的相同字符和未进行合并的不同字符得到压缩数据。

在本申请一些实施例中，所述对各所述服务端接口名称中相同的字符进行合并，基于进行合并的相同字符和未进行合并的不同字符得到压缩数据，包括：

确定所有服务端接口名称构成的树形数据结构，以及各所述服务端接口名称对应的前缀树父节点和前缀树叶子节点；

对所述服务端接口名称中相同的前缀树父节点进行合并，基于合并后各所述前缀树父节点和各所述服务端接口名称的所述前缀树叶子节点，得到所述压缩数据。

在本申请一些实施例中，对所述用户许可标识、所述应用程序的标识，及所述标签信息进行编码，得到编码字符串和所述编码字符串与原文的映射关系，包括：

对所述用户许可标识、所述应用程序的标识，及所述标签信息按照预设顺序进行排列，形成待编码字符串；

对所述待编码字符串进行编码，得到编码字符串和所述编码字符串与原文的映射关系。

在本申请一些实施例中，所述对所述待编码字符串进行编码，得到编码字符串和所述编码字符串与原文的映射关系，包括：

采用循环冗余码校验编码方式，对所述待编码字符串进行编码，得到编码字符串，以及所述编码字符串与原文的映射关系。

在本申请一些实施例中，所述将所述压缩数据、所述编码字符串以及所述映射关系上传至数据收集设备，包括：

对于各次远程调用过程，基于所述编码字符串和所述压缩数据中未进行合并的字符串，形成链路单元；所述链路单元表示存储链路数据的数据结构，用于描述两个服务之间的一次远程调用；

将所述链路单元，所述编码字符串，所述编码字符串与原文的映射关系，以及所述压缩数据中进行合并的字符串，上传至数据收集设备。

在本申请一些实施例中，所述将所述链路单元，所述编码字符串，所述编码字符串与原文的映射关系，以及所述压缩数据中进行合并的字符串，上传至数据收集设备，包括：

基于各次远程调用过程中生成的所述链路单元、所述映射关系以及所述压缩数据中合并的字符串，生成链路数据包；

将所述链路数据包上传至数据收集设备。

本申请第二方面实施例提出了一种数据采集方法，应用于数据采集系统，所述系统包括数据采集设备和数据收集设备的，所述方法包括：

所述数据采集设备执行第一方面所述的数据采集方法；

所述数据收集设备接收所述数据采集设备上传的数据，对上传数据中包括的所述压缩数据进行解压，并基于所述编码字符串与原文的映射关系对所述编码字符串进行还原，以及将解压后的数据和还原后的数据发送至链路数据存储设备。

本申请第三方面实施例提出了一种数据采集装置，包括：

数据获取模块，用于获取应用程序节点远程调用应用程序生成的链路数据；所述链路数据至少包括远程调用过程中请求的服务端接口名称、应用程序节点的用户许可标识、调用的应用程序的标识以及涉及的标签信息；

数据压缩模块，用于基于预设算法对所述服务端接口名称进行压缩，得到压缩数据；

数据编码模块，用于对所述用户许可标识、所述应用程序的标识以及所述标签信息分别进行编码，得到编码字符串和所述编码字符串与原文的映射关系；

数据上传模块，用于将所述压缩数据、所述编码字符串以及所述编码字符串与原文的映射关系上传至数据收集设备。

本申请第四方面实施例提出了一种数据采集系统，包括数据采集设备和数据收集设备的数据采集系统；

所述数据采集设备用于执行第一方面所述的数据采集方法；

所述数据收集设备用于基于所述预设算法对所述压缩数据进行解压，并基于所述编码字符串与原文的映射关系对所述编码字符串进行还原，以及将解压后的数据和还原后的数据发送至链路数据存储设备。

本申请第五方面的实施例提供了一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序以实现上述第一方面或第二方面所述的方法。

本申请第六方面的实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行实现上述第一方面或第二方面所述的方法。

本申请实施例中提供的技术方案，至少具有如下技术效果或优点：

在本申请实施例中，先获取应用程序节点远程调用应用程序生成的链路数据；然后对链路数据中的服务端接口名称进行压缩，得到压缩数据；对链路数据中的用户许可标识、应用程序的标识及标签信息进行编码，得到编码字符串和编码字符串与原文的映射关系；将压缩数据、编码字符串以及映射关系上传至数据收集设备。如此，在采集链路数据时，分别对链路数据中各次远程调用都可能不同的服务端接口名称进行压缩，还对链路数据中各次远程调用通常不会变化的用户许可标识、应用程序的标识及标签信息进行编码，然后将压缩和编码后的数据进行上报，可以在数据完整性的基础上，有效降低数据的传输量，减小链路数据传输过程中的通信开销和性能开销。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变的明显，或通过本申请的实践了解到。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本申请实施例中包括数据采集设备及系统的可观测系统示意图；

图2示出了本申请一实施例所提供的数据采集方法的流程示意图；

图3示出了本申请一实施例中步骤S2的具体流程示意图；

图4示出了本申请一实施例中步骤S22的具体流程示意图；

图5示出了本申请实施例中Span1、Span2和Span3的服务端接口名称形成的前缀树示意图；

图6示出了本申请一实施例中在步骤S4的具体流程示意图；

图7示出了本申请一实施例中在提供的链路数据包的结构示意图；

图8示出了本申请一实施例所提供的一种数据采集装置的架构示意图；

图9示出了本申请一实施例所提供的一种电子设备的结构示意图；

图10示出了本申请一实施例所提供的一种存储介质的示意图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施方式。虽然附图中显示了本申请的示例性实施方式，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

需要注意的是，除非另有说明，本申请使用的技术术语或者科学术语应当为本申请所属领域技术人员所理解的通常意义。

目前，在可观测领域中，大多通过采样的方式来降低需要上报的链路数据的数量，如此，不能获取系统的全部链路数据，可能会使系统的可观测性大大降低。但其实也可以从链路数据本身入手，通过一些编码压缩算法减少链路数据本身的大小，从而减少链路数据的通信开销。

基于上述考虑，本申请实施例提供了一种数据采集方法，该方法包括：获取应用程序节点远程调用应用程序生成的链路数据；对链路数据中的服务端接口名称进行压缩，得到压缩数据；对链路数据中的用户许可标识、应用程序的标识及标签信息进行编码，得到编码字符串和编码字符串与原文的映射关系；将压缩数据、编码字符串以及映射关系上传至数据收集设备。如此，在采集链路数据时，分别对链路数据中各次远程调用都可能不同的服务端接口名称进行压缩，还对链路数据中各次远程调用通常不会变化的用户许可标识、应用程序的标识及标签信息进行编码，然后将压缩和编码后的数据进行上报，可以在数据完整性的基础上，有效降低数据的传输量，减小链路数据传输过程中的通信开销和性能开销。

其中，链路数据，也可以称为追踪数据，可理解为远程调用应用程序过程中生成的数据，用于描述外部请求在分布式系统中的调用轨迹，对调用请求在系统中的流转路径进行追踪和记录，通过这些数据，开发人员便能够深入了解请求在系统中的处理过程和性能瓶颈。具体地，链路数据包括但不限于请求的调用链路、跨服务的调用关系等，以TraceId为唯一标志，各条链路数据均是由包含同一TraceId的多个链路单元(Span)组成的有向无环图。在分布式系统中，一个请求通常会在多个服务之间进行远程调用，各个远程调用均可看作一个"链路"，表示请求从一个服务到另一个服务的传递，链路单元可看做存储链路数据的数据结构，用于描述分布式系统中两个服务之间的一次远程调用。Span以SpanId为唯一标志，包含ServiceName(服务端接口名称)，StartTime(开始时间)，EndTime(结束时间)，TraceId和parentSpanId(关联Span的引用)及一些标签数据等。

Span中的服务端接口名称用于描述一次远程调用过程中，请求的服务端的接口名称。Span中的标签数据用于对Span进行更详细的描述和注释，可记录与Span相关的元数据、服务信息、环境信息，以及其它根据服务需求进行自定义的任何信息等。元数据例如请求的URL(Uniform Resource Locator，统一资源定位符)、HTTP(Hyper Text TransferProtocol，超文本传输协议)方法、数据库查询语句、RPC(Remote Procedure Call，远程调用)协议等。服务信息例如订单号、用户标识、产品名称等。环境信息例如主机名、IP(Internet Protocol)地址、端口号、运行环境(例如生产环境、测试环境等)。

该数据采集方法的执行主体可以为分布式系统或微服务架构中部署在应用程序节点上的组件，可称为应用探针(Agent)，或数据采集装置，也可以为安装该组件的数据采集设备，例如图1中所示可观测系统中的应用程序节点，可以拦截服务调用，生成Span数据，并上报至数据收集设备，数据收集设备可以对接收到的压缩数据和编码数据进行解压和解码，还原出原文数据，并将量原文数据发送至链路数据的存储设备(可以是单台设备，也可以是集群)，以对该链路数据进行存储。之后，控制台可基于标签对可观测数据进行查询，具体可以根据ServiceName从Trace存储设备中查询Trace数据，也可根据标签原文查询Trace数据。具体地，上述应用程序节点可以部署在云网络的分布式系统或微服务架构中，也可以部署在本地的分布式物理服务器或集群中；同样地，数据收集设备可以部署在云网络的分布式系统或微服务架构中，也可以部署在本地的分布式物理服务器或集群中，本实施例对此不做具体限定，只要能应用本实施例提供的数据采集方法，对链路数据进行采集即可。

下面结合附图对本申请实施例提供的数据采集方法进行详细阐述。

实施例1

请参见图2，为本申请实施例提供的数据采集方法的流程示意图，如图2所示，该数据采集方法可以包括以下步骤：

步骤S1，获取应用程序节点远程调用应用程序生成的链路数据。

其中，链路数据至少包括远程调用过程中，应用程序节点请求的服务端接口名称、应用程序节点的用户许可标识、调用的应用程序的标识以及涉及的标签信息等。应用程序节点的用户许可标识用于规定用户对调用的应用程序的使用权限和限制，通常由应用程序的供应商提供，包含用户在使用应用程序时的授权信息，例如使用期限、访问权限、用户数限制等。应用程序的标识，也称为应用ID(Application ID)，是一种用于唯一标识一个应用程序的标识符。在应用程序开发过程中，应用ID可以由开发人员或系统管理员分配，并用于区分不同的应用程序。应用ID可以是一个数字、字符串或其他形式的标识符，用于在系统中唯一标识一个应用程序。应用ID在应用程序的开发中通常用于识别和管理应用程序，例如在系统配置、日志记录、错误跟踪等方面都可以使用应用ID来标识不同的应用程序。

在实际应用中，可能会有成千上万甚至更多个应用程序节点，也需要成千上万甚至更多个应用探针(可称为Agent端)去拦截远程调用服务，生成链路数据，并对该链路数据进行压缩和编码，然后将压缩和编码后的数据上报至数据收集设备，数据收集设备可以将接收到的压缩和编码后数据进行还原，并将还原后的原文发送至链路数据存储设备。数据收集设备与链路数据存储设备之间进行数据传输属于内部传输，可以采用较大的传输带宽传输原文数据，产生的通信开销较小。

步骤S2，对服务端接口名称进行压缩，得到压缩数据。

在实际应用中，由于远程调用的链路通常涉及多个服务，所以请求的服务端接口名称也有多个，致使服务端接口名称会比较长，对服务端接口名称进行传输时会产生较大的通信开销。且各次远程调用中服务端接口名称往往不同，通过编码的方式对服务端接口名称进行压缩往往达不到较为理想的压缩效果。故，本实施例对服务端接口名称进行一定的压缩，可以将得到的压缩数据进行上报，数据收集设备可预设相同的解压方式，对上报的压缩数据进行解压，从而有效降低服务端接口名称产生的通信开销。

在一些实施例中，如图3所示，上述步骤S2可以包括以下步骤：步骤S21，从链路数据中获取各次远程调用过程中，应用程序节点请求的服务端接口名称；步骤S22，对各服务端接口名称中相同的字符进行合并，基于进行合并的相同字符和未进行合并的不同字符得到压缩数据。

在本实施例中，链路数据中可以包含多个远程调用产生的数据，各次远程调用的服务端接口名称可能相同，也可能不同，可以先获取各次远程调用过程中，应用程序节点请求的服务端接口名称，然后对获取的服务端接口名称进行整理统计，确定各服务端接口名称中，相同的字符和不同的字符，然后对相同的字符进行合并，并基于进行合并的相同字符和未进行合并的不同字符得到压缩数据，如此，应用程序节点将链路数据上报至数据收集设备时，可仅上报压缩后的数据，从而可以有效降低链路数据传输过程中，服务端接口名称产生的通信开销。

例如，Span1中的ServiceName1为/test/abc，Span2中的ServiceName2为/test/abe以及Span3中的ServiceName3为/test/cdf。则三个服务端接口名称中相同的字符为/test/，不同的字符为“abc”、“abe”以及“cdf”，而Span1和Span2中相同的字符为/test/ab，不同的字符为“c”和“e”。则对于包括Span1、Span2和Span3的链路数据，压缩后的数据中服务端接口名称可以包括/test/ab，c，e，/test/cdr，相较于/test/abc，/test/abe和/test/cdf，可以明显降低数据传输量，减小通信开销。

进一步地，如图4所示，上述步骤S22可以包括以下步骤：步骤S221，确定所有服务端接口名称构成的树形数据结构，以及各服务端接口名称对应的前缀树父节点和前缀树叶子节点；步骤S222，对服务端接口名称中相同的前缀树父节点进行合并，基于合并后各前缀树父节点和各服务端接口名称的前缀树叶子节点，得到压缩数据。

其中，树形数据结构是一种非线性的数据结构，树的节点表示树中的数据元素。本实施例中具体可获取基于不同字符串的公共前缀构造的树形数据结构(简称前缀树)，以能够更大限度的减少字符串的存储空间。

在本实施例中，例如上述的Span1、Span2和Span3，可构成如图5所示的前缀树。则Agent端先对本次采集的Span数组中所有Span的ServiceName生成前缀树，且该前缀树的各个节点中，均持有对父节点的引用。然后在各个Span中存储该Span的ServiceName对应的前缀树叶子节点，即图5中的“c”、“e”及“f”。并将该前缀树以及包括多个Span的Span数组，均存储于本次上报的链路数据包中。具体地，对于上述的Span1、Span2和Span3，在Span1中存储叶子节点c，在Span2中存储叶子节点e，在Span3中存储叶子节点f。由此可得，在此场景下，ServiceName的压缩效率为：

其中，length(T)表示当前Span1、Span2和Span3的压缩后数据长度，等于10个前缀树父节点(/test/+ab+cd)，加上3个前缀树叶子节点(“c”、“e”及“f”)，即10+3；length(ServiceName)表示压缩前各ServiceName的长度，即/test/abc、/test/abe和/test/cdf，三个ServiceName的长度均为9。

可以理解的是，上述基于前缀树算法对服务端接口名称进行压缩的方式，只是本实施例的一种压缩方式，本实施例并不以此为限，只要能够对服务端接口名称进行压缩即可，例如也可以采用字典压缩算法：通过构建一个字典或词典，将重复出现的数据片段替换为对应的字典索引，从而实现数据的压缩。或者滑动窗口算法，通过滑动窗口算法将数据分割成固定大小的窗口，并对每个窗口内的数据进行压缩，如果窗口内的数据重复出现，只需要存储一次，并在后续的窗口中使用引用或索引来表示，从而减小数据的存储空间。滑动窗口算法常常应用于压缩网络传输中的数据。

步骤S3，对用户许可标识、应用程序的标识以及标签信息分别进行编码，得到编码字符串和编码字符串与原文的映射关系。

本实施例在对服务端接口名称压缩的情况下，还对链路数据中的用户许可标识、应用程序的标识，及标签信息分别进行编码，以进一步降低链路数据的数据量，减小链路数据传输过程中的通信开销。且由于用户许可标识、应用程序的标识，及标签信息往往是固定信息，各次远程调用过程中，同一用户的用户许可标识，以及相同应用程序的标识均不会变化，故可以采用编码的方式，将一条链路数据中的用户许可标识、应用程序的标识，及标签信息生成一个字符串，并将该字符串与链路数据中的用户许可标识、应用程序的标识，及标签信息的映射关系上传至数据收集设备，数据收集设备便可基于接收到的映射关系和编码字符串还原出链路数据中的用户许可标识、应用程序的标识。

在一些实施例中，上述步骤S3可以包括以下处理：对用户许可标识、应用程序的标识，及标签信息按照预设顺序进行排列，形成待编码字符串；对待编码字符串进行编码，得到编码字符串和编码字符串与原文的映射关系。

其中，预设顺序可以是用户许可标识、应用程序的标识，及标签信息的任意组合顺序，本实施例对此不做具体限定，只要能将三者的字符串联在一起，排列成一个长的字符串，形成待编码字符串即可。

在实际应用中，可将排列好的待编码字符串进行编码，并保存编码时采用的待编码字符串与编码字符串的映射关系，且在一次远程调用过程中，对所有Span中的待编码字符串均采用相同的映射关系，如此，在上传链路数据时，可以将采用的映射关系和编码字符串上传至数据收集设备，由于所有Span均采用相同的映射关系，则仅需上传一个映射关系和各Span中的编码字符串即可，从而可以大幅度降低上述的数据量，进一步减小传输链路数据的通信开销。

具体地，上述对待编码字符串进行编码，得到编码字符串和编码字符串与原文的映射关系的步骤，可以包括以下处理：可以但不限于采用循环冗余码校验编码方式，对待编码字符串进行编码，得到8字节的编码字符串，以及编码字符串与原文的映射关系。

其中，循环冗余码校验(Cyclic Redundancy Check,CRC)编码，是指通过对数据进行多项式计算，生成一段固定长度的冗余校验码，并基于该冗余校验码生成编码串。其中，固定长度通常为8字节，故可以明显降低原始数据的数据量。

本实施例中，在生成冗余校验码之后，可以将生成的冗余校验码转化为16进制的编码字符串，即该编字符码串为固定8字节的字符串，可以将该编码字符串，以及该编码字符串与原文的映射关系存储于本次上报的链路数据包中，并将编码字符串存储于对应的Span中。

可以理解的是，上述采用的循环冗余码校验编码方式，只是本实施例的一种编码方式，本实施例对具体的编码方式不做具体限定，只要能对上述取值与Span无关，仅与Agent端相关的公共字段，即待编码字符串，进行编码即可，例如也可以采用MD5(Message-Digest Algorithm 5，信息摘要算法5)编码方式对待编码字符串进行编码。

步骤S4，将压缩数据，编码字符串，以及映射关系上传至数据收集设备。

在一些实施例中，如图6所示，上述步骤S4可以包括以下步骤：步骤S41，对于各次远程调用过程，基于编码字符串和压缩数据中未进行合并的字符串，形成链路单元；步骤S42，将链路单元，编码字符串，映射关系，以及压缩数据中进行合并的字符串，上传至数据收集设备。

在本实施例中，对于各次远程调用过程，可能会形成包括多个链路单元，可以将一条链路数据中具有个体差异性的数据形成链路单元，与没有个体差异性的公共字段共同上传至数据收集设备，从而可以在数据完整性的基础上，降低链路数据的通信开销，以及设备的性能开销。

具体地，上述步骤S42可以包括以下处理：基于各次远程调用过程中生成的链路单元，和编码字符串与原文的映射关系，以及压缩数据中进行合并的字符串，生成链路数据包；将链路数据包上传至数据收集设备。

在本实施例中，对于各次远程调用过程，可能会形成包括多个链路单元，则在形成链路数据包时，一个链路数据包可包括一组编码字符串，该编码数据串与原文的映射关系，压缩数据中进行合并的字符串，以及一组由多个链路单元组成的Span数组，各链路单元均包括压缩数据中未进行合并的字符，如图7中所示。如此，将一条链路数据中具有个体差异性的数据形成链路单元，与没有个体差异性的公共字段(用户许可标识、应用程序的标识以及标签信息的编码字符串，该编码数据串与原文的映射关系)共同形成链路数据包，并将生成的链路数据包整体上传至数据收集设备，从而可以在数据完整性的基础上，采用较大的传输带宽进行链路数据传输，从而进一步地降低链路数据的通信开销，以及设备的性能开销。

可以理解的是，上述步骤S2和步骤S3的顺序，仅限定描述上的顺序，并不对两个步骤的处理顺序进行限定，即，步骤S3也可以优先步骤S2执行，也可以和步骤S2一同执行，本实施例对此不作具体限定。

本实施例提供的数据采集方法，先获取应用程序节点远程调用应用程序生成的链路数据；然后对链路数据中的服务端接口名称进行压缩，得到压缩数据；对链路数据中的用户许可标识、应用程序的标识及标签信息进行编码，得到编码字符串和编码字符串与原文的映射关系；将压缩数据、编码字符串以及映射关系上传至数据收集设备。如此，在采集链路数据时，分别对链路数据中各次远程调用都可能不同的服务端接口名称进行压缩，还对链路数据中各次远程调用通常不会变化的用户许可标识、应用程序的标识及标签信息进行编码，然后将压缩和编码后的数据进行上报，可以在数据完整性的基础上，有效降低数据的传输量，减小链路数据传输过程中的通信开销和性能开销。

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

实施例2

基于上述数据采集方法，本申请的一些实施例还提供了另一种数据采集方法，该方法应用于包括数据采集设备和数据收集设备的数据采集系统，包括以下步骤：

数据采集设备执行上述实施例1中任一实施方式的数据采集方法；

数据收集设备接收数据采集设备上传的数据，对上传数据中包括的压缩数据进行解压，并基于编码字符串与原文的映射关系对编码字符串进行还原，以及将解压后的数据和还原后的数据发送至链路数据存储设备。

可以理解的是，本实施例2基于上述实施例1相同的构思，上述实施例1中任一实施方式均可应用于该实施例2，并达到相同的有益效果，在此不再赘述。

实施例3

本申请的一些实施例还提供了一种数据采集装置，该装置用于执行上述实施例1中任一实施方式中提供的数据采集方法，图8示出了该数据采集装置的一种示意图，如图8所示，该数据采集装置包括：

数据获取模块，用于获取应用程序节点远程调用应用程序生成的链路数据；链路数据至少包括远程调用过程中请求的服务端接口名称、应用程序节点的用户许可标识、调用的应用程序的标识以及涉及的标签信息；

数据压缩模块，用于基于预设算法对服务端接口名称进行压缩，得到压缩数据；

数据编码模块，用于对用户许可标识、应用程序的标识以及标签信息分别进行编码，得到编码字符串和编码字符串与原文的映射关系；

数据上传模块，用于将压缩数据、编码字符串以及编码字符串与原文的映射关系上传至数据收集设备。

可以理解的是，本实施例3提供的数据采集装置与本申请实施例1提供的数据采集方法出于相同的发明构思，至少能够实现数据采集方法相同的有益效果，且数据采集方法实施例的各种实施方式，也同样适用于该数据采集装置的实施例，在此不再赘述。

实施例4

本申请的一些实施例还提供了一种数据采集系统，如图1所示，该数据采集系统包括：数据采集设备和数据收集设备的数据采集系统；

数据采集设备用于执行实施例1中任一实施方式的数据采集方法；

数据收集设备用于基于预设算法对压缩数据进行解压，并基于编码字符串与原文的映射关系对编码字符串进行还原，以及将解压后的数据和还原后的数据发送至链路数据存储设备。

需要说明的是，上述的数据采集系统可以部署在云网络中的分布式系统或微服务架构，也可以部署在本地分布式物理服务器或集群中，本实施例对此不做具体限定，只要能应用本实施例提供的数据采集方法，对链路数据进行采集即可。

可以理解的是，本实施例4提供的数据采集装置与本申请实施例1提供的数据采集方法出于相同的发明构思，至少能够实现数据采集方法相同的有益效果，且数据采集方法实施例的各种实施方式，也同样适用于该数据采集系统的实施例，在此不再赘述。

实施例5

本申请实施方式还提供一种电子设备，以执行上述实施例1提供的数据采集方法。请参考图9，其示出了本申请的一些实施方式所提供的一种电子设备的示意图。如图9所示，电子设备4包括：处理器400，存储器401，总线402和通信接口403，处理器400、通信接口403和存储器401通过总线402连接；存储器401中存储有可在处理器400上运行的计算机程序，处理器400运行计算机程序时执行本申请前述任一实施方式所提供的数据采集方法。

其中，存储器401可能包含高速随机存取存储器(RAM：Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口403(可以是有线或者无线)实现该装置网元与至少一个其他网元之间的通信连接，可以使用互联网、广域网、本地网、城域网等。

总线402可以是ISA总线、PCI总线或EISA总线等。总线可以分为地址总线、数据总线、控制总线等。其中，存储器401用于存储程序，处理器400在接收到执行指令后，执行程序，前述本申请实施例任一实施方式揭示的数据采集方法可以应用于处理器400中，或者由处理器400实现。

处理器400可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器400中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器400可以是通用处理器，包括处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器401，处理器400读取存储器401中的信息，结合其硬件完成上述方法的步骤。

本申请实施例提供的电子设备与本申请实施例1提供的数据采集方法出于相同的发明构思，具有与其采用、运行或实现的方法相同的有益效果。

实施例6

本申请实施方式还提供一种与前述实施1所提供的数据采集方法对应的计算机可读存储介质，请参考图10，其示出的计算机可读存储介质为光盘50，其上存储有计算机程序(即程序产品)，计算机程序在被处理器运行时，会执行前述任意实施方式所提供的数据采集方法。

需要说明的是，计算机可读存储介质的例子还可以包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。

本申请的上述实施例提供的计算机可读存储介质与本申请实施例提供的数据采集方法出于相同的发明构思，具有与其存储的应用程序所采用、运行或实现的方法相同的有益效果。

需要说明的是：

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下示意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

以上，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。