酷应用

苏宁11·11：Monitor在左，Control在右，监与控的结合——深度剖析穆加决策分析平台

百家作者：InfoQ 2017-11-13 04:05:28

作者｜朱健荣

编辑｜蔡芳芳

一、背景

在当今互联网时代，企业大都采用分布式系统设计和微服务化，内部关系错综复杂，各产品分散，集成度不高。虽有众多日志监控工具，但没有全链路监控，定位问题及根因分析耗时长。同时由于缺乏决策并自动控制（自愈）机制，基本靠人工来排查处理，面对大规模高并发的场景时，对数据中心的性能、安全、稳定性影响缺乏量化，合理性规划时也很难兼顾性能与稳定性、可用性。

此前苏宁已有穆加服务端性能监控（以下简称 Baymax）、穆加调用链监控（以下简称 HIRO）等产品，但这仅仅是在“监”的层面上去主动发现系统出现的一些问题，而没有对解决这些问题做出“控”的动作。基于此，我们研发了穆加决策分析平台（以下简称 ZEUS），它将打通苏宁内部所有的监控渠道，真正意义上使得监控系统具备“控”的能力，通过与运维系统联动，达到系统问题自愈的效果，实现“监”与“控”完美结合。

二、关于穆加

穆加是苏宁数据云公司中间件研发中心自研的端到端系统监控的产品线名称。目前中间件研发中心有四款穆加旗下的产品已经上线并提供服务，分别是：Baymax、HIRO、穆加智能告警平台（以下简称 APOLLO）以及 ZEUS，如图 2.1 所示：

图 2.1

三、ZEUS 剖析

什么是决策分析

决策分析就是用海量的数据来支持决策。这些数据包括历史记录中的和实时产生的，通过大数据分析、系统的规则匹配及自主学习，将数据转化为用户可读的决策信息，从而减轻了用户从事低层次信息处理和分析的负担，提高了决策的质量和效率。

ZEUS 介绍

ZEUS 基于监控系统采集的原始监控数据，使用 CEP 做聚合计算、Drools 做规则判断，将监控数据按照系统及时间维度统合后，能够为用户提示监控数据背后可能引起问题的根因，缩短问题定位的时间。主要特点如下：

1、基于苏宁系统运行时与 IDC 环境建模构建的规则引擎库，同时支持用户自主分析并手工添加规则

2、精确定位，秒级响应，快速解除问题，降低人工剖析问题的时间，由系统智能分析并提供决策

3、提供系统画像、资源管控、大促投屏等功能，让用户可以实时、全方位、全天候感知自己系统的健康状况，并给大促提供全息监控视图

4、灵活扩展分析能力，开放平台接口，实时访问数据，无缝对接第三方系统

5、与苏宁内部的 IaaS/PaaS 以及运维管理平台联动，进行自动扩缩容和故障处理

6、支持 SaaS 公有云和私有化部署

ZEUS 架构

ZEUS 架构分为六层，从上到下依次是源数据层、数据接入层、决策分析层、数据存储层、Portal 层以及对外输出层。如图 3.3.1 所示：

图 3.3.1

1) 源数据层：决策分析平台的数据来源。目前接入的数据有 Baymax、HIRO、主机、发布事件、CDN 和移动 APP。随着源数据越来越丰富，平台的决策分析也将更精准。后期我们将全面接入用户画像、后端系统、IDC 及基础平台、业务全息信息等数据源，实现基于全息监控的决策分析，如图 3.3.2：

图 3.3.2

2) 数据接入层：负责把源数据接收到决策分析平台。目前有实时和离线两种接入方式，分别应对不同的场景需求。

3) 决策分析层：负责实时和离线的决策分析功能，是整个平台的核心。实时分析通过对流式数据进行即刻和短时汇聚分析，从而实现实时决策；离线分析可以实现对时间跨度比较长的数据进行分析，匹配出符合用户自定义规则、专家规则和机器学习规则的决策事件。机器学习目前采用的是监督式学习，样本数据来自专家系统和用户反馈数据。

4) 数据存储层：用于存储原始数据和处理后的数据。目前原始数据主要存储在 HDFS，处理后的数据按业务特性分别存储在 HBase、Hive、Druid 和 MySQL 中。

5) Portal 层：负责数据展示和交互。用户可以通过 Portal 进行配置规则、查看决策事件和问题反馈原因，也可以查看系统的健康状况。图 3.3.3 和图 3.3.4 分别展示了系统健康状况和根因分析：

图 3.3.3

图 3.3.4

6) 对外输出层：负责决策分析平台的对外输出。目前主要是将决策事件发送告警平台、大促期间的统一监控平台以及 CD、PCP、ITSM 等平台。

