宜信智能监控平台建设实践|分享实录

摘要：介绍宜信智能运维平台UAVStack的设计思想、技术架构和核心功能，及落地实践经验。

内容来源：宜信技术学院第6期技术沙龙-线上直播|宜信智能监控平台建设实践

主讲人：宜信高级架构师 & 智能监控平台负责人谢知求

1、UAVStack平台的产生背景

目前业界经常使用的监控软件有不少，主流产品或以监控深度见长、或以监控广度见长。

• 关注监控广度的表明产品是Prometheus，其特色是生态圈活跃，针对常见的互联网中间件（如MySQL、Redis、Kafka、RocketMQ、MongoDB、ElasticSearch等）均提供了现成的指标采集插件来进行监控。相似产品还有Zabbix、Nagios和Open-Falcon。
• 关注监控深度的产品也有不少，如听云、OneAPM、PinPoint、SkyWalking。这类软件通常是探针型的，在应用性能监控方面提供了更深刻的监控能力。

这些产品各有优点，也存在不足之处：

• 没法兼顾监控的广度和深度；
• 没法同时支持实时指标、调用链和日志三类类数据的采集，未考虑这三类功能的集成连通性，没法解决数据的时效、品控、对齐等问题。

为了克服上述不足，同时知足公司多样化和智能化的监控需求、下降二研的成本和难度，咱们自主研发了全维监控与智能运维基础平台（UAVStack）。

做为智能监控平台，监控仅仅是智能化运维的第一环。咱们认为，智能运维(AIOps)能够分三步走：全维监控、全维关联和全维智能。

• 第一步：全维监控，经过统一的采集体系，采集全维度的监控数据，包括系统、应用和服务的画像数据、实时指标数据、调用链数据和日志数据。
• 第二步：全维关联，获取全维度的监控数据后，须要进一步创建数据之间的关联关系。这种关联关系能够是经过画像、服务流图谱或调用链数据创建的强关联关系，也能够是经过机器学习算法创建的关联关系。经过全维关联，能够在监控数据之间创建实时关联关系；有了关联关系，咱们就能够作根因分析了。
• 第三步：全维智能，经过引入包括异常检测、根因分析、智能降噪及任务机器人等AI服务，用机器取代人进行一些决策，从而持续提高公司智能化运维的水平。

2、UAVStack平台的整体技术架构

2.1 全维度监控+应用运维解决方案

使用UAV的全维监控和应用性能管理工具集能够搭建一站式全维度监控+应用运维解决方案。

首先，UAV在每一个物理机、虚拟机以及容器上部署一个监控代理程序（MonitorAgent，MA）。MA其实是部署在宿主机上的独立JVM进程。

其次，在每一个JEE中间件、JSE应用或其余JVM语言应用中，可经过Java Agent的形式植入监控探针，监控探针会与应用在同一个JVM进程中一块儿启动。

监控探针启动时，会自动对应用进行画像和监控。应用画像包括服务组件、客户端组件和日志组件的画像。

• 服务组件是应用对外暴露服务能力的接口，如服务URL；
• 客户端组件是应用访问的其它服务或第三方数据源（如MySQL,、Oracle、 Redis、MQ等）客户端；
• 日志组件是应用输出的日志。

除对以上三类组件进行自动画像和实时数据采集外，监控探针也会记录每一个请求/响应生成端到端的调用链路，绘制各个应用/服务之间的调用关系，并生成服务图谱。

监控代理程序（MA进程）会定时拉取监控探针采集的数据，同时也会采集应用环境的性能指标（如CPU、内存、磁盘IO等）。此外，MA还提供了插件机制，支持个性化指标的采集。

最终，咱们采集到了包括指标Metrics、调用链Tracing及日志Logging的全维度监控数据。其中：

• Metrics数据包括：业务自定义指标、应用环境性能指标、应用集群/实例性能指标、服务组件/客户端组件/URL性能指标。
• Tracing数据包括调用链指标、客户端体验（UEM）数据。
• Logging数据包括日志、线程栈（Thread）数据。

2.2 监控探针架构

UAV采集侧主要包括监控Agent和监控探针两部分。

