应用运维智能化的关键技术——《应用智能运维实践（试读版）》

点击免费下载《应用智能运维实践 试读版 》https://developer.aliyun.com/topic/download?id 1193

本章内容简介

前面介绍了应用智能运维发展演进的历史 回答了应用智能运维是什么、为什么、有什么价值、能干什么的问题。为了指导企业实践、落地 本章围绕应用场景 从技术角度总结归纳了相比于传统的监控运维技术 应用智能运维系统特有的几个关键技术特征 以及介绍了如何用这些技术来解决实际应用运维问题。

智能运维的核心思想是利用算法来处理海量运维数据 积累运维经验 从而代替人工思考判断 以自动化的过程实现风险的预防、发现、定位和处理。在应用运维场景下实现智能化 判断研究用哪些技术来解决实际问题 需要从具体应用场景出发 匹配现有可行的技术。图4-1中总结了当前常见的应用智能运维场景 其中包括用于主动发现

图4-1? 常见的应用智能运维场景

潜在风险的应用运行期风险主动探伤、用户数字体验保障与优化、风险定位与根源问题分析 以及应用运行期负载趋势预测与容量规划等。围绕这些场景 我们需要从当前可用的统计、机器学习、人工智能和自治控制技术堆栈中匹配相关的算法。总的来说 当前能够匹配企业应用运维场景、可以用来解决实际运维问题的技术有面向海量实时指标数据的异常检测、发现异常后的关联及根源问题定位、风险处理方案决策支持及预防性维护的探伤检测等。

4.1? 异常检测 筛选时间序列数据 发现潜在风险4.1.1 ?技术简介

随着互联网和大数据的发展 数据在现实生活中发挥着日益重要的作用。其中 大部分数据都是流式传输的时间序列数据 将同一统计指标的数值按其发生的时间先后顺序排列而成的数列 。针对时间序列数据的数据挖掘已经应用于许多领域 其旨在找到一些频繁出现的模式。当从这些模式中发现某种规律时 异常数据通常被作为噪声而忽略。但是 在庞大的数据量背后 难免会存在异常数据 从数据的异常中往往能够获得更有价值和参考性的信息[1]。快速准确地检测数据中的异常 既能及时减少损失 又方便在短时间内采取适当的应对策略。尤其是在企业应用中 如果能准确地发现系统中出现的异常 对于系统状态的检测及对系统错误的处理将起到积极的推动作用。特别是若能够在异常发生的短时间内检测且报告异常 然后根据以往的异常数据对异常进行分析 推断异常出现的位置及原因 并给予初步的建议解决方案 则将对系统状态稳定起到巨大的作用。

传统的时间序列数据异常检测方法通常聚焦在一维场景下 根据不同时间点数据样本间的关联来对异常进行判断。这个方面的工作经过多年的发展已经相对成熟 其中较为简单的方法包括自适应阈值法、聚类法和指数平滑法等。Smith等人利用三次指数平滑法实现异常检测 利用历史数据中的不同特征来推测当前的数据值 这在商业领域十分有效[2] Stanway等人提出了针对流数据异常检测的Skyline项目 其包含一组简单的检测器和一个投票方案 以输出最终的异常评分 该项目在监测高流量网站的实时异常方面卓有成效[3] Bianco等人提出的ARIMA算法是一种针对具有季节性的时间序列数据建模的通用技术 它对于检测有规律的数据效果较好 但无法动态地确定季节性数据中的异常[4]。另外 在一些特定领域 有许多基于模型的方法已经投入应用 但这些方法往往只针对它们建模的领域 如云数据中心的温度检测[5]、飞机发动机测量中的异常检测[6]和ATM欺诈检测[7]等。虽然这些方法在特定的异常检测系统中可能是成功的 但它们无法应用于通用领域。

循环神经网络 Recurrent Neural Network RNN 等神经网络在时间序列数据异常检测方面具有一定的优势 是对于时间序列数据训练最常见的算法模型之一。然而 由于梯度消失问题的存在 传统的RNN在处理存在长期依赖问题的数据时会遇到巨大的困难[8]。近年来 长短期记忆网络 Long Short Term Memory Network LSTM 由于其在处理时间序列数据方面的优势而受到广泛关注 LSTM本身的特点使得其极适用于处理时间序列数据 同时LSTM克服了RNN无法处理长距离依赖的缺点 因此 许多学者提出了基于LSTM的异常检测方法。Numenta公司提出了基于RNN的层级实时记忆HTM算法 并提出了公开数据集NAB 在NAB数据集上验证了HTM算法的性能[9] Pankaj Malhotra等人利用基于LSTM的异常检测方法在四个不同领域的数据集上取得了极好的效果[10] Sucheta Chauhan等人定义了5种不同的异常类型 并修改获得了一种LSTM变体以对其进行区分[11]。类似的工作还有 Anvardh Nanduri 通过添加GRU来改造LSTM 从而实现了对飞机航班的异常检测[12] Jihyun Kim等人实现了一种无监督的异常检测方法 并在真实的工业数据集上进行了验证[13]等。

近年来 随着数据样本量级与维度的迅速增长 多元时间序列数据异常检测的需求日益增加。诸多机构与学者在多元时间序列数据异常检测的研究方面取得了极大进展。Pavel Filonov等人利用将多元向量合成一元向量的方法处理多元数据 再用常规一元数据异常检测方法进行检测[14]。这种将多维数据转化为一维数据再进行异常检测的方法在维数不多的情况下可行 且通常要求不同维度数据之间具有一定的关联性。类似的工作还有Han Bao等人通过多维特征序列变换算法、增量特征选择算法以无损方式将时间序列数据转换为特征向量 再基于C-SVM的异常检测方法进行异常检测[15]。近年来 业内一些学者提出了一些具有创新性的方法 如Jones等人将8维数据扩展至32维 再结合一维异常检测方法 根据不同维度之间关联性的变化进行多维度的异常检测[16]。该方法既适用于一维时间序列数据 也适用于多维时间序列数据 是一种极具创造性的方法。

4.1.2 ?深入浅出应用实践

目前 异常检测方法很多。人们对一元时间序列数据的异常检测研究较多 对多元时间序列数据的异常检测研究较少 并多采用降维方法来处理多元时间序列数据。下面介绍几种常用的异常检测方法。

1. 基于曲线拟合的检测算法

对于时间序列数据来说 t时刻的数值对于t-1时刻的数值有很强的依赖性。例如 某个游乐园的人在8:00这一时刻很多 在8:01时刻其人很多的概率是很大的 但如果其在7:01时刻的人较多 这对于其在8:01时刻人数的多少影响不是很大。

针对最近时间窗口内的数据遵循某种趋势的现象 可以使用一条曲线对该趋势进行拟合。如果新的数据打破了这种趋势 使曲线变得不平滑 则该点就出现了异常。

曲线拟合的方法有很多 如回归、滑动平均等。本书用EWMA 即指数权重移动平均方法来拟合曲线。EWMA的递推公式

EWMA(1) p(1)????? ?????????????????????????????????????????????????????????? 4-1

EWMA(i) αp(i) (1-α)EWMA(i-1)?????????????????????????? 4-2

其中 α是一个0 1的小数 称为平滑因子。EWMA(1)有时也会取前若干值的平均值。α越小 EWMA(1)的取值越重要。从式 4-2 可知 下一点的平均值是由上一点的平均值加上当前点的实际值修正而来的。对于每个EWMA值 每个数据的权重是不一样的 越近的数据拥有越大的权重。

有了平均值之后 就可以使用3-σ理论来判断新的输入是否超过了容忍范围。根据实际的值是否超出了容忍范围就可以知道是否可以告警 若超出了上界 可能是流量突然增加了 若低于下界 可能是流量突然降低了 这两种情况都需要告警。可以使用Pandas库中的ewma函数来实现上面的计算过程。

EWMA的优点如下。

1 其可以检测到在一个异常发生较短时间后发生的另一个 不太高的突变型 异常。

2 因为它更多地参考了突变之前的点 所以它能更快地对异常做出反应。

3 其非常敏感 历史数据如果波动很小 那么方差就很小 容忍的波动范围也会非常小。

EWMA的缺点如下。

1 其对渐进型 而非突发型 的异常检测能力较弱。

2 异常持续一段时间后可能被判定为正常。

3 其业务曲线自身可能有规律性的陡增和陡降。

4 其过于敏感 容易误报 因为方差会随着异常点的引入而变大 所以很难使用连续三点才告警这样的策略。

考虑到这些缺点 需要引入周期性的检测算法来针对性地处理具有周期性趋势的曲线。

2. 基于同期数据的检测算法