核心流程

ZEUS 整体处理流程如下：

平台接收来自各平台如 Baymax、HIRO、Zabbix 等监控源数据，通过 CEP 进行事件的聚合和分析
CEP 处理后的事件，进入规则引擎，进行规则判断推算出发生异常的根本原因或决断出接下来采取什么动作 / 决策。规则转化的处理如下：
将业务语言转换成 EPL（CEP 引擎能处理的语言）文件和 drl（规则引擎 Drools 能处理的语言）文件。
生成 EPL 文件和 drl 文件的步骤如下：

管理员在后台录入 metric
管理员在后台页面录入业务规则，业务规则需要与 metric 关联
后台将规则转换成 EPL 文件和 drl 文件，存入数据库并写入 Zookeeper
举例说明，用户在页面录入的规则如下：

  当 [机器的 CPU 使用率]>90% 并且 [请求错误率]>90% 并且 log 日志中出现“Too many open files”字段

  可能发生的原因为：“Too many open files，文件描述符设置不足”

后台翻译后的 EPL 文件和 drl 文件分别如下：
epl.xml：

  ?xml version="1.0" encoding="UTF-8"?>
  
      
          
              
              
          
          
              select b.licenseId, avg(c.memoryHeapMax), b.currentStatTime from
@memstat.win:time(10 sec) c,@ctspm.win:time(10 sec) b

rule.drl：

  package com.suning.zeus

  import com.suning.zeus.storm.bolts.drools.module.MetricDroolsModule;

  rule "rule1"
  no-loop
      when
          metric : MetricDroolsModule( cpu > 0.9, errorRate > 0.9,logs contains "Too many open files")
      then
          metric.setReasons( "Too many open files，文件描述符设置不足" );
          update( metric );
  end

最终的分析结果落入 HDFS
将 HDFS 中的分析结果进行聚合，计算出最终结果，展示给用户或通过 APOLLO 进行告警，如图 3.4.1 所示：

图 3.4.1

决策分析层分为实时处理和离线处理，其流程分别为：

实时分析处理流程

图 3.4.2

主要功能：

1) 对系统层、业务层、主机层进行实时监控

2) 通过实时处理平台，从简单事件流数据中匹配出符合规则的复杂事件

数据处理流程：

1) 监控数据作为简单事件流进入实时处理平台

2) CEP 引擎对多个简单事件流进行识别、规则匹配生成最终符合特定规则的复杂事件数据

3) 通过最终生成的复杂事件数据甄别出业务系统可能存在的问题，并根据甄别出的数据给出决策（在对问题事件进行甄别时所有指标基线都来自历史基线数据，历史基线数据由相关数据模型定期学习更新）

离线分析处理流程

图 3.4.3

主要功能：

1) 生成各个维度不同时间粒度的统计报表，可进行纵向和横向的指标对比

2) 根据统计计算规则，生成不同指标的临界阈值，用于辅助实时决策判断

3) 根据统计结果，找到各类数据不同指标的统计异常点，结合用户问题描述，给出指标值与问题的关系，并输出为描述规则，该规则可用于问题的自动判断和预测

4) 利用机器学习的回归、分类等算法，对数据进行训练学习，生成回归、分类等模型，利用此模型可对新的数据进行分类、预测，从而实现问题的自动判断和定位

数据处理流程：

1) 所有外部数据统一接入 Kafka 消息队列

2) 通过 Flume 将数据收集到 HDFS 文件系统

3) 使用 Spark 对原始文件进行预处理后保存在 HDFS/Hive 中，该数据将长期保存，用于应对历史数据分析

4) 使用 Spark 对保存在 HDFS/Hive 的数据进行各类统计分析，使用机器学习算法对数据进行训练学习，生成分类、预测模型，统计分析和机器学习结果根据需要分别保存到 MySQL 和 Druid 中

5) 利用 Druid 提供的各种查询统计功能（时间序列、聚合、上卷下切、关联等）对 Spark 分析出来的数据进行二次分析

技术难点

在设计和开发过程中，遇到很多难点，其中最具有代表性的有：

