hubble 微博广告Hubble系统：秒级大规模分布式智能监控平台架构实践

关键词:微博广告哈勃监测平台D+大数据机学习LSTM张量流

工作经历

哈勃(哈勃，意思是数据大如浩瀚宇宙，哈勃像望远镜，可以看到明亮的星星，发现数据的真正价值)平台定位为智能全景监控、数据透视、微博广告的商业洞察。

计算广告系统是集智能流量分配、投递、结算、CTR估算和客户关系管理于一体的大型互联网商务系统。随着微博业务的快速增长，广告系统的复杂度越来越高，成千上万的模块需要不断计算和沟通。如何保证这样一个复杂系统的正常健康运行是一个巨大的挑战。

微博广告哈勃平台每天处理TB级监测数据和万级报警规则。哈勃平台利用机器学习技术预测趋势，智能调整报警阈值，保证商业产品中数千台服务器、数百个系统和服务的正常运行。

接下来，我将详细介绍微博商业广告哈勃系统的设计原理以及智能全景监控实践中的一些思考。

核心问题

在设计系统架构之前，我们应该首先从业务和系统的角度深入挖掘架构要解决的核心问题。对于监控平台，可以从平台角度、业务角度、系统架构角度分析核心问题。

从平台化的角度来看，监控报警平台需要解决的问题有

能否指导RD的快速定位？

是否为业务发展预估提供参考？

从业务角度来看，监控报警平台需要解决的核心问题主要包括以下几个方面

监测指标:准确性和覆盖率

警报:实时性能和准确性

故障诊断(故障诊断)

自动处理(自动处理)

从系统架构和设计的角度来看，监控报警平台应能解决以下问题:

大数据分析和处理能力，包括数据收集、ETL和数据抽象分析

数据分析和处理的实时性能

大型监控指标等时序数据存储、报警规则存储和报警触发

高可用性

数据聚合能力

简单来说，哈勃全景监测的核心功能包括提供基本的监测、报警和预警服务，如图1所示。

图1哈勃全景监视服务的核心功能

整体架构

哈勃平台的整体架构如图2所示。

图2哈勃平台总体架构图

如图2所示，哈勃的整体设计包括三个层次

数据收集层(数据收集层)

数据采集层负责实时采集系统日志、系统指标、业务日志、业务指标等数据。对于日志数据，它支持日志收集工具，如水槽和划线，还支持文件和索引收集工具，如filebeat和metricbeat。

对于系统和业务指标，我们可以通过我们开发的w-agent客户端收集数据。w-agent是哈勃的轻量级、低资源的数据收集工具。作为微博广告标准基础工具集的一部分，在服务器初始化时安装配置，通过zookeeper进行配置管理，支持数据采集配置的远程更新和配置变化的实时效果。同时，数据采集层支持通过API直接提交数据，便于个性化定制数据，满足不同的业务需求。

数据分析层(数据分析层)

数据分析层负责收集数据的ETL、预处理、分析和聚合。为了提高可用性，收集的数据将被写入HDFS进行持久化，数据分析层可以根据需要从HDFS重新加载和重新计算。此外，离线监测和预测模块将定期对模型进行训练，并将训练后的模型储存在HDFS。报警触发模块负责根据报警规则监控报警触发。

可视化层(可视化层)

分析后的数据写入可视化层(Druid、弹力素搜索和MySQL)的存储系统，可视化层负责显示、配置和管理监控图，并根据业务端的要求管理报警信息和规则。此外，可视化层提供了API，允许第三方获取聚合数据并通过API管理警报。

三层中的模块相互协作，完成从数据采集到可视化的整个过程。

核心功能

监控指数

经常听同学说系统处理百万监控指标来描述监控平台的处理能力。当然，这些数据在一定程度上可以反映监控平台的复杂程度和能力，但是我们的业务真的需要这么庞大的监控指标吗？事实上，大量的监测指标毫无价值或多余。这些指标根本不能真实反映系统或业务的状态，或者可以直接被其他指标替代，或者需要用更多的信息进行分析。

摘要，监测指标应具备以下几类。

机器(系统)索引

这部分指标，从机器资源的角度，特别是从与硬件瓶颈相关的早期征兆，捕捉硬件故障信号进行监控。抽象地说，它包括机器CPU、内存、磁盘IO/空间和网络IO。

系统指标监控的目的是:

发现机器故障

限流和扩容

应用索引

应用指标分为基本应用指标和非基本应用指标。基本应用指标是指对标准化、通用化应用的监控，如Nginx/Apache服务器的请求状态、访问日志和端口、MySQL数据库端口、Hadoop集群运行状态等。非基本应用指示符是指除基本应用指示符以外的应用指示符，例如服务的端口号指示符和进程数。此外，从应用程序日志中提取的指标也可以归类为非基本应用程序指标。

业务指标

业务指标侧重于具体的业务和产品指标，如每日收入趋势、订单、广告计划等业务层面。

智能全景监控的实践

基本监控

基本监测要求对指标的波动做出实时反应。其中一个关键技术是时间序列数据的聚合，聚合的粒度因业务不同而不同，当然受到指标、数据处理能力等因素的制约。目前，Twitter、Facebook等国外公司一般做30秒甚至1分钟聚合，而大多数公司做10秒聚合是为了满足业务需求。根据业务需求，一些指标的聚合粒度为1秒。

基础监控底层使用D+(Data Plus)平台提供实时数据服务，其中D+平台是微博广告的商业数据基础设施，负责数据采集、存储、监控、聚合和管理，提供高可用的实时流媒体和离线数据服务。在D+上，可以进行不同的数据源以及实时数据和离线数据的关联。D+的技术架构细节将在后续文章中进一步分享。

