基于监控的异常检测技术

二、基于监控的异常检测技术

1.基于无监督学习算法处理被监视的KPI

---

在这个技术中，中心思想是：利用无监督学习算法来处理在应用程序无故障运行中应用程序服务上监视的KPI，并学习其行为的基线建模，然后在线使用基线模型来检测服务上新监视的KPI是否偏离基线模型，从而表明服务存在某些异常。

Gulenko等人判断异常的检测方法：首先为不同的服务构建不同的基线模型来检测多服务应用程序中的性能异常。在给定时间在服务上监视的KPI被建模为向量，在初始训练阶段使用BIRCH在线聚类算法对监视的KPI对应的向量进行聚类。在训练阶段结束时，得到的聚类的质心和质心半径决定了被监测KPI的向量应归属的基线子空间，如果被检测的KPI的向量不在基线子空间内，则被判断为异常。

LOUD判断异常的检测方法：通过将每个被监视的KPI与相应的服务配对来为整个应用程序训练基线模型。将应用程序离线运行中监视的KPI被传递给IBM ITOA-PI，构建出KPI基线模型和因果关系图。基线模型提供关于KPI随时间变化的平均值和可接受的变化的信息。因果关系图中的每个节点都对应于服务的KPI，边表示KPI之间的因果关系，权重表示源KPI的更改会导致目标KPI的更改的概率。LOUD通过IBM ITOA-PI来检测性能异常，如果监视的KPI值超出基线模型中编码的可接受的变化范围，或者如果因果关系图中表示的因果关系没有得到遵守，则将KPI和相应的服务报告为异常。

MicroRCA、Wu等人对于异常的判断点和上述几人不同，他们更加关注给定的KPI。MicroRCA和Wu等人考虑了应用程序服务的响应时间和资源消耗，他们通过要求多服务应用程序的Kubernetes 部署被检测为具有Istio和Prometheus的服务网格来监控这一点。在每个服务上监视的KPI被建模为一个向量，并且BIRCH算法用于聚类与应用程序正常运行中监视的KPI对应的向量，即假设在这些运行中没有发生异常。获得的聚类确定基线子空间，其中监视KPI的向量应该归属于“正常”。这允许在线处理每个服务的新监视KPI，只需检查对应的向量是否属于任何基线子空间。如果不是，则认为业务存在性能异常。

DLA判断异常的检测方法：DLA关注的是每个应用程序服务的响应时间，同时也考虑了由于最终用户事务的增加或减少而可能出现的波动，它还关注于容器化的多服务应用程序。DLA在用于部署应用程序的虚拟机中安装监控代理。代理通过将每个被监视的响应时间与时间戳和相应的用户事务关联起来，收集每个VM中运行的容器化服务的响应时间，通过收集到的信息判断响应时间是否根据同时发生的用户事务数量而变化。然后使用获得的相关性来检查新监控的响应时间的变化是否对应于由于用户事务增加或减少而导致的预期波动，或者它是否实际上表示影响服务的性能异常。

小结

上述讨论的技术在离线学习步骤中训练应用程序行为的基线模型，然后在应用程序运行时使用训练过的模型检测异常。这些技术是在以下假设下工作的：应用程序运行的条件不会随着时间的推移而改变(例如，没有新的应用程序部署在相同的vm上)，或者在训练阶段监视的内容足以为应用程序建模所有可能的情况。

改进

CloudRanger通过对应用程序前端的历史监测数据的基线模型进行初始的离线训练来完成的，其最终目标是不断调整异常检测系统，以跟踪应用程序及其运行环境的演变。CloudRanger在应用程序的前端服务上实现了持续学习，以学习在当前条件下哪个是它的“预期”响应时间，也就是说，基于监视的响应时间、负载和吞吐量。当应用程序运行时，CloudRanger对监控的KPI应用多项式回归来更新基线模型，以反映应用程序在动态变化的运行时条件下的行为。然后，通过检查应用程序前端的响应时间是否与预期的响应时间有显著差异，即预期的响应时间与监控的响应时间之间的差异是否高于给定的阈值，从而进行在线异常检测。

