直击传统运维痛点，京东金融智能运维实践

直击传统运维痛点，京东金融智能运维实践

随着互联网+时代的到来，京东金融业务规模不断扩大，业务场景不断创新。然而，业务变化的速度超乎想象，相应的SOA和微服务架构日益深化，服务数量不断扩大，在线环境日益复杂，服务依赖每天都在变化。

●如何实时看到系统的容量水位，为容量评估和系统扩容提供客观依据？

●发生故障时，如何准确判断影响范围？

●如何确定每笔交易中各系统的处理时间？

●处理一个事务时，每个系统在数据库、NoSQL、缓存、日志、RPC和业务逻辑上花费多少时间？

●如何快速确定系统的真正瓶颈？

面对上述问题，本文将从智能能力评估和智能报警的角度，分享京东金融的运维实践。

智能容量评估

应用的容量评估是一个由来已久的问题，目前还没有简单有效的方法，主要是通过压力测量的方式直接得到单个应用最高QPS的相关数据。

离线压力测量

为了测试数据的相对真实性，在能力评估的离线压力测量中，一般会通过tcpcopy等工具将在线流量复制到测试服务器，在测试服务器出现瓶颈时，获取应用最高的QPS。然后，可以通过线上线下的换算系数计算出线上应用的容量。

注:此图转自tcpcopy官网。

在线压力测量

通过离线测压进行容量评估的优点是测压过程对在线环境几乎没有影响，但过程复杂，耗时长。因此，具有短、平、快特点的互联网公司更倾向于通过在线测压进行产能评估。

如何进行在线电压测量？

一般来说，集中负载设备(如F5、Radware等)支持加权轮询算法。)、四七层软负载(LVS、Nginx、HAProxy 等。)或开源服务框架(如SpringCloud、DUBBO等。).简单地说，不同的服务器可以在负载轮询期间指定不同的权重。

在线测压的原理是逐渐增加某台服务器的权重，使这台服务器的流量远大于其他服务器，直到这台服务器的性能瓶颈出现。这个瓶颈可能是CPU、负载、内存、带宽等物理瓶颈，也可能是RT、故障率、QPS波动等软瓶颈。

当单机性能出现性能瓶颈时，工程师注意到此时的应用QPS就是单机的容量，然后根据集群服务器的数量就很容易得到集群的容量。

Nginx的以下配置使得服务器192.168.0.2的流量是其他服务器的5倍。假设此时服务器192.168.0.2出现瓶颈，QPS为1000，那么集群容量为3000。(假设负载中没有瓶颈)

http {    upstream cluster {    server 192.168.0.2 weight= 5;    server 192.168.0.3 weight= 1;    server 192.168.0.4 weight= 1;       }    }

容量计算

无论是在线压力测量还是离线压力测量，都反映了压力测量时所施加的容量。在互联网高速发展的今天，程序版本的迭代速度惊人。为每个版本迭代和环境变化进行在线压力测量是不现实和不可 *** 作的。

那么换个方式想，我们通过压力测量来评估应用的容量，是因为我们无法知道具体方法的时间在哪里。也就是说，被按压的物体对我们来说就是一个黑匣子。如果我们尝试打开黑匣子，就可以从理论上计算应用容量，实时评估应用容量。

因此，迫切需要寻找另一种方法来解决问题:QPS的瓶颈是什么？如果这个问题弄清楚了，就可以计算出应用的QPS。

结合下图耗时细节和应用的运行环境，可以找到具体的瓶颈。

举个简单的例子:

如果某个方法在某个采样时间内平均QPS为200，平均耗时为100ms，那么对耗时的详细分析显示，平均访问数据库6次，每次耗时10ms，即数据库总耗时为60ms，其余40ms用于业务逻辑。如何确定应用程序的容量？

如果数据库连接池的最大连接数为30，执行该方法的线程池的最大数量为50(为简单起见，暂时不考虑线程的切换代价)，那么单个数据库的理论最大QPS为30*1000/60=500。