D+的整体架构如图3所示。

图3 D+系统架构图

基本指标数据和日志数据会从D+流出到ETL进行数据处理，然后输入到Druid提供上层Graph显示，同时会有一部分数据(日志)输出到ElasticSearch进行后续查询。D+位于哈勃整体架构的数据采集层和数据分析层。详见图2。

趋势预测

目前，许多企业都在试图通过趋势预测的方式提前预测系统或业务的未来发展，以期待提前规划。业内普遍做法是采用统计方法，如霍尔特温特、ARIMA、3西格马等。

这种方法的特点是简单，可以结合一些历史数据来预测趋势。然而，它也有许多缺点。例如，ARIMA算法的技术难点之一是时间序列的稳定性，它对预测结果起着至关重要的作用。另一个问题是，如果移动平均操作导致明显的波动锯齿，容易造成误报干扰，那么监测周期就会增加。

微博广告团队率先尝试通过机器学习来预测系统指标的变化趋势，取得了一定的效果。已应用于广告曝光和互动的趋势预测。

趋势预测的架构图如下:

图4基于机器学习的趋势预测架构图

主要分为离线模型训练和在线计算两部分。离线部分的数据源是HDFS存储的历史索引数据，输出是模型。在线部分根据模型进行计算，然后导入Druid进行存储和部分聚合，可以通过仪表盘实时显示。

LSTM(长-短时记忆网络，RNN变种)能够很好的把握时间序列上下文之间可能联系的特点，所以在模型训练方面，我们选择了LSTM模型，Python中有很多可以直接调用的包来构建LSTM模型，比如Keras，Tensorflow，antano等等。本文选择Keras作为模型定义和算法实现的机器学习框架，选择后端作为TensorFlow，使用均方误差作为误差计算方法，采用RMSprop算法作为权重参数的迭代更新方案。

图5展示了微博广告中某产品曝光(pv)趋势的预测效果。

图5趋势预测曲线效果图

注:红色为训练数据；蓝色是实际值；绿色是测试输出

图6显示了微博上一个广告产品的预测曝光值和实际曝光值之间偏差的比例分布。

图6趋势预测效果图

可以看出，pv预测值和实际值小于1000的比例约为73%，小于1500的比例约为96%。按1000次曝光(PV量)计算，广告计量单位为1CPM，误差在1.5CPM以内占96%。

然而，基于机器学习的趋势预测不能支持精度要求高的指标，如基于点击率的广告互动数指标。

动态阈值

系统报警常与监控结合，是指对某个指标触发某个设定阈值后，向相关人员发送消息提醒。目前大多数做法是固定门槛，根据经验来定。其优点是简单直接，可操作性强。其缺点是经验值不准确，设置GAP过小，增加报警，增加误报率，GAP设置过大，导致误报。另外，很多数据指标是周期性波动的，很难通过经验或者手工设定合适的GAP。

为此，我们在趋势预测的基础上增加了动态阈值。比如报警条件在趋势预测曲线上下10%，可以根据业务进行调整。

服务全景-二维

假设监控平台只需要一个或两个视图就可以清晰地显示服务监控状态，并对所有需求和指标进行优先级排序，则可以提取两个关键维度，即机器维度和服务维度。

机器尺寸

在这种观点下，我们的核心是明确确定所有机器的基本状态，可以简化为健康、亚健康、发病。健康状态表示机器资源使用情况(cpu、内存、网络输入输出、带宽、负载等)。)都是正常的，以后也可能是正常的(比如7天)，机器用户完全可以不用担心机器的这部分；亚健康状态说明机器资源存在一定风险。比如高峰时期网络IO过高，但仍未达到影响机器正常运行的水平。机器用户需要考虑机器IO或扩展的类型，以应对短期内可能出现的压力；生病是指机器对某个资源的消耗有上限，比如磁盘已满，需要机器用户立即处理。

根据这个需求，我们需要设计这样一个视图，如图7所示:

图7服务全景:机器尺寸

当一台机器出现异常时，可以显示当前机器的异常级别、时间和具体的异常信息。

服务维度

在这个视图中，我们关心的核心问题是业务应用是否正常运行，整个链接是否畅通，是否有异常和告警，有多少节点受到影响。您可以在空下查看所有相关服务的上下游整体运行状况，并显示异常原因和异常节点的监控报告。

同时，结合自动化平台，显示服务之间的上下游关系(拓扑图)，如图8所示。

图8服务全景:服务维度

智能恢复触发器

恢复触发器的作用是当触发报警时，系统进行一定程度的维护工作，如降级或迁移。它的设置目标必须是可扩展的，并且可以支持用户定义的触发器。

目前哈勃系统的设计只是简单的支持重启、重装、停止等标准触发，还有很多路要走。

附笔

监测系统要解决的首要问题是指标覆盖率，这是一个庞大而完整的指标。在此基础上，要做深度培养，提高准确率。最后要简化抽象，发现数据背后最本质的东西。微博广告基础设施团队在监控方面积累了一定的量，并率先在监控方面运用机器学习技术做了一些尝试。未来，它将在智能预测和自动服务处理(降级、恢复等)方面进行更深入的尝试。).

作者简介

董朋·安德鲁(微博@AndrewPD，微信正义版)

新浪微博商业产品部架构师目前负责广告核心引擎基础设施、哈勃系统、D+商业基础数据平台的建设及相关管理工作。专注于计算广告、大数据、人工智能和高可用性系统架构设计。

开放创新，崇尚技术，追求极致创新和开放、技术、极致完美

本文作者董朋，请在转载翻译中注明出处、技术原创和建筑实践。欢迎您通过微信官方账号菜单“联系我们”提交文章。

高可用性架构

改变互联网的构建方式