很多监控项都具有一定的周期性 其中以一天为周期的情况比较常见 如淘宝VIP流量在早晨4点最低 而在晚上11点最高。为了将监控项的周期性考虑进去 可以选取某个监控项过去14天的数据。对于某个时刻 将得到的14个点作为参考值 记为 其中。

用静态阈值方法来判断输入是否异常 突增和突减 。如果输入比过去14天同一时刻的最小值乘以一个阈值还小 那么就认为该输入为异常点 突减 如果输入比过去14天同一时刻的最大值乘以一个阈值还大 那么也认为该输入为异常点 突增 。

静态阈值方法中的阈值是根据历史经验得出的值 实际中如何给出 最大阈值 和 最小阈值 是一个需要讨论的问题。根据目前静态阈值方法的经验规则 取平均值是一个比较好的思路。

静态阈值方法的优点如下。

1 其反映了周期性。

2 其可以确保发现大的故障 给出告警的一定是大问题。

静态阈值方法的缺点如下。

1 其依赖周期性的历史数据 计算量大 而且无法对新接入的曲线告警。

2 其非常不敏感 无法发现小波动。

3. 基于同期振幅的检测算法

基于同期数据的检测算法遇到如图4-2所示的现象就无法检测出异常。例如 今天是11月11日 过去14天淘宝VIP流量的历史曲线必然会比今天的曲线低很多 如果11月11日这天出了一个小故障 曲线下跌了 但相对于过去14天的曲线仍然是高很多的 这样的故障使用基于同期数据的检测算法就检测不出来 那么将如何改进呢 直观来看 两个曲线虽然不一样高 但“长得差不多” 那么 怎么利用这种“长得差不多”呢 此时就可以采用基于同期振幅的检测算法。

图4-2? 淘宝VIP流量示意

怎么计算t时刻的振幅呢 可以使用来表示振幅。例如 t时刻有900人在线 t-1时刻有1000人在线 那么 可以计算出掉线人数是100。如果参考过去14天的数据 那么可得到14个振幅值。使用14个振幅的绝对值作为标准 如果m时刻的振幅大于振幅阈值且m时刻的振幅大于0 那么认为该时刻发生了突增 如果m时刻的振幅大于且m时刻的振幅小于0 那么认为该时刻发生了突减。

??????????? 4-3

基于同期振幅的检测算法的优点如下。

1 振幅要比绝对值敏感。

2 其利用了时间周期性 规避了业务曲线自身的周期性陡降。

基于同期振幅的检测算法的缺点如下。

1 其要求原曲线是平滑的。

2 周期性陡降的时间点必须重合 否则会发生误警。

3 按百分比计算容易在低峰时期发生误警。

4 陡降不一定代表故障 由上层服务波动引起的冲高再回落的情况时有发生。

4. 基于环比数据的检测算法

对于时间序列数据 可以利用最近时间窗口 T 内的数据遵循某种趋势的现象来进行检测。如将T设置为7 取检测值 和过去7个点的值 记为i 进行比较 如果结果大于阈值 将count加1 若count超过了设置的 则认为该点是异常点。

??????????????? ??????? 4-4

式 4-4 涉及threshold 动态阈值 和两个参数 可以根据需求进行设置 如果对异常比较敏感 可以将设置得小一些 如果对异常不敏感 可以将设置得大一些。业界关于threshold设置的方法有很多 下面介绍一种比较常用的阈值设置方法 通常阈值设置方法会参考过去一段时间内的均值、最大值及最小值 取过去一段时间 如窗口T 的平均值 avg 、最大值 max 及最小值 min 然后取max-avg和avg-min的最小值作为阈值 见式 4-5 。之所以取最小值 是要让筛选条件设置得宽松一些 让更多的值通过此条件 从而减少漏报。

????????????? 4-5

5. 基于Ensemble的检测算法

iForest算法是南京大学的周志华于2010年设计的一种异常检测算法 该算法利用数据构建iTree 进而构建iForest 是一种无监督的检测算法 具有很好的效果 具体可参见http://www.cnblogs.com/fengfenggirl/p/iForest.html。

iForest是由iTree构建而成的。iTree是一种随机二叉树 其每个节点要么有两个子节点 要么为叶子节点。对于给定的数据集D 数据集中的所有的特征都是连续变量 iTree的构造如下。

1 在数据集D中随机选择一个特征A。

2 随机选择特征A的一个可能取值v。

3 根据特征A及值v将数据集D分为两个子集 将特征A的值小于v的样本归入左子节点 余下部分归入右子节点。

4 递归构造左、右子树 直至满足以下的终止条件

①传入的数据集只有一条记录或多条相同的记录

②树的高度达到了限定高度。

iTree建好以后 就可以对数据进行预测了 预测的过程就是将测试记录在iTree上走一遍。iTree能有效地检测异常点是基于异常点都很稀有这一假设的 异常点应该在iTree中很快被划分到叶子节点 因此 可以利用检测点被分入的叶子节点到根的路径长度h(x)来判断检测点x是否为异常点。

在构建好iTree后 就可以构建iForest。在构造iForest中的每棵树时 并不是要将所有的数据都用上 而是随机采样 抽取一部分构造iTree 并尽量保证每棵树都不相同。事实上 如果iTree在构造时运用了很多数据点 反而不能得到很好的效果 这主要是因为数据点会有重叠。因为由iTree变成了iForest 所以S(x,n)的计算公式也要改变 将h(x)变为E[h(x)] 它就是检测点x在每棵树上的平均高度。iForest算法在Python中有现成的包可以调用。

利用iForest算法进行判断时 如果检测点的孤立森林分数为正数 那么 检测点为正常点 否则 检测点为异常点。

6. 基于神经网络的检测算法

人工神经网络 Artificial Neural Networks ANN 是20世纪40年代后出现的。它是由众多的神经元可调的连接权值连接而成的 具有大规模并行处理、分布式信息存储、良好的自组织和自学习能力等特点。BP Back Propagation 算法又称为误差反向传播算法 是人工神经网络中的一种监督式的学习算法。BP算法在理论上可以逼近任意函数 其基本的结构由非线性变化单元组成 具有很强的非线性映射能力 而且其网络的中间层数、各层的处理单元数及网络的学习系数等参数可根据具体情况设定 灵活性很大 在优化、信号处理与模式识别、智能控制、故障诊断等许多领域都有广阔的应用前景。

当前用于异常检测的基于神经网络的检测算法有很多 其中比较常见的是卷积神经网络 CNN 算法、循环神经网络 RNN 算法、深度神经网络 DNN 算法等 下面介绍一种称为长短期记忆网络 LSTM 的算法。

LSTM是一种改进后的RNN 可以解决RNN无法处理长距离依赖的问题 目前比较流行。其思路 原始RNN的隐藏层只有一个状态 即h 它对于短期的输入非常敏感 现在再增加一个状态 即c 让它来保存长期的状态 称它为单元状态 Cell State 如图4-3所示。

图4-3? 从RNN到LSTM

把图4-3按照时间维度展开 如图4-4所示 在t时刻 LSTM的输入有三个 当前时刻网络的输入值、上一时刻LSTM的输出值 以及上一时刻的单元状态。LSTM的输出有两个 当前时刻LSTM的输出值和当前时刻的单元状态。

为了控制单元状态c LSTM使用了三个“门”作为开关 如图4-5所示。

图4-4? LSTM示意

图4-5? LSTM的“门”开关

遗忘门 Forget Gate 负责控制继续保存单元状态c 它决定了上一时刻的单元状态有多少保留到当前时刻的单元状态

输入门 Input Gate 负责控制把即时状态输入到单元状态c 它决定了当前时刻网络的输入有多少保存到单元状态。

输出门 Output Gate 负责控制是否把单元状态c作为当前的LSTM的输出 它决定了单元状态有多少输出到LSTM的当前输出值。

遗忘门的计算如式 4-6 所示。

???????????????????????????????????? 4-6

其中 是遗忘门的权重矩阵 表示把两个向量连接成一个更长的向量 是遗忘门的偏置项 是sigmoid函数。

输入门和一个tanh函数配合控制该加入哪些新信息。tanh函数产生一个新的候选向量 输入门为中的每项产生一个0 1的值 用于控制新信息被加入的多少。至此 已经有了遗忘门的输出 用来控制上一单元被遗忘的程度 和输入门的输出 用来控制新信息被加入的多少 此时就可以更新本记忆单元的单元状态了

????????????????????????????????????????????????

输出门用来控制当前的单元状态有多少被过滤掉。先将单元状态激活 输出门为其中每项产生一个0 1的值 用来控制单元状态被过滤的程度。

???????????????????????????????