• 监控探针负责应用层面的监控。
• 监控Agent负责应用环境层面的监控，同时会定时拉取监控探针的数据并上送给UAV服务端。

上图所示是监控探针的架构图。随着UAV功能的加强，探针已不只仅用于监控目的，如今已经更名为中间件加强框架。

上图左边能够看到，中间件加强框架位于应用服务器和应用之间，采用了中间件劫持技术，对应用服务器的代码进行了类加载劫持和字节码改写，对上层应用代码无侵入。

右边是监控探针放大以后的架构图，最底层是应用服务器适配层，对互联网经常使用的开源中间件（如Tomcat、Jetty、SpringBoot）提供了适配支持，对其它服务器能够相应地扩展一个Adapter适配器来进行支持。

在适配层之上，首先提供了一系列通用的扩展点SPI，再基于这些SPI，扩展出了与监控相关的画像收集和指标采集功能；与问题诊断分析工具相关的调用链跟踪、浏览器跟踪、JVM线程分析、堆内存dump执行等功能；与服务治理相关的服务限流/降级以及服务安全管控等功能。此外，还提供了这些功能对Docker和K8s容器环境的适配。

最上层提供了应用对接API以及数据发布API，支持经过HTTP和JMX两种方式来获取探针上的监控数据。

2.3 数据捕获架构

接下来将介绍UAV数据捕获和传输的架构。

从上图能够看到，监控代理程序Agent数据传输采用了双通道+双心跳的方式：

1）双通道是指HTTP心跳和MQ传输这两条通道：

• Http心跳传输通道，用来传输应用环境相关的监控数据，主要包括：容器/节点画像数据和实时监控数据；
• MQ传输通道，用来传输应用相关的监控数据，主要包括：应用实时数据，画像数据，日志数据，以及调用链和JVM线程栈等APM数据。MQ数据传输通道上的数据格式采用了统一的Schema，方便后期对数据的转换和处理。

2）双心跳是指无论来自Http通道仍是MQ通道的数据，实际上既能够当作监控数据，也能够当作心跳数据。来自每一个通道的数据都会到UAV监控后台服务“签到”。两种通讯方式意味着更高的可靠性。

Agent经过双通道的方式，将数据传输到UAV监控后台，咱们称之为健康管理服务。

健康管理服务会根据数据类型对监控数据进行解析处理，并分别持久化到合适的数据源，好比OpenTSDB存储时序指标数据；ES存储日志、调用链、JVM线程分析等APM数据。

AppHub是UAV的统一门户，提供了监控数据的集中展现及用户权限的管理功能。用户能够在PC端和移动端登陆UAV，得到随时随地的运维体验。

健康管理服务也是采用微服务架构构建的，包括多个微服务，支持集群部署和扩容。

3、UAVStack平台的核心功能及其原理（附案例）

3.1 UAVStack核心功能

上图展现了目前UAVStack的核心功能，主要包括：应用监控、应用环境监控、服务流、调用链、JVM监控、数据库监控、日志监控、性能告警、浏览器跟踪、配置中心、时空沙盘、上帝罗盘、服务治理、容器生态支持、业务监控、智能运维（AIOps）等。其中：

• 浏览器监控：用来监控前端Web页面的性能数据；
• 时空沙盘：提供了对历史监控数据的查询；
• 上帝罗盘：提供了监控大屏的展现；
• 智能运维（AIOps）包括：异常检测、根因分析、告警收敛和智能降噪、任务机器人四个方面的能力。

此外，还包括图上未列出的一些运营支持的相关工具，如UAV统一升级中心；UAV监控日报、周报、月报；UAV使用状况统计等。本次分享将重点介绍上图中白色字样的功能。

3.2 应用监控

首先介绍UAV应用监控的核心原理。

3.2.1 核心原理：对应用代码无侵入技术

UAV应用监控的核心原理是：对应用代码无侵入技术。

• UAV对应用代码无侵入，应用无需任何改造。
• UAV不须要应用使用统一的开发框架。

UAV的代号是“无人机”的缩写，寓意：无人机翱翔蓝天，智能地、透明地完成任务。