同样，业务逻辑的最高QPS是50*1000/40=1250。显然，这种方法的瓶颈在于数据库，即这种方法的最高QPS是500。

然后优化这种方法后，数据库访问时间降低到5ms，平均访问次数为4次，即数据库总访问时间为 20ms，业务逻辑时间仍为40ms，此时单个数据库最高QPS为 30*1000/20=1500。这时候，明显的瓶颈就在业务逻辑上，即这种方法的单机最大QPS是1250。

上面的例子是单机最大QPS推断的一种方法。结合其他方法做同样的分析，通过计算该方法在整个应用中的资源占用率，可以计算出整个应用的单机最大QPS。

进一步分析，业务逻辑的耗时，即总耗时，除去IO的耗时(如RPC远程调用、数据库访问、磁盘读写等。).业务逻辑的耗时主要分为两部分:

●可运行线程正在运行。

●耗时的线程等待(阻塞、等待、定时等待)

按照业务逻辑耗时的分类，真正消耗CPU资源的是线程运行时间，那么问题就变成了如何得到运行时间与等待时间的耗时比。

CPU利用率(进程、线程)可以通过proc虚拟文件系统获得，这不是本文的重点，这里不讨论。不同的环境也可以通过不同的特征快速获取这些数据。以Java应用为例，我们可以从JMX得到线程执行的统计数据，大致计算出上述比例，如下图所示:

继续分析上面的例子。假设通过分析线程的运行情况，我们知道运行时间和等待时间是1:1，进程CPU的利用率是20%。那么CPU 指标支持的单机最大QPS为200*100%/20%=1000，即该方法的单机最大QPS为1000。同样，也可以推断出网络带宽等物理资源的瓶颈。

一般来说，在业务逻辑耗时中，CPU在计算密集型应用中占较大比例，而IO密集型应用则相反。

通过以上数据，我们可以实时评估系统的容量，如下图所示:

实时水位图的应用

智能报警

根本原因分析是基于网络拓扑，结合呼叫链，通过时间关联、权重、机器学习等算法，对告警进行排序和筛选，快速找到告警的根本原因。它可以从大量的告警中找到问题的根源，从而大大缩短故障排除和恢复时间。

报警处理步骤

●报警过滤(过滤掉不重要的报警和重复报警)

●生成衍生报警(根关联生成各种衍生报警)

●告警相关性(同一时间窗口内不同类型的派生告警之间是否存在相关性)

●权重计算(根据预设的各种告警的权重，计算成为根源告警的可能性)

●生成根本原因报警(将权重最大的衍生报警标记为根本原因报警)

●根告警合并(如果多种告警计算的根告警相同，则合并)

●根据历史告警处理知识库，找出类似根告警的处理方案，智能给出解决方案。

根本原因报警示意图

例如:

假设多个系统通过RPC进行服务调用，调用关系如下:D系统->:C->:B->:A系统。

当A系统数据库发生查询超时时，告警会逐层推进，导致B、C、d系统出现N个超时告警，此时根分析可以收敛告警，直接分析出根告警是A系统数据库访问异常，导致A、B、C、d系统异常。

通过这种方式，避免了处理器和每个系统开发者之间的通信，辅助处理器快速定位问题的根源，并且增加了平均解决时间(MTTR)。如下图所示:

根报警调用链关系

根本原因警报列表

根源分析主要分为强相关性分析和机器学习。

A.强相关数据分析

强联想是指已知的、明确的联想。比如:

●应用程序之间的调用链关系

●数据库和应用服务器

●网络设备和网络设备、网络设备和应用服务器

●主机和虚拟机之间的关系等

在同一时间窗口内，如果多个强相关的设备或应用服务器同时报警，则这些报警很有可能是相关的。

在加权算法中，有一个重要的规则。链路上的连续告警之间可能存在关联，应用越晚越有可能是根本原因。现在我们根据实例计算各种根源告警。