上面描述的LSTM是一个标准版本 并不是所有LSTM都和上面描述的一模一样。事实上 每个人所使用的LSTM都有一些细微的不同 有人专门比较总结过LSTM的各种变体 并比较了其效果 结果显示 这些变体在多数公开数据集上的表现差异不大。[17]

上面介绍了六种检测算法 每种算法都有其优缺点 都有能检测和不能检测的范围。在应用时 应根据实际情况来选择具体的算法 也可以使用多种算法进行综合检测 更多的检测算法可以参考开源项目Skyline中的算法库。

4.1.3? 应用案例

异常检测的应用场景极为广泛 其中针对时间序列数据的异常检测在工业、金融、军事、医疗、保险、关键系统安全、机器人、多智能体、网络安全和物联网等多个领域具有极其重要的地位与意义[18]。斯坦福大学的Melvin Gauci等人将1000个智能体组成系统 通过模拟实验证明不加限制的单个短时异常会在群体内快速传播 最终导致系统的崩溃[19] 从而说明异常检测效果是诸多场景安全交互的核心。鉴于异常检测在实际应用中的重要意义 开发性能更优、速度更快、检测更精准的异常检测算法急迫且意义重大。

1. 面向大数据应用的异常检测

随着计算机和互联网信息技术的迅猛发展与普及应用 各行各业的数据均呈现爆炸式增长 巨大的数据资源被很多国家和企业视为战略资源 大数据己经成为目前互联网领域的研究热点之一 这也标志着全球已经进入大数据时代[20]。

数据挖掘是从海量异构的数据中挖掘出未知的、潜在的信息和知识的过程。数据规模大、数据多样性是大数据的基本特点。海量复杂的数据中可能存在一些数据对象 这些数据对象与普通数据的期望行为模式并不一致 被称为异常值或离群点。随着数据规模和数据多样性的不断增加 数据中异常值 或离群点 的个数也会不断增加 合理有效地处理和应用这些异常值对大数据挖掘具有重要的意义[21]。针对大数据中异常值的识别和挖掘称为异常检测。虽然数据中的异常值是不寻常的 但如果考虑的数据量多达数十亿 则可能性为“千分之一”的异常值也可能是百万量级 在大数据挖掘过程中 这些异常值是不能忽视的。因此 异常值检测在大数据挖掘中有着至关重要的作用[22]。

2. 面向车联网应用的异常检测

近年来 随着信息化时代的到来及社会经济的高速发展 人们对交通的需求日渐增长 致使车辆运输效率不断下降 能源消耗持续高涨 运输环境日益恶化 交通拥堵越发严重 交通事故愈发频繁 这些成为我国许多城市的普遍性问题。因此 智能交通系统 Intelligent Traffic System ITS 应社会对交通发展的需求而产生。车联网 Internet of Vehicles IoV 作为物联网 Internet of Things IoT 在智能交通系统中的一个主要组成部分 其发展对于智能交通系统的发展具有推动作用。车联网将目前的新一代信息技术 如移动互联网、人工智能、物联网等相互融合 给传统汽车生产商带来了全新的变革 智能化和网络化已成为全球汽车与交通领域发展的主流趋势。预计2020年 全球将有超过500亿个智能设备接入物联网中 其中很大一部分便是车联网设备。车辆传感器的联网率将由现在的10%增加到90% 中国将有超过35%的汽车实现网络互联[23]。

然而 由于车联网的特殊性 即开放的无线传输介质、车辆节点的高速移动性、网络拓扑结构的频繁变化、易受环境影响及人为的信息干扰 使得传感器或传输线路可能出现故障 从而引起数据被篡改、失真或丢失。如果一个突发交通事故的数据在传送过程中混入了其他虚假杂乱的数据 那么可能会造成交通堵塞 更有甚者会威胁司机的生命安全。此外 异常数据的存在会影响数据分析的完整性和准确性[24]。2016年 腾讯科恩实验室通过车辆之间的无线连接和蜂窝连接漏洞两次成功破解了特斯拉MODEL S 其向汽车网络中发送恶意软件并将破解程序渗透到CAN总线 从而获得了刹车系统的远程操控权。这些远程控制车辆的案例说明外设人员篡改车辆数据成为可能 进而导致车联网中数据的安全性和可靠性受到严重的威胁。

因此 对车联网实时数据的异常检测及恢复迫在眉睫 它可以有效地提高数据质量 确保交通分析模型的准确性和智能交通系统的实用性 进而有效协助司机做出适当的驾车行为 合理调度交通资源 实时监测车辆故障并在必要时发出警告 避免发生交通事故 对交通安全、环境保护及人员健康都有着极其重要的作用和意义。

3. 面向工业应用的异常检测

近几年 传统工业控制系统和互联网、云平台逐渐连接起来 构成了工业互联网平台。工业互联网平台将现场设备、生产物料、网络系统连接成一个整体的系统 实现了工业数据的动态采集和实时分析 用智能控制替代了原来的人为操作 提高了工厂生产效率 是工业生产布局的新方向。工业互联网平台集海量数据采集和分析于一体 能够精准高效地对数据进行实时处理 推进了制造业发展的新征程[25]。

工业互联网在给工业控制系统带来便捷操作的同时 也引入了一系列的安全问题 各种入侵、攻击手段层出不穷 建设满足工业需求的安全体系是保障工业互联网平台正常运行的前提。各种网络入侵技术的发展已对工业互联网平台造成了严重的威胁 工业控制系统的现场设备、控制系统及网络设备都存在被攻击的风险 一旦这些设备出现异常 将会给工业带来不可估量的经济损失 影响生产进度 甚至危害人员的生命安全[26]。2010年 在著名的“震网”病毒事件中 攻击者利用4个“0day”漏洞 致使伊朗核设施的离心机出现了故障 震惊了全球。因此 应对各种网络攻击已经成为保障国家关键基础设施安全的基本需求。

?

4.2?关联分析 实现全景化应用监控的基础4.2.1 ?技术简介

应用运维智能化技术和相关软件系统是伴随应用系统复杂度、运维工作量和技术难度激增而出现的 因此 通过人工智能算法来代替人工融合和分析数据、推理、决策、处理问题是建设应用智能运维系统需要考虑的关键问题之一。

传统应用运维过程中常用的监控运维系统一般是针对特定场景、特定资源建设的。例如 日志分析平台采集分析应用日志 APM监控代码链路和对全量用户请求的处理情况 网络性能管理 NPM 平台追踪网络中的交易情况和网络异常 IT资源监控系统监控服务器、网络设备、云环境和应用运行依赖的中间件等。要做到智能化 首先要有运维数据治理平台的支撑 将离散、竖井式的监控系统关联打通 构建同构的、一致的全景化应用监控视图 这样才能为运维人员过滤冗余信息 提供精准的风险态势监控和定位决策支持。

4.2.2 ?深入浅出应用实践

关联分析是整合应用运行期生成的各层级全栈数据、关联打通竖井式监控系统的关键。目前可以用来关联应用运维数据的方法主要有如下几种。

1 读取配置管理数据库 CMDB 信息。CMDB是一个数据库 其中包含有关组织 IT服务中使用的硬件和软件组件 以及这些组件之间关系的所有相关信息。信息系统的组件称为配置项 CI 。CI可以是任何可以想象的IT组件 包括软件、硬件、文档和人员 以及它们之间的任意组合或依赖关系。应用运行期依赖物理IT基础设施设备、虚拟IT基础设施设备与应用之间的部署关系 网络拓扑关联关系可以从CMDB中定义的CI关联读取出来。一旦设备出现故障 这些关系可以用来辅助找出影响范围。

2 监控分析网络流量。NPM工具可以通过旁路镜像网络流量来监控网络上应用中的服务接口之间、应用与用户之间的交互关系 获取网络层的关联关系。利用深度网络包检测 Deep Packet Inspection DPI 技术 甚至可以将网络报文中的业务交互信息解析出来 补充业务层的调用关系。

3 追踪应用代码链路。APM工具提供了对应用程序性能深入分析的能力 当用户向应用程序发出请求时 APM工具可以通过探针看到分布式部署的应用系统中的接口调用关系、代码链路执行过程和方法调用关系 并且可以显示有关此请求发生的系统数据、参数和与数据库交互的SQL语句。应用白盒监控能力提供的关联关系 可以在排查代码缺陷导致的故障时 快速定位根源问题。

4 利用人工智能算法计算关联关系。以上三种方法利用传统运维监控工具提供的数据关联和检索能力构建了覆盖物理部署、网络交互、接口交互与代码交互的关系图结构 见图4-6 基于此视图可以实现在异常情况下的信息关联。但是 一旦出现未能直接监控的问题导致的应用故障 就需要用算法来辅助分析海量历史监控数据 发现数据中隐含的关系 并根据发现的问题及已知事件推理进行决策。常用的技术是查找时间序列指标数据波动之间的相似性、相关性等关联关系 主要方法有Pearson、Granger Kendall、Spearman等 。基于关联关系构建的因果推理分析模型 可以基于概率图模型 如Bayesian Networks、Markov Random Fields等 建模来实现因果关系发现和推理。

