RARE：一个用于云原生内存异常的标注数据集

1 引言

与传统的单体式系统相比，云原生系统具有更多的动态组件。这些系统由多个相互连接的服务组成，通常部署在不同的机器上。不同的服务通过网络进行通信，并且存在编排器、负载均衡器、消息总线以及许多在单体式系统中不需要的其他组件，而这些组件都可能出现问题。在这种复杂的系统中，运行时故障不可避免，必须加以控制[4, 12]。

因此，引入异常检测系统至关重要，以维持服务质量并避免因云资源的异常使用而导致意外成本增加[12, 14]。

异常可以被定义为一种罕见事件，即系统行为偏离了标准、正常或预期的状态。此类事件通常与其他数据存在显著差异。例如，某个服务可能使用了异常数量的内存或处理器，导致其他服务无法正常运行。再比如，某些服务消费者可能会停止向代理发送获取请求，这意味着该服务可能已停滞或失效。

不同的研究人员提出了异常检测机制。然而，绝大多数机制都是基于专有数据集或非常通用的数据集[7, 12, 14]此外，内存相关问题是云原生系统中最常见的异常之一[12]而缺乏明确标注内存相关异常发生位置、特别是引发异常的事件何时引入的标注数据集，使得研究人员无法定义准确的预测模型来预防此类异常。

这项工作的目标是提供一个从云原生系统生成的数据集，其中包含一系列标注的内存相关异常，以使研究人员能够应用机器学习模型，并比较其模型的性能。

为此，本文提出了“datasetf oR cloud-nAtive memoRy anomaliEs”（RARE）。RARE 是一个标注数据集，专门为云原生内存相关异常创建。它包含在10K个数据点上收集的7062个指标，以及随机注入的600个内存异常。

RARE数据集将能够对用于内存相关异常检测的机器学习模型进行基准测试。使用通用数据集还将使研究人员能够复现已有工作，并提升用于异常检测阶段的机器学习算法的性能。

据我们所知，已有两个其他数据集被提出用于云原生系统中的异常分析：雅虎 Webscope S5[1]和 Numenta 异常基准测试 [9]。然而，它们均未包含内存相关异常。

(1) Yahoo WebscopeS5是在雅虎网站发生一些近期事件后创建的，这些事件几乎导致其网站崩溃。他们提供了一个包含系统异常（崩溃）的数据集。该数据集由367个时间序列组成，每个时间序列的长度为1500。为了提高数据集的简洁性，已将其分为4个类别，计数分别为： 67/100/100/100。类别 A1由来自计算服务的真实数据组成，而接下来的三个类别（即 A2、 A3、 A4）则由复杂性递增的合成异常数据组成。所有时间序列均提供了真实标签 （GT）。

(2) NumentaAnomalyBenchmark(NAB)是一个用于评估实时异常检测算法的严格基准测试。我们遵循了三个要求来生成该数据集：包含所有可能类型的流式异常、包含多个数据指标，并体现包括噪声在内的常见挑战。该数据集由58个数据文件组成，每个文件包含1000至22000个数据实例。整个数据集已手动标注。然而，该数据集的主要特点是其非常严格的评分函数，该函数对不同类型的错误进行差异化加权。

NAB评分机制的三个核心要点是：异常窗口、其评分函数以及应用场景配置文件。异常窗口是指围绕真实异常（GT anomaly）中心的一段数据点范围，评分函数利用这些窗口来识别真阳性、假阳性和假阴性。应用场景配置文件的评分采用S型函数，对异常的早期检测给予更高的分数，而在这此窗口之外的检测则给予负分。

本文的其余部分结构如下。第2节介绍了RARE数据集，第3节描述了生成该数据集所采用的技术。第4节介绍了我们采用的数据收集方法。第5节提出了一个案例研究，以验证机器学习在该数据集上的适用性。第5节还提出了可能的应用，特别是可能的机器学习方向。第7节最后得出结论并讨论了未来工作。

2 RARE：内存异常数据集

RARE 旨在提出一种从受容器内存不足影响的云原生系统中生成的数据集。我们将内存异常定义为（以下简称为异常），即运行云原生系统的容器中内存使用量增加，可能导致系统性能下降。