继续用上面的例子，dapply->:C->:B->:A->:数据库的异常情况。

●首先计算数据库根告警。根据数据库关系，会派生出数据库类型的数据库告警和应用告警。它还会产生一个应用程序类型应用程序数据库异常警报。

根据数据库派生的告警、数据库与应用的关系和权重，可以得出应用A的查询超时是由数据库异常引起的。

●接下来，计算应用根告警。根据调用关系，我们首先计算连续应用告警的链路。当前-->:C->；b->；答:四个应用程序产生了符合此规则的警报。

●然后，找到最后一个报警应用，即应用A。列出时间窗口内应用A的所有派生告警(可能有多个派生告警，根据权重计算根源告警)，将权重最高的派生告警标记为根源告警。

例如，系统A中有两种类型的派生警报，即数据库警报和GC警报。

根据权重计算规则，数据库告警为90，GC告警为10，也就是说数据库异常告警的权重最高。此时，因为数据库根告警与调用链根告警一致，所以两类告警会合并。最后得出结论:数据库异常导致A、B、C、D系统报警。

B.机器学习的根源分析

强关联数据分析是指已知告警的关联，直接分析根源告警。但有时候，关系不明。这时候就需要通过机器学习算法找到告警之间的隐含关系，进而预测根源告警。

目前机器学习的做法有两种。

1.关联规则算法

关联规则算法主要由Apriori算法和FPGrowth算法实践。这两种函数类似，都可以发现频繁项集。经过实际测量，FPGrowth比Apriori更高效。

我们按照一定的时间间隔划分时间窗，计算各时间窗内各类告警出现的频率，找出各类告警之间的相关性。最后，可以根据分析的相关性生成根本原因告警。

关联规则算法的优点是易于理解和实现。缺点是效率低，灵活性不够高。

2.神经网络算法

递归神经网络(简称RNN)是一种与时间序列相关的神经网络。对于单张图片来说，像素信息是静态的，而对于一个段落来说，里面的词的构成是顺序的，通常情况下，后面的词与前面的词是顺序相关的。

此时，卷积神经网络通常很难处理这类时间序列关联信息，但RNN可以有效处理。

随着时间间隔的增加，RNN对后一时间的节点的感知会比前一时间的节点减少。要解决这个问题，需要长短期网络(LSTM)，通过刻意的设计可以避免长期依赖。在实践中，LSTM可以默认记住长期信息，而无需付出很大代价。

某类故障引起的大量告警之间存在时间相关性。历史衍生报警用作输入，根报警类型用作输出。通过LSTM提取衍生的告警特征，建立告警相关性分析模型。这样就可以将符合特征的衍生告警实时划分为同类根告警，帮助用户快速定位问题。

需要注意的是金融本身的业务特点决定了其对第三方的依赖性，因此报警本身的随机性较大，客观上导致学习样本的质量较低，需要长期的积累和修正才能达到较好的效果。所以对于根源告警，如果获得强相关性，建议使用强相关性分析，可以达到事半功倍的效果。

结论

智能运维是目前运维领域最热的词汇之一。但是我个人认为没有一个智能运维产品是放之四海而皆准的，智能运维需要在真实环境中不断的磨合才能达到我们预期的效果。

随着人工智能在运维领域的不断尝试和探索，未来运维领域的异常检测、智能告警和自动容量规划与分配将得到快速发展，从而成为运维的核心竞争力。

沈建林●京东金融集团高级架构师

曾在多家知名第三方支付公司担任系统架构师，致力于基础中间件和支付核心平台的研发，主导设计开发了RPC 服务框架、数据库子数据库和子表、统一日志平台、分布式服务跟踪和流程安排等一系列中间件，参与了多家支付公司的支付核心系统建设。现任京东金融集团高级架构师，负责基础开发部基础中间件的设计和研发。擅长基础中间件设计与开发，重点研究大型分布式系统、JVM 原理与调优、服务治理与监控等。