腾讯SNG多维监控的进阶之路

近年来，随着大数据概念的持续火热，无论是开源界还是大公司的自研体系中，相关的技术都已逐渐趋于成熟。那么当我们有了能可靠地对大数据进行采集、处理和存储的能力后，我们可以将这些能力用于哪些实际业务场景，并让数据产生价值呢？

目前最常见的大数据落地产品有广告推荐、BI报表、画像分析、日志搜索、机器学习等。暂且抛开离线计算不谈，实时计算还有一个重要应用场景就是监控。无论是PV、UV、交易量等业务数据的统计还是异常数据的告警，都是越快越好。

传统的单维监控在这条数据处理链路上已经处理的很好，而现在越来越多的业务数据都表现出多维度、多指标的特征，多维监控便成了业务监控发展的一个新趋势。

本文详细介绍了织云多维监控的设计理念、整体架构，以及如何利用它的能力快速实现对腾讯 SNG 业务的多维监控覆盖。

多维监控的前身

织云多维监控源自腾讯SNG哈勃大数据实时处理平台，前身是MM（Mobile Monitor）系统。2012年前后，随着智能手机的爆发式增长，公司大多产品都从PC端走向了移动端。移动用户数出现迅猛增长，如何对移动端进行质量监控就变得越发重要。

MM系统就是在这个阶段应运而生，把从移动端收集到的“地区、运营商、版本、命令字、SET、APN”等维度和“请求数、成功率、平均延迟、发包、回包、匹配率”等指标，通过 storm 进行实时的监控分析和告警。

维度：用于描述数据。就是数据对象的属性、特征，比如运营商、版本等。

指标：用于衡量数据。就是数据对象的值，比如成功率、总数等。

MM 系统虽然满足了一个阶段的移动端监控需求，但是随着业务的多样性发展，个性化需求也随之增多，MM 系统的使用场景也就变得相形见绌。

局限性主要体现在以下几个方面：

• 数据源单一。只能接入腾讯单一系统流过来的数据，无法对接其他数据源；

• 实时处理逻辑固定。只能清洗出固定的维度和指标，进行固定的聚合统计，不支持自定义处理逻辑；

• 技术栈没有更新。还在使用 Storm 早期版本和 Impala，无法适应业务数据的成倍增长，经常出现丢数据、查询慢等现象；

• 可扩展性和可运维性较差。代码中遍布 hardcode，很多功能点没有抽象成配置项，扩容步骤繁复。

针对以上问题，MM 系统迎来了重建的契机，并正式改名为哈勃。

多维监控的设计

我们在设计时主要考虑的几个方面：

• 向下兼容原有功能。也就是多维监控分析能力，不影响已接入业务方的正常使用；

• 通用化改造。对常用的实时处理功能进行封装，做成组件化、积木化；

• 降低门槛。将数据处理过程封装成界面化配置，无需接入人员写Storm代码；

• 优化架构。通过后台架构升级，提高数据准确性和查询速度，降低数据链路延迟；

• 体验优化。统一界面风格，优化交互设计，提供友好的错误提示等。

所以，织云多维监控首先要解决的一个问题，就是如何让不会写代码的用户也能按自己的处理需求生成 storm 的拓扑。

我们先来看一下 storm 最常见的三种开发模式：

1. Java。门槛最高但是最灵活，通过继承 Storm 提供的各种 spout 和 bolt 接口进行逻辑实现；

2. Pig On Storm。用 Pig 语言来进行开发，好比在 Java 语言之上又封装了一层更高级的语言，降低开发门槛；

3. SQL On Storm。相比 Pig，SQL 的普及程度更高，使用也更简易。

但这三种方式都还是没有摆脱编程的概念，始终有一个开发调试的过程。为什么不直接做一个只需通过界面化配置就能生成 Storm 拓扑的系统呢？技术实现上并不会比上述三种方式复杂。大多数团队没有这么做的原因应该是界面化的配置经过高度抽象封装后，丧失了部分灵活性，无法支撑所有业务场景。

哈勃的目标是兼容MM系统并满足大部分新业务的场景，所以在易用性和通用性之间做了取舍，打算做一个全界面化配置的 Storm 开发环境。由此就诞生了织云多维监控的数据加工厂。

数据加工厂

先对常见的大数据分析场景进行分类归纳，一般就是以下几种：

然后分别将这几种操作封装成界面上的配置项。