表1：按工具分组的数据集中指标列表。

TOOL	编号 指标	指标示例
Java_lang	jmx	java_lang_runtime_starttime
kafka	kube	kafka_exporter_build_info
Kubernetes	node	kube 节点 created _ _ Kubernetes 构建信息 _ _
prometheus	工作队列	节点_arp_条目 Prometheus_引擎_查询 工作队列_adds_total
其他	get_token_计数

特别是，我们将容器中可用内存低于85%的情况视为一种异常。在本节的其余部分，我们将介绍RARE数据集及其结构。用于生成该数据集的系统的详细描述见第4.1节，而所采用技术的描述见第3节。

2.1 数据集

在当前版本的RARE数据集中，我们提供了时间序列数据，其中每一行包含一个时间戳以及7062个指标中每个指标的单个标量值。

RARE数据集的目标是：（i）包含从行业领先工具（如 Prometheus、kafka和Kubernetes）收集的所有类型的指标；（ii）提供带标签的时间序列，以标明异常注入的开始位置以及异常结束的位置。在图1中，可以查看数据集中存在的一个异常示例。

针对特定范围的应用是基于时间序列的数据集中的基本要求。当训练模型以预防和克服特定时间事件时，拥有一个能够真实描述此类事件的数据集至关重要。因此，RARE需要提供一段数据序列，用以表示节点在数据过载之前、期间和之后的状态演变。为此，我们选择使用人工生成的数据，以减少混杂变量的影响，并确保异常是由特定的（人工生成的）事件所引发。若使用真实数据集，则无法准确识别异常的根本原因，更无法确定触发异常的具体事件。

该数据集总共包含942个唯一指标，其摘要如表1所示。大多数指标的值与不同实例相关，因此完整数据集共有7062 个指标。

2.2 数据集结构

这项工作提出的数据集包含两个表格，每个表格分别存储在不同的CSV文件中：异常列表和RARE。

异常列表_包括对注入的_异常的解释。由于该数据集是人工生成的，因此通过脚本注入了过载，这为我们提供了与系统中任何事件开始和结束相关的时间戳的非常准确的标签。表2中展示了数据集中5个异常入口的示例。具体来说，我们可以看到以下字段：

表2：List_of_异常的5个入口示例。

时间戳_从	时间戳_到	异常发生前_
1579033135	1579033155	11
1579033582	1579033602	10
1579033997	1579034017	8
1579034411	1579034431	7
1579034846	1579034866	13

表3：RARE数据集的5个入口示例。

| Time | 异常 | 实例 | load_| brokertopic内存_1_0指标_byt
esinpersec_c
ount_2 | machine
bytes_0 |
| — | — | — | — | — |
| 1579033025 | 0 | 等待 Kafka流 启动 | 0.21 | 207 | 2089807872 |
| 1579033132 | 0 | Kafka运行中 | 1.2 | 276 | 2089807872 |
| 1579033142 | 1 | 正在生成 异常 | 1.47 | 414 | 2089807872 |
| 1579033167 | 0 | 等待 脚本 启动 | 0.97 | 552 | 2089807872 |
| 1579034005 | 1 | 正在生成 | 1.36 | 828 | 2089807872 |

Node Kafka服务器_ 异常

• 时间戳_来自 ：异常注入开始的时间（以 Unix/纪元时间 表示 [5]）
• 时间_到 ：异常注入完成的时间（也以 Unix 时间 [5] 表示）。
• Before_异常 ：kafka 在异常开始前发送消息的秒数。

RARE 是包含实际数据集的文件。它包括10K个条目，每个条目由以下变量描述：

• 时间 ：每个数据点的时间戳，每秒记录一次，以Epoch格式表示。
• 异常 ：一个标签（布尔值），用于指示该数据点是否为异常。
• 实例 具有四个不同的值：(i) 等待脚本启动 ，表示Pod在被销毁后正在创建，此操作通常需要300到350秒；(ii) 等待Kafka流启动 ，表示容器启动到Kafka生产者开始发送字节流之间的时间；(iii)Kafka运行中，表示Kafka生产者正在发送字节但尚未生成异常；(iv)正在生成异常 ，表示异常正在被生成。
• 指标列表 ，每个指标对应一个变量。总共有942个唯一指标（如表1所示），每个Pod和实例创建时均包含这些指标，总计7062个指标。