其中用到的核心技术主要包括：

• 中间件劫持技术，含Java Agent探针和字节码改写；
• 应用/服务画像与监控技术。

3.2.2 无侵入技术：应用/服务画像

监控探针经过中间件劫持技术实现对应用/服务的自动画像和监控。

• 中间件劫持就是将咱们本身的代码植入到中间件的各类行为中。
• 中间件劫持的核心是：掌控类加载树，获取优先加载权，植入咱们本身的代码。

以应用/服务画像为例：

• 当Web容器中Standard Context这个类加载时，经过字节码改写植入了相关的画像代码。JEE应用启动时会执行植入的代码，生成应用画像和服务画像；
• 应用画像主要包括：应用标示、应用名称、应用的URI：http(s)://<本地IP>:<端口>/、应用的类库信息（从加载应用的webapp class loader中获取）；
• 服务画像是按照JEE技术规范进行扫描的，经过扫描注解和部署描述符，提取了服务注册相关的信息，从而生成了服务画像。

3.2.3 无侵入技术：应用/服务监控

与应用/服务画像相似，应用/服务监控也是在加载服务器相关类时，经过字节码改写植入相应的监控代码。

以Tomcat为例：

• CoyoteAdapter负责整个Tomcat的服务请求；StandardWrapper负责全部Servlet的服务请求。
• 加载这两个类时，UAV会经过字节码改写植入监控代码。当有实际请求发生时，会调用植入的请求拦截代码和响应回复拦截代码，进行性能指标的采集。
• 采集到的性能统计指标会缓存到全局计数器中，后续由监控Agent集中采走。

上图所示是应用监控的一个实际展现界面。

能够从应用集群的展现界面，钻取到应用实例的监控展现界面，再钻取到自动画像出来的服务组件/客户端组件和日志组件的展现界面，最后再钻取到服务组件/客户端组件的每一个URI的监控指标界面以及日志展现界面。能够从全局钻取到细节，获取想看的监控数据。

此外，咱们还提供了服务URL监控报表和客户端URL监控报表。

以服务URL监控报表为例：

• 能够直观地看到该应用中全部服务URL的访问计数、平均响应时间、累计访问计数、累计错误计数、成功率等指标在选定时间区间内的统计数据。
• 时间区间支持最近10分钟、最近3小时、今天、昨天、最近7天以及自定义的任意时间区间。

如上图，点击查看某个URL的详情，能够查看该URL在不一样时间区间的详细报表。

3.3 应用/服务拓扑：服务流

接下来介绍服务流相关的功能。基于应用/服务画像和监控数据，UAV提供了服务流的功能。服务流涵盖了应用拓扑的内容，但提供了比应用拓扑更丰富的运行时状态的展现。

从上图能够看到，当前服务位于中间位置，左边是调用当前服务的服务，右边是当前服务调用的其它第三方服务。

在服务流图上，连线的粗细表示调用量；连线的颜色表明健康情况，以响应时间和错误数为参考：绿色表明健康、黄色表明警告、红色表明严重。好比当连线为粗红线时，表明着有大量请求发生了错误。

如图，咱们能够从全局的服务流钻取到某个业务线的服务流，再钻取到该业务线下某个应用集群/实例的服务流，进行全局范围的性能追踪。

3.4 调用链

3.4.1 调用链：全链追踪

调用链分为轻调用链、重调用链和方法级调用链。

• 轻调用链也叫基本调用链。应用无需任何改造，能够运行时启动和中止。获取的数据包括服务/请求URL、服务类+方法、调用类+方法、耗时、结果状态+异常、应用特征、技术栈特征等，性能开销能够忽略；
• 重调用链是在轻调用链的基础上增长了对请求/响应数据报文的获取，性能开销稍大，依据报文数据量通常会有5%的性能降低；
• 方法级调用链：若是不开启方法级调用链，则仅在服务的入口和出口生成调用链节点。若是想要在应用内部也生成调用链节点，可使用方法级调用链。能够经过AppHub界面配置须要跟踪的类和方法。方法级调用链的性能开销较小，具体消耗取决于报文数据量。