• 过滤：1、保证数据完整性、合法性，比如不能是空值、脏值；2、通过标识字段过滤掉冗余信息，比如过滤掉 plateform 是 Android 的数据。

• 格式化：1、时间格式的转换；2、数据类型的转换；3、URL编解码。

• 翻译：1、内外部IP信息翻译；2、数据库表字典翻译；3、分隔符切分；4、四则运算；5、UDF翻译。

•转发：1、转发到 SNG 的 DC 通道；2、转发到 CDB；3、转发到 Kafka。

•分组：配置统计周期、时间字段和分组字段。

•聚合统计（支持聚合时过滤）：1、统计个数（PV）、去重统计个数（UV）；2、最大值、最小值；3、第一个值、最后一个值；4、求和、求平均。

通过上述提供的功能，用户就能在织云多维监控中对数据进行各种处理，最终生成一个类似下图的Storm拓扑。

这一步做的是数据的初步聚合，比如统计周期是 1 分钟，那么 storm 在 1 分钟的滑动时间窗口内将接收到的数据进行分组聚合后落地到对应的 OLAP 存储中。最终展示到界面上的结果数据还需要进行二次聚合，整个过程如下：

目前织云多维监控主推的 OLAP 存储引擎是 Druid。Druid 是一个在多维分析场景下表现非常亮眼的时序数据库，弥补了之前 Impala 在查询速度和并发上的不足。而对于体量较小的业务数据，也会优先选择落地到 Pgsql、Mysql 等传统数据库，节省服务器资源。需要做全文检索的业务数据则存入 ES。

数据加工厂的整体架构：

数据加工厂的特点：

数据应用生态

通过数据加工厂，各类业务的数据就能接入织云多维监控进行处理，再流入应用生态中。

多维下钻分析

在这些应用生态中，最重要的两个就是多维下钻分析和多维监控告警。当业务数据接入织云多维监控之后，就会在多维分析菜单下生成一个默认页面。

这个页面主要分为四块：业务树导航、维度过滤条件、指标趋势图、数据分析板块。其中维度还可以再次进行筛选、翻译等操作，指标可以进行更复杂的复合运算和格式化等操作。

下面给一个业务定位故障的典型例子：

第一步：发现指标趋势图中成功率掉了一个坑，点击对应时间点进入下钻分析；

第二步：根据请求数排序，找到请求数高且成功率低的AppID，这样就确定了出现异常的AppID，点击进入第二个维度的下钻分析；

第三步：继续找出有异常的命令字和返回码两个维度，这样就确定了该业务在AppID为a、命令字为b、返回码为c的情况下，出现了请求量暴增，最终导致成功率下跌。

帮助开发定位业务在哪一个细分维度组合下出现了异常是哈勃多维下钻分析的一个主要场景，另外，也经常用于查看用户在各大运营商的占比、iOS/Android 占比等数据分析。

多维监控告警

只有分析界面是不够的，在指标出现异常时，用户更希望能第一时间收到告警通知，所以织云多维监控也支持多维监控告警。相比传统的单维监控，x轴就是时间、y轴就是值，多维监控的设计就要复杂很多。比如维度 1 为 a 时，维度2为 b 时，指标 1低于 90% 则告警；维度 3 和维度 4 任意组合下，只要指标 2 低于 80%，则告警。所以整体的页面配置如下：

用户先配置告警规则，设定告警条件。然后配置订阅规则，设定订阅条件和方式。有必要时还可以配置收敛规则和屏蔽规则。当产生告警时，告警内容本身就是一个分析结果，开发或运维收到告警后就能快速进行修复，省去了定位故障的过程。

所以有了多维下钻分析和多维告警的功能之后，业务方就可以将告警从传统的监控系统中迁移到织云中。

其实我们梳理一下常见的业务场景，客户端、服务端的维度、指标无非就是如下几种，如果在传统单维监控中配置，就需要每个维度值相乘的告警项数量，而在织云多维监控中就只是一份数据。利用织云多维监控的能力，就可以把监控粒度从IP放大到一个微服务，从每个指标一个监控项变成每个微服务一个大盘。

智能化

目前我们在机器学习领域也取得了不错的进展，比如针对上述手动进行多维分析的案例，我们已经实现了通过“多维根因分析算法”学习推荐出异常维度组合；告警也无需设定阀值，可以自己根据历史数据和模型学习到异常值进行告警和收敛。