3 采用的技术

为了生成该数据集，我们使用Kubernetes、Docker、kafka和 Prometheus构建了一个基于微服务的系统。在本节中，我们简要介绍这些技术。

• Docker 允许将应用打包并部署在容器中。每个容器都封装了其作为独立运行系统所需的一切，即使与其他容器隔离，也可以在需要时与其它容器通信。由于其特性，容器通常被误认为是虚拟机，但与后者相比，容器更加轻量，因为一组容器由单一操作系统内核运行。因此，它们无需启动和部署完整的操作系统即可工作。此外，它们仅使用所需的资源，并在无感知的情况下共享这些资源，这就需要通过外部实体来进行此类管理。

• Kubernetes 是一个开源平台，用于在机器集群上运行和管理容器化应用。对于每个应用，Kubernetes 能够管理其整个生命周期，将其转变为一个完整的分布式系统。此类系统完整、可靠且可扩展。该平台之所以能够保证这些特性，是因为它由多个层次构成。该系统的底层是 Pod。Pod 是保证运行在同一主机上的容器，能够共享资源而不会发生冲突。它们的管理可以委托给控制器。一组协同工作的 Pod 被定义为服务，而一个 Pod 包含一组容器，例如 Docker。

• Prometheus 是 Kubernetes 中使用最广泛的监控系统。它是一个开源平台，能够正在生成人类可读的事件日志和指标。Prometheus 服务器会定期抓取目标以生成此类数据。此外，它还具有自动发现功能，可增加目标。生成的数据模型基于键值对，其中没有意外情况与Prometheus中的相同。

• Kafka 是一种基于发布‐订阅架构的可扩展的消息系统。这意味着发布者可以发送记录流，以便消费者接收。在这个已被一些最著名的基于Web的公司广泛采用的系统中，消息被组织为主题，因此使用关键词有助于将属于同一类的消息进行分组。对我们而言，最重要的特性是它支持容错性，并能产生实时流消息[8]。

4 数据收集与准备

在本节中，我们首先介绍所监控的系统以及如何注入内存异常。然后，描述如何从同一系统中收集数据。

4.1 被监控的系统

前述工具已组合起来，用于创建和部署基于微服务的系统、异常生成器系统以及完整的基础设施，包括 Kubernetes、 kafka 和 Prometheus，如图 2 所示。

开发该系统的第一步是在4台不同的虚拟机 (VMs) 上部署 Kubernetes，其中一台作为主节点，另外三台作为工作节点。我们选择了配备2个CPU、2 GB内存并安装Ubuntu操作系统的虚拟机。所有机器均配置在同一网络中。

第二步，我们通过ZooKeeper（一个用于分布式系统协调的开源软件 [17]）来设置kafka。随后，安装并使用自定义配置文件配置了Prometheus及其Alertmanager。后者运行后，可以通过网页浏览器访问其图形用户界面来检查Prometheus的状态。

Kafka的实现创建了一个包含3个kafka代理Pod的“有状态集” 和一个包含3个ZooKeeper Pod的“有状态集”。为了允许集群内外的其他应用访问kafka代理，我们使用NodePort创建了一个将kafka端点暴露到静态端口的服务。这意味着可以轻松创建 kafka生产者和消费者并连接到代理。该图表还提供了配置 Prometheus收集指标的选项，在本例中，我们导出了JMX指标 以及kafka提供的其他指标。Prometheus通过修改和使用来自 [16]的一些清单进行部署。它被定义为一个副本的部署，并像 kafka一样暴露了NodePort。通过这种方式，可以使用主节点的 IP地址和NodePort提供的外部端口，通过任何网页浏览器访问 Prometheus的图形用户界面。Prometheus Alertmanager也 采用相同的部署和服务方式进行了设置。此外，还启动了另外两个服务以生成更多指标：Kube‐state‐metrics [6] 和 Node Exporter [2],，前者负责更新集群状态，后者是硬件信息收集器。