3.4.2 调用链：实现原理

上图展现的是一个调用链具体的生成流程。调用链节点主要是在服务接口代码处和客户端调用代码处生成。若是开启了方法级调用链，也会在过程方法代码处生成调用链节点。

此外，介绍一下关于调用链上下文的传递。

服务内上下文的传递：同线程的状况下使用了基本ThreadLocal；跨线程（池）的状况下使用了可传递ThreadLocal（TTL）。

服务间上下文的传递：经过客户端劫持（client hook)对原协议（如HTTP，RPC，MQ）进行适配，并在协议头注入调用链上下文的元数据。传输到下一个服务接口的时候，会由下一个服务解析协议头里的调用链上下文元数据，从新构建调用链上下文，而后再继续往下传递。

3.4.3 调用链：关键技术

调用链的实现主要使用了4个关键技术。

• 服务内上下文的传递。主要基于原threadlocal实现了支持父子线程之间值传递的threadlocal。
• 服务间上下文的传递。经过客户端劫持（client hook），对原协议进行适配，并在协议内注入调用链上下文元数据。
• 报文体内容提取。重调用链提取请求/响应数据报文体内容时，为把对应用的影响降到最低，使用了servlet wrapper机制在用户读取报文体时进行数据转存（利用string池的属性最小占用内存）。
• 调用链数据的收集和处理。经过agent对调用链数据进行抓取，HM端进行数据解析入库并提供查询接口，使用极简数据格式最小化占用带宽。

3.4.4 调用链展现：可视化，可关联日志，快速定位问题

这是调用链的实际展现界面。在调用链列表上，

• 能够一键获取最近1分钟、最近12小时前100及最近1小时最慢的调用链。
• 能够根据应用服务的特征，按照时间区间或业务关键词自定义搜索相关的调用链。
• 在调用链的任何环节，均可以查看整个端到端的完整的调用链。
• 经过端到端完整的调用链的展现，能够快速发现调用缓慢的瓶颈或出错的节点。
• 可从调用链的任意节点跳转到日志界面，查看该调用链环节对应的日志。
• 能够从日志界面跳转到该日志对应的调用链，查看该日志位于完整调用链路的哪一环，从而帮助咱们快速排查和定位问题。

3.4.5 调用链展现：查看请求/响应报文

开启了重调用链的状况下，咱们能够查看请求/响应报文的详细数据。

上图中能够看到，开启了重调用链的状况下，咱们能够获取到请求头信息、请求内容、响应头信息、响应内容等详细数据。

3.5 日志监控/管理

3.5.1 日志捕获架构

上图所示是UAV日志功能的架构图。UAV日志功能采用了日志管理系统流行的EKK架构，包括日志的采集、上送Kafka、ES存储/查询、RAID历史备份/下载以及基于异常/关键字和时间的统计和告警功能。

应用服务器上的Agent采集、读取日志，并把读取到的数据发送到Kafka集群上。

• 对于需热查询的日志，由logging-store程序从Kafka读取日志并保存到ElasticSearch集群中；
• 对于需冷备份的日志，由logging-raid程序从Kafka读取日志，先存到本地磁盘，天天凌晨会将本地日志按天压缩，备份到RAID集群中。

日志的统计和告警功能：由logging-statistics程序从Kafka读取异常、关键字、Nginx日志，并以分钟为单位统计数量，保存到Redis中，供后续统计展现和告警。

具体日志展现界面在介绍调用链关联到日志部分已出现过了，这里就不赘述了。

3.6 性能告警

3.6.1 性能告警：多指标联合表达式，流式/同比/环比，双收敛，反馈动做

UAV获取到全维度的服务端指标集、客户端指标集、日志指标集和自定义指标以后，能够设置多指标联合告警条件，这些条件包括流式/同比/环比的条件（“同比”好比今天10点和昨天10点的对比；“环比”好比最近5分钟和上一个5分钟的对比），能够混合使用构成联合表达式。

为避免告警轰炸，UAV提供了2种告警收敛策略：时间冷却收敛和梯度收敛。梯度收敛策略上，咱们配置了“1”“5”“10”，即第1次、第5次、第10次知足告警条件时才会发送告警提醒，其余时间则进行压制处理，不发送告警提醒。

