RARE：云原生内存异常标注数据集

1 引言

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

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

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

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

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

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

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

据我们所知，已有两个其他数据集被用于云原生系统异常分析：Yahoo 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	206	java_lang_runtime_starttime
jmx	3	jmx_config_reload_failure_total
kafka	187	kafka_exporter_build_info
kube	62	kube 节点 created _ _
Kubernetes	1	Kubernetes 构建信息 _ _
node	155	节点 arp 条目
prometheus	130	prometheus 引擎 查询
其他	11	工作队列 添加 总数 get_token_count

特别是，我们将容器中可用内存低于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_| 代理topic内存_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个条目，每个条目由以下变量描述：

• 时间 ：每个数据点的时间戳，每秒记录一次，以纪元时间表示。
• 异常 ：一个标签（布尔值），指示数据点是否为异常。
• 实例 具有四个不同的值：（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的公司广泛采用，消息被组织为主题，因此使用关键词有助于将属于同一类别的消息进行 grouping。对我们而言，最重要的特性是它具有容错性，并能产生实时流消息[8]。

4 数据收集与准备

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

4.1 被监控的系统

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

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

第二步，我们通过Zookeeper（一种用于分布式系统协调的开源软件 [17]）来设置Kafka。随后，安装并使用自定义配置文件对Prometheus及其告警管理器进行了配置。后者运行后，可通过其图形用户界面（GUI）从网页浏览器访问以检查 Prometheus的状态。Kafka的实现生成了一个包含3个Kafka broker Pod的“有状态集”以及一个包含3个Zookeeper Pod的 “有状态集”。为了允许集群内外的其他应用访问Kafka broker，我们使用NodePort创建了一个将Kafka端点暴露到静态端口的服务。这意味着可以轻松创建Kafka生产者和消费者并连接到broker。该图表还提供了配置Prometheus收集指标的选项，在本例中我们导出了JMX指标以及其他由Kafka提供的指标。

Prometheus通过使用并编辑来自[16]的一些清单进行部署。它被定义为1个副本的部署，并像Kafka一样通过NodePort暴露服务。通过这种方式，可使用主节点的IP地址和NodePort提供的外部端口，通过任何浏览器访问Prometheus的图形用户界面。Prometheus告警管理器也采用相同的部署和服务方式进行设置。

此外，还启动了另外两个服务以生成更多指标： Kube-state-metrics [6] 和 Node Exporter [2],，前者负责更新集群状态，后者是硬件信息收集器。集群中的主要元素包括4个部署（Kafka broker、ZooKeeper、Prometheus和 Kube-state-metrics）和1个守护集（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/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：列联矩阵

	预测的真正例	预测的假阴性
实际真正例	122	14
实际假阳性	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]。