广告业务监控系统实现

一、背景

进入移动互联网时代，移动端广告投放市场占比越来越重，买量竞争也越来越激烈。为了在竞争中投好广告，我们业务就需要在不同媒体去不断尝试创建广告单元，频繁的广告创建和操作任务大大地增加了我们业务同事的负担。

虽然量子和鲲鹏结合实现了广告批量创建和操作的功能，大大地提高了我们业务同事的效率，但是因为竞价广告跑量不定等特性，我们业务同事还需要花很多精力去盯广告的投放效果来做出对应的调整策略。
我们的广告业务监控系统因此诞生，提供实时监控广告数据并做出响应调整。

二、架构设计

1、模块划分

在考虑实现之前，我们需要先梳理监控涉及的模块，主要会包含监控规则、监控数据、监控校验、监控操作、监控告警等。因为监控也是广告投放环节的一部分，所以整体将监控作为量子的一个模块开发，与之相关联的系统如下。

数据中台：获取监控所需要的数据，可以通过API或者查询DB的方式获取。（监控数据）
鲲鹏：通过鲲鹏API来操作广告，如调整广告预算、出价、ROI、投放时段、投放状态等。（监控操作）
告警平台：通过告警API来通知监控情况，告警方式包括微信、企业微信等。（监控告警）
监控核心：集中在量子系统，拆分为监控规则管理模块和监控实现引擎模块。 

2、监控实现逻辑

承接上文，监控的实现主要依赖监控核心模块：监控规则和监控引擎。

监控规则可视为广告调控策略，由各个业务设定，主要由监控属性、筛选器（数据过滤条件）、校验器（监控判断条件，可采用且或条件组合、二叉树、多条件树结构，我们目前就只取最简单的且或条件组合）、触发器（配置校验通过的操作，如调整广告预算、出价等）。

划分好监控规则，我们就可以梳理出该规则的实现逻辑。

3、如何保证可靠性

上文介绍的监控实现逻辑只是针对单个规则而言，但是实际上我们不会只有一个规则的，而且随着业务使用的频繁，我们规则会约来越多。如果只是单纯的轮询规则，很快会让监控的性能遇到瓶颈，随着规则的增加，监控耗时会越来越大。如果监控的延时过大，对于广告的调控就不够准时，这样监控的意义就不大，所以我们得考虑保证监控的实时性和可靠性。

分析各个环节，为了减少耦合性和方便横向拓展，我们采用异步分布式模式。分生产和消费两个环节，每个监控规则是一个消费任务。因为监控操作和告警涉及到与其他系统进行HTTP请求，为了减少监控耗时，所以也将这两个模块也抽离成异步分布式模块。为了减少烟囱式的开发，异步分布式我们采用数据部自研的天翼框架（配置简单、性能可靠稳定）。

规则消费解决完，还得考虑数据获取的性能优化。
1、监控任务获取数据取用读取缓存（Redis）的方式，从而提高监控任务的处理速率。为了避免出现redis大key现象，缓存数据进行分片存储。
2、既然用到数据缓存，那么数据查询就放在监控任务生产环节，在生产之前先查询好数据并缓存起来。
3、对于一些查询比较复杂的指标，为了减小生产环节的耗时，会有另外的程序去执行（离线指标查询计算程序）。

最终方案如下，在保证实时性的前提下，如果性能遇到瓶颈，就可以通过拓展机器来提高并发性。

性能优化好了，我们还得考虑可靠性和稳定性。
1、监控对数据极为敏感，有问题的数据不仅准确调控广告，还会导致误操作，所以在任务生产环节我们增加了熔断机制（判断数据是否延迟，延迟则告警熔断）。
2、数据异常值校验机制（通过对比前后两次的数据来判断某些指标是否异常，如广告金额突然变少了应视为异常）
3、接入grafana看板，直观化查看情况