集群中的主要元素包括4个部署（kafka代理、ZooKeeper、 Prometheus和Kube‐state‐metrics）和一个守护集（ NodeExporter）。

1 (API网关)
2 3
生异常生成器
Prometheus ZooKeeper

第三步是部署待监控的系统（图2中的MS1、MS2和 MS3）。然后，在系统正确启动并运行后，我们需要生成异常 （即引发不寻常情况的奇怪或意外状况）。

为了生成异常，我们实现了一个“异常生成器”微服务来引发内存异常。该异常生成器微服务在集群内一个独立的 Kubernetes Pod 中启动，随后连接到 kafka 代理，并发送字节流持续随机数量的秒数，直到该请求超出允许的最大值并导致容器被销毁。这种随机化设计旨在使数据集更接近真实场景，同时保留人工创建异常的优势。异常生成器基于一个脚本，该脚本包含一个无限循环，在与代理建立连接后于后台运行。

有关所实现系统及采用配置的更多详细信息，请参见[13]。

4.2 数据收集和准备

在本节中，我们对上一节中描述的关键点进行简要总结。

• 设置系统：我们首先在由4个节点组成的集群上安装了系统，其中一个作为主节点，其余3个作为工作节点。我们还安装了监控系统（即Prometheus）和kafka。
• 异常生成：我们创建了一个脚本来向系统注入异常。该脚本启动一个Kafka流，随机等待5到15秒的时间，然后产生异常。
• 异常持续时间：异常的持续时间为4到20秒之间的随机值。
• 系统运行时间：我们运行了系统三小时，并设置监控系统每秒收集一次数据。
• 数据导出：数据已以CSV格式导出。
• 数据集上传：最后，我们将生成的数据集上传至 Figshare [11]。

5 基于机器学习的数据集验证方法

在本节中，我们进行了一个案例研究，以了解是否可以将机器学习算法应用于该数据集。

案例研究的目标是了解异常是否依赖于数据集中可用的指标。因此，我们将研究问题（RQ）表述为 RQ1：能否基于数据集中的指标来预测内存异常？

5.1 数据分析

为了回答我们的研究问题，我们采用了一个随机森林[3]二元分类器，使用异常作为因变量（布尔值变量），其余指标作为自变量。

我们使用1,000棵树作为基分类器来拟合分类器。我们决定采用随机森林分类器，因为它相比更简单的模型更不容易发生过拟合，同时在对用于构建模型的数据进行子采样时具有良好的随机性[3]。此外，我们没有选择深度神经网络等更先进的工具，因为这项工作的目标是为机器学习在RARE数据集上的示例应用提供说明。

为了评估随机森林算法的检测准确率，我们进行了10折交叉验证，将数据分为十部分；即我们共训练模型十次，每次使用十分之一的数据作为测试折。每个项目相关的数据被划分为十个连续的部分，从而保持了时间顺序和每个项目的数据比例。

模型在测试集之前的数据组上进行迭代训练。训练集内的各组也遵循时间顺序：例如，在第1折中，我们使用第1组进行训练，第2组进行测试；在第2折中，使用第1组和第2组进行训练，第3组进行测试，以此类推直至完成所有折的验证。

作为准确率指标，我们首先计算了精确率和召回率。然而，如[15]所指出，这两个指标存在一些偏差，因为它们主要关注正例和预测结果，而无法反映错误的类型和发生频率的相关信息。

混淆矩阵（也称为混淆矩阵）及其相关的F值有助于解决此问题。此外，正如Powers [15]所建议的，应考虑使用马修斯相关系数（MCC），以了解实际值与预测值之间可能存在不一致的情况，因为它涵盖了混淆矩阵的所有四个象限。

从列联矩阵中，我们提取了特异性（TNR）指标，用于衡量被正确分类为阴性的负样本所占的百分比；假正率（FPR），用于衡量被错误分类为阳性的负样本所占的百分比；以及假负率（FNR），用于衡量被错误分类为阴性的正样本所占的百分比。真阳性率指标未予列出，因其等同于召回率。这些指标的计算方法见表4。

