关键词：
微博广告 Hubble 监控平台 D+ 大数据 机器学习 LSTM Tensorflow
业务背景
Hubble（哈勃，其含义是数据如浩瀚宇宙之大，Hubble 如太空望远镜，能窥见璀璨的星辰，发现数据的真正价值）平台定位为
微博广告智能全景监控、数据透视和商业洞察
。
计算广告系统是集智能流量分发、投放、结算、CTR 预估、客户关系管理等为一体的大型互联网业务系统。
随着微博业务的快速增长，广告系统复杂度越来越高，成千上万的模块需要不停地进行计算和通信，如何保证这么复杂的系统正常健康运行是一个巨大的挑战。
微博广告 Hubble 平台每日处理 TB 级别的监控数据和万级别的报警规则，Hubble 平台利用机器学习技术进行趋势预测和报警阈值的智能调整，保证商业产品上千台服务器和数百个系统及服务的正常运行。
下面我将详细介绍一下微博商业广告 Hubble 系统的设计原理及在智能全景监控实践中的一些思考。
核心问题
设计系统架构之前，应该首先从业务和系统等角度深度挖掘架构要解决的核心问题，对于监控平台而言，可以从平台化视角、业务视角及系统架构视角三个层面解析核心问题。
从平台化视角考虑，监控报警平台要解决的问题是
-
是否能指导 RD 快速定位问题？
-
是否为业务发展的预估提供参考？
从业务视角考虑，监控和报警平台所要解决的核心问题主要有以下几个方面
-
监控指标：精准性和覆盖率（Accuracy and Coverage rate）
-
报警：实效性和准确性（real-time performance and Accuracy）
-
故障诊断（fault diagnosis）
-
自动处理（Automatic processing）
从系统架构及设计视角考虑，监控报警平台要能解决：
简单的讲，Hubble 全景监控的核心功能包括提供基础监控、报警、预警服务，
如图1所示。
图1 Hubble全景监控服务核心功能
整体架构
Hubble 平台的整体架构如图2所示。
图2 Hubble平台整体架构图
如图2，Hubble 整体设计包含三个层次
数据采集层（data collection layer）
数据采集层负责将系统日志、系统指标、业务日志、业务指标等数据进行实时采集。对于日志数据，支持 flume、scribe 等日志搜集工具，也支持 filebeat、metricbeat 等文件及指标搜集工具。
对于系统及业务指标，可以通过我们开发的 w-agent 客户端进行数据搜集，w-agent 是 Hubble 的轻量级、低资源消耗的数据采集工具，它作为微博广告标准基础工具集里的一部分，在服务器初始化时进行安装配置，通过 zookeeper 进行配置管理，支持远程更新数据采集配置和配置变更实时生效。同时，数据采集层支持通过 API 的方式直接提交数据，方便数据个性化定制以适应不同的业务需求。
数据分析层（data analyzation layer）
数据分析层负责将采集到的数据进行 ETL、预处理、分析和聚合。为了提高可用性，采集到的数据同时将写入 HDFS 进行持久化，数据分析层可以根据需要，从 HDFS 中 reload 并重新计算。另外，离线部分的监控预估模块会定时进行模型训练，并将训练后的模型存储在 HDFS 中。alert trigger 模块负责根据报警规则进行报警触发监测。
可视化层（visualization layer）
经过分析处理的数据写入到可视化层的存储系统中（Druid、ElasticSearch 和 MySQL），可视化层负责根据业务方需求，进行监控图表的展示、配置和管理，以及报警信息及规则的管理。另外，可视化层提供 APIs，允许第三方通过 API 的方式获取聚合分析后的数据以及对报警的管理。
三层各个模块相互协作，完成从数据搜集到可视化整个流程。
核心功能
监控指标
经常听到同学说系统处理百万级别的监控指标，以此来形容监控平台的处理能力，当然，这个数据在一定程度上可以反映监控平台的复杂度和能力，但是我们业务真的需要这么庞大的监控指标么？实际上，很大一部分的监控指标是毫无价值或多余的，这些指标要么根本无法真实反应系统或者业务的状态，要么可以直接被其他指标取代，要么是需要结合更多的信息来分析。
抽象出来，监控指标应该有以下几个分类。
机器（系统）指标
这部分指标，从机器资源角度，尤其是从硬件瓶颈相关的早期迹象并捕获硬件故障信号进行监控。抽象概括起来包括机器 CPU、Memory、Disk IO / Space、Net IO。
系统指标监测的目的是：
-
发现机器故障
-
限流与扩容
应用指标
应用指标分为基础应用指标和非基础应用指标。基础应用指标是指能被标准化和常见应用的监控，比如 Nginx / Apache 服务器的请求状态和 access 日志及端口、MySQL 数据库端口、Hadoop 集群运行状态等。非基础应用指标，指针对基础应用指标以外的应用指标，比如某个服务的端口号指标、进程个数等。另外，对于应用的日志抽取出来的指标，也可以归类于非基础应用指标。
业务指标
业务指标关注具体业务、产品的指标，如日收入走势、订单数、广告计划数等业务层面的。
智能化全景监控实践
基础监控
基础监控要求实时反应真实的指标波动情况，其中关键技术之一是对时序数据进行聚合，其聚合的粒度根据业务不同而有一定差异，当然也会因指标及数据处理量等因素制约。目前 Twitter、Facebook 等国外公司一般做的 30 秒甚至分钟级别聚合，大部分公司做到 10 秒级聚合已经满足业务需求。微博广告监控根据业务需求，对部分指标聚合粒度为 1 秒级。
基础监控底层使用
D+
（Data Plus）平台提供实时的数据服务，其中
D+
平台是微博广告商业数据基础设施，负责数据搜集、存储、监测、聚合及管理，提供高可用的实时流和离线数据服务，在
D+
上可以对不同数据源及实时数据与离线数据的关联，关于
D+
技术架构细节，后续文章会进一步分享。
D+
的整体架构如图3所示。
图3 D+系统架构图
基础指标数据、日志数据会从 D+ 流出到 ETL 部分进行数据处理，然后输入到 Druid 提供上层 Graph 展示，同时输出一部分数据（日志）进入 ElasticSearch，以便后续查询，D+ 位于 Hubble 整体架构的 data collection layer 和 data analyzation layer，具体可结合参考图2。
趋势预测
目前很多企业都在尝试通过趋势预测的方式，提前预测系统或者业务的未来发展，以期望未雨绸缪，业内普遍的做法是通过统计学的方法，如 Holt Winter，ARIMA，3Sigma 等。
此类方法的特点是简单，能结合部分历史数据进行趋势预测，然而也有很多不足，如 ARIMA 算法的一个技术难点就是时间序列的平稳化，平稳化的时间序列对于预测结果的好坏起着至关重要的作用。另一个问题是滑动平均操作带来的结果如波动锯齿明显，容易造成误报干扰的化，则加大监控监测周期。
微博广告团队率先尝试通过机器学习的方法来预测系统指标的变化趋势，取得了一定的效果，目前已经应用于广告曝光量、互动量的趋势预测。
趋势预测的架构图4如下：
图4 基于机器学习的趋势预测架构图
主要分两部分：离线模型训练和在线计算。离线部分的数据来源是 HDFS 存储的历史指标数据，输出为模型；在线部分根据模型进行计算后导入到 Druid 进行存储和部分聚合，通过 dashboard 可以实时展示。
