微博广告系统全景运维大法( 五 ) _微博

另外一部分是运维比较关心的数据，今天来了多少流量？流量有多少是正常的？有多少是异常的？平均耗时是多少？针对这一部分，我们采取了实时数据计算的方法。
在数据采集阶段发生了变化，我们并不采集全量日志，而是在客户端做了预处理，进行分类计算。
比如说监控数据，就按监控数据的方法计算；告警数据，就按告警数据的计算。而且按照用户读取的需求进行分类存储，保证了高并发数据的实时性。
海量指标监控系统流程
接下来详细介绍实时数据计算。
首先从数据采集上讲，上文提到我们不采取全量的采集方式，而是通过 Agent 对数据进行处理。
在数据采集阶段，在数据产生的服务器上，针对不同的需求按不同的时间进行分类聚合，最终向后推送的数据是 key-value、计算方法这种模式，推送给 Proxy 。
Proxy 拿到已经被打包的数据进行拆包，然后送给不同的计算结点，再按照 Key 进行计算，打时间戳。
这个数据并不精准，但我们可以接受部分损失，只需要保证数据的趋势是正确的。
另外，关于分类计算，不同的需求推送给不同的计算节点。存储也进行了分类，实时性要求比较强的话会直接放到内存，以最精细粒度进行存储。
前三个小时的数据是按秒存的，按天计算的数据是按 10 秒、30 秒存的，一些单机数据是按分钟存的。
另外一些历史性的数据需要出报表的，比如说要看前一周的数据，前一个月的数据，按照大数据的方式存到 OpenTSDB 当中。
存储的数据提供一个 API ，通过 API 我们进行了分类计算、分类存储，这种分类的需求来源于用户，需要看用户有什么要求，要什么样的数据。
比如， Dashboard 的展示数据会直接被放到内存里。另外，上文提到的在线扩缩容数据，会相应获取数据给用户，其他相关的获取需求 API 也会进行分类获取。
接下来我们计算过的数据还有一部分会存储到 redis 通过 WatchD 作为告警中心的数据，因为告警数据一般都只要求当前数据，不会有人需要查看上个月这台机器的负载有没有告警。
所以 Alert 节点计算之后的数据直接存在 Redis ， Redis 把这个数据拿出来之后经过告警中心根据告警规则进行清洗，通过各种方式推送到需求方。
同时有一个相对个性化的展示叫九宫格。我们的九宫格实际上是一个结合报警功能的监控，它是一个页面，但具备了告警功能。