企业多云时序数据实时监测方案研究与实现

程学林，郑佳卉，蒋烁淼，贝毅君

1(浙江大学 软件学院，杭州 310027) 2(上海驻云信息科技有限公司，上海 200120)

1 引 言

近几年来，企业的IT架构渐渐地从物理服务器迁到由云服务器构成的IaaS(Infrastructure as a Service)云.云计算这种高效的新型资源共享模式，其核心是云服务供应商借助网络向客户提供包含计算、数据存储、网络、软件等计算资源.在大多数企业中，应用程序部署在云服务器上，并选择云资源服务来作为底层的软硬件支撑.

《Flexera 2020年云状态报告》1收集了全球云计算相关调查数据，从企业云策略调查数据中可知几乎所有的受访企业均选用了多云且大多数企业使用混合云策略，但所有参与调查的企业或组织中只有33%使用多云管理工具，而多云管理的基础是多云监测.在快速发展的公共云、私有云和混合云市场中，云资源在运行过程中每时每刻都能产生带有时间维度的时序数据，数据总的体量十分庞大.多云环境下监测的任务是，对采集到的原始海量时序监测数据进行预处理并存储用于实时展示；或使用预处理后的数据来实时分析判断云资源的运行状态(正常/异常)，从而能够及时通知运维人员[1].

当前全球云资源市场生态已基本成型，各大云服务供应商向客户提供有偿的云资源的同时，也向客户提供了内嵌于各自云平台中的监测工具供客户来查看所购买资源的运行状况，然而这些自带的监测与分析服务，基本止步于单云资源运行数据的实时展示，对云资源运行状态的告警也仅仅采用基于固定阈值的简易方式[1].

图1 网络流量Fig.1 Network traffic

在云资源实际运行过程中，这种基于用户主观经验的阈值设定机制脱离了动态变化的现实环境，易产生异常的迟报、漏报或误报.况且许多异常并不是空间(数值)上的异常而是时间维度上的异常，如图 1所示，这是企业某台ECS上网络流量的时间线图，圆点处标明异常发生点，此处网络流量开始持续处于高位，即便设置了阈值也无法判断是否发生了异常.除此之外，监测数据可能会发生概念漂移(Concept Drift)[2]，如图 2所示，CPU使用率的时间线图中两点标注处才是异常发生时刻，但软件的运行导致CPU使用率整体升高，后又因为软件运行结束导致CPU使用率下降，这两种运行状态都是正常模式，在这种情况下模型必须通过连续在线学习[3]适应新的正常模式.

图2 CPU利用率Fig.2 CPU used percent

除了异常检测方面存在缺陷外，内嵌于各云服务提供商提供的云平台之中所造成的数据隔离也是个不小的问题，在当前企业普遍选择多云策略的背景下，IT运维人员需要分别登陆各云平台的管理后台查看资源运行情况或是设置告警规则显然增加了运维成本，无法以企业为单位的视图进行综合分析.

针对上述问题，本文提出了一种基于时序数据的企业多云实时监测方案MCloudMonitor，围绕多云资源运行产生的海量时序数据提供可靠的存储和处理服务，基于在线学习和模式记忆的方式来动态分析时序数据从而进行异常检测，而不是简单根据静态阈值来判断是否产生异常.除此之外，本文基于该方案借助时序数据存储、流处理等关键技术进行实现和测试评估，证明该方案能有效帮助企业运维人员对多云平台资源海量时序数据进行实时、便捷地处理、展示和分析，从而驱动企业做出综合决策，准确发现异常，提升企业的运维效率，降低运维成本.

2 相关工作

2.1 数据采集技术

单一云环境监测只需专注于单一云平台或云资源，不必费心数据的采集和传输，但它以数据汇总成本为代价，自动汇总的能力几乎为零，往往需要用户手动操作；而多云环境正好与之相反，因此在数据采集和传输上需要设计合适的解决方案降低复杂度.许多云平台都有提供特定的接口用于获取该平台资源的监测数据，但主要存在两大问题：

1)平台提供的接口限制了数据的采集范围.