图4-6? 应用全景监控数据关联关系建模的策略

相关性是一种双变量分析 用于测量两个变量之间的关联强度和关系方向。就关联强度而言 相关系数的值在 1 和 -1 之间变化 其值为1表示两个变量之间完全关联 值为 0 表示两个变量之间的关联较弱。关系方向由相关系数的符号指示 “ ”表示正关系 “-”表示负关系。通常 利用统计学方法可以计算以下几种相关性 皮尔森相关性 Pearson Correlation 、斯皮尔曼相关性 Spearman Correlation 和格兰杰因果关系检验 Granger Causality 。

皮尔森相关性是使用最广泛的相关统计 用于测量持续变化的变量之间的线性相关程度。例如 在股票市场中 如果想要测量两只股票之间的关系 那么就可以使用皮尔森相关性。

斯皮尔曼相关性评估两个连续变量之间的单调关系。在单调关系中 变量往往一起变化 但不一定以恒定速率变化。斯皮尔曼相关系数是基于每个变量的排名值而不是原始数据的。斯皮尔曼相关性通常用于评估正数变量的关系。

格兰杰因果关系检验是经典方法 在计量经济学的时间序列分析中有较多的应用。除此之外 还有收敛交叉映射 Convergent Cross Mapping CCM 方法。格兰杰因果模型的前提假设是事件是完全随机的 但现实情况是很多事件是非线性、动态且非随机的 格兰杰因果模型对这类情况不适用。CCM方法则适用于这一类场景 其可在多组时间序列中构建因果网络。

4.3 ?数据统计 敏捷高效的信息提取手段4.3.1 ?技术简介

虽然人工智能算法具有识别复杂模式、可替代人脑进行推理分析等优势 但目前由于缺少通用的人工智能平台 其计算复杂度和实施成本相对较高 在某些运维场景下并不适用 而某些统计学方法简单高效 与人工智能算法结合的效果很有可能出人意料。

Google前SRE工程师Tom Limoncelli在编著的The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems一书[27]中讲过一个故事 “当有人问我建议平时都要监控什么时 我会开玩笑地跟他们说 理想情况下 我会首先要求他们删掉监控系统里的所有数据采集和告警策略 当再次发生故障时 想想什么指标可以预测这次故障的发生 然后把这个指标监控和告警策略加回到监控系统中来。如此不断积累 现在监控系统中只存在能够预测各种不同故障的指标和告警 从而当故障发生时 监控系统不会被大量告警信息淹没。”

还有一种更加简便的方法也能达到预期效果 但要有完整的历史数据支撑 即查看历史30天或半年的故障恢复记录 看哪些指标对发现并解决特定问题和特定故障有用。例如 如果我们发现一台Web服务器停止响应了 首先要查找的是发现这一现象的相关指标数据 而且这些指标未必是从Web服务器本身采集的 例如

1 应用层 Web页面加载时间持续增加

2 操作系统层 服务器内存使用率无波动 磁盘读写无波动

3 数据库层 数据库事务执行时间持续升高

4 网络层 负载均衡器挂载的活跃计算节点数量降低。

以上这些指标异常都有可能提前反映某些潜在的应用故障。对于之前发生过的每种故障类型 找到其对应的能提前反映异常的指标 定义告警策略。如果日常运维持续这个过程 积累经验数据 那么能提前发现的异常类型就会越来越多 由于应用故障导致直接影响用户的情况就会越来越少 运维体系的工作负荷就会越来越低。

使用平均值和标准差检测呈高斯分布的指标异常是行之有效的方法。但是 对于其他非高斯分布的指标 有可能达不到预期效果 一旦指标数据的概率分布不符合高斯钟形曲线 基于平均值和标准差来过滤异常数据的手段就不适用。例如 要监控某网站上每分钟下载特定文件次数这一用户行为 可定位下载次数异常增高的时间窗口 即过滤大于平均值3倍标准差下载量的时间段。在图4-7中 灰色柱形图展示了用户每分钟下载量的时间序列分布 上方黑色滑动窗口序列对应标识了下载量大于平均值3倍标准差的时间段 灰色未标识窗口对应的下载量则小于平均值3倍标准差。

图4-7? 每分钟下载量指标使用平均值3倍标准差规则时过度警报的效果截图

从图中可以看出 如果用大于平均值3倍标准差策略生成告警 很明显的一个问题是 大多数时间段都需要产生告警。为了更明显地展示此问题 我们将该指标数据的概率分布可视化 如图4-8所示。图4-8中 横轴是指标可能出现的数值 纵轴是一段时间内该值出现的次数统计值。很明显 其并不是对称的高斯钟形曲线。通常情况下 文件下载频率都比较低 但高于平均值3倍标准差的下载任务 在时间轴上的分布规律性相对较强。

图4-8? 每分钟下载量指标数据直方图

像这种非高斯分布的指标 在生产环境中并不是少数。对这种现象 Simple Math for Anomaly Detection[30]一书的作者Toufic Boubez博士认为 “在运维过程中 我们采集的很多指标数据满足‘卡方 Chi Squared ’分布的概率分布。在这类指标上使用平均值3倍标准差做异常检测和告警 会导致告警风暴或干脆检测不出来” 。她认为 “如果过滤小于平均值3倍标准差的数据 我们将得到负数 得到的结果很明显也没有什么意义” 。

告警风暴是运维人员不愿意遇到的情况 一些故障有时并不严重 或者根本没有必要深夜起床处理。而若出现风险迹象或已经发生故障未检测出来 后果则更为严重。假如我们要监控已经完成的用户提交事务指标 由于系统软件出现故障 该指标陡降50% 如果我们使用平均值3倍标准差的统计学方法检测异常 则监控指标值在正常范围内 不会产生告警。后果就是 用户将先发现此问题 接近50%的用户提交事务将返回执行失败的提示 该问题造成的损失会更大。我们需要用其他方法来发现这类问题。

?

案例

Scryer是Netflix开发的用来解决Amazon AWS云平台Amazon Auto Scaling AAS 功能缺陷、提升应用服务质量的工具。AAS可以探测AWS云上的应用负载 自动增加或减少应用云上弹性集群的计算能力。Netflix开发的Scryer在AAS功能的基础上 可以通过分析历史数据的趋势和规律对应用未来的负载进行预测 预先弹性控制集群规模 分配或回收资源。总的来说 Scryer弥补了AAS以下三个不足。一是AAS对用户并发访问量突发峰值处理方面的不足。由于并发量突然增加 持续时间较短 而AAS处理采用弹性控制策略 创建、启动新AWS EC2计算节点的速度要持续几分钟甚至几十分钟时间。等集群节点创建完毕 也错过了并发访问量激增的时段。二是由于AAS判断策略简单 用户访问量的突然减少会使AAS消减过多的集群节点 以至于其不足以处理即将发生的用户访问。三是AAS不能从历史用户访问数据中找到趋势和规律来指导未来的容量规划。

Netflix用户访问数据的概率分布并不符合高斯分布 但数据规律性较明显 每天分时段访问量、节假日和工作日的访问量都有明显的规律可循 因此可预测性较强。可通过使用多种异常检测策略监测突发的访问量激增 结合快速傅里叶变换 Fast Fourier Transform FFT 、线性回归平滑处理数据 同时保留合理的有规律激增点。通过这些处理技术 Netflix能够在处理并发访问量激增时预测趋势 获得一些提前量来增加资源 见图4-9 从而保障用户体验流畅。在Scryer系统上线第一个月 Netflix就监测到了明显的用户体验和服务质量的提升 AWS EC2计算资源的使用成本也有所降低。

图4-9? Netflix Scryer预测用户流量和生成的 AWS 计算资源计划

对于规律性不是很明显的非高斯分布的时间序列指标数据的异常检测 常采用指定时间窗口平滑处理 即选定一个时间窗口 沿时间轴滑动 将每个点的监控值替换为时间窗口内所有点的平均值。这么处理可以将指标曲线波动剧烈的锯齿状波形平滑掉 突出曲线趋势和规律。图4-10所示为原始曲线和经过平滑处理的曲线的对比 灰色为原始数据曲线 黑色为经过30天时间窗口平滑处理后的曲线。