告警可经过短信、邮件、微信及移动App推送通知到人，也能够经过HTTP方式通知其余系统。

3.6.2 性能告警：预警策略模板、灵活的策略编辑、多种通知

建立预警策略时，可使用预警策略模板。上图是系统里的预警策略模板截图。

选定策略类型以后，预警策略的规则和条件会根据咱们缺省推荐的套餐自动设置，用户只要配置须要报警的目标范围和通知方式，直接保存就能够了。也能够调整模板套餐里的阈值和报警表达式。此外，告警也支持运行时动态启用和禁用。

3.7 JVM监控分析

3.7.1 JVM监控分析工具：总体架构

JVM监控分析工具基于UAVStack已有总体架构，如上图所示。总体分为前端、后台及探针MOF部分。

• 前端负责数据展现以及向后台发送用户的执行指令。
• 后台负责将指令下发到具体节点及结果的归集和处理。
• 监控探针MOF负责接收后台下发的指令，执行指令返回结果。

其中在探针部分：

• JVM实时监控数据，如堆内存大小、Minor GC和Full GC的状况，都是经过JMX提供的接口来获取。
• JVM堆内存采样分析数据和CPU采样分析数据，则经过JDK提供的Java Attach API进行获取。

3.7.2 JVM监控分析工具：监控功能展现

上图是JVM监控分析工具的监控功能展现页面。JVM监控分析工具的功能主要包括：

• 基本信息Tab显示JVM基本信息，包括JVM版本、启动时间、JVM参数、系统属性等。
• 监控Tab提供JVM实时监控指标展现，包括CPU、线程、内存、GC统计等。用户能够切换时间/区间，好比最近10分钟、最近3小时、今天、昨天、最近七天或自定义的时间/区间，查看不一样时间/区间内的JVM监控数据。
• 线程分析和内存Dump Tab提供了JVM线程分析与JVM堆内存Dump在线工具。
• CPU采样和内存采样Tab提供了JVM堆内存采样分析和CPU采样分析工具。

3.7.3 JVM监控分析工具：堆内存采样和CPU采样分析

• 堆内存采样分析可实时采样JVM的堆内存分配、每一个类实例对象的数量以及这些实例所占用的内存大小，从而辅助定位内存泄露的根源。
• CPU采样分析可实时采样JVM每一个方法的CPU执行时间，可辅助定位热点方法。好比CPU达到100%时，能够定位哪些方法占用CPU比例较高。

3.8 数据库监控

3.8.1 数据库监控：核心功能

区别于传统的数据库端的监控，UAV的数据库监控采用新的视角，从应用端切入分析，弥补了现有数据库端监控的不足，增长了数据库-应用的关联分析能力。

数据库监控目前已实现的功能包括：数据库链接池监控、SQL分类统计、慢SQL统计、慢SQL耗时分布统计、慢SQL追踪以及与调用链/日志关联。

慢SQL的监控功能主要包括慢SQL统计+慢SQL追踪。对慢SQL的监控，能够自主设定阈值，界定多慢才算是慢SQL。用户能够按具体应用和它操做的数据库实例来设置，高于设置阈值的SQL操做才计入慢SQL。

在开启调用链/日志归集的状况下, 慢SQL操做可关联至对应的调用链以及日志，帮助咱们诊断和定位问题。

上图是数据库监控功能的慢SQL统计报表，展现了某段时间以内慢SQL的计数状况。慢SQL分类统计根据SQL类型，包括I-插入、D-删除、U-更新、Q-查询、B-批量操做，对慢SQL进行分类统计。

图中下方两个报表中，一个是数据库链接池监控，能够查看链接池总链接数、活动链接数以及空闲链接数；另外一个是SQL分类统计，能够根据SQL类型来分类统计。

3.8.2 数据库监控案例：某催收系统

经过某外购催收系统的数据库监控案例来讲明数据库监控的使用方法。