2)每个平台都有不同的接口要求，不仅在实现过程中需要对每个接口进行特殊处理增加系统实现的工作量，还使得监测系统强依赖于云平台、失去云中立性：当增加新的云平台监测需求时，开发者必须修改系统实现.因此会导致系统的适用性和扩展能力较差.

综上所述，单纯通过接口获取多云平台资源运行数据的方式存在一定局限性，数据采集的灵活度较低，相应地提供给用户的自定义采集能力就较差.

本文借助了专用于采集时序数据的采集探针Telegraf2来解决多云平台监测数据获取的问题，大大降低了系统实现的复杂性，提高了可操作性.采集探针运行在各个云平台的被监测端，Telegraf拥有内存占用小的优点，已经集成了很多Input插件，它可以直接从其运行的系统中提取各种指标，它还具有多种Output插件，能够将采集到的数据发送至各种数据相关系统，如InfluxDB和Kafka.

2.2 时序数据存储技术

时间序列数据在现代社会中有着非常重要的作用[4-10]，数据获取与分析的实时程度往往同其背后所蕴含的巨大价值挂钩，并衍生出了存储和处理海量时序数据的需求.

时序数据的数据量大，表示数据源在某个时间点的的某些特征，数据写入的频率极高，已存储的数据几乎不需要更新.上述特征使得时间序列数据处理与常规数据库的数据处理在工作量上存在一定差异.其中最明显的就是数据规模问题.传统的关系型数据库由于存储成本大、维护成本高、写入吞吐低、查询性能差等缺点[11]，无法利用时序数据具有时间这个天然维度的特性进行存储与处理海量的时序数据.在数据分析领域大展身手的数据仓库也因为根本的实现原理上存在问题[12]而无法实时抽取数据用于实时分析.

时间序列数据库(TSDB)应运而生，专用于应对上述行业对时序数据的插入和查询应用场景.这类数据库自带时间戳维度的索引和优化，针对时间维度有专门的存储结构，提高了对时序相关数据的读写分析效率[13].

2https：//www.influxdata.com/time-series-platform/telegraf/

现如今，主流的TSDB有TimescaleDB、OpenTSDB、KairosDB、InfluxDB3等.从刘等人的实验4中可以得出，InfluxDB的性能领先于其他时序数据库，因为它在数据摄取和大多数查询工作负载中的性能都远远好于其他的时序数据库.从杨婕的研究[14]中可以得出，开源的InfluxDB凭借其优势和版本迭代速度，在各种TSDB中脱颖而出，直到现在都是最受关注的时序数据库.

2.3 流处理技术

对于一些时间要求比较高的应用，必须有非常低的延时展示统计结果，随着流式时间序列大数据处理的工作量不断增加，数据处理框架将成为大数据集处理延迟的潜在性能瓶颈.从Wissem等人的调查[15]中，Hadoop和Spark等常用大数据工具在处理数据的实时性方面显得力不从心.当它们在进行离线计算时，数据从获取到分析，时间消耗会高达数小时，甚至几天，高数据延迟是实时系统无法接受的.

为此Nathan Marz提出一套Lambda架构方案[16]来处理不同类型的数据，采用批计算和流计算整合的方式，例如借助Hadoop进行离线批处理，使用Apache Storm进行实时流处理.这种架构由于框架过多，造成分析系统复杂、运维成本高昂等方面的问题，因此Lambda架构还不是最完美的解决方案.

Apache Spark推出了基于Spark的 Spark Streaming.该流式计算框架将流数据切分成微批进行流式数据处理，但由于其依旧基于批处理模式来处理离散化流(Discretized Stream)，因此不算完全意义上的流处理，也不能高效地处理原生数据流.

张利兵研究得出有状态流计算会逐步成为企业数据架构解决方案[17]，而目前从社区来看，能够满足的只有Apache Flink5.它是一个高吞吐、低时延、高性能的分布式流处理计算框架和引擎，通过用于对无界(没有定义数据流的结束)和有界(定义了数据流的开始和结束)数据流进行有状态的计算，对于在流处理的支持上和低延迟上，Flink更胜于Spark Streaming[18].

2.4 异常检测算法

如何实现真正意义上的自动化实时异常检测是实现一个优秀的云资源监测的主要难题，尽早地检测出异常极具价值和意义，但在实践中很难可靠地执行.