Hora解决在线异常检测问题的方法：它将体系结构模型与统计分析技术结合起来，以预先确定多服务应用程序中出现的性能异常。Hora利用SLAstic来自动提取多服务应用程序中架构实体的表示，以及组件对另一个组件的依赖程度。通过收集到的这些信息创建贝叶斯网络，建模构成应用程序的服务之间性能异常的可能传播。然后，通过将每个应用程序服务与检测器相关联来实现在线异常检测，检测器监视该服务的给定KPI，并分析所监视的指标，以检测当前监视的KPI是否表示性能异常。
此技术的优势：由于被监控的指标是时间序列数据，探测器利用自回归综合移动平均来确定性能异常是否影响被监控的服务。无论何时在服务上检测到性能异常，Hora都会实施贝叶斯推断来确定异常是否会传播到其他服务。然后，它返回最有可能受到性能异常影响的应用程序服务集。

---

2.基于有监督学习算法处理被监视的KPI

---

ADS能够在容器化的多服务应用程序中检测性能异常，给定它们的k8s部署和用于在其服务中注入故障的模块。ADS为每个容器应用程序服务考虑一组预定义的KPI，即CPU、内存和网络消耗。在训练阶段，应用程序加载了一个工作负载生成器，该生成器由应用程序操作员提供，用于模拟最终用户请求。模拟了应用程序的多次运行，包括在无故障的条件下，以及通过利用故障注入模块在应用程序服务中注入故障。被监控的KPI被标记为与应用程序的“正常”或“异常”运行有关，这样就可以用监督机器学习算法(即，最近邻居，随机森林，朴素贝叶斯，或支持向量机)对其进行处理，以训练分类器，假设同时发生不超过一个异常。经过训练的分类器为应用程序的正常/异常行为提供了基线模型，它用于根据新监视的KPI对经历某些已知性能异常的应用程序服务进行分类。

PreMiSE则是训练一个基线模型，用于检测多服务应用程序中的异常，假设每个服务运行在不同的VM中，被监控的KPI被视为时间序列:在初始的离线学习阶段，PreMiSE训练应用程序服务正常无故障执行的基线建模。基线模型捕获与被监控KPI对应的时间序列数据中的时间关系，以模拟趋势和季节性，并应用Granger因果关系检验来确定两个KPI之间的相关性是否足以预测另一个KPI的演变。PreMiSE还训练了一个签名模型，该模型表示出现故障时应用程序的异常行为。这是通过在运行应用程序服务的虚拟机中注入预定义的故障(例如，数据包丢失/损坏、网络延迟增加、内存泄漏和CPU占用)以及监控KPI的相应变化来实现的。然后，监控的KPI训练分类器，以检测与注入故障对应的异常的发生，其中六分之一支持监督机器学习算法。然后将训练好的基线模型与新监测的KPI进行比较，以进行在线异常检测。一旦检测到异常，就会使用签名模型对检测到异常的应用服务及其故障进行分类。

---

总结

大部分被调查的技术都依赖于处理在目标应用程序的训练运行中收集的数据。其思想是使用在应用程序的训练运行中收集的日志、跟踪或KPI作为基线，以比较新生成的日志或跟踪或新监视的KPI。机器学习是最常用的方法来训练基线模型应用程序的行为:日志,痕迹,或KPI培训期间收集运行的应用程序确实是用来训练基线模型与非监督学习算法,或与监督学习算法,如果这些信息也贴上故障发生或被注入在培训服务运行。经过训练的基线模型通常是定义新监测的KPI不应被视为异常的空间的集群，或者用新监测的KPI、日志或跟踪来检测它们是否表示异常的分类器或深度神经网络。