除了平滑处理 类似常用的处理方法还有KS检验 Kolmogorov-Smirnov Test 用于检测数据是否符合指定分布 、快速傅里叶变换 Fast Fourier Transforms 等。大多数和用户触发任务执行相关的指标都是存在规律性的 通过学习历史数据中每天、每周、每年的规律 就能够发现实时数据是否异常。例如 若周六晚上的用户成功交易量相比于历史同期下降了50% 则有可能存在系统异常 导致用户请求执行缓慢或失败。

图4-10? 原始曲线和经过平滑处理的曲线对比

4.3.2 ?深入浅出应用实践

2014年 在Monitorama公司 Toufic Boubez博士介绍了使用KS检验方法实现异常检测的案例[28]。KS检验方法在统计学中通常用于检验两个数据集的相似性 使用这种方法的常用运维监控工具有侧重数据采集与存储的Graphite和侧重分析展现的Grafana。

图4-11所示为某电子商务网站的交易笔数指标的月交易量时间分布。从指标曲线变化趋势能直观看出 箭头所指处的交易量异常 并没有往常那么多。

如果使用平均值3倍标准差规则判断异常 将收到2次告警 周一交易量未恢复正常值的异常会被忽略掉。在理想情况下 若交易量与历史同期的平均值相差太大 我们也希望收到告警通知。Boubez博士在Simple Math for Anomaly Detection一书中提到 “KS检验方法对运维人员分析监控指标数据非常有帮助 因为其不需要预先判断分析的指标是否符合正态分布或其他概率分布 这对了解复杂系统的监控数据规律很关键 可以帮助运维人员找出周期性指标数据的周期波动变量。”

图4-12所示为通过KS检验方法处理交易笔数指标数据的效果。图中与时间轴平行的灰色时间序列代表处理后的正常状态 其中 黑色区域是检测出异常的时间窗口。目前有三个检出异常的黑色窗口 分别对应1次周二交易量增加、1次周二交易量降低和1次周一交易量降低。这些异常是人眼观察不到的 用平均值3倍标准差规则也无法检测出来。如果这些异常是由系统运行异常导致的 接收到告警后 运维人员及时介入就有可能降低影响范围 保障未来交易量不会受到更大的影响 从而提升用户数字体验。

图4-11? 某电子商务网站的交易笔数指标的月交易量时间分布

图4-12? 使用KS检验方法对交易笔数指标异常情况发出告警

时间序列数据异常检测中的一个重要问题是概念漂移 时间序列中的数据是流动的 有实时性且数据量庞大 随着时间变化 时间序列中数据的分布及标签可能发生变化 出现概念漂移及异常现象。针对概念漂移及异常问题 很多学者提出了解决方法。解决概念漂移及异常的方法大致可分为两类 ①对概念漂移及异常进行检测 在检测到发生概念漂移及异常的位置调整学习策略 以适应新的数据 ②实时动态调整学习器以适应新数据 不需要考虑是否发生了概念漂移及异常。

所谓时间序列概念漂移及异常是一种数据随时间而发生变化的现象。对于时间序列相关的挖掘来说 当发生概念漂移及异常时 已构建模型的性能指标会随时间而降低 甚至导致模型完全失效。因此 准确检测和判断是否发生概念漂移及异常 对于时间序列相关的挖掘来说是至关重要的一环 对于概念漂移及异常的检测成为近年来学术界研究的热点问题之一。

由于发生概念漂移及异常时 模型只能通过自我更新的方式来适应新的数据环境 因此 对概念漂移及异常进行实时检测 从而控制模型进行更新 是克服概念漂移及异常最好的方法。传统的概念漂移及异常检测往往通过对模型内部参数的监控来达到检测概念漂移及异常的目的。例如 对于时间序列分类问题 通过监控模型的分类准确率来判断是否发生了概念漂移及异常 这种方式的优点是实现简单、直观 缺点是检测往往由于受噪声的影响而发生误判 且具有滞后性。

高维监控数据的概念漂移及异常时间序列学习是一个很重要的课题 高维数据带来的维数灾难使得传统的机器学习方法不再适用。一个比较经典的检测概念漂移及异常的方法是由Dasu等人提出的一种用于检测高维时间序列的概念变化问题的信息理论方法。该方法基于空间分割方案 运用KL散度度量两个经验分布之间的距离。但是 该方法在离散化划分之后才能求得概率密度 经过离散化后运用Bootstrap 使算法需要花费较大的时间代价。另外 该方法只能判断两类情况下的概念漂移及异常 对多类情况只能两两判断或采用其他策略。

综上所述 对于高维时间序列的概念漂移及异常检测问题 关键是找到既能满足时间序列的实时性要求 又能准确判断概念漂移及异常是否发生的方法 从而为模型更新提供帮助。尽管目前有不少检测方法 但受时间序列自身特点的限制 其尚无法很好地解决概念漂移及异常问题。另外 大数据下的概念漂移及异常呈现多样化的特点 不同类型的概念漂移及异常所需方法也无法统一。

时间序列概念漂移的研究在机器学习和数据挖掘领域的重要性与日俱增 并在处理途径方面呈现多样化的趋势 从近年来机器学习与数据挖掘领域的一些国际权威期刊论文和国际顶级会议论文来看 时间序列概念漂移的挖掘和分类研究正日益成为学术界关注的焦点 对数据流概念漂移的研究已经开始与转移学习、进化计算、特征选择、聚类、时间复杂度分析、社会计算等结合。因此 从趋势上来说 已有各种模式分类的理论和算法都可与概念漂移相结合 从而引出更多新的研究问题。

?

?

4.4 ?预测分析 使应用性能风险防患未然4.4.1 ?技术简介

面对智能、互联时代更广泛的用户群、更多类型的终端接入、更复杂的应用技术架构 采用数据驱动、机器分析决策代替人工运维方式建设运维系统、保障服务质量目标、提供应用运维服务已是大势所趋。下面介绍如何利用现有的开源、商业版工具分析监控数据 发现应用潜在风险 规避故障。分析手段涉及统计学方法、人工智能算法。

在用户受影响之前 预先发现问题并处理的能力对提供在线互联网服务的企业尤为重要。毕竟用户体验下降 甚至服务中断会直接影响企业营收。在互联网公司中 通过分析监控数据实现主动探伤、预防风险的公司已经非常普遍 Netflix 面向全球的在线视频服务提供商 就是其中之一。Netflix 依赖互联网在线平台向全球用户提供影音视频服务 非常重视这方面能力的建设 已经实现了一定范围的应用异常预警和预处理。由于需要面向海量终端用户提供在线服务 应用性能和用户数字体验直接决定企业营收 互联网行业对运维系统建设的重视程度相比于制造业、政府等要高。2015年 Netflix在线用户数达到7500万 年营业额达到62亿美元 其经营的首要目标是为用户提供极致用户体验的在线视频服务。为达到此目标 应用运维至关重要。Roy Rapoport形象地将Netflix基于云平台的视频服务运维保障面临的挑战描述为“从一群长相和行为都相似的牛群中 找出最与众不同的那头牛”。如果应用系统包含上千个无状态的计算集群节点 所有节点都在运行同样的代码 分担相同规模的计算负载 那么从这些集群中选出异常节点并不容易。

4.4.2 ?深入浅出应用实践

为了解决上千节点运行期的海量监控数据筛选问题 Netflix于2012年引入了异常检测算法。约克大学 University of York 的Victoria J. Hodge 和Jim Austin 将异常检测 Outlier Detection 定义为“检测导致明显性能下降的运行期异常事件 如自动检测飞机发动机运转过程中的异常的传感器指标数据”。Netflix使用的方法类似 即首先利用算法识别节点反馈的监控指标正常运行的状态数据模式 然后过滤集群中监控指标状态数据模式类似的节点 将其识别为正常 剩下的就是疑似异常节点。

Netflix已经能够在不需要人工定义什么是正常节点运行行为的情况下 自动找出异常状态节点。由于计算集群部署在云端 其实现了集群规模的可伸缩弹性控制功能。异常节点由系统自动清除处理 负载自动由新创建的或其他正常的节点接替。因此 不需要通知任何人干预处理。为了排查故障原因 自动处理过程和异常节点的状态数据会被保存并通知相关工程师。通过应用异常检测算法 计算集群中异常节点定位、故障排查和恢复的人工工作量大幅度降低了 服务质量也有了显著提升。Netflix在利用异常检测算法检测监控数据方面的尝试验证了通过智能运维系统替代人工运维、实现大规模复杂应用运维管理的可行性。

分析指定时间范围内应用指标数据是否存在异常最简单的统计学方法是计算指标的平均值和标准差。通过这种方法 我们能很快发现持续采集的监控数据中指标波动异常的时间范围。例如 用户请求并发量的平均值环比显著升高 则应用有可能受到恶意攻击 需要定义告警策略并通知相关责任人。

