【.com原稿】随着互联网+时代的到来，京东金融业务规模不断扩大，业务场景不断创新。然而，业务变化的速度超乎想象，相应的SOA和微服务架构在不断深化，服务数量不断膨胀，线上环境越来越复杂，服务依赖每天都在变化。如何实时看到系统的容量水平，为容量评估和系统扩容提供客观依据？当故障发生时，如何准确判断影响范围？如何确定每笔交易中各系统的处理时间？系统在处理一个事务时，有多少时间花在了数据库、NoSQL、缓存、日志、RPC、业务逻辑上？如何快速判断系统真正的瓶颈？面对以上问题，本文将从智能容量评估和智能报警切入，与大家分享京东金融的运维实践。智能容量评估应用的容量评估是一个长期存在的难题。目前还没有简单有效的方法。主要方法是通过压测直接获取应用单机最大QPS的相关数据。离线压测为了测试数据的相对真实性，在容量评估的离线压测中，一般会使用tcpcopy等工具，将在线流量直接复制到测试服务器，在应用出现异常时，获得最佳效果。测试服务器QPS有瓶颈，然后用在线离线换算系数计算在线应用可以承载的容量。注：此图转自tcpcopy官网。在线压测的优点是可以通过离线压测进行容量评估。压测过程对线上环境几乎没有影响，但过程繁琐耗时。因此，以短平快为特点的互联网公司更倾向于通过线上压测的方式进行容量评估。如何进行线上压测？一般来说，无论是通过集中式负载设备（如F5、Radware等），还是四层、七层软负载（LVS、Nginx、HAProxy等）或开源服务框架（如SpringCloud、DUBBO等）都支持加权轮循（WeightedRoundRobin）。简单的说就是不同的服务器在负载轮询的时候可以指定不同的权重。线上压测的原理是逐渐增加某台服务器的权重，使这台服务器的流量远大于其他服务器的流量，直到这台服务器出现性能瓶颈。这个瓶颈可能是CPU、LOAD、内存、带宽等物理瓶颈，也可能是RT、故障率、QPS波动等软瓶颈。当单机性能出现性能瓶颈时，工程师记录此时的应用QPS为单机容量，然后根据集群服务器数量很容易得到集群容量。下面的Nginx配置使得服务器192.168.0.2的流量是其他服务器的5倍。假设此时服务器192.168.0.2出现瓶颈，QPS为1000，则集群容量为3000。（假设负载没有瓶颈）http{upstreamcluster{server192.168.0.2weight=5;server192.168.0.3weight=1;server192.168.0.4weight=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远程调用、访问数据库、读写磁盘耗时等）的总耗时，耗时业务逻辑为主要分为两部分：线程运行耗时（RUNNABLE）线程等待时间（BLOCKED、WAITING、TIMED_WAITING）通过业务逻辑耗时的分类，我们知道真正消耗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次超时告警，此时ROOT分析可以收敛告警，直接分析出rootcause告警是系统A的数据库访问异常，导致A、B、C、D多个系统异常。这样就避免了处理人员和各个系统开发人员的沟通，协助处理人员快速定位问题根源，提高平均解决时间（MTTR）。如下图所示：根因告警调用链关系根因告警明细表根因告警分析主要分为强关联分析和机器学习两大类。A。强相关数据分析强相关是指已知的、确定的相关。例如：应用数据库与应用服务器网络设备与网络设备之间的调用链关系、网络设备与应用服务器宿主机与虚拟机之间的调用链关系等。如果在同一个时间窗口内，存在多个强关联设备或者应用服务器同时告警，很可能告警之间存在关联。在加权算法中，有一个重要的规则，链路上连续告警可能是相关的，后面的应用更可能是根本原因。下面我们通过实例计算各种根因告警。继续用上面的例子，D应用->C应用->B应用->A应用->数据库异常。第一个是计算数据库根警报。根据数据库关联关系，会导出数据库类型的数据库告警和A应用告警。还会产生应用类型A的应用数据库异常告警。根据数据库导出的告警，以及数据库和应用的关系和权重，可以断定是数据库异常导致A应用的查询超时。接下来是计算应用程序根警报。根据调用关系，我们先计算出多个连续应用告警的链接。目前D->C->B->A四个应用都有派生告警，符合这个规则。然后，找到最后一个告警应用，即应用A。列出时间窗口内应用A的所有衍生告警（可能有多个衍生告警，根据权重计算根因），标记衍生告警权重最高的作为根告警。例如：系统A中有两种派生告警，分别是数据库告警和GC告警。根据权重计算规则，数据库告警为90，GC告警为10，即数据库异常告警的权重为***。此时，由于数据库根告警与调用链根告警一致，两种告警会合并。***结论：数据库异常导致A、B、C、D系统告警。b.机器学习根因分析强关联数据分析是分析已知告警之间的关系，直接分析根因告警。但有时，关联关系是未知的。这时候就需要通过机器学习算法来寻找告警之间的隐含联系，进而预测告警的根源。目前，主要有两种类型的机器学习实践。1.关联规则算法关联规则算法主要进行Apriori算法和FPGrowth算法的实践。这两类功能类似，都可以找到频繁项集。经过实测，FPGrowth比Apriori更高效。我们按照一定的时间间隔划分时间窗口，计算各个时间窗口内各种告警一起出现的频率，找出各种告警之间的相关性。最后，根据分析出的相关性，生成根本原因告警。关联规则算法的优点是理解和实现起来比较简单。缺点是效率比较低，灵活性不够高。2.神经网络算法递归神经网络（简称RNN）是一种与时间序列相关的神经网络。对于单张图片来说，像素信息是静态的，但是对于一段文字来说，里面的文字组成是Sequentially的，通常后面的文字跟前面的文字有顺序关系。这时，卷积神经网络通常很难处理这种时序相关信息，但RNN却可以有效处理。随着时间间隔的增加，与更早的时间节点相比，RNN对较晚时间节点的感知会降低。解决这个问题需要使用LongShortTerm网络（简称LSTM），它通过刻意的设计避免了长期依赖问题。LSTM在实践中可以默认记住长期信息，而无需付出很多代价。某类故障引起的大量告警之间存在时间相关性。将历史派生的警报作为输入，将根本原因警报类型作为输出。通过LSTM提取导出的告警特征，建立告警关联分析模型。这样就可以将符合特征的派生告警实时划分为同类型的根告警，帮助用户快速定位问题。需要说明的是，金融本身的业务特性决定了对第三方的依赖，所以报警本身就比较随机，客观上导致了学习样本质量不高，需要长期的积累和修正才能达到更好的效果结果。所以对于根因告警，如果有条件获得强关联，建议使用强关联分析，可以达到事半功倍的效果。结语智能运维是目前运维领域最热的词之一，但个人认为智能运维没有普遍适用的产品，智能运维需要持续运行在真实环境中。达到我们想要的效果。随着人工智能在运维领域的不断试验和探索，未来运维领域的异常检测、智能告警和自动容量规划分配必将得到快速发展，从而成为运维的核心竞争力。操作和维护。京东金融集团资深架构师沈建林，曾在多家知名第三方支付公司担任系统架构师。致力于基础中间件和支付核心平台的研发。设计研发服务跟踪、流程编排等一系列中间件，参与多家支付公司支付核心系统建设。现任京东金融集团高级架构师，负责基础开发部基础中间件的设计与开发。擅长基础中间件设计与开发，专注于大型分布式系统、JVM原理与调优、服务治理与监控等领域。【原创稿件，合作网站转载请注明原作者和出处.com】编辑：王雪艳、陶家龙、孙淑娟