表4：准确率指标公式

准确率指标	公式
精确率	TP / (TP + FP)
召回率	TP / (TP + FN)
MCC	(TP × TN − FP × FN) / √((FP + TP)(FN + TP)(FP + TN)(FN + TN))
F值	2 × (precision × recall) / (precision + recall)
TNR	TN / (TN + FP)
FPR	FP / (TN + FP)
FNR	FN / (FN + TP)

TP: 真阳性; TN: 真阴性; FP: 假阳性; FN: 假阴性

5.2 结果

将随机森林算法 [3] 应用于数据，揭示了现有指标之间的有趣依赖关系。

特别是，我们可以看到，使用所有变量训练的模型表现非常出色，证实了指标与注入的异常之间的依赖关系。混淆矩阵（表5）以及其他收集的准确率指标（表6）均验证了该模型的准确性。

表5: 混淆矩阵

Actual \ Predicted	True Positive	False Negative
False Positive	122	14
True Negative	6	2361

表6: 准确率指标结果

准确率指标	结果
精确率	95.31%
召回率	89.71%
MCC	92.05%
F值	92.42%
TNR	99.75%
FPR	0.25%
FNR	10.29%

我们意识到，不同角色的指标（例如服务间通信的指标）出现频率可能高于其他指标，并且可能对结果产生不同的影响。此外，我们不排除其他统计或机器学习方法（如深度学习）可能产生与我们的建模方法相似甚至更高的准确率。

此次验证主要旨在验证指标之间的依赖关系，而未考虑其数值的演变。对每个数据点中依赖关系的识别，为进一步的研究提供了可能，并证实了进行时间序列分析的可能性。

6 可能的应用

该数据集将为机器学习和软件工程领域的研究人员开辟不同的研究途径。人们将能够探究各种机器学习方面的内容，例如：

• 识别实时应用以防止异常。由于RARE是一个基于时间的人工数据集，它依赖于特定的时间窗口，这些时间窗口可以帮助训练的机器学习方法学会预测异常，从而在发生之前防止拥塞。
• 定义基于机器学习的方法。事实上，该数据集可用于构建定制的机器学习方法，以应对内存拥塞异常这一特定情况。
• 提出自愈机制以主动预防异常。例如，当实时异常检测算法检测到可能的异常时，可以激活Kubernetes自愈机制以防止内存不足错误。

我们计划将不同的机器学习算法应用于RARE数据集。这些算法包括基于决策树的、集成技术、神经网络以及其他方法。比较将从预测准确率、训练和测试时间以及所需资源方面进行。例如，某种算法可能比另一种算法准确得多，但需要过长的训练或测试时间，或消耗过多资源。

此外，一旦确定了合适的机器学习方法，就可以利用该方法来测试在多长时间内可以预测异常，以及预测所需的必要指标。这可以作为从业者的参考指标，以便他们仅收集和关注特定的一组指标。

7 结论

本文提出了RARE，一个包含1万个数据点和7062个指标的数据集，用于描述人工生成的内存异常。该数据集经过精心准备，旨在提供一个基于时间的真实异常测试环境。文中详细描述了数据集开发过程的各个阶段。此外，为完善描述，还提供了一个测试示例，展示了一个简单的随机森林算法，用于将数据点分类为异常或非异常。

RARE数据集将使研究人员能够对其用于内存相关异常检测的机器学习算法进行基准测试。具体而言，本文介绍了一些可能的应用，旨在激发与基于时间的异常检测相关的新研究问题。

尽管我们认为RARE数据集将被用于机器学习领域的开发和进步，软件工程，我们认识到该数据集可以进一步扩展和改进。为此，未来的工作包括扩展数据集、执行不同类型的系统，以及注入不同类型的异常，包括与CPU相关的异常，以及其他类型的异常，如拒绝服务攻击。最后但同样重要的是，我们计划开展不同的实验，以测试最合适的人工智能方法[10]。