软件系统的工业开发需要高度关注最终产品的容错能力，以及对故障和故障发生时的快速响应。 监控当然有助于更高效、更快速地响应故障和失败，但这还不够。 首先，跟踪大量服务器非常困难——需要大量人员。 其次，您需要充分了解应用程序的工作原理才能预测其状态。 因此，我们需要很多对我们正在开发的系统及其性能和功能有深入了解的人。 我们假设，即使您找到足够多的人愿意这样做，仍然需要花费大量时间来培训他们。
该怎么办？ 这就是人工智能为我们提供帮助的地方。 文章将谈到 （预测性维护）。 这种方法正在积极流行。 人们撰写了大量文章，包括关于哈布雷的文章。 大公司充分利用这种方法来维持其服务器的性能。 在研究了大量文章后，我们决定尝试这种方法。 结果是什么呢？
介绍
开发出来的软件系统迟早会投入运行。 对于用户来说，系统无故障运行非常重要。 如果确实发生紧急情况，应尽快解决。
为了简化软件系统的技术支持，特别是在有许多服务器的情况下，通常使用监控程序来从正在运行的软件系统获取指标，从而可以诊断其状况并帮助确定到底是什么导致了故障。 这个过程称为软件系统监控。
图1. Grafana监控界面
指标是软件系统、其执行环境或系统运行时的物理计算机的各种指标，并带有收到指标时的时间戳。 在静态分析中，这些指标称为时间序列。 为了监控软件系统的状态，指标以图表的形式显示：时间在X轴上，值沿着Y轴（图1）。 可以从正在运行的软件系统（从每个节点）获取数千个指标。 它们形成了度量空间（多维时间序列）。
由于复杂的软件系统需要收集大量的指标，手动监控成为一项艰巨的任务。 为了减少管理员分析的数据量，监控工具包含自动识别可能问题的工具。 例如，您可以将触发器配置为在可用磁盘空间低于指定阈值时触发。 您还可以自动诊断服务器关闭或服务速度严重下降。 在实践中，监控工具可以很好地检测已经发生的故障或识别未来故障的简单症状，但总的来说，预测可能的故障对它们来说仍然是一个难题。 通过手动分析指标进行预测需要合格专家的参与。 这是生产力低下。 大多数潜在的失败可能会被忽视。
最近，所谓的软件系统的预测性维护在大型IT软件开发公司中越来越流行。 这种方法的本质是利用人工智能在早期阶段、在出现故障之前发现导致系统退化的问题。 这种方法并不完全排除对系统的手动监控。 它对整个监控过程有辅助作用。
实施预测性维护的主要工具是搜索时间序列异常的任务，因为 当异常发生时 在数据中，一段时间后很可能 会有失败或者失败。 异常是软件系统性能中的某种偏差，例如识别出一种类型的请求的执行速度的下降或在恒定的客户端会话级别上服务的请求的平均数量的减少。
搜索软件系统异常的任务有其特殊性。 理论上，对于每个软件系统，都需要开发或完善现有方法，因为异常搜索非常依赖于执行搜索的数据，并且软件系统的数据根据实现系统的工具而变化很大，具体到它运行在哪台计算机上。
预测软件系统故障时搜索异常的方法
首先值得一提的是，预测失败的想法是受到文章启发的 。 为了测试自动搜索异常方法的有效性，选择了 Web-Consolidation 软件系统，这是 NPO Krista 公司的项目之一。 此前，是根据收到的指标对其进行手动监控。 由于系统相当复杂，因此需要大量的指标：JVM指标（垃圾收集器负载）、执行代码的操作系统指标（虚拟内存、％操作系统CPU负载）、网络指标（网络负载） ）、服务器本身（CPU 负载、内存）、所有关键子系统的 Wildfly 指标和应用程序自身的指标。
所有指标均来自使用石墨的系统。 最初，whisper 数据库被用作 grafana 的标准解决方案，但随着客户群的增长，Graphite 已经无法应对，耗尽了 DC 磁盘子系统的容量。 此后，决定寻找更有效的解决方案。 做出了有利的选择 ，这使得磁盘子系统的负载减少了一个数量级，占用的磁盘空间减少了五到六倍。 下面是使用石墨+clickhouse收集指标的机制图（图2）。
图 2. 收集指标的方案
该图取自内部文档。 它展示了grafana（我们使用的监控UI）和Graphite之间的通信。 从应用程序中删除指标是由单独的软件完成的 - 。 他把它们放入石墨中。
Web Consolidation 系统的许多功能在预测故障时会产生问题：
- 趋势经常发生变化。 该软件系统有多种版本可供选择。 它们中的每一个都会对系统的软件部分带来变化。 因此，通过这种方式，开发人员可以直接影响给定系统的指标，并可以引起趋势变化；
- 实施功能以及客户使用该系统的目的通常会导致异常情况而没有之前的降级；
- 异常相对于整个数据集的百分比很小（< 5%）；
- 从系统接收指标可能存在差距。 在某些短时间内，监控系统无法获取指标。 例如，如果服务器过载。 这对于训练神经网络至关重要。 需要综合填补空白；
- 异常案例通常仅与特定日期/月份/时间（季节性）相关。 该系统对用户的使用有明确的规定。 因此，这些指标仅与特定时间相关。 该系统不能一直使用，而只能在几个月内使用：根据年份选择性地使用。 出现这样的情况：在一种情况下相同的指标行为可能会导致软件系统故障，但在另一种情况下却不会。
首先分析了软件系统监控数据异常检测方法。 在有关该主题的文章中，当异常百分比相对于数据集的其余部分较小时，最常建议使用神经网络。
使用神经网络数据搜索异常的基本逻辑如图 3 所示：
图 3. 使用神经网络搜索异常
根据当前指标流窗口的预测或恢复结果，计算与从正在运行的软件系统接收到的偏差。 如果从软件系统和神经网络获得的指标之间存在较大差异，我们可以断定当前数据段是异常的。 使用神经网络会出现以下一系列问题：
- 为了在流模式下正常工作，训练神经网络模型的数据必须仅包含“正常”数据；
- 必须有一个最新的模型才能正确检测。 指标中趋势和季节性的变化可能会导致模型出现大量误报。 要更新它，需要明确模型过时的时间。 如果您稍后或较早更新模型，那么很可能会出现大量误报。
我们也不能忘记寻找和防止误报的频繁发生。 据推测，它们最常发生在紧急情况下。 然而，它们也可能是由于训练不足而导致神经网络错误的结果。 有必要最大限度地减少模型的误报数量。 否则，错误的预测将浪费管理员大量的时间来检查系统。 管理员迟早会停止响应“偏执”的监控系统。
循环神经网络
要检测时间序列中的异常，您可以使用 具有 LSTM 记忆。 唯一的问题是它只能用于预测时间序列。 在我们的例子中，并非所有指标都是可预测的。 图 4 显示了将 RNN LSTM 应用于时间序列的尝试。
图 4. 具有 LSTM 存储单元的循环神经网络示例
从图4可以看出，RNN LSTM能够应对这个时间段内的异常搜索。 如果结果具有较高的预测误差（平均误差），则指标实际上已经发生了异常。 使用单个 RNN LSTM 显然是不够的，因为它适用于少量指标。 可以作为搜索异常的辅助方法。
用于故障预测的自动编码器
– 本质上是一个人工神经网络。 输入层是编码器，输出层是解码器。 所有此类神经网络的缺点是它们不能很好地定位异常。 选择了同步自动编码器架构。
图 5. 自动编码器操作示例
自动编码器接受正常数据的训练，然后在输入模型的数据中发现异常情况。 这正是您完成此任务所需的。 剩下的就是选择适合此任务的自动编码器。 自动编码器的架构最简单的形式是前向、非返回神经网络，它与 （多层感知器，MLP），具有输入层、输出层以及连接它们的一个或多个隐藏层。
然而，自动编码器和 MLP 之间的区别在于，在自动编码器中，输出层具有与输入层相同数量的节点，并且自动编码器不是被训练来预测由输入 X 给出的目标值 Y，而是被训练来重建自己的X。因此，自动编码器是无监督学习模型。
自动编码器的任务是找到与输入向量 X 中的异常元素相对应的时间索引 r0 ... rn。这种效果是通过搜索平方误差来实现的。
图 6. 同步自动编码器
对于选择的自动编码器 。 其优点：与其他架构相比，能够使用流处理模式以及相对较少数量的神经网络参数。
最大限度减少误报的机制
由于会出现各种异常情况，以及可能存在神经网络训练不足的情况，对于正在开发的异常检测模型，决定有必要开发一种最小化误报的机制。 该机制基于管理员分类的模板库。
（DTW算法，来自英文dynamic time warping）可以让你找到时间序列之间的最佳对应关系。 首先用于语音识别：用于确定两个语音信号如何表示相同的原始口语短语。 随后，它在其他领域也得到了应用。
最大限度减少误报的主要原则是在操作员的帮助下收集标准数据库，操作员对使用神经网络检测到的可疑案例进行分类。 接下来，将分类标准与系统检测到的案例进行比较，并得出该案例是否错误或导致故障的结论。 DTW算法正是用来比较两个时间序列的。 主要的最小化工具仍然是分类。 预计在收集大量参考案例后，由于大多数案例的相似性以及类似案例的出现，系统将开始向操作员提出较少的要求。
因此，基于上述神经网络方法，建立了一个实验程序来预测“Web-Consolidation”系统的故障。 该计划的目标是，利用现有的监控数据档案和有关先前故障的信息，评估这种方法对我们软件系统的能力。 该程序的方案如下图 7 所示。
图7 基于度量空间分析的故障预测方案
在图中，可以区分两个主要块：在监控数据流（指标）中搜索异常时间段以及最大限度地减少误报的机制。 注意：出于实验目的，数据是通过 JDBC 连接从石墨将其保存到的数据库中获取的。
以下是开发后得到的监控系统界面（图8）。
图8 实验监控系统界面
界面根据收到的指标显示异常的百分比。 在我们的例子中，收据是模拟的。 我们已经掌握了几周的所有数据，并正在逐步加载，以检查是否存在导致故障的异常情况。 下部状态栏显示给定时间数据异常的总体百分比，这是使用自动编码器确定的。 此外，还会显示由 RNN LSTM 计算的预测指标的单独百分比。
使用 RNN LSTM 神经网络基于 CPU 性能进行异常检测的示例（图 9）。
图 9. RNN LSTM 发现
使用 RNN LSTM 成功计算出一个相当简单的案例，本质上是一个普通的异常值，但却导致系统故障。 该时间段的异常指标为85%~95%；凡高于80%（阈值由实验确定）的均视为异常。
系统更新后无法启动时的异常检测示例。 自动编码器可以检测到这种情况（图 10）。
图 10. 自动编码器检测示例
从图中可以看出，PermGen 停留在一个级别。 自动编码器发现这很奇怪，因为它以前从未见过类似的情况。 这里异常保持 100%，直到系统恢复到工作状态。 所有指标均显示异常。 如前所述，自动编码器无法定位异常。 在这些情况下，操作员需要执行此功能。
结论
PC“Web-Consolidation”已开发多年。 系统处于相当稳定的状态，记录的事件数量较少。 然而，在故障发生前5-10分钟就有可能发现导致故障的异常情况。 在某些情况下，提前通知故障将有助于节省分配用于执行“维修”工作的预定时间。
根据已进行的实验，现在得出最终结论还为时过早。 到目前为止，结果是相互矛盾的。 一方面，很明显基于神经网络的算法能够发现“有用”的异常。 另一方面，仍然存在很大比例的误报，并且并非合格的神经网络专家检测到的所有异常都能被检测到。 缺点包括现在神经网络需要老师的训练才能正常运行。
为了进一步开发故障预测系统并使其达到令人满意的状态，可以设想几种方法。 这是对导致失败的异常情况的更详细的分析，因为添加了对系统状态有很大影响的重要指标列表，并丢弃了不影响系统的不必要的指标。 此外，如果我们朝这个方向前进，我们可以尝试专门针对导致失败的异常情况的算法。 还有另一种方法。 这是神经网络架构的改进，从而提高检测精度并减少训练时间。
我对帮助我撰写和保持本文相关性的同事表示感谢： 和谢尔盖·菲诺格诺夫。
来源： habr.com