洪斌[1]等人提出了几种分别基于统计分析、数据分类、最近邻分析等理论基础的状态监测技术和基于概率分析、方程拟合、机器学习和事件感知等状态预测技术，并给出了它们的假设、思路、应用和性能分析.除此之外，他们还提出云资源状态分析研究发展趋势将往非监督化算法、降低对人工干预的依赖的方向发展.

但他们提及的异常检测算法基本均为静态批式异常检测，与流式异常检测是完全不同的问题，大多数现有的异常检测算法(甚至那些专门为时间序列数据设计的算法)不适用于流式应用.如洪斌等人提到的UBL算法[19]虽然根据时间序列设计、具有无监督、多指标统筹识别的优势，但其模型训练主要还是借助云资源各种工作负载模式的数据离线训练完成，过多的增量更新模型会降低模型的质量，对于云资源进入一个新的工作负载模式需要重新引导SOM[20]，因此不适用于不断变化的流环境，而且检测的指标组合与SOM中的特征向量维度是一一对应的，若改变了组合，则需要重新引导SOM，扩展能力十分有限，灵活性不高，并且随着数据维度增多，该方法的计算量将成倍增长.

还有一些异常检测算法采用部分在线学习的方式，他们需要有一个离线学习的初始化阶段，或是依靠的前瞻之前发现并标记的异常状态来进行预测和判别，在灵活性和时效性上存在缺陷.大多数基于聚类的方法都属于这种算法范畴，如自适应动态K-means[21]、数据流多类学习算法(MIAS)[22]等.

而分层时间记忆网络(Hierarchical Temporal Memeory，HTM)6在创建时空输入流的不变表示方面具有前景，可以通过记忆序列的时空模式的方式同时满足无监督、实时流式分析和在线学习三大要求，可以高效地、鲁棒地分析实时时序数据流，并且对噪声数据具有极高的容忍度[23]，可持续适应检测数据的变化且几乎不需要参数调整.

HTM的核心算法组件[24]如图3所示.

图3 HTM算法核心组件

原始数据通过编码器编码成二进制向量，然后再经HTM的空间池化(Spatial Pooling，SP)算法生成稀疏离散表征(Sparse Distributed Representation，SDR).最后通过HTM的时间记忆(Temporal Memory，TM)获得预测向量.对于给定输入xt，向量a(xt)是一个代表当前输入的稀疏二进制向量，π(xt)表示对a(xt)的预测，即下一个输入xt+1.HTM网络能够持续学习并建模数据流的时空特征，并被证明在预测任务上表现优秀[25].

3 企业多云时序数据实时监测方案

本节根据前两节研究内容中所描述的多云实时监测中存在的问题和关键技术，围绕时序数据的采集、处理、分析、存储等方面，设计了一个企业多云实时监测方案MCloudMonitor.

3.1 MCloudMonitor总体架构

MCloudMonitor主要分为数据支持子系统和业务支持子系统，其架构如图4所示.

图4 MCloudMonitor架构图Fig.4 Architecture diagram of MCloudMonitor

其中数据支持子系统主要划分为采集、传输、处理、存储、展示5大层，这5层在系统中的主要作用分别是：

3https：//www.influxdata.com/products/influxdb-overview

4http：//arxiv.org/abs/1901.08304

5https：//flink.apache.org/

6https：//numenta.com/neuroscience-research/research-publications/papers/hierarchical-temporal-memory-white-paper/

1)数据采集层：该层主要作用是在各云平台的资源中实时采集各类的Metrics，如CPU使用信息、Mem使用信息、Swap使用信息、Disk使用信息、Net使用信息等.

2)数据传输层：该层主要作用是借助消息队列传输采集到的监测数据，并起到数据缓冲的作用，防止因数据传输量太大或数据流阻塞而造成数据的丢失.