当关键产品服务发生异常时 在凌晨或其他任何时间生成告警短信或电话以通知责任人都是有必要的。但是 当产生的告警并没有明确指出异常原因 或者根本就是错误告警时 就没有必要推送了。例如 某弹性组计算集群服务节点的CPU使用率升高 导致使用率升高的原因很多 且集群节点故障宕机并不影响应用业务正常运行 因此 基于此指标告警就意义不大。如开发运维一体化领导者、资深应用运维工程师John Vincent所说 “告警疲劳是我们现在唯一待解决的问题 我们需要让告警更智能 否则我们就得疯掉 ”

从理论上说 好的告警需要有较高的信噪比 能指示关键KPI指标上实时产生的异常数据点 并能与明确有所指的告警信息匹配 引导责任人快速定位、修正问题。假如要监控某应用未授权用户尝试非法登录系统的行为 采集的指标数据的概率分布为高斯分布 概率密度函数如图4-13所示 其中 μ为指标平均值 σ为标准差。越靠近高斯分布钟形曲线边缘的取值 为异常数据的可能性越高。在运维数据分析场景下 这种方法最常用的场景是利用一段时间的监控数据 计算概率分布 并通过标准差设置告警阈值 然后计算实时采集的数据偏离平均值的程度来判断是否触发告警。例如 若监控的未授权登录量指标符合高斯分布 则可以设置告警策略为筛选未授权登录量比平均值3倍标准差大的时间。

对于统计学方法 要围绕实际场景 本着计算简单、结果有效的原则进行选择。因为我们面对的是几万甚至百万级别的指标 过于复杂的统计学方法会给监控系统带来巨大的负担 影响产生结果的时效性 我们也不可能对每个甚至每类指标都定义统计学方法。

图4-13? 呈高斯分布的指标的概率密度函数

4.5? 因果推理 专家经验辅助决策支持4.5.1 ?技术简介

在实际运维场景下 很多应用故障的原因相当复杂 故障不能被直接监控到 或者不能靠设计确定性计算方法来分析现有监控数据 找到问题线索。在这种情况下 利用知识工程手段建设专家系统 利用非确定性计算方法积累专家经验 并基于经验推理来分析解决应用运维场景下的风险管理问题 是应对未来应用系统复杂度快速增长、运维成本增加的可行的技术手段。实现具备推理分析能力的应用智能运维系统 需要突破的技术难点主要有 ①积累专家经验知识 形成专家系统知识库 为构建知识型人工智能运维系统提供基础支撑 ②利用知识库中积累的知识 在出现异常时自动推理分析以找到最优解决方案。

寻找第一个难点的解决途径 需要首先从现有知识工程领域的研究成果下手。在人工智能领域 通过积累经验知识提升人工智能的水平已经不是一个新话题。早在1977年 美国斯坦福大学的计算机科学家、图灵奖获得者爱德华·费根鲍姆 Edward A. Feigenbaum 教授就提出 传统的人工智能忽略了具体的知识 人工智能必须引进知识。在第五届国际人工智能会议上 费根鲍姆教授第一次提出了知识工程的概念 并带领团队研发了第一代知识工程驱动的专家系统。如今盛行的知识图谱又将知识工程推向了一个新高度。

在IT运维领域 经验知识的积累主要体现在数据采集策略、指标告警策略、分析仪表盘、报表模板和CMDB方面。这些专家知识以结构化、半结构化的方式定义了针对不同类型的应用中间件和运行环境支撑设备如何采集指标、如何判断异常状态 以及如何管理应用部署配置等相关知识。

这些知识固化在运维软件系统中 对辅助运维人员监控应用、发现风险发挥了重要作用。但是 应对技术架构、拓扑结构较为复杂的互联网应用 微服务架构已经力不从心。要找出包含几十种中间件和数据库、对接公有云服务和私有云服务、连接手机和汽车等多种智能终端的应用的潜在风险 定位故障原因 需要更加智能的专家系统。这些专家系统不但要能积累海量知识 而且要能基于条件自动关联知识进行因果推理分析 替代人脑在海量知识中找出答案。

1. 具有应用运维经验知识的专家系统

专家系统作为早期人工智能的重要分支 是一种在特定领域解决问题的能力达到专家水平的程序系统。专家系统一般由两部分组成 知识库与推理引擎。它根据一个或多个专家提供的知识和经验 通过模拟专家的思维过程进行主动推理和判断 从而解决问题。第一个成功的专家系统DENDRAL于1968年问世。1977年 费根鲍姆将其正式命名为知识工程。目前获得广泛关注的知识图谱技术是在当前技术的发展背景下 知识工程演进到新阶段的产物。

对于应用运维场景 知识图谱提供了一种定义运维领域的经验知识 以及应用实体及其相互间部署、交互、网络拓扑等关系的结构化方法。知识图谱对应用本身及其相关的实体范围内可以识别的客观对象和关系进行规范化描述 形成运维智能化支撑的知识库。知识图谱本质上是一种语义网络 其中的节点代表实体或概念 边代表实体/概念之间的各种语义关系。

2. 使用知识对非确定性问题进行因果推理分析

因果推理分析是UCLA教授、图灵奖获得者Judea Pearl在Probabilistic Reasoning in Intelligent Systems一书中提出的 其将人工智能领域处理非确定性问题的方法划分为三个学派 逻辑主义学派 Logicist 、新计算学派 Neo-Calculist 和新概率论 Neo-Probabilist [29]。

逻辑主义学派试图用非数字技术来处理不确定性 主要运用非单调逻辑。新计算学派使用不确定性的数值表示不确定性 但认为概率积分 Probabilistic Calculus 不足以完成这项任务 因此 其发明了全新的微积分 如Dempster-Shafer理论、模糊逻辑和确定性因素。新概率论仍然存在于概率理论的传统框架中 同时试图用执行人工智能任务时所需的计算工具来支持其理论。处理不确定性的延伸方法 也称为生产系统、基于规则的系统和基于程序的系统 将不确定性视为附加到公式的广义真理值 并将任何公式的不确定性计算转化为其子公式的不确定性计算。在有意的方法 也称为声明性或基于模型的方法 中 不确定性与可能的世界状态或子集相连。

对于运维场景 推理任何现实问题总需要对目标场景进行一些抽象、对高维数据进行一些降维以简化计算。准备知识来支持推理的行为要求我们留下许多未知、未说或粗略的总结事实。例如 如果我们定义“HTTP-500错误代表服务器端页面ASP、JSP代码解析错误”或“应用可用性终端和服务端节点日志中同时出现Out of Memory异常 代表内存溢出导致的应用宕机”等规则来对知识和行为进行编码 那么将有许多我们无法列举的例外情况及规则适用条件。

要实现人工智能驱动的运维 知识是不可缺少的。在设计运维系统的智能化处理过程时 只采用过程性方法来定义风险是不够的。应对复杂策略 还必须使用说明性方法及积累的历史经验和领域知识。当解决问题时 单纯设计算法来实现高效率的求解 而不考虑由于数据维度的增加、条件组合数的无限增加而导致的搜索量增加 也是不切实际的。

网络表示不是人工智能系统外在的。大多数推理系统使用复杂的指针系统 将事实分组为结构 如框架、脚本、因果链和继承层次结构 的索引网络来编码相关性。这些结构虽然被纯粹的逻辑学家所回避 但在实践中已经证明是不可或缺的 因为它们将执行推理任务所需的信息放在接近任务所涉及的命题的位置。事实上 人类推理的许多模式只能用人类遵循这种网络所制定的途径的倾向来解释。

本书讨论的网络的特点是它们具有明确的语义。换句话说 它们不是为使推理更有效率而设计的辅助设备 而是知识库语义中不可或缺的一部分 它们的大部分功能甚至可以从知识库派生出来。

4.5.2 ?深入浅出应用实践

在特定场景下面向具体问题的应用实践中 对于不确定性推理 可按照是否采用数值描述不确定性来选择不同的方法 一种是数值方法 它是一种用数值对不确定性进行定量表示和处理的方法 另一种是非数值方法 它代表除数值方法以外的其他各种对不确定性进行表示和处理的方法。

对于数值方法 其又可以根据所依据的理论分为两种不同的类型 一种是基于概率论的有关理论发展起来的方法 如确定性理论、主观Bayes方法、证据理论和概率推理等 另一种是基于模糊逻辑理论发展起来的方法 如模糊推理 它可以用来对由于操作系统最大线程数限制 或者应用系统线程数过多导致的服务异常问题进行推理判断。如果采用传统的根据预定义条件判断的方法枚举这种操作系统配置导致的异常 那么前期需要配置的数据量将非常庞大。