催收系统在查询催收历史时，统计记录数的count(*)语句，由于执行计划异常，执行效率低，占用了大量资源，致使数据库服务器CPU资源耗尽，进而系统不可用。从图上能够看到，故障期间的慢SQL数目明显变大，慢SQL具体为count(*)语句。

上图能够查看到慢SQL的详细SQL语句，得知故障期间的链接池资源被耗尽，活动链接数达到峰值，而空闲链接数为0；SQL分类统计图表也显示故障期间查询错误SQL数量明显变大。

经过慢SQL追踪界面，能够查看故障期间的慢SQL列表，发现执行时间长的三条SQL全是count(*)语句。

每一条慢SQL的执行结果及SQL语句均可以与调用链关联。继续点击，查看慢SQL详情及与调用链关联，均显示了count(*)语句执行时间长，且执行错误。经过慢SQL的执行与调用链、日志的关联，能够辅助定位和分析故障问题。

3.9 容器生态支持

3.9.1 容器生态支持：基本原理

对容器生态上的支持是指UAV以上全部功能都能在容器云平台上无缝迁移和使用。在容器环境下，监控Agent和应用分别在不一样的容器中，须要作一些适配工做，主要体如今应用画像/监控数据的采集、进程画像/监控数据的采集、日志采集路径的适配上。

• 首先，在应用画像/监控数据的采集上，监控agent容器应容许经过容器的虚拟IP访问应用的容器，经过http请求获取应用画像及实时监控数据。
• 其次，在进程画像/监控数据的采集上，监控agent的容器PID namespace须要和宿主机保持一致，从而保证监控agent能够扫描宿主机的/proc目录获取进程信息。
• 最后，在日志采集路径的适配上，监控agent应容许经过API获取应用和agent自身使用的volume信息。有了双方的volume信息，agent才能正确地在自身的容器内找到应用输出的日志路径。

3.9.2 容器生态支持：应用环境监控 — Kubernetes

UAV以上全部功能都能在容器云平台上的无缝迁移和使用，因此从UI上看不出来和VM有何区别，仅在应用环境监控界面上有些不一样。上图截取了Kubernetes环境下的应用环境监控界面，能够看到一个物理主机上有10个主机进程、17个容器、28个在容器里的进程。

应用环境监控能够显示容器和进程的对应关系。可点击分别查看容器性能指标和进程性能指标。

在容器或进程的属性列表里，新增了K8S相关的属性展现。这是在容器云环境下，咱们能够从应用环境监控UI中看到和VM环境下的些许差别。而对于其它功能（如调用链、日志监控、数据库监控，等等）而言，界面在容器环境下和VM环境下是没有任何区别的，用户感受不到差别。

3.10 Agent插件支持

3.10.1 Agent插件支持：支持Open-Falcon插件与UAV自定义插件

为了弥补监控广度上的不足，UAV目前提供了指标采集插件，支持已有的Open-Falcon的指标采集插件（相似Prometheus的exporter），也支持UAV自定义插件，使UAV监控能力可灵活扩展到对几乎全部经常使用的互联网中间件的监控，如MySQL、Redis、Kafka、RocketMQ、MongoDB、ElasticSearch等。

上图展现了UAV对Kafka、RocketMQ、Redis指标的监控曲线。

3.11 业务链路监控与告警

3.11.1 业务链路监控与告警：解决方案

宜信公司业务大多跨多个业务线和多个系统，为在IT层面能够快速定位问题系统，在业务层面上也能够给出受影响或波及的具体业务单据和客户范围，解决业务/运营人员的痛点，UAV提供了一套通用的业务链路监控与告警接入平台。

如图所示，该平台包括异构业务日志归集、数据上送、数据切分、过滤、聚合计算等功能，以后能够将结果持久化，提供业务报表大屏展现，也能够根据结果告警，生成业务工单。

实施过程当中，各业务组先在应用中埋点具备业务涵义的日志，而后自助配置和维护对业务日志的解析逻辑、具体的告警策略和告警消息模板内容，从而能够快速搭建针对自身业务的链路监控系统。

这套业务监控系统的优点在于：