3)数据处理层：由于监测数据(数据源)是实时采集、源源不断的，因此对数据的处理是流式的而不是批式的，需要借助Flink流处理框架进行在线处理.该层主要作用是对采集到的原始时序数据进行一些必要的流计算预处理，将加工处理后的数据存入存储层作为数据展示层的数据源.若为该数据的对象设置了告警，将该数据异步发送至异常检测模块.异常检测模块在做数据分析时需要考虑到数据乱序的情况，具备乱序处理能力，并通过异常检测算法判断云资源是否处于异常状态，若处于异常状态，则将相关信息发送至告警模块.告警模块生成告警记录存入存储层，并异步调用消息通知服务向联系人发送通知.

4)数据存储层：该层的主要作用是使用InfluxDB时序数据库存储所有的时序数据，包括监测数据和告警记录，为后面的数据可视化提供数据源.除此之外，关系型数据存储至MySQL关系型数据库中.为了保证系统低延迟的特性，使用Redis作为内存数据库存储一些临时数据和热点数据的缓存，减少从MySQL读取数据的时间开销.

5)数据展示层：该层嵌入Web前端之中，主要作用是将时序数据通过可视化图表展示出来，通过图表用户可以直观地知道运行在不同云平台的云资源运行状态.

业务支持子系统主要包括用户管理、工作空间管理和辅助服务.

3.2 数据支持子系统设计与实现

3.2.1 数据采集

首先在每个平台需要采集的云服务器中安装采集探针，它可以采集服务器运行的基本信息和其上的运行的软件的信息，MCloudMonitor当前主要采集的是服务器运行的数据指标，采集探针配置如图 5所示.

图5 Telegraf配置

通常来说，从采集工具采集的监控数据量会很大，因此需要考虑到数据量的大小以及未来的数据量变化造成的峰谷状态，而Kafka无论从性能吞吐量，还是在可靠性和运维方面来讲，对于监测系统来说是最佳的选择.Kafka中Topic格式为“采集方式-数据领域”，本方案中用于传输Telegraf探针采集多云数据的Topic为telegraf-multicloud，将来增加其他的采集方式和数据领域可以增加新的Topic.同一个采集器始终将数据发往同一个Broker中，同一host写入到Topic的同一分片中，由输出插件kafka配置中routing_tag一项来保证.

3.2.2 数据预处理

借助流计算来完成时序数据的预处理，其所在的流式计算视为主流，主流中对于原始数据的加工处理和派发流程如图6所示.

图6 预处理流程图

需要先将从Kafka中接收到的各类指标数据转换成各类Measurement对象，并计算派生属性的值.接着通过流计算解析时序数据中的标签从而获得被监测的对象信息以及其所拥有的指标列表并存入关系型数据库中.这些采集对象信息将存入数据库中，但同步存储至关系型数据库时间开销较大，因此通过消息队列解耦，异步将数据存入关系型数据库中.

为了保证子模块的单一职责，将对象是否设置了告警规则交由异常检测子模块(辅流)来判断，加速主流计算的其他处理流程，主流计算只需要派发各类指标对象至异常检测子模块，该过程也使用消息队列解耦来实现异步通信.

最后主流计算无需等待辅流的完成信号即可将Measurement对象存入时序数据库的指标库中.

3.2.3 异常检测

异常检测子模块同样借助流计算框架来完成，检测流程如图7所示.

图7 异常检测流程图Fig.7 Flow chart of anomaly detection

其中检测对象状态步骤分为基本检测和高级检测.基本检测即普通的阈值检测.高级检测使用了在线学习的模型训练方法，根据线上数据的变化，实时调整模型，并对设置了告警的对象检测其当前运行状态是否异常或即将产生异常(所选用的算法能识别出资源即将产生异常的数据流变化，其方式与判断当前异常的方式一致，本质都是根据数据流偏差来做出判断).由于在线学习使得模型能够反映线上数据的变化，从而提高检测的准确率.

上述内容中高级检测所使用的算法是基于分层时间记忆(HTM)网络来设计的，对于连续的输入流，在每一个时间点t，检测器需要识别云资源状态.然而HTM本身能做的不是异常识别，而是预测下一个流模式，即正常情况下应该出现的状态，并不能直接给出异常判断结果.因此对于HTM预测的结果设计了如图8所示两个附加处理步骤.

图8 异常检测算法主要步骤Fig.8 Main steps of anomaly detection algorithm