考虑投入产出比 我们不可能为每种可能发生的异常情况和每个监控指标设计特定的数据采集策略与异常检测算法。因此 基于先验知识 使用由现象到本质的不确定性推理 Induction 来解决更为合适 这样虽然不能保证完全准确 但能在一定程度上替代运维专家辅助决策 给出解决问题的正确方向。

推理过程实质上是不断寻找和运用可用先验知识的过程。在应用运维场景下 可用先验知识是指根据经验积累的风险现象、应用配置前提条件 以及可与历史风险处理知识库匹配的知识。类似采用推理解决应用系统线程数过多的问题 针对运维过程中需要采用不确定性推理方法处理的场景 需要考虑的基本问题包括以下方面。

1. 不确定性的表示

不确定性的表示包括知识不确定性的表示和证据不确定性的表示。知识不确定性的表示通常需要考虑两方面的问题 如何能够比较准确地描述问题本身的不确定性 以及如何定义能便于推理过程中不确定性的计算。

知识的不确定性通常是用一个数值来描述的 该数值表示相应知识的确定性程度 也称为知识的静态强度。证据的不确定性表示推理中的证据有两种来源 第一种是应用出现故障后在求解问题的原因的过程中所提供的初始证据 如系统内存溢出问题、内存使用率超阈值等先验知识 第二种是推理过程中得出的中间结果。通常 证据的不确定性应该与知识的不确定性表示保持一致 以便推理过程能对不确定性进行统一处理。

2. 不确定性的匹配

推理过程实质上是不断寻找和运用可用知识的过程。可用知识是指其前提条件与综合数据库中的已知事实相匹配的知识。那么如何匹配呢 目前常用的解决方案是 设计一个用来计算匹配双方相似程度的算法 并给出一个相似的限度 如果匹配双方的相似程度落在规定的限度内 那么称双方是可匹配的。

3. 组合证据不确定性的计算

在不确定性系统中 知识的前提条件既可以是简单的单个条件 也可以是复杂的组合条件。匹配时 一个简单条件只对应一个单一的证据 一个组合条件将对应一组证据 而结论的不确定性是通过对证据和知识的不确定性进行某种运算得到的。所以 当知识的前提条件为组合条件时 需要有合适的算法来计算组合证据的不确定性。

?

4. 不确定性的更新

由于证据和知识都是不确定的 那么就存在两个问题 如何利用证据和知识的不确定性更新结论的不确定性 在推理过程中 如何把初始证据的不确定性传递给最终结论。

对于第一个问题 一般的做法是按照某种算法 由证据和知识的不确定性计算结论的不确定性。对于第二个问题 一般的做法是把当前推出的结论及其不确定性作为新的证据放入综合数据库。

目前已有一些解决此类问题的研究成果 如墨尔本大学CLOUDS实验室的Rajkumar Buyya等人[30]分析了以服务等级协议 SLA 感知方式解决计算资源分配问题的关键挑战 提出了基于计算风险管理的SLA感知推理资源分配策略。为利用云计算的资源动态分配能力 一些文献[31]分别介绍了集群系统及多层应用的资源的随需分配实现策略 详述了以SLA及QoS事件触发方式实现云计算资源动态调配的主要机制。

为实现服务质量感知的资源自适应配置 Amir Vahid等人[32]通过语义查找、分析和匹配用户需求 实现了多云环境下的QoS感知云服务选择 针对私有云环境中资源交付与调度的高效实现问题 我们提出了一种基于分裂聚类的云应用的资源交付与配置方法 优化了虚拟机与虚拟设备的资源配置[33] 为了优化云应用在多种云环境下的部署策略 Grozev Nikolay等人针对多云联邦环境下部署的三层Web应用性能进行了性能建模 并给出了跨多云部署的三层Web应用运行期基于负载的资源动态响应是资源优化策略的结论[34]。现有文献研究成果[35]主要通过事件或人工触发被动调整资源配置的方式来实现资源与负载适配 存在响应不及时、调整效果不明显的问题。

所述目标应用场景如图4-14所示。由基础设施提供商 InP 提供的物理网络 SN 、虚拟网络 VN 以及由服务提供商 SP 通过部署云应用提供的服务之间的关系可抽象为相互依赖的三个层叠平面结构。其中 服务层实例由服务提供商以预定义模板的形式通过IaaS平台部署云应用来构建。在此过程中 云应用运行期所需的虚拟网络通过将模板中包含的依赖资源描述文件转换为虚拟网络来构建请求 然后由IaaS平台处理并创建对应的虚拟网络实例。运行期间 服务提供商可根据业务目标调整预期的服务质量目标 云管理系统则定期根据服务质量目标和历史监控指标数据生成虚拟网络重配置请求 修正虚拟网络配置以规避风险。

图4-14? 基于虚拟网络的服务部署逻辑层次映射

服务质量目标是服务提供商向其用户提供的请求响应时间、请求并发量等业务服务质量承诺。基础设施提供商以虚拟网络的形式向服务提供商交付所需资源。为了方便计算 所有网络资源量 网络带宽、计算资源 被抽象定义为整数。在图4-14中的物理网络层中 标注于物理网络节点和物理网络链路之上的以斜线分隔的数字分别代表可用资源和资源总量 在虚拟网络层中 标注于虚拟网络节点和虚拟网络链路之上的数字代表需要的资源量。

4.6 ?自治控制 应用运维过程的自动化管理4.6.1 ?技术简介

基于自治控制的理念实现应用智能运维系统也是降低人工运维工作量的一种思路 对该课题的研究已存在一些行之有效的研究成果。其中 大多数成果集中在通过经典控制理论、自治计算和机器学习来实现集中式的资源管理方面。D.Ionescu等人[36]提出了一种基于IBM MAPE-K[37]自治控制框架的虚拟环境管理平台设计方案 其能够通过集中控制节点实现资源的自交付 Self-Provisioning 及自优化 Self-Optimization 。自治计算的处理被视为一种具有持续线性参变不确定性的非线性不确定系统。P.T.Endo等人[38]设计了面向云计算基础设施的自治云管理系统 该系统能够对云基础设施的资源使用率做持续优化 并降低运维管理成本。为了研究云计算服务自治管理的可观测性和可控制性 L.Checiu等人[39]提出了基于自治计算模型的输入 状态 输出 Input-State-Output 数学模型。通过预定义策略实现自治管理是一种简洁有效的手段 M. Sedaghat等人[40]基于这种理念提出了基于策略的自治云环境管理方案。该方案利用更高层次的管理系统监控整个云计算环境与其中部署的服务的状态 当发现服务状态不能满足业务目标时 则调整底层资源控制策略来适应变化。Wenjie Liu[41]则利用不同类型的应用 如计算密集型应用、存储密集型应用 对不同类型的资源的消耗程度存在差异的特点 将不同类型的应用系统自动调配部署 从而提高了资源使用率和提升了应用可用性 达到了云计算环境下自治管理云计算资源的目标。

自治管理是为了降低日益复杂的数据中心环境中人工干预管理的复杂度 通过自动化的监控、管理和控制手段来代替传统人工手动处理异常、管理配置等的过程。当前常用的自治管理技术是IBM提出的MAPE-K自治计算框架 Autonomic Computing Framework 。MAPE-K是Monitor、Analysis、Plan、Execution and Knowledge Base的缩写 其主要设计理念是以知识库为核心构建集监控、分析、计划和控制于一体的闭环自动控制系统 从而实现能够自配置 Self-Configuration 、自恢复 Self-Healing 、自优化 Self-Optimization 和自保护 Self-Protection 的自治控制系统。自治计算的层次可分为以下两种。

1 自治元素 Autonomic Elements 自治元素是组成自治系统的基本元素 如具有自治功能的服务器、路由器等设备。

2 自治系统 Autonomic Systems 自治系统给自治元素提供一个相互合作、通信的环境 并且提供人机界面。

每个自治元素拥有一个MAPE-K闭环自动控制系统。在结构上 自治元素包含传感器、执行器及知识库 Knowledge Base 三部分。传感器负责感知周围环境 执行器通过推理分析得到需要执行的动作集合以调整和控制外部环境。推理和分析过程是依靠知识库中记录的数据来完成的。在一个自治计算环境中 新加入的元素将被自动设置 不同的自治元素间相互合作完成一个任务 这个任务可能由管理员通过所谓的政策来指定 但这个政策的定义是用高层语言编写的。各自治元素通过项目合作、谐调、优化来完成任务。

4.6.2 ?深入浅出应用实践