• 将IT层面的调用链与业务事件双向关联，给IT层面的调用链赋予了业务涵义的同时，将跨系统的调用跟踪升级为跨业务领域的跟踪。
• 发生问题后，能够发出具备业务涵义的告警消息，将业务问题直接反馈给业务/运营人员；也能根据调用链快速定位到问题节点，从而帮到技术运维人员；此外，技术人员与运营人员也可经过业务ID反查系统链路来追溯问题。

3.11.2 业务链路监控与告警：业务告警示例

这是一个业务告警的具体例子。

上方是发给业务同事的告警邮件，内容能够细化到X年X月X日X:X:X，在X个系统的X个业务环节，发生了X问题，影响了X类型的客户，客户姓名是X，手机号是X。帮助业务运营人员快速定位问题单据和受影响的客户。

下方是发给技术运维同事的邮件，在业务同事邮件的基础上，额外提供了IT调用链路，方便技术运维同事快速定位和诊断问题。

3.12 智能运维

目前UAV在AIOps智能运维上的工程实践主要包括异常检测，根因分析，告警收敛和智能降噪，以及任务机器人HIT这4个方面。本次分享将重点介绍指标异常检测和根因分析两部分。

3.12.1 智能运维：异常检测框架

上图是UAV工程实践中使用的较流行的时间序列异常检测框架。主要包括离线模型优化、在线模型预测、A/B TEST部分。其中，离线模型优化和在线模型预测造成了指标异常检测的智能监控闭环。具体流程如图所示，其中要点包括：

• 对无标记数据的分析，采用无监督的方法进行异常识别。好比，在进行连续数据的异常检测时，可选用孤立森林算法，经过多棵iTree树造成森林来判断是否异常。
• 对已标记的数据的分析，采用了监督学习的方法，学习异常和正常群体的历史表现。这样，进行新数据检测时，能够经过模型直接决策，输出异常状况。
• 可是采用人工标注样本，工做量比较大，通常难以知足监督学习方法对数据量级的要求，因此可采用半监督的方法扩充标注的样本库。

3.12.2 智能运维：全维度的数据可关联

按照全维监控->全维关联->全维智能的技术路线，UAV采集到了多维度的监控数据后，须要创建起这些数据以前的关联。

这种关联关系：

• 能够是经过画像创建的强关联关系，好比宿主机与虚拟机、虚拟机与应用服务器、应用服务器和应用、应用和服务组件之间的关系；
• 也能够是经过调用链路或服务流图谱创建的强关联关系；
• 也能够是经过机器学习算法创建的关联关系，好比同一时间窗口同时变化的指标，可能存在某种关联。

须要说明的是，金融行业自己的业务特色决定了对第三方存在依赖性，所以告警的随机性较大，客观上致使学习样本的质量不高。所以，UAV目前使用强关联关系。

3.12.3 智能运维：根因分析，告警收敛与智能降噪

有了关联关系，就能够作根因分析了。咱们能够收集各个渠道的告警，先经过告警过滤将其中重复的告警和不重要的告警过滤掉，再根据关联分析创建同一时间窗口内不一样类型告警之间的关联，能够按画像创建关联，也能够按调用链路创建关联。而后是权重计算，根据预先设置的各种告警的权重，计算成为根源告警的可能性。最后将权重最大的告警标记为根源告警。此外，还能够根据历史告警处理知识库，找到相似根源告警的推荐解决方案。

在根因分析和定位的过程当中，顺带实现了告警收敛和智能降噪。好比咱们对重复告警、非根源的通常告警、同一条链路的其它告警进行了压制。

4、总结

上图为线上实际的宜信核心业务线调用关系的图谱。UAV做为宜信的公司级智能监控标准软件，已持续覆盖到宜信全部关键业务系统，支持公司超过300个业务线。愈来愈多的同事能够熟练地使用UAV，将UAV应用于平常运维、事前预警、事中问题诊断和过后复盘分析等各个方面。

使用UAV，能够得到随时随地的运维体验。目前UAVStack监控部分已在GitHub上开源，能够登陆查看更多详细介绍。

• 官方网站：https://uavorg.github.io/main/
• 开源地址：https://github.com/uavorg