首先从两个稀疏向量计算原始异常分数，再得出异常似然值，以此确定系统是否异常.下面详细介绍这两个步骤:

1)计算原始异常分数

该分数用来衡量当前时刻HTM网络接收到的实际流模式相对预测流模式的差异，通过矢量的投影来计算.在t时刻，原始异常分数的计算公式见公式(1).

(1)

若实际流模式与预测流模式完全一致，St=0；若两个矢量正交，即完全不相似，则St=1；或根据两者的相似程度介于0～1之间.由于HTM的持续学习特性，对云资源的行为变更也能进行较好的处理.当云资源行为变化时，异常分数在变化时刻将很高，伴随着模型适应并稳定，异常分数会自行降至0.

2)计算异常似然

原始异常分数用来衡量当前输入可预测性，可预测性的变化通常是异常行为的标志，但由于云资源运行数据出现随机跳跃或尖峰的情况并不少见，因此将异常分数直接阈值化会导致许多假阳性，产生误报.

为了处理这类问题，引入第2步计算异常似然.不通过对原始异常分数限定阈值的方式来判断数据流是否异常，而是通过建模异常分数的分布来衡量当前状态异常的可能性.因此，异常似然是基于不断变化的数据流整体来定义资源当前状态异常程度的度量.

具体做法是在原始异常分数之上使用尺寸大小为W的滑动窗口来建模正态分布，样本均值和方差随着窗口的滑动不断更新，见公式(2)和公式(3).Flink提供了滑动窗口机制来连续计算样本均值和方差.

(2)

(3)

接着计算异常分数的短期平均值替代当前异常分数起到滤波的作用，再利用高斯尾部概率[26]阈值化来判断是否将云资源当前状态数据定义为一个异常，见公式(4)～公式(6).其中W′是用来短期平均值的窗口，W′远小于W.

(4)

(5)

Anomaly≡Lt≥1-ε

(6)

在无噪声的场景中，异常分数样本集中分布在0附近，异常似然对异常分数的值较为敏感.在有噪声的场景下异常分数方差较大且均值偏移，分布较为分散，并且通过滤波降低异常似然的敏感度，使得异常分数持续峰值才会导致异常似然的增大，因此对噪声具有很强的容忍性.

基于Flink框架实现的异常检测模块如图9所示.首先以Measurement和Tags为key，通过keyBy算子将DataStream分流成KeyedStream，并借助Flink的KeyedProcessFunction来自定义异常检测函数.其中高级检测是根据算法设计的内容，借助Flink提供的基于滑动窗口的流处理聚合计算和Watermark乱序处理机制来实现，并封装成接口供异常检测模块调用，通过Flink来运行多个网络.由于Flink是有状态的流计算框架，因此可以借助Flink的Keyed State来存放每个Field对应网络实例和异常分数分布实例的引用.

图9 基于Flink框架实现的异常检测模块Fig.9 Anomaly detection module based on Flink

4 测试与评估

4.1 异常检测算法评估

The Numenta Anomaly Benchmark(NAB)是专门为流实时应用而设计的用来评估异常检测算法的Benchmark，包含了许多带有异常标签的真实和模拟的时序数据文件，从服务器指标到工业机器上的传感器再到社交媒体聊天数据，涉及算法将应对的场景：空间和时间维度的混合异常、纯净和有噪声的数据类型以及随时间变化的数据流.本文选用NAB的AmazonCloudwatch提供的AWS服务器指标数据集进行算法测试，包括CPU利用率，网络流入字节数，磁盘读字节数，测试结果如表1所示，其中每个数据集的前15%部分的数据用于模型的初始自动校准.

表1 NAB数据集测试结果

由于HTM能够根据数据流的偏差预见异常的发生，因此在测试数据的每个异常点前都设置一个预见窗口，只要算法检测出的异常点落在该窗口内，该窗口中实际的异常点都标记为检测成功.但若预见窗口太小，会将检测结果视为误报，若窗口太大，会将误报视为正确结果，因此权衡两者关系，将预见窗口的长度定为数据总长度的1%.