通常 部署在云环境下的互联网应用所面临的环境是开放的、动态的 云与云应用之间应能按多种静态链接和动态合作方式 在开放的网络环境下实现互连、互通、协作和联邦。这就要求建立能够支撑云环境下服务交互的云服务管理框架 采用面向服务的方式动态组织应用系统之间的服务交互 并且能够面向特定的应用场景 基于语义知识自主地做出交互服务决策。这种具有自适应服务交互特性的运行支撑框架涉及的研究内容包括以下几方面。

1 自适应组合服务技术。对于公共云服务 用户的业务目标通常需要通过多个服务的组合来实现 这就需要建立一种被调用者和调用者一对多的关联关系 并提供相应的组合策略。这一过程涉及的需要突破的关键技术有面向服务的业务目标分解技术、聚合服务技术和多目标服务组合技术。

2 云协同服务技术。公共云服务是一个复杂的需求形态 需要跨机构、跨领域的服务协同才能完成。因此 运行支撑框架 需要研究能支持服务需求特征提取 业务流程编排 跨域服务交互 协同运行监控 实现跨组织、跨地域、多应用系统协同服务的技术 从而满足云计算复杂应用系统的业务敏捷化的需要。

3 服务动态演化技术。服务的动态演化是支持云计算多变环境下自适应特征的一个良好体现。互联网的开放、动态和多变 以及用户使用方式的个性化要求 决定了云应用下的服务构件在发布之后 会在长时间内持续不断地演化 不同服务之间的运行、调整和演化并不是独立的 需要相互协作。服务的动态演化包含了服务构件本身的演化及聚合服务的动态演化 主要需要解决两方面的技术问题 服务调用的透明性技术和服务状态转换技术。

在典型的能够支撑多个云应用运行的多主机集群云计算环境下 基于集中部署的管理系统提供了对负载及资源使用率都在动态变化的云应用的性能和稳定性的保障能力。同时 提升主机、网络设备的资源使用率需要考虑很多动态变化的不确定因素 采用集中控制逻辑实现会非常困难。基于多智能体系统 利用多智能体协作方式解决此类问题 能够有效降低集中控制策略的复杂度和系统实现的工作量 被业界广泛采纳。

多智能体技术是实现软件系统自治的一个主流技术 也是解决复杂应用运维行之有效的技术方案。软件智能体能够系统化地开发可以适应随机的、动态的变化环境和情况的复杂应用。智能体的主要特征可归纳为封装、面向目标、反应性、自治性、主动性、交互性和持久性[42]。与对象相比 智能体间的交互更像请求服务而不是方法调用。关键是 与智能体交互相比 面向对象的方法缺少能够灵活控制方法双向调用通信的概念和机制。面向对象的构件的元素都是在设计期预定义好的、静态的 而在面向智能体的软件工程中 元素是动态创建的 因此 智能体比传统构件显示了更多的行为和灵活性。智能体间的交互需要一个智能体平台 智能体的通信通常采用智能体通信语言 ACL 。随着智能体理论和技术研究的不断深入 许多学者将智能体的概念、理论和技术引入软件工程领域 出现了面向智能体的软件工程。近年来 面向智能体的软件工程受到了学术界和工业界的高度关注与重视。至今 人们已经提出了许多面向智能体的开发方法学、程序设计语言 以及CASE工具和集成开发环境。研究人员正试图从更广的范围系统地开展面向智能体软件工程方面的研究 包括面向智能体的软件复用、项目管理、形式化规范、系统验证和模型检测。领域内也涌现出一批面向智能体软件系统的专业化公司及产品 如Agent Oriented Software Ltd。IBM、Microsoft、Fujitsu和Toshiba等著名软件产品生产商也纷纷加强在该领域的技术和产品研发。OMG和FIPA等国际标准化组织也开始致力于智能体技术的标准化工作 并推出了一系列关键的智能体技术规范和标准 如FIPA提出了智能体通信语言。如今 面向智能体的软件工程正与其他计算机技术进行着更加紧密的结合 如面向服务的计算、语义Web、对等计算、普适计算、网格计算和自治计算等[43]。一些开源的智能体平台产品 如JADE、Tryllian智能体软件开发包、KATO也逐渐获得了业界的广泛应用。

?

案例

虚拟化技术的快速发展使得应用与基础设施环境解耦 为实现更灵活的资源配置交付奠定了基础。云计算使得将虚拟化的计算、存储、网络资源以随需即取的服务形式交付给目标用户成了可能。这种商业模式使企业用户能够以更低的成本灵活、快速地开发和部署应用系统。借助云服务 应用部署人员能以更加敏捷的方式配置和部署具有随需动态伸缩、迁移能力的云应用。当前 基础设施即服务 Infrastructure as a Service IaaS 平台已被广泛应用 云应用开发平台即服务 Platform as a Service PaaS 服务平台及直接面向终端用户的软件即服务 Software as a Service SaaS 也逐渐成熟。然而 由于不同云平台在相同配置下存在计算、存储、网络性能的差异 且云应用负载和资源使用率随时间动态变化 如何实现云应用运行期资源的自适应配置 在保障预定义应用服务质量目标的前提下支撑云应用资源分配策略随负载动态衍化以提升资源使用率 是目前该领域需要攻克的关键难题之一。

为了实现云应用资源的自适应配置 首先要能够实时探查云应用的运行期状态 通过分析历史指标数据推理判断云应用资源是否处于资源超配或资源配置不足的状态 之后生成对应的任务 自动调整资源配置。为实现目标效果 需要构建具备运行期监控指标采集、监控数据存储分析和管理控制能力的跨平台监管系统。

云计算环境将物理设备和应用解耦 应用运行直接依赖云计算环境 间接依赖物理设备。云计算环境为多应用提供运行期支撑服务 物理设备不再被一个应用独占。当物理设备、云计算环境中的虚拟设备或应用本身发生资源配置风险时 将影响应用的直接运行。为了有效监管云应用与云计算环境的运行状态 自动发现并处理资源配置风险 本书提出了如图4-15所示的云应用运行期管理系统模型。该模型分为应用层风险分析子系统和环境层管理子系统 两个子系统通过消息通信来交换监控指标数据集和风险处理任务。

图4-15? 云应用运行期管理系统模型

环境层管理子系统包含的关键组件如下。

环境监视器 部署在云计算环境中的环境管理节点 可以是物理服务器或虚拟服务器 定期采集环境中各资源 物理主机、虚拟主机、网络、操作系统等 运行期的监控指标并将指标数据保存在云环境知识库中 以便供应用处理器查询。

环境控制器 部署在云计算环境中的环境管理节点 接收任务处理器发送的环境控制指令 如迁移虚拟机、提高虚拟机CPU的配额、重启虚拟机等 将指令转换成可直接执行的程序 并通过接口调用执行动作。

任务处理器 部署在云计算环境中的环境管理节点 与云应用中的应用风险分析器通信 向其发送指定资源运行期的指标数据集 接收应用风险分析器发送的环境控制任务。

应用层风险分析子系统包含的关键组件如下。

应用监视器 部署在云应用中 定期采集云应用中各服务运行期的监控指标 并将指标数据保存在云应用知识库中 供应用风险分析器查询。

应用知识库 部署在云应用中 存储应用监视器定期采集的指标数据。

应用风险分析器 部署在云应用中 负责维护云应用运行期监控指标的关联推理模型 定期读取云应用知识库中的监控指标数据集和环境层管理子系统从云应用运行支撑的云环境中采集的监控指标数据集 以便更新模型属性 定期执行告警判断策略 并在告警触发时执行风险自动处理 推理任务执行策略 然后向环境层管理子系统中的任务处理器发送任务。应用风险分析器由如图4-16所示的三个核心模块组成。

图4-16? 应用风险分析器的组成

概率推理模型生成模块 通过分析定期采集的包含虚拟设备指标历史数据及服务质量指标历史数据的历史数据集 生成基于贝叶斯网络的概率推理模型。

虚拟设备重置请求推理模块 部署在云应用中 存储应用监视器定期采集的指标数据 基于服务等级协议中的服务质量目标定义 利用随机本地搜索算法搜索给定的数学模型 查找资源超配与资源不足概率最大的虚拟节点及虚拟链路 同时通过计算找到各虚拟节点及虚拟链路需要追加或释放的资源量。

虚拟设备重配置请求处理模块 基于推理结果对指定虚拟设备进行重配置。

本章小结

应用智能运维系统能够在降低应用运维系统日常工作压力的同时 赋予运维人员、应用开发人员在发现、处理更复杂的应用系统故障或优化系统性能和稳定性过程中更准确的判断能力。本章深入浅出地介绍了一些常用的应用智能运维技术与实践案例 分别从技术原理和技术应用落地的角度做了介绍 希望能为企业规划应用智能运维系统的前期技术预研提供参考。

本文转自网络，原文链接：https://developer.aliyun.com/article/785113
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！