数据关联存储：当数据种类较多时，需要将各类数据关联起来进行统一分析，才更容易发现问题的原因，如何有机的关联各种数据，同时如何有效的存储这些数据才能方便应用展示也有相当的难度。
对策：从不同的维度对数据进行整合，比如从系统维度、用户维度、主机维度、统计指标维度等，将某一维度属于同一对象的数据进行整合集中存储，不同维度的数据可以分别存储，使用不同的存储方案。既可以从不同维度进行数据分析，还能有效降低上层应用获取并展示数据的复杂性。
规则复杂性：对于有些问题，需要由多个条件组合的复杂规则才能判断，当条件较多、组合方式较多时，实现的复杂性会大大增加。
对策：实现一套灵活的规则定义逻辑，能有效的将用户的业务规则定义成程序可以理解的规则。
规则提炼：如何能够提炼出有价值的判断规则，能根据实际问题自动生成规则，或者调整现有规则的一些阈值。
对策：结合统计方法和机器学习算法，对历史数据进行分析挖掘，结合用户处理问题的经验，提炼出有价值的规则，并计算出合适的阈值。

规则定义实例说明

定义一套灵活的规则，关键要明确该套规则应用的问题场景，要点在于收集系统应用层、服务层、主机层等系统各方面产生的实时特征数据，包括相互关系、类型、数值、产生时间等信息，从特征数据中提取出判断指标以及对应的阈值。

ZEUS 规则定义逻辑如下：

1) 约定规则定义因子：指标集 (指标来源)、指标、统计函数（avg、sum、count、max、min、tp、variance）、关系运算符 (>、< 、=、!=、>=、< =、in、between)、阈值、逻辑运算符 (&&、||、!) 等

2) 定义规则时，可以通过指标集、指标、统计函数、关系运算符、阈值组合出基本规则表达式

3) 基本规则表达式可以通过逻辑运算符与其它规则表达式继续组合，也可以与其它规则表达式的嵌套进而形成结构灵活、逻辑完善、功能更强的复杂规则

规则保存为 json 格式，通过规则解析模块翻译处理后载入规则处理引擎。

当实时处理模块中的规则处理引擎处理数据命中某条规则时，则可以根据该规则精准判断出问题场景、产生的原因并给出相应解决建议。

例如，某次大促活动期间监控大盘显示某核心系统响应耗时统计超过正常刷新时间数据仍然不变，经过排查是由于该核心系统所在主机上的另一系统在该时间段上流量过大，抢占了该主机的网络带宽，导致该核心系统网络延迟，同时通过 ping 测试该段时间丢包严重，某 RPC 服务接口频繁连接超时。我们可以按照如下思路定义该场景的规则：

1) 定义响应耗时规则：单位时间内某 PRC 服务接口响应耗时超时次数>n

2) 定义网卡流量规则：单位时间内网卡平均流量>m

3) 定义 ping 丢包规则：单位时间内的网络丢包率>p

4) 定义组合规则: (单位时间内响应耗时超时次数>n)&&(单位时间内网卡平均流量>m) &&(单位时间内的网络丢包率>p)

由此，规则定义结束并提交到实时处理模块。如果实时处理模块命中该规则，触发系统告警提示，就可以推测出某程序大量占用网络带宽，造成网络负载较重，进而造成服务响应超时，无法正常提供服务。

四、远景规划

在今年的双 11 大促中，ZEUS 已经在苏宁展示了其强大的功能——联合 Baymax、HIRO、APOLLO 等产品组成一个封闭的监控生态圈，实现了“监”与“控”的结合，为各业务系统的稳定运行提供了强有力的保障。

ZEUS 的未来规划如下：

丰富产品功能，添加如用户反馈、问题回演、问题分析归纳等功能，从多维度剖析问题根因
深度利用机器学习、深度学习以及自然语言处理，实现决策判断的真正智能化，降低对专家系统的依赖，以适应更多复杂场景
提升系统的开放程度，形成开放平台，提供决策分析结果的同时共享原始数据，与其它系统共同挖掘数据中隐含的价值

作者介绍

朱健荣，苏宁云商 IT 总部资深中间件技术专家，主要负责应用系统监控的整体解决方案。研发的中间件应用系统经历了苏宁 818、双 11 等购物狂欢节的严苛考验，真正具备低延迟、高并发、高可用、高可靠，可支撑万亿级的数据洪峰。深知系统的稳定性对电商平台的重要性，现在正和研发团队一起建设应用系统监控层整体解决方案，已研发出服务端和调用链监控、智能警告和决策分析平台。始终秉承工匠精神，精益求精，持续优化用户体验、提神技术实力，力争做出更好的产品。

渴望了解更多双 11 背后最新的技术架构？12 月 8-11 日，请前往由 InfoQ 举办的 ArchSummit 全球架构师峰会 北京站，大会与阿里巴巴合作策划了 双 11 架构专场，并邀请了顶级技术专家担任出品人，设置了“新一代 DevOps”、“人工智能与业务应用”、“架构升级与优化”等 17 个热门话题，更多详情可点击 阅读原文 了解大会日程。