本文在该数据集上还运行了另外两种开源的无监督实时异常检测算法的检测器作为对比实验，分别为Twitter的ADVec7和随机切割森林(Random Cut Forest)[27]，但这两种算法都不能预测异常的发生，因此不设置预见窗口.得出的结果如表2所示.

表2 不同检测算法的评价指标

从结果中可知，在处理流数据上(即O(N)规模的数据)，Twitter ADVec的处理时间最短，随机切割森林的处理时间最长，两种算法的检测器检测效果均不如本文的异常检测算法.因此综合考虑，本文的异常检测算法表现较优.

表3 真实数据集测试结果Table 3 Test results of real data set

除了开源数据集外，本文还使用企业的实际云资源运行数据来进行测试.由于数据量较大、产生较快，因此难以手动对运行时产生的数据进行实时标记.但根据观察，实际运行环境中异常出现次数较少，异常时间点相对于总数据量占比较小，可以先收集企业所使用云资源的运行数据并将其可视化，由运维人员来手动筛选并标记异常时间点.最后将该实际运行所得的数据集转为流数据逐个输入检测器中，设置好预见窗口并进行测试，得到如表3所示的测试结果，计算得到各项评价指标如表4所示，可以看出使用实际数据进行测试得到的结果也同样较好.

7https：//blog.twitter.com/engineering/en_us/a/2015/introducing-practical-and-robust-anomaly-detection-in-a-time-series.html

表4 真实数据集测试结果评价指标

检测器随同系统在实际运行中漏报、误报率低且能够实时地、尽早地检测出已知和未知的异常，但在检测起步阶段由于数据量不足且HTM网络通过在线学习处于频繁更新模型阶段，检测器会频繁将云资源运行状态误判为异常，解决方法是通过告警规则设置的沉默时间使得用户免于在HTM自动校准阶段受到“告警轰炸”.

4.2 功能测试

对基于上述方案实现的系统进行完整功能测试并且测试用例均通过，下面给出部分关键功能的实现效果.

使用者在安装配置完采集器后，可以在对象一栏查看采集到的各个云平台的被监测对象的信息，如图10所示.

图10 被监测对象的信息Fig.10 Information of monitored objects

使用者可以自定义场景，并配置图表数据源读取时序数据库中的时序指标数据来满足不同的运维业务视角，如图11所示的多云平台综合场景.

图11 多云资源视图场景Fig.11 View of multi-cloud resources status

使用者可以至异常检测库中配置告警规则组，还可对告警规则组进行告警通知配置，配置完成后可前往系统的事件界面查看告警历史记录，如图12所示，每条包含发生时间、来源、状态、检测库名称、异常内容.

4.3 压力测试

对实现的系统进行的压力测试分为两部分：

1)云服务器指标数据测试：通过采集探针采集服务器数据(cpu，mem，disk，network，system等)，以该数据为样本(333个数据点，137条时间线).

2)最大承载量测试：通过MockData，生成500个数据点，每个点包含5个tag，5个field(500个数据点，227条时间线).

图12 告警记录Fig.12 Alarm records

测试工具为5.3版本的Jmeter，测试环境为本系统的预发环境，系统实例在4核8G单节点部署，InfluxDB实例也在4核8G单节点部署.

表5 压力测试结果

每轮测试新建工作空间，通过设置不同线程数，每次将数据写入新工作空间来观察系统的性能.测试结果如表5所示.从测试结果可知系统在该预发环境部署下吞吐量均在200/sec左右，且很少出现Error，系统的表现比较稳定.

5 总 结

本文提出了一种企业多云时序数据实时监测方案MCloudMonitor，围绕多云资源运行产生的海量时序数据提供时序数据存储和实时流处理服务，基于分层时间记忆网络来设计实时在线异常检测算法并将其整合进所实现的系统之中.除此之外，本文通过测试来评估和调整该方案的实现效果，使得该系统能够帮助运维人员从企业的视角进行便捷的多云监测，并在实时监测云资源运行状态的基础上，通过告警机制缩短异常处理响应时间，提升企业的运维效率.

基本的多云实时监测架构已经完成，但本文的实现成果仍存在不足和值得提升之处，如增加PaaS层的监测以及异常的联合分析，需要后续的不断研究